There’s a story I hear from nearly every business owner.
It goes something like this: “We’ve been running this process for fifteen years. We know exactly what works, exactly where it breaks, and exactly what we’d change if we could. But the software doesn’t do that. And the last time we asked, someone quoted us six figures and nine months.”
So they don’t change it. They build workarounds. They maintain spreadsheets that have become load-bearing infrastructure. They hire people to bridge the gap between what the software does and what the business actually needs. Every year, the gap gets wider. The workaround gets more fragile.
I know this story because I’ve lived on both sides. I spent years inside the consulting machine — rooms where we’d map processes onto whiteboards, translate them into requirements documents, send them to development teams, wait months for a build, and watch the business outgrow it before it launched. A factory for producing expensive approximations of what someone needed six months ago.
That era is over. Not ending — over.
The economics of building have fundamentally changed.
The numbers that matter: GitHub reports that 46% of all code written by Copilot users is now AI-generated. In a controlled study, developers using AI assistants completed tasks 55.8% faster. Y Combinator’s Winter 2025 batch — some of the most technically capable founders in the world — had 25% of startups with codebases that were 95% AI-generated. Their CEO said it plainly: “Ten engineers are delivering what used to take fifty to a hundred.”
In practical terms: a startup called Atonom was paying 1,200. Not a stripped-down version. The version they actually needed.
This pattern is repeating everywhere. Klarna — a 40 million annually.
These are large companies. But the shift is even more dramatic for small and mid-sized businesses. The average company with 50 employees spends over $200,000 a year on SaaS subscriptions. Most of that covers features nobody uses.
You don’t need to code. You need to specify.
There’s a concept gaining traction called spec-driven development. Thoughtworks defined it as a paradigm where “well-crafted software requirement specifications serve as prompts, aided by AI coding agents, to generate executable code.” GitHub’s internal research puts it more directly: “The specification becomes the primary artifact — the shared source of truth. Code is the last mile.”
What that means for someone running a business: the most valuable thing you bring isn’t technical knowledge. It’s domain knowledge. You know your processes. You know where things break. You know what “good” looks like because you’ve been doing the work for years, sometimes decades.
That knowledge — the kind that lives in your head, in your team’s muscle memory, in the workarounds you’ve built — that’s the specification. The gap between “I know exactly what this should do” and “I have working software that does it” has collapsed from months to days. Sometimes hours.
Red Hat’s technical team described it this way: “Humans craft the ‘what’ while setting ‘how’ guardrails.” You write the specification in plain language. The AI generates the code. You review, adjust, iterate. No six-month procurement process. No 47-slide deck to justify the budget. No consultant who arrives on Monday, turns everything upside down, and leaves you poorer and more confused by Friday.
The consultant trap — and the way out.
Let me say something uncomfortable for someone in my line of work: 70% of digital transformation projects fail to meet their goals. That’s McKinsey’s number. Bain puts it higher: 88% don’t achieve their original ambitions. Globally, an estimated $2.3 trillion has been wasted on unsuccessful digital transformation programmes.
The typical pattern: a large consultancy arrives, runs discovery workshops, produces a beautiful strategy document, recommends enterprise tools, oversees a multi-year implementation, and moves on. The organisation is left with a system that sort of does what was promised, takes years to see ROI, and is already behind by the time it launches.
SAP implementations for enterprises routinely cost 20 million or more. Fifty-five percent exceed their budgets. These aren’t edge cases. This is the system working as designed — designed for the vendor, not for you.
The alternative isn’t to go without systems. It’s to build exactly what you need, with the specificity that only you can provide, at a cost and timeline that would have seemed fictional three years ago.
Fewer tools, connected the right way.
The average organisation now uses 112 SaaS applications. Seven new ones enter the environment every month. Eighty-four percent of that spending sits outside IT’s oversight. Companies aren’t choosing these tools strategically — they’re accumulating them reactively, solving yesterday’s problem with tomorrow’s subscription.
The philosophy we work from is deliberate simplicity. Not fewer tools for the sake of minimalism — the right tools, connected intentionally, serving the processes you’ve already proven work. When a tool doesn’t exist for your specific need, you build it — quickly, cheaply, precisely. When an existing tool does the job, you keep it. The goal is never “transformation.” The goal is getting your time back.
Because here’s what I’ve learned after twelve years: the person who knows the business best should direct what gets built. Not a consultant who arrived on Monday. Not a vendor whose roadmap has nothing to do with your reality. You. The people who built these processes — you are the specification.
The economics have finally caught up. Software that works the way your business actually works. Built in days, not quarters. Costing thousands, not millions. Owned by you, not licensed to you.
Your time is sacred. Everything we build starts from that principle.
MAKE YOUR CASE.