AppliHelm is a career profile tool I'm building solo, with an AI doing a lot of the pairing, build your profile once, export it as AI-ready context for any AI tool, generate a career narrative from it. This isn't about the product though, it's about the process behind it.
Before AppliHelm, I'd already built a handful of other projects, and every one of them taught me something about the last one's process that I didn't want to relearn the hard way twice. So before I wrote a line of AppliHelm, I wrote down an SOP: how discovery should work, how a PRD (a document describing exactly what's getting built, before anyone builds it) gets frozen, how a build actually gets sequenced and shipped. Then I fed that SOP into the AI I've been pairing with and started building AppliHelm from it, not from scratch.
The SOP didn't stay static. As I built, I grew it: a Capability Map here, a per-flow PRD split there, a "cross-cutting gate table" that got added specifically because AppliHelm's launch had blockers that didn't belong to any one flow. Refinement, not invention, each addition earned its place by solving a real problem I hit mid-build.
Then, a while back, reviewing the AppliHelm docs and the process itself, I paused and got curious: exactly which named ideas does each piece of this correspond to in the actual literature, not just in my own reasoning? Here's the mapping, with a real bug from this week as the running example.
Why write an SOP at all
The SOP itself isn't a solo invention either. Every part of it started the same way: research how it's actually done in the industry, and why, then hold that up against how I'd genuinely been doing it on past projects, until I land on something that doesn't ignore industry standard but also doesn't import it wholesale without checking it fits my reality. That's the honest reason the mapping in this article works as cleanly as it does. The SOP was never "my own thing" pretending to be standard practice, it grew out of standard practice from day one.
Three reasons I bothered writing it down instead of carrying the judgment project to project in my head:
You can't improve what you don't track. If a process only exists as instinct, there's nothing to look at and ask whether a given step is actually working, it just repeats, good or bad, forever.
Consistent quality across products. A written process is what makes the fifth project as solid as the first, instead of quality depending on how much attention I happened to be paying that particular week.
Delegation. A process is what makes delegating safe. Hand someone a task with no defined process behind it and you get their judgment, which might be great or might not be. Hand them a task inside a process and you get the process's quality, repeatably, regardless of who's executing it.
The scope-freeze problem
Before any of this, there's a simpler question: how do you stop scope from sliding while you build? My answer was a running "Capability Map," a big list of everything AppliHelm could plausibly do, that never freezes, plus a "Version PRD" that picks a subset of it and does freeze.
This is Dual-Track Agile. Marty Cagan (Silicon Valley Product Group) and Teresa Torres ("Continuous Discovery Habits") both write about it: a discovery track that runs continuously and a delivery track that consumes frozen, committed slices of it. The map keeps growing forever. The PRD is a snapshot you commit to.
Amazon's "Working Backwards" process is the same idea at a different altitude: write the press release and FAQ before you build anything, so scope gets frozen against a concrete artifact instead of vibes and Slack messages. My PRD does the same job at a much smaller scale.
The part that matters practically: once a PRD is frozen, I stop negotiating with it mid-build. If a good idea shows up while I'm building, it goes back into the Capability Map, not into the current PRD. That discipline is the entire point. Without it, "discovery" and "delivery" collapse into one undifferentiated stream of scope creep.
Build it fully, hide the excess
A recurring decision on this project: build a feature completely, then gate it behind a role check instead of shipping a half version or deleting it. CV Builder and Role Recommendations are both fully built in AppliHelm right now and completely invisible to a default user, because they didn't make the v1 cut but the code was already good.
This is feature flagging, specifically what Martin Fowler calls a "release toggle" in his writing on Feature Toggles, distinct from an experiment toggle (A/B testing) or an ops toggle (circuit breaker). The practical payoff: nothing gets rebuilt later. When v1.1 decides CV Builder is in scope, I flip a gate, not rewrite a feature.
One PRD per flow, not one PRD to rule them all
Early on I had one big release PRD trying to describe onboarding, profile, subscriptions, and admin all at once. It became unreadable. So I split it: one PRD per user-facing flow, each independently readable, each with its own build-state table.
This is vertical slicing, standard agile decomposition advice going back to writers like Alistair Cockburn and Henrik Kniberg. Slice by user-facing capability, not by technical layer, so each slice is independently reviewable and shippable. My "per-flow PRD" split is exactly that, just applied to documentation instead of tickets.
The gate table, and the bug it just caught
Some things block launch no matter which flow they live in. Legal review. Payment processing actually being live. Row-level security actually being enforced. I keep these in one table, separate from the per-flow PRDs, with a priority: P0 blocks launch, P1 is a fast-follow.
This is a Launch Readiness Review, LRR, a documented practice at companies like Google (it shows up in the Google SRE book's launch-checklist material): a cross-cutting checklist independent of any single feature team, covering security, legal, monitoring, on-call readiness, whatever would block a public launch regardless of which team owns which feature.
Here's where it got real. I had this gate table in one Notion page, positioned as "the authority." But I also had the same handful of facts, RLS audit status, Paystack live-key status, legal review status, restated with full detail across two other Notion pages and two files the AI I pair with keeps as its own running notes between sessions. Six places, one set of facts. Then I found a live staleness bug because of it: the "authoritative" page still said "Paystack is on a test key, swap at deploy" a week after the swap had already happened in production. The actually-current status was sitting correctly in a different page nobody had told was supposed to be secondary.
This is a named anti-pattern in technical writing circles, sometimes called docs drift, and it's the specific failure single-source-of-truth documentation is supposed to prevent. The fix isn't "write more carefully." It's structural: pick one page that owns each fact, and make every other reference a link, not a copy. Architecture Decision Records (Michael Nygard's original ADR pattern) solve the same problem for technical decisions specifically, an ADR is immutable once written, so a changed decision gets a new ADR that supersedes the old one instead of an edit war nobody remembers happened.
I went back and fixed all six places the same afternoon I found the bug. The fix took twenty minutes. Finding the bug took a week, because nobody was looking at the six places side by side until I asked "how many places is this actually tracked" out loud.
Sequencing the build itself
Last piece: what order do you build the flows in. My build sequence is ordered so each numbered item mentions which earlier flows it touches, so I'm never building against a foundation that might still shift.
This is dependency-ordered backlog sequencing, related to Alistair Cockburn's "walking skeleton" idea: build the thinnest possible end-to-end path first, then thicken it flow by flow, so each step proves the previous one's foundation actually holds instead of building everything in isolation and discovering the seams don't fit at integration time.
The actual takeaway
None of this required a team. It required knowing the shape of the problems in advance, so when they showed up solo, I recognized them instead of reinventing worse versions from scratch. Dual-Track Agile, feature flags, LRRs, and single-source-of-truth docs weren't built for teams of fifty. They're built for the problems that show up whenever software gets built for real users, and those problems don't care how many people are on the team.
If you're building solo, or solo-plus-AI, the process isn't optional overhead you get to skip because it's just you. It's the same discipline, compressed. The compression is fine. Skipping it isn't, I found that out the slow way, in a Notion page that was quietly wrong for a week.
And it isn't only insurance against my own memory. The day AppliHelm stops being solo, this SOP is what lets someone else step in and produce the same quality I would have, without needing to inherit my judgment first. That was the point of writing it down before knowing whether I'd ever hand any of it off.
If you want to see what this process actually produces, not just how it works: try AppliHelm. Free to start.
