Non-technical founders with domain expertise
This is the clearest fit.
You have spent years inside an industry. You know a problem that costs real money, and you can describe exactly how people work around it today. Turning that into software means making decisions you have no basis to make.
What you need is not a supplier taking instructions. It is a technical counterpart who will push back on scope, explain trade-offs in commercial terms, and take responsibility for the architecture.
That is what the studio model provides. It is why we start with a one-week Discovery Sprint rather than a proposal — the sprint is where the pushing back happens, cheaply.
What tends to go wrong for this group elsewhere is that a supplier takes the brief literally. A founder describing a product in the only vocabulary they have is not writing a specification. Building exactly what was asked for produces something technically correct and commercially useless.
The work in the first week is translation. Turning industry knowledge into a scope, and being willing to say when the thing described is not the thing that should be built.
Businesses productising an internal tool
A spreadsheet, script or internal application that runs part of your business is often a real product waiting for a decision.
The hard question is never whether the tool works — it does, for you. It is which parts of it generalise beyond your own processes, and what has to be rebuilt when the users are strangers rather than colleagues.
This work suits a Discovery Sprint followed by an MVP build, because the existing tool gives the scope an unusually solid starting point.
This group also arrives with an advantage they usually discount: real usage data and real users. You already know which parts of the workflow are used daily and which were built once and abandoned. That history is worth more than any amount of market research.
Teams needing senior technical leadership
Some teams already have engineers but nobody senior enough to own architecture, hiring and technical strategy. Others have a product built elsewhere and no confidence in what it can support.
A fractional CTO retainer fits here: part-time senior judgement, month to month. No salary or equity cost for a full-time hire made before there is enough product to hire against. For products we did not build, the first month is spent reading the codebase and writing an honest assessment before anything is changed.
The distinguishing question is whether decisions or capacity are missing. Where a team can execute but cannot agree on direction, leadership is the gap and adding engineers makes it worse. Where direction is clear and delivery is the constraint, we would say so and recommend hiring rather than retaining us.
Getting that diagnosis right in the first conversation saves everybody a quarter.
Work we decline, and why
Price-first procurement
When the selection criterion is the lowest quote, the winning bid is the one that understood the problem least. That engagement ends in a rebuild, and the rebuild costs more than doing it properly would have.
Staff augmentation
Where engineers are treated as interchangeable capacity, the value we add — judgement accumulated on your specific product — does not exist. If you need bodies rather than decisions, a staffing firm will serve you better and cost less.
Tactical fixes with no strategy
Individual features bolted onto a product with no thesis behind it produce a system nobody can reason about. We would rather spend a week establishing what the product is than three months adding to something undefined.
What a good engagement looks like
Long-term and strategic, in both directions.
Engagements that go badly almost never fail on engineering — they fail because a decision sat unanswered for three weeks while a fixed timeline kept running.