Assumption mapping
We break the idea into statements that must be true: who has the problem, what they switch from, what they pay. Then rank by fatality and test the top three.
Ranked assumption mapProduct engineering
Build the product your market keeps using
Product development is a sequence of decisions under uncertainty. We build the smallest honest version of each one, instrument it, put it in front of real users, and let evidence decide what survives.
- Fixed scope
- 14 days to demo
- Full IP transfer
- 30-day warranty
The work between idea and fit
Almost every product budget is spent competently on the wrong thing. The code compiles, the design is clean, the launch happens, and nobody comes back on day thirty. The expensive mistake is rarely slow engineering. It is six months of features stacked on one untested assumption about who the user is and what would actually make them change their behaviour. Generated code made building cheap, which only moved the bottleneck: the constraint now is how honestly you decide, and how willing you are to delete.
So we do not start with a backlog. We start by writing down what has to be true for this product to work, ordering those statements by how fatal each one is, and agreeing in advance what result would make us stop. Then we build the thinnest end-to-end slice that can test the first one, with the analytics events defined before the screens are. Anything still a hypothesis is written to be cheap to remove, and every removal is logged.
| What is true of this work | What it forces | What we do about it |
|---|---|---|
| The requirement is still a hypothesis | total scope cannot be priced upfront | fixed scope and fee per cycle |
| Users react only to real software | surveys and mockups cannot settle it | thin end-to-end slice in production |
| Tenancy, identity and money resist retrofit | those forks land before any feature | built once in the first slice |
| Analytics bolted on afterwards read false | the event schema precedes the interface | versioned events defined before screens |
| Generated code makes shipping cheap | deleting, not adding, becomes the bottleneck | written deletion log each cycle |
In scope
- Assumption teardown with agreed kill criteria
- Thin end-to-end slices in your cloud
- Event schema, funnel and cohort readouts
- Pricing, entitlements and release flagging
Not in scope
- On-call and change work after warranty
- Independent test strategy and release certification
- Brand, paid acquisition and sales hiring
Handled by
- Maintenance & SupportKeeps the product running once the build team steps back.
- Software QA & TestingOwns independent test strategy and release certification.
What we build
Thin-slice builds
One complete journey, sign-in to the moment of value, running in your cloud behind a flag. Thin still needs real auth, real data and a real error path.
Working end-to-end sliceProduct instrumentation
A versioned event schema written before the interface, so activation, time-to-value and cohort retention are readable from the first release rather than argued about a quarter later.
Versioned event schemaPricing and entitlement plumbing
Plans, limits, trials, upgrades and the metering behind them. This is where products stall: the demo converts, then nobody can change a price without an engineer.
Plan and entitlement modelAI features users trust
Where the product needs judgement rather than rules, we build it with a graded test set, a confidence threshold and a defined fallback. Unmeasured accuracy is a support queue.
Graded evaluation setScale-readiness hardening
When a slice earns its keep we pay its debt on purpose: tests around the paths that carry money, backups you have restored from, rate limits, an on-call runbook.
On-call runbookHow the work runs
- 01Weeks 1–2
Assumption teardown
We run a working session with whoever actually decides and convert the pitch into ranked, falsifiable statements. For the top three we agree the test, the expected signal, and the result that stops us.
You getRanked assumption map with kill criteria
- 02Weeks 3–4
First slice
We ship one end-to-end journey within fourteen days of the build starting, in your cloud account, with the event schema, auth and error handling real. Named users get it, behind a flag we can pull.
You getWorking slice in your cloud
- 03Fortnightly from week 5
Evidence and cuts
Every fortnight a change goes in front of users and we read three things: did activation move, did the cohort curve flatten, what did five interviews say. Then we sort: harden, hold, or delete properly.
You getFortnightly evidence readout and deletion log
- 04Final fortnight
Handover and warranty
We move the repository, cloud account and secrets under your control, hand over the event schema and evidence trail, walk your engineers through the architecture decisions and runbook, then hold a thirty-day warranty.
You getFull IP transfer and runbooks
What you are handed
- Ranked assumption map with kill criteria
- Working product in your own cloud account
- Versioned analytics event schema
- Fortnightly evidence readout and deletion log
- Graded evaluation set for AI features
- Architecture decision records for every fork
- Pricing, plan and entitlement model
- On-call runbook and restore-tested backups
- Repository, infrastructure as code, and secrets
Typical stack
Product core
TypeScriptNext.jsPython / FastAPIDjangoPostgreSQLRedis
Delivery
GitHub ActionsTerraformDockerUnleash / FlagsmithPreview environmentsPlaywright
Evidence
PostHogMetabaseOpenTelemetrySentryGrafana
Commodity layer
StripeWorkOSAuth0TemporalResendCloudflare R2
The calls we make, and why
Should we build the real thing now, or something disposable first?
Both, in one codebase — hypotheses disposable, constraints permanent.
Anything still a hypothesis is written so it can be deleted in an afternoon. Tenancy, identity, money and the core data model are built once and built properly, because retro-fitting those costs a migration that eats a quarter.
We’d choose otherwise whenyou already have a signed pilot and a security review waiting — a build, not a search.
Do we start with microservices so we do not have to rewrite later?
No. One deployable, one database, hard module boundaries in code.
That is the fastest thing to change while the product is still moving, and module boundaries — not network hops — are what make later extraction cheap. Distributing a product you have not validated buys deployment complexity and pays nothing back.
We’d choose otherwise whena workload has a genuinely different runtime shape — long-running jobs, GPU inference, video.
Should we build our own auth, billing and admin, or buy them?
Buy everything that is not the product. Own the metering.
Keep a thin seam of your own code between the app and each vendor, so a swap is a week rather than a quarter. Metering is the exception: it is what sales changes monthly, and the hardest thing to move later.
We’d choose otherwise whenresidency or procurement rules put user records somewhere no vendor will host them.
How much of this is written by AI, and can our team maintain it?
Generation where a test states the requirement, never around invariants.
A lot is generated, and that is only safe under a rule: not where an invariant guards money, permissions or customer data. Every change lands as a human-reviewed pull request under your conventions. If a module cannot be read in one sitting, it goes back.
We’d choose otherwise whenyour auditors or regulator require a named human author for every line shipped.
This fits if
- You or your product lead sit in customer interviews fortnightly
- You can already reach the first hundred users you want
- You are funded for several release-and-learn cycles, not one launch
- You will delete a feature the evidence does not support
Look elsewhere if
- Your specification is signed off and final, with no discovery
- Your budget covers a single launch date, not learning cycles
- Nobody your side can commit weekly hours to decisions
EngagementFixed-scope cycles
Typical length12–24 weeks typical
How it startsA paid two-week assumption teardown, priced separately, with no obligation to continue into the build.
Questions we get asked
How is this different from your MVP Software Development service?
An MVP is a deliverable; this is the loop. MVP Software Development ends when the first cut ships. Software Product Development covers the cycles after — reading the evidence, cutting what nobody used, hardening what survived, and adding the pricing and onboarding machinery a product needs before it can be sold repeatably. Want just the first cut? Buy the MVP.
Why can you not quote the whole product up front?
Because a fixed price for an unfixed problem is priced fiction, and you pay for it in change requests. We fix scope and fee per cycle instead: each cycle has a written goal, a fixed fee, and a defined set of artefacts. You approve the next one or you stop, and the teardown is priced on its own.
Who owns the code, the data and the accounts?
You do, from the first commit rather than at the end. The repository sits in your organisation, cloud and vendor accounts are opened under your billing, and infrastructure lives as code in the same repository. Full IP transfer is written into the contract and covers everything we produce, including designs, schemas and decision records.
What happens if the evidence says the idea does not work?
We tell you, with the numbers and the interview notes, and we stop rather than quietly building the next feature. That is what kill criteria are agreed for at the start — so the call is made before anyone is invested. Usually the finding is narrower than failure: wrong buyer, wrong first five minutes, or a price nobody would pay.
What happens when something breaks after launch?
Defects in what we shipped are fixed under a thirty-day warranty at no cost, measured from the handover of that cycle. Beyond that, most teams move onto a support arrangement or take it in-house with the runbook. We separate the two deliberately: a warranty covers our mistakes, while new behaviour under real load is new work.
Often bought alongside
Tell us the requirement.
Thirty minutes with the engineers who would build it. You leave with a scope, a timeline and a fixed price — or an honest no, and the reason why.