Kintsugi “Something's broken or stuck.”
Software project rescue — repair what's broken, keep what's good.
The software exists. Money was spent, promises were made — and it still isn't doing what it was supposed to do. Maybe the agency ghosted. Maybe the launch slipped three times. Maybe the one person who understood the code is gone.
Kintsugi is the repair: an honest account of what you actually have, a clear diagnosis of what's broken, and a route back to a project that runs — without starting over.
What it is
Projects arrive here in recognizable states: half-finished by a vendor who stopped answering. Technically working but impossible to change without breaking. Inherited by a new team that can't tell what's load-bearing. Ninety percent done for a year. And increasingly: the AI feature that works in every demo and fails with real customers. The chatbot bolted onto the product that users have learned to avoid. The app an AI wrote in a weekend that no one — human or machine — can safely change. If any of that sounds familiar, you're in the right place, and you're not the first.
A project arrives in Kintsugi for all sorts of reasons. It might be unfinished, or technically messy, or scoped badly from the start. It might be difficult to maintain, stuck in development, abandoned by the people who built it, or simply not producing the result it was meant to.
The name is the method. In kintsugi, a broken vessel is repaired with gold along the break — it is not disguised as new, and the history stays visible. The same is true here: most of what exists is worth keeping. The hard part, and the first part, is telling which part.
金継ぎ golden joinery
The craft of mending broken pottery with lacquer dusted in gold. The story usually told is of a fifteenth-century shogun who sent a favourite tea bowl to China for repair and got it back stapled with ugly metal, prompting Japanese craftsmen to find a better way. Whether or not that is how it began, the principle held: the break is filled rather than disguised, so the mended object shows its history — and is often valued more for it.
A codebase that has been through something is not worth less than a fresh one; it knows things a fresh one doesn't. Repair keeps that knowledge. A rewrite that pretends the history never happened throws it away and pays for the same lessons twice.
What you end up with
A clear account of what you have, a project that runs and can be worked on again, and a route out of the state it was stuck in.
How the work goes
-
Understand what exists
Read the system as it actually is, not as it was meant to be — code, decisions, and the reasons behind them.
-
Decide what stays
Separate what is valuable from what is merely present. Rewriting is a last resort, not an opening move.
-
Name what is broken
Be specific. "Bad code" is not a diagnosis. Say which part fails, under what conditions, and what it costs.
-
Make a path forward
A sequence that produces working software along the way, not a rewrite you have to finish before anything improves.
-
Do the repair
Fix it in an order where each step leaves the project in better shape than it found it.
The shape of it
How a rescue starts: the audit
Every Kintsugi engagement begins with a fixed-scope, fixed-price audit — typically 1–2 weeks. We read the code, the infrastructure, and the history, and deliver a written account you own regardless of what happens next.
- What exists
- And what state it's actually in.
- What's worth keeping
- And what isn't — with reasons.
- What is broken
- Specifically: under what conditions, and what it costs you.
- A sequenced repair plan
- Where each step leaves the project better than it found it.
The audit stands alone. Use it to work with us, to brief an internal team, or to decide the project's future with real information for the first time. Sometimes the honest conclusion is that the project isn't worth saving — and hearing that after two weeks is far cheaper than after six more months. There is no obligation to continue: the honest diagnosis is the product. We are not a vendor running a free "assessment" scoped to find reasons to hire us.
Choosing correctly
Is this the right practice?
It fits when
There is real software, and real value in it, but it has stopped moving.
It doesn't when
If the product is healthy and the question is where to take it next, that is continuous work, not repair.
What it represents
Recovery.
Questions
Project rescue, answered.
Our previous agency disappeared with the project half-done. Can you take it over?
Yes — one of the most common ways projects arrive here. We start by getting you full control of code, accounts, and infrastructure, then audit what's there. Even without the previous team's cooperation, the code and its history usually tell the story.
Should we just rewrite it from scratch?
Almost never as a first move. Rewrites feel clean and are usually the most expensive way to lose the knowledge embedded in working code. In kintsugi — the craft — a broken vessel is repaired with gold, not thrown away. If a rewrite genuinely is right, the audit will say so, with reasons.
Our app was largely AI-generated and it's become unmaintainable. Can you fix it?
Yes — this is now one of the most common arrivals. AI-generated codebases fail in patterns: duplicated logic, security gaps, missing tests, architecture that fights change. Patterns can be audited and repaired. The prototype proved what you want; we keep that knowledge and make the software worthy of it.
We shipped an AI feature and can't tell if it's working. Is that repair?
If there's no evaluation, nobody can tell — and un-measurable AI is a liability wearing a feature's clothes. The audit establishes ground truth: what it actually does with real inputs, where it fails, what it costs. From there it's a normal repair: fix, measure, verify.
The project is live and customers are affected. How fast can you move?
If something is actively failing in production, stabilizing comes before auditing. Write with "production" in the message and we'll triage the same day.
Can you work with our existing developers?
Yes. Kintsugi often runs alongside an internal team — the repair includes leaving the people who stay able to maintain it.
Start here
Tell us where your product is, and we will tell you what we would do next.
No pitch deck required. A short description of the situation is enough for a useful first conversation.