ApprenticeLog
A logbook app built for New Zealand trade apprentices. Record what you did out loud, and it becomes a structured entry in the format BCITO expects. Works offline, because job sites do not have signal.
- Role
- Sole designer and engineer. Product definition, interface, and build.
- Stack
- Next.js, TypeScript, Voice to text, Offline first, PWA
- Source
- Jonta254/apprentice-log
A closer look
The problem
New Zealand trade apprentices have to keep a logbook for BCITO, and the logging is universally disliked. It happens at the end of a long day, from memory, in a format that fights the person filling it in. The work itself is done well. The record of it is done badly, late, or not at all, and a thin logbook can hold up qualification.
The objective
Make the record as easy to produce as the work is hard. An apprentice should be able to log a day in under a minute, in a form BCITO accepts as it stands, without a desk, a signal, or a second attempt.
Research
The research was observation rather than a survey. I looked at how the log actually gets kept: hands full through the day, memory fading by evening, and an official format written for the assessor rather than the apprentice. The existing options were generic note apps that produce nothing submittable, or the paper process the app is meant to replace. The gap was a tool shaped like the job.
Design decisions
One button, because hands are busy
The core interaction is a single record button. You say what you did and it becomes a structured entry. Typing on a phone with dusty hands at the end of a shift is the failure case the whole interface is designed around, so the happy path avoids the keyboard entirely.
Compliant by construction
Entries map to the BCITO structure directly, so the output is something an apprentice can submit as it stands rather than raw text they still have to reformat. The compliance is the product, not a feature bolted on beside it.
Engineering decisions
Offline as the default, not a fallback
Everything works with no connection and syncs when one returns. A tool that needs a bar of signal on a construction site is a tool that gets abandoned in the first week, so local first storage came before anything that talked to a server.
Installable, so it lives on the home screen
Built as a progressive web app so it installs like a native app without an app store gate, launches straight to the record screen, and updates itself. The lowest friction between wanting to log and having logged.
Challenges and tradeoffs
The honest constraint is compliance I do not own. BCITO can change its format, and the product has to track that or it stops being useful the day it drifts. I traded a faster first release for an entry structure kept in one place, so a format change is an edit rather than a rebuild. The other trade was scope: voice capture that is genuinely reliable mattered more than a wide feature list, so the feature list stayed short on purpose.
It worked the moment the compliance format stopped being a feature and became the product itself. After that, every other decision got simpler.
The solution
A voice to logbook app, free for NZ apprentices, spanning construction, carpentry, electrical, plumbing and automotive. Record a day out loud, review the structured entry, and keep a running log that works with no signal and installs to the home screen.
- Next.js
- TypeScript
- Voice to text
- Offline first
- PWA
Results
Live and open to anyone, running as a real deployment you can put through a day. The full loop, from a spoken note to a structured entry, runs in the browser right now. I am not going to claim adoption numbers I cannot show you. Open it and try it for yourself.
Lessons learned
The build was the easy part. The lasting lesson was to design around the constraint I do not control from the very start. Keeping the compliance format editable without a redeploy should have been the first decision, not a correction. I learned that the slightly harder way, and it changed how I scope anything that depends on someone else's rules.