Automation
Clean Taggy
Clean Taggy turns the repetitive, error-prone part of preparing manufacturing label and wire-tag data into a structured workflow. It runs from a link, works offline on a single device, and syncs each person's projects to the cloud once they sign in.
01 — The problem
What was actually happening
A quality control team was assembling label and wire-tag data by hand — reading values off drawings and exports, retyping them into spreadsheets, and reconciling versions between people. The work was slow, and every manual transcription was a chance to introduce a defect that would only surface on the floor.
- Tag data was rebuilt by hand for every job, with no shared source of truth between team members.
- Transcription errors were invisible until late in the process, when they are expensive to fix.
- IT constraints ruled out installing desktop software or standing up a server, so most off-the-shelf tools were unusable.
- Anything adopted had to work for non-technical users on their first attempt, with no training session.
02 — The solution
What I built, and why
Instead of fighting the environment, the constraint became the design: the entire application ships as a single HTML file. It can be dropped into SharePoint, published on GitHub Pages, or pinned as a Microsoft Teams tab — no install, no server, no admin approval.
- Structured project workspace that replaces the ad-hoc spreadsheet with a consistent, validated data shape.
- Local-first by default — the app is fully usable before anyone signs in, so adoption never blocks on IT.
- Optional Google or email sign-in adds cloud sync, so each person's projects follow them across devices.
- Firestore security rules scope every read and write to the signed-in user's own document.
- Light and dark themes that follow the operating system, because the tool is used on a shop floor and at a desk.
03 — Process
How the work was sequenced
- 01
Understand the workflow
Sat with the actual process first — what gets read, what gets retyped, where the mistakes happen — before deciding what software could remove.
- 02
Map the constraints
Established the real boundaries early: no installs, no server, corporate SSO, and users who would judge the tool in the first thirty seconds.
- 03
Design for zero friction
Chose a single-file architecture so the app could be shared as a link, and made sign-in optional so the first run needed no setup at all.
- 04
Build
Implemented the workspace, the data model and the theming in vanilla HTML, CSS and JavaScript — no build step, so the file that is tested is the file that ships.
- 05
Add sync
Layered Firebase Authentication and Cloud Firestore on top of the working local app, with rules that isolate each user's data.
- 06
Deploy and iterate
Documented three deployment routes (GitHub Pages, SharePoint, Teams tab) so the team could pick whichever their IT policy allowed, then refined against real use.
04 — Technology
The stack, as decisions
Application
Identity & data
Delivery
05 — Results
What it changed
1 file
The entire application — no build step, no dependencies to break
0 installs
Deployed as a link, inside a locked-down corporate environment
Per-user sync
Projects follow each person across devices once signed in
The hardest constraint turned out to be organisational, not technical. Designing around what IT would actually approve — rather than what would be technically ideal — is what got the tool into daily use. It also proved how far a disciplined single-file architecture can go before it needs a framework.
Have a problem worth solving?
Tell me what the process looks like today and where it breaks. If technology is the right answer, I will tell you what I would build — and if it is not, I will tell you that too.