"No specs" reads as a red flag until the method is on the page. Here it is: five steps, in the order they happen, each paired with the line item it removes from a buyer's bill.
Domain experts make a consistent mistake: they translate their manual process directly into software. "Automate my spreadsheet." This overconstrains the problem because humans and software think in fundamentally different categories.
Stakeholders describe what they're thinking. No brief. No "how should the software work" — because they don't know, and asking forces premature decisions.
Removes: the written brief, and the misreading that follows when one is forced.
Instead of extracting requirements through questions, build a working prototype that embodies the idea. Show it. The prototype becomes the conversation — stakeholders react to concrete software, not abstract specs. The building is the requirements process.
Removes: the discovery phase, and the months it takes to produce a document nobody can react to.
Each cycle reveals what actually matters. Features stakeholders thought were critical often turn out to be later work. More important things emerge that couldn't have been articulated upfront.
Removes: the mis-prioritised feature, and the cost of building it before the real priority surfaced.
Beneath 457 different job boards, or 5 different CRMs, or every executive assistant's unique habits, there is always a universal shape. Find it, abstract it, build around it — that is what makes the system scalable rather than bespoke.
Removes: the bespoke one-off, and the maintenance bill that comes with it.
Full stack: architecture, implementation, infrastructure, deployment. Bare-metal Docker on commodity servers. No DevOps dependency.
Removes: the DevOps team, and the cloud bill and handoffs that come with it.
Five method steps, in order: start with direction, not requirements; build to think; iterate to surface the real priorities; find the invariant pattern; ship production-grade, solo.