Consulting engagements fail at the start more often than at the end, and they fail in one of two mirrored ways. The strategy shape diagnoses without committing: weeks of workshops, a deck full of recommendations, and a goodbye, leaving you to execute advice the advisors never had to live with. The body-shop shape commits without diagnosing: developers start coding your backlog on day one, and six months later you discover the backlog was the problem. Both failures share a root: somebody separated deciding from doing.
We start every engagement with a structure built to refuse that separation, and since it’s the most copied-from part of how we work, it deserves a public writeup. We call it the decision sprint: two weeks, fixed price, and the first week produces decisions, not code.
The map comes from doing, not talking
The first week is spent inside your actual artifacts: the repository, the deploy pipeline, the test suite, plus interviews with the people who live there. We ask about facts and fears, which is different from a workshop collecting votes. I’ve published the reading list we use, and the form factor matters more than any single item on it: evidence from the code over opinions about the code. An architecture workshop produces a map of how people feel about the system, and the deploy pipeline doesn’t perform for visitors.
Concretely, day one needs read access to the repo, CI, and the deploy tooling, plus an hour with whoever ships most often. The disruption to your team is a handful of conversations, not a workshop calendar. The map itself is an unglamorous document: a list of items, each with a verdict, a reason traced to something we read, and a price. A real line looks like “kill react-on-rails: taxes every deploy, conversion shippable in slices, roughly N sprints, unblocks the build simplification.”
The output of that reading is a map with three lists: what to kill, what to keep, and what to build first. Kill the infrastructure that taxes everything (at Domestika that was react-on-rails). Keep what works, especially where it offends your taste. Build what the business is actually waiting on. I’ve written about the decision logic; the sprint is that logic applied to your specific repository, with prices next to the items.
Then comes the part that separates this from a paid diagnosis: the rest of the sprint ships the first item from the map, the first kill killed or the first build building. It ships in your repo, through your pipeline, before the two weeks end. That’s where the map earns its credibility, because a map drawn by people who must immediately follow it gets drawn differently than a deck built for a steering committee.
Why the shape de-risks both sides
The scope and the price are fixed before anything starts: €5K per product engineer per week, the same number we publish on the homepage. You know the worst case going in: one sprint’s cost. For that you keep the map, the first shipped change, and everything we learned, whether or not there’s a sprint two. There are no multi-year contracts and no exit clauses to lawyer through, because the structural promise is the opposite one: you can stop after any sprint, and the work has to keep earning the next one.
That same shape disciplines us. A consultancy that must re-win the engagement every two weeks cannot coast on a signed contract. The first item on the map gets executed by the people who drew it, before the sprint ends, and the rest of the map gets executed only if that first item earns a sprint two. Padding gets caught at the first checkpoint instead of in year two.
It also answers the question every founder quietly has about bringing in outsiders: what if they’re wrong for us? Two weeks answers it at a known price. The alternative ways of finding out (a six-month retainer, a big-bang rewrite contract) answer the same question at many times the price.
What it isn’t
A decision sprint isn’t an audit you file away, because the second week converts diagnosis into a shipped change, and that asymmetry is the entire point. It isn’t a discovery phase that bills until it finds something, because the scope and the price are fixed before it starts. And it isn’t right for everything: a greenfield MVP has nothing to read yet, and a team that just needs more hands on a healthy codebase needs hiring, not deciding.
Where it fits is the situation we keep meeting: a product past MVP, something materially stuck (delivery, scale, an AI adoption), and a founder who needs to make a real decision with real information and doesn’t want to bet the company on a stranger’s deck.
Steal the structure even if you never call us. Make whoever diagnoses your codebase commit to shipping the first fix in the same engagement, at a price fixed before they start, with everything they produce staying yours. The vendors who accept those terms are the ones whose maps you can trust, and the ones who won’t have told you something useful too.