The problem
Most days just happen. You pick up your phone to check one thing and look up forty minutes later. The usual fix is another app with its own streak and its own scoreboard, and after a few of those you’re managing apps instead of your life.
I wanted the opposite: a few small tools that each do one job well, all writing to one honest record of how your time actually went. Train on Purpose logs workouts. Scroll on Purpose blocks the feed until you’ve earned it. Doorway teaches modern Greek by putting you inside the Odyssey. Telos holds your goals and keeps the books.
Constraints
- One builder. I’m the product owner, designer, engineer and on-call. Every decision had to lower the cost of the next one.
- Works with no signal. Every feature works with no account and no connection. The cloud is a bonus, never a requirement.
- Privacy is the product. No analytics, cookies or trackers. The few pilot events are built on the server, need consent, and expire in 90 days.
- A personal budget. Pay-per-use only: no load balancers, NAT gateways, database servers or always-on anything.
The decisions
One source of truth. Telos is the system of record for goals and rewards. The other apps read and request; they never write balances. Every system has a written table of what it owns and what it never holds, with one writer per record.
Contracts, not hope. The apps share golden test fixtures, copied verbatim into each repo and pinned by a checksum. If one app’s idea of the data drifts, its build fails before a user ever sees it.
Sync that can’t double count. Each change commits locally alongside an outbox entry. The server dedupes by operation ID forever, keeps tombstones so deleted things stay deleted, and credits each goal once per session. Imported history never counts toward goals, so nobody can backfill their way to a reward.
Ship dark, roll back cleanly. Every new capability ships off and turns on per account. Rolling back means switching it off, and no rollback loses data.
Infrastructure that releases on its own. The AWS stacks live in their own CDK repos and deploy separately from app releases. A shared release tool signs all three Android apps without touching their code and scans every build for secrets before it ships.
AI with a ceiling. Doorway uses AI to play the Odyssey’s characters, but scenes follow authored branches that always rejoin the story, every account has daily caps, and an on-device mode works with no service at all.
What happened
Five weeks after the first commit, the public site was live at daysonpurpose.com, and a handful of friends, invited by name, were using the web app and three Android apps in a private preview. An iPhone build is in testing on the same shared engine.
What I’d do differently
I shipped too much at once, and testing is where it showed.
Four apps, three platforms, offline sync and one shared ledger multiply into more combinations than any person can tap through. I tested on my own phone every day and still couldn’t keep up: a fix in one app could quietly change what another one counted. What actually kept the suite honest was more than 600 test files my AI agents wrote alongside the code, plus the shared contract fixtures that fail a build the moment two apps disagree.
That suite was necessary, and it was also a symptom. When the surface area outruns real-life testing, the cheaper fix is less surface area per release. I’d build this the way I’d run a team: one app and its tests, real use, then the next app. Iterative, even when the only stakeholder is me.