The Growth Project
Custom Dev Tooling: From Out of Reach to Non-Negotiable
A tool that used to need a team and a quarter now takes an afternoon.
That’s not a productivity tip. That’s the build-vs-buy calculus flipping on its head.
The Calculus That Defined the Last Decade
For fifteen years, the answer to “should we build this ourselves?” was almost always no.
And it was the right answer.
Building a small internal tool meant pulling an engineer off revenue work. It meant a spec, a sprint, a code review, a deploy, and then the part nobody budgets for: owning it forever. A bespoke tool was a liability with a maintenance bill attached.
So you bought instead. You found the SaaS product that covered eighty percent of what you needed, signed the contract, and absorbed the other twenty percent as “how we do things now.”
That twenty percent is where the cost lives. You never see the invoice for it. It shows up as the extra step in every workflow. The export-reimport dance between two tools that don’t talk. The status field that doesn’t match how your team actually works, so everyone keeps the real status in their head. The report you rebuild by hand every Monday because the dashboard shows nine metrics and you need one.
None of it is fatal. All of it is permanent. You paid for the contortion in a currency that never appears on a P&L: friction, compounding, forever.
The math made sense because building was genuinely expensive. The math was correct.
The math is no longer correct.
What Changed
The cost of a small, sharp tool fell off a cliff.
Not the cost of a platform. Not the cost of the thing you’d sell. The cost of the internal rail that does one specific job for your specific team. The script that turns a two-hour Tuesday ritual into a button. The view that shows your data the way your people actually think about it. The glue between two systems that were never meant to meet.
That category used to start at a team-quarter. It now starts at an afternoon.
When the build cost was high, buying-and-contorting won every time. When the build cost approaches zero, the entire equation inverts. You’re no longer weighing a quarter of engineering against a subscription. You’re weighing one day against a friction tax you’ll pay every working day until you quit the tool.
We’ve felt this directly. We build our own software, and the internal rails we now stand up in an afternoon would have been a planning meeting, a backlog ticket, and a “maybe next quarter” two years ago. The line moved. Most teams haven’t repriced.
This isn’t the AI-will-replace-engineers story. It’s narrower and more useful. The expensive part of small tooling was never the hard thinking. It was the grind: scaffolding, plumbing, the tenth CRUD form (the rote add-edit-delete screens every tool needs), the integration boilerplate. That grind is what collapsed. The judgement about what to build, and whether it’s worth owning, is still entirely yours.
The New Default Is the Expensive One
Here’s the trap, and it’s the same trap as always, just with the prices swapped.
Every individual decision to not build still looks reasonable. You have a workflow problem. A SaaS tool solves eighty percent of it. The other twenty percent is annoying but survivable. So you absorb it. Ship it. Move on.
That was the correct instinct for a decade. It is now backwards.
| What Buying-and-Contorting Looks Like | What It Costs Now |
|---|---|
| ”It covers most of what we need” | A daily friction tax on the missing 20% |
| “We’ll just adapt our process” | Your process now serves the tool, not the work |
| ”Building it isn’t worth an engineer” | The build is an afternoon; the workaround is forever |
| ”One more integration to wire up” | Brittle export-reimport rituals nobody owns |
| ”The dashboard is close enough” | Someone rebuilds the real report by hand, weekly |
Read that right column as a recurring charge, because that’s what it is. The workaround you accept today bills you every week for years. The afternoon you didn’t spend was a one-time cost you talked yourself out of.
When not-building was cheap to maintain and building was expensive, defaulting to buy was discipline. Now defaulting to buy is how you accumulate a friction debt that never gets refinanced.
Build Small and Sharp, Not Big and Generic
The reflex, once people accept this, is to overreach. If building is cheap, build everything. Replace the CRM. Replace the whole stack. Build a platform.
Don’t. That’s the addition trap wearing a new hat, and we’ve written before about why adding fails. The win isn’t building big systems cheaply. It’s building small, sharp ones that fit your process exactly.
A sharp tool does one thing, for your team, the way your team works. It has no roadmap, no settings page, no second user persona to accommodate. It’s a chisel, not a Swiss Army knife. Because it’s small, it’s cheap to build, cheap to understand, and cheap to throw away when the process changes.
That last part matters more than it sounds. SaaS makes you marry the tool. A sharp internal tool is disposable by design. When the workflow shifts, you don’t file a feature request and wait two quarters. You rebuild the chisel in another afternoon. The tool bends to the process, every time, instead of the process bending to the tool.
This is the actual divide opening up between teams right now. It isn’t who has the best AI. Most teams have access to the same models. The divide is who points that capability at their own friction.
The teams pulling ahead audit their process for the daily papercuts, then build the exact rail that removes each one. Small tools, sharp edges, owned outright. Their software fits them like a tailored suit because they cut it themselves.
Everyone else is still wearing off-the-rack and calling the tailoring “best practice.”
The Catch Nobody Mentions
This is not free, and pretending it is will get you a different mess.
A sharp tool you stand up in an afternoon still has to be one you can trust on Monday. Cheap to build is not the same as safe to run. That gap is the difference between vibe coding and vibe engineering: one accepts whatever the AI produces, the other stays suspicious until it’s earned trust. The judgement about what’s worth owning, what has to be reliable, and what’s allowed to break, is exactly the senior-operator judgement that doesn’t get cheaper. If anything it gets more valuable, because now you can act on it at a tenth of the cost.
So the discipline shifts. It’s no longer “can we afford to build this?” It’s “is this the right small thing to build, and can we trust it once it’s running?” Those are better questions. They’re also the ones generic SaaS quietly answered for you, badly, by making the decision a contract instead of a choice.
Owning the tool means owning the answer. That’s the price. It’s a fraction of what the friction tax costs, but it isn’t zero, and the teams that win treat it seriously.
First Thing Tomorrow
Stop pricing your tooling decisions with last decade’s numbers.
- List your five daily papercuts. The export-reimport ritual. The report you rebuild by hand. The status everyone keeps in their head. The step that exists only because the tool can’t do it. Write them down. That’s your friction tax, itemised.
- Reprice the build. For each one, ask what it would actually take to build the sharp tool now, today, not two years ago. The honest number is smaller than your instinct says.
- Pick the worst one and build the chisel. One papercut. One small tool. One afternoon. Make it do exactly one thing for exactly your team. Resist every urge to make it general.
- Refuse to marry it. Build it to be thrown away. When the process changes, you rebuild, you don’t maintain a roadmap.
- Apply the trust test before it goes live. What happens when this breaks? Who notices? What’s the fallback? If you can’t answer, it’s not ready, no matter how fast it was to build.
The goal isn’t to build everything. It’s to stop defaulting to the answer that made sense in 2015 and costs you every week in 2026.
The Bottom Line
The build-vs-buy line moved, and most teams are still standing where it used to be. What was discipline a decade ago is now debt.
The teams pulling ahead don’t have better tools. They build their own rails around their exact process, small and sharp and disposable, and let the work stay the work.
Don’t bend your process around the software.
Bend the software around your process.
Need help building rails that fit your process instead of fighting it? That’s what we do. We build our own software, and we know the difference between a sharp tool and a sprawling one. Let’s talk.