Learning project · September 2026 to present
HoldOff
Product Manager and Product Builder · Consumer health: smoking reduction
HoldOff is a phone-first smoking reduction app for smokers who want to cut down. I am building it as a learning project and MVP, to practise every part of product management end to end with new tools, systems and ways of building. It is built entirely with Claude Code.
Open holdoff.vercel.appIn brief
The first release was a quick, low-cost check, built from a spec in under two days and put in front of 18 testers to learn whether they could engage with the logging engine and whether it addressed their problem. It was never meant as a designed product.
Testers reported text-heavy screens, unclear actions and overlapping questions, and ~92% of entries in an early export were incomplete. Both findings pointed to the question model.
The second release, five days later, was the first meant to be used as a product, so I designed it before building it. Research into what predicts smoking shaped the rebuilt data model, and research into interface design shaped the design system, 44 light and dark screen mockups and a clickable prototype that testers reviewed before the build.
The second release carries 214 logic and file checks and 265 interface tests, and its validation with the same 18 testers closed with no fix release needed.
The problem
HoldOff logs each time a user smokes against the hours they are actually awake, then turns the log into goals, live guidance and patterns that help them cut down. It installs on the home screen and works offline. All data stays on the phone. There is no account, no server and no data sent anywhere after the app loads, and the app contains no third-party code, trackers or analytics.
The first release was a quick validation of the logging engine with 18 testers. They reported text-heavy screens with no visual hierarchy, unclear actions, and detail questions that overlapped, so several true answers could not all be recorded. An early export matched the feedback, with ~92% of entries incomplete, and both traced to the question model.
What I did, release by release
Four research reports, each on one subject
- The evidence on what predicts smoking, which set the data model.
- Interface and visual design, which set the second release’s design.
- The psychology of smoking and cessation.
- The use of AI in smoking cessation and in cessation-plan design.
The first two shaped the second release. The last two shape the AI features now in design.
A quick, low-cost validation of the logging engine
I took a spec to a tested, deployed app in under two days and released it the same day to 18 regular smokers recruited as testers. It was a deliberately quick, low-cost check of whether they could engage with the logging engine and whether it addressed their problem, and it was never meant as a designed product. The same 18 testers stayed on for the second release.
Designed before the build, with a rebuilt data model
Five days after the first release, the second was the first meant to be used as a product, so I designed every screen before the build and rebuilt the data model from the research.
- Logging
- One tap logs an entry with its time and its place in the waking day. Four quick questions follow, one per card, and any can be skipped by closing the sheet. Optional questions sit behind a separate link.
- Questions built from evidence
- Each question earns its place from the research. Urge strength was the single strongest predictor; triggers, others smoking nearby, and coffee, food and alcohol followed. Where the two research reports disagreed, I settled the conflict on the record. One report wanted the previous context pre-filled silently and the other said never to preselect answers, so a one-tap “Same as last time” card settled it and stale context is never carried forward unnoticed.
- Rules for the questions
- Each question answers one distinct thing, each option points to a different action, nothing recorded automatically is asked, and no question has more than six options, so the options fit a phone screen as thumb-sized tiles.
- Metrics that point to an action
- Hold-off time after waking is the headline. Craving-driven against autopilot smoking, shown as counts of the day’s total, tells a user whether the fight is with cravings or with routine. The clinical Heaviness of Smoking Index appears as a weekly trend and never as a label, and hold-off is measured against clinical bands.
- Tone
- A warm and honest coach. Real wins are named specifically, setbacks get empathy and a next step, and nothing is shamed or faked. There is no confetti, no badges and no streaks that reset. The model is Jürgen Klopp’s way with players. The research supports it, since rising confidence predicts quit attempts, and shame and a drop in confidence after a slip predict relapse.
- Scope
- Behaviour-change mechanics, resisted-urge logging and a structured reduction plan were held back to a later release, so that the effect of each change could be attributed. To save time, no compatibility with earlier data is kept during the MVP releases; it begins with a production product.
- Privacy and security
- A strict security policy, nothing sent over the network after loading, damaged or wrong import files refused with the data unchanged, and a rule for any third-party asset: secure, free to use, legal, needing no disclosure to users, and respecting privacy.
Testing the second release with the test group
I planned validation around testers’ exports and answers. Testers gave feedback instead, so I moved the method to collated tester feedback as the input. Every completed day in the exported data reviewed carried both its start and end markers. Validation closed with no fix release needed, and four findings carry forward to the next release:
- The progress ring’s colours read as go and no-go, and the day-start and day-end keys were tapped by accident.
- Half logging was unused across the test group (0%), so it is being removed.
- History should show the last seven days, with each past day marked as met or missed.
- Charts need axes and counts, so they can be read at a glance.
How it is built and tested
- AI build workflow
- A defined workflow on Claude Code with 16 roles, each with its own instructions, covering spec, design, build, independent testing and a logger that records every decision with its reasoning. The independent tester runs from a second account and writes its own tests using only the spec.
- Decision rights
- I make the product decisions, and the builder lists its own choices for my sign-off. Conflicts between sources follow a fixed rule: the spec decides behaviour and wording, the mockups decide layout, and the design system decides visual tokens.
- Documentation
- Product requirements, app flow, spec, data model, architecture, security, testing, deployment, items carried forward to the next release, and an index of all of them.
- Design
- A design system (colours, type, components, motion, voice, 68 icons, app icon and wordmark), 44 screen mockups in light and dark, and a clickable prototype of the logging flow that testers reviewed before the build.
- Technology
- Plain JavaScript with no framework, an offline-first app stored on the phone, deployed on Vercel. It supports iPhone and Android.
The second release carries 214 logic and file checks and 265 interface tests, run in both the Chrome and iPhone browser engines. Separately, the independent tester wrote 112 tests of its own (75 logic tests run in three time zones and 37 interface tests) and made 9 fixes before release. One fix addressed a refused save that left an entry on screen although it had never been stored.
Every difference between the spec, the design and the built app is recorded. The second release had 71: 4 decisions I made during the build, 14 settled by the rule above, 33 builder choices and 20 changes after the independent review. 11 known behaviours were accepted for release.
AI in the product
- Shipped
- “Copy for Claude” copies the user’s own data, with a ready-made analysis prompt, for pasting into a Claude chat. There is no API call, so nothing leaves the phone unless the user chooses.
- Researched and in design
- AI features that draw on each user’s real-time usage to choose the right nudge, the right tool and the right encouragement, and to help manage cravings, in the voice of the warm, honest coach. This work runs in parallel with the core MVP and has not shipped.
Results
- <2 days
Spec to a tested, deployed first release (28 to 29 September 2026), released to 18 testers the same day.
- ~92%
Share of entries incomplete in an early export of the first release, which matched tester feedback.
- 5 days
From the first release to the second, which was designed before the build and rebuilt the data model.
- 214
Logic and file checks in the second release’s build.
- 265
Interface tests in the second release’s build, run in the Chrome and iPhone browser engines.
- 112
Tests written by an independent tester using only the spec. The same tester made 9 fixes before release.
- 0%
Use of half logging across the test group during validation of the second release.
- 18
Regular smokers in the test group, recruited for the first release and kept for the second.
- 21
Days live, counted from the first release on 29 September 2026.
My role and the team
Product Manager and Product Builder on a learning project and MVP. I make the product decisions and direct a 16-role AI build workflow on Claude Code, which covers spec, design, build, independent testing and decision logging. 18 regular smokers test each release.