Your software was an asset.
Now it's an anchor.
You built something real — customers, revenue, a team. But somewhere along the way, “what should we build?” became “what can we build?” That shift is quiet. And expensive.
Why fast-growing SaaS companies hit the wall
Every engineering decision made over the life of your software was reasonable at the time. Your early team made sensible trade-offs with the information they had. So did the engineers who came after them.
The problem isn’t bad engineering. It’s that each of those decisions was made without full visibility into where the business was heading — and each business decision was made without full visibility into what those choices would cost technically.
Over time, that gap compounds. The codebase starts reflecting the business it was, not the business it needs to be.
The result is Sclerosis. Your engineers aren’t slow — your software is inflexible. This difference matters enormously because one is a people problem, and the other is a structural one.
You feel it when a significant new feature takes six months instead of six weeks. When a competitor ships something you’ve had on your roadmap for a year. When your CTO and your board are both aligned, but somehow nothing moves. When your codebase has a veto on your roadmap.
That’s not a technology problem. It’s a translation problem. And it’s fixable.
Can’t we just use AI?
It’s the right question and the honest answer is … sometimes — but not for this problem.
AI tooling can help your engineers write code faster. What it can’t do is fix the underlying patterns that code is written into. If your architecture encodes the wrong trade-offs — if the decisions baked into your system three years ago no longer reflect where your business needs to go — then generating more code faster just accelerates the problem. You’re just pulling the knot tighter when you should be untying it.
The constraint isn’t tokens. It’s the gap between how your system was designed to move then and how your business needs to move now. That gap requires expert judgment to map and prioritise — someone who can understand the technical reality and the business strategy simultaneously and tell you which threads to pull first.
AI is a tool. This is a diagnosis.
What a Rails Rehab engagement looks like
A fixed-fee engagement for SaaS companies running Ruby on Rails systems who’ve outgrown the software that got them here.
Phase 1 — The Diagnostic (weeks 1–2)
Deep investigation into where your system is constraining your business. Codebase review combined with structured conversations with you, your CTO, and your engineering leads. Not to find someone to blame. To map precisely where accumulated technical decisions are limiting your options, and why.
Phase 2 — The Roadmap (end of week 2)
A prioritised roadmap delivered in plain language — not a technical document, a business document. What’s costing you the most strategic flexibility. What to fix first. What each fix unlocks. Something your board can read and your engineers can action.
Phase 3 — Implementation Advisory (months 1–3)
Three months alongside your leadership team while the work happens. Weekly sessions to keep the roadmap from gathering dust, async access for decisions that can’t wait, and a full roadmap review at month three to adjust for what’s changed.
The goal isn’t a perfect codebase. It’s a business that can move at the speed the market demands.
Fixed fee. No hourly billing. No scope creep. No surprises. You know exactly what you’re investing before we begin.
Who is this for
Rails Rehab is built for a specific situation:
- SaaS companies with $5M–$50M ARR
- Rails codebase that has gone through transitions (normally 3–7 years old)
- A founder or leadership who’s technically literate but no longer close to the code
- A growing gap between what the business needs to do and what engineering says is possible
- You’ve already tried hiring more engineers. It helped a little, but it didn’t fix it.
If that’s you, the problem isn’t going to solve itself. Every month it goes unfixed is another month your decision space quietly shrinks.
Rails Rehab is the work of Dave Kinkead — software architect, former GM, military officer, and academic philosopher.
Dave has over 20 years experience asking the question nobody in the room wants to answer — why isn’t this working? His background is unusual by design: a decade running organisations and P&Ls, a decade researching how complex systems make decisions, and years inside production Rails codebases.
Most people who understand the code don’t understand the business. Most people who understand the business can’t read the code. Dave works in the gap between the two — which is precisely where this problem lives.
Let’s find out if this is the right moment
A 30-minute discovery call. No pitch — just an honest conversation about where you are, what’s blocking you, and whether this engagement is the right fit. If it is, we move quickly. If it isn’t, you’ll leave with a clearer picture of what’s actually going on.