Your Next App is Built for an Audience of One

Updated July 2026 with the numbers, and with what happened after publication: usage curves, audit findings, and the one tool that refused to die.

A healthcare client asked me to create a lengthy document with manuals for various departments. The kind of thing that takes a full day to write and lives in a dusty SharePoint folder forever. Instead, I vibe-coded a website with an AI chatbot and OAuth login in roughly two hours. The employees actually used it. They asked questions, got answers, and never scrolled through 200 pages looking for "that one procedure".

Then came the part I did not predict. After a couple of months, usage dropped. Not because the portal failed, but because people had internalised the tools it explained. They no longer needed the manual, in any form. The portal completed its job and made itself unnecessary.

That outcome would be a catastrophe for a six-month IT project. At two hours of build time, it is a bargain: a couple of months of real utility for the cost of a long meeting. This is what disposable software looks like when you stop theorising about it and actually live it. The economics of building change what "success" means: a tool that dies because its users outgrew it is a tool that worked.

Receipts from three more builds

Because "I vibe-coded a few tools" is exactly the kind of sentence anyone can write, here is what each one actually was.

A pitch competition platform. For The Most Innovative Session, a pitch competition I co-organised at a major European health conference in January 2026, I built the platform in four to five hours in total: public application form, submission handling, terms, and a jury workflow. It processed 70+ applications, from which we selected five finalists for 120-second pitches on stage. And the honest detail: on the day itself, the jury scored on a one-page paper scoresheet. The platform earned its keep where the pain was (collecting and structuring 70+ submissions); nobody needed a login screen between four judges and five pitches. Build the part that hurts. Keep paper where paper wins.

A partnership roulette. Innovation Ecosystem Roulette spins your company against a database of 100+ hand-profiled organisations across health, wellness and longevity, and generates a deliberately over-the-top collaboration proposal. It started in August 2025 as a pure learning project. Eleven months later it is still running, and still deliberately stateless: no accounts, no saved history. When I wanted a conversion mechanism, I added an emailed report instead of building a login system. At an audience-of-one scale (mine), features have to be earned by usage, and refusing complexity is a feature.

An events calendar that refused to die. What began as "I need a list of longevity conferences" is now a living database of 468 events with 5,107 speakers and 2,165 sponsors, maintained by automated weekly quality checks. This is the counterweight to the disposable-portal story: some throwaway tools turn out to have a real audience, and the moment one does, it stops being disposable. Then it needs what any production system needs: quality gates, backups, audits. The skill is telling the two kinds apart early.

N equals one, six months of version history later

When I first published this piece, my PersonalOS (a personal operating system built on Claude Code skills) ran 28 skills. By mid-2026 it had grown to 82, and a monthly audit pruned it back to 76: 50 vault skills, 19 global skills, 7 commands.

That audit is the part worth copying. A deterministic script counts which skills were actually invoked across 90 days of session transcripts; skills that earn their keep stay, dead weight gets archived. The June audit also caught something less comfortable: one skill with write access to a production database had been left explicitly un-gated. Found by the audit, fixed the same day.

I mention the failure deliberately. A personal system is not a pile of prompts. It is software, with everything that implies: version discipline, usage data, security review, pruning. The only difference from enterprise software is that the entire user base is one person, which means the feedback loop is honest and immediate. As with everything in this field, the quality of outputs depends on the quality of context you put in.

Now imagine this for health

The health chapter of this story is not hypothetical either. I built an agent for patients who need to follow a medical ketogenic diet: a treatment with strict fat-to-carbohydrate-plus-protein ratios where getting a meal wrong is not a matter of taste. Its knowledge base was built exclusively on validated information from a university hospital. It helps patients choose recipes and plan meals inside those ratios, working around ingredient dislikes and allergies that would otherwise require tedious recalculation by hand.

Notice what made it work. Not a bigger model; a smaller world. A general chatbot with the whole internet behind it is exactly what you do not want steering a medical diet. The value was curation (hospital-validated knowledge only) plus personal constraints (this patient's preferences, this treatment's ratios). That is N=1 health tech: not a diagnosis machine, a constraint solver for one person's treatment.

Traditional Health App	Personal Health Skills
Built for millions	Built for you
Generic recommendations	Contextual, evolving
Vendor-controlled updates	You control the versions
Data locked in silos	Data flows between your agents
You adapt to the app	The app adapts to you

And here is the claim I made in January, now with evidence behind it: we will need more health professionals, not fewer. Through 2026 I have been running a 13-session AI acceleration programme inside a healthcare organisation. Mid-programme, non-technical staff build working mini-apps in a single afternoon hackathon. Coding is visibly no longer the scarce skill. The scarce skills are choosing the right pain point, keeping data in the right classification tier, quality-controlling what the machine produces, and knowing when a prototype must remain a prototype. Those are human, professional judgements, and the demand for them grows with every tool built. The more personal our technology becomes, the more we need human guides to help us use it well.

Next experiment

Identify one repetitive health-related decision you make weekly: meal planning, workout selection, supplement timing. Spend two hours configuring a simple AI assistant to help you make that decision. Document what context it needed before it became useful, and check back in a month: is it still alive, did it die because you outgrew it, or is it quietly turning into infrastructure? All three outcomes teach you something. That is your first step into N=1 health tech.

💥 May this inspire you to build for an audience of one, and to count the hours when you do.