How a project runs with us, from the first call to handover.
You know what you are getting and what it costs before you commit to the build. You make the product decisions, and you use working software as we build it.
The Blueprint
A project without a published price starts with a Blueprint, a paid first step that settles what to build and what it costs. A free call comes first. The call settles whether software is the right fix and, if it is, what the Blueprint covers and what it costs.
In the Blueprint we shape the idea with you. We check that the idea can work and look at it from the point of view of the people who will use it. We find examples worth learning from and build prototypes you can try.
The Blueprint ends in an agreed spec, which says what the software must do, and a fixed price for the build. You know the cost before you commit to the build.
What your Blueprint gives you
A working prototype
An agreed spec
A fixed price
A plan
You keep the Blueprint whether or not we build the software.
How we work with you
You decide what gets built.
One person on your side makes the product decisions, and Mihir works with them directly. He is the product manager on every project, and you have his contact details from day one. When three or more people work on your project, a project manager joins too, named at kickoff.
You use working software as we go.
You try it while we build it, so you see problems early. We give a plain-language reason for every system and infrastructure choice, so by launch you understand your own product. Ask why at any point.
We agree on a change before we build it.
When you want something the spec doesn’t cover, we tell you what it does to the price and the plan. We build it once you agree.
You hear back fast.
On working days during a project, we reply within an hour in our working hours and within 12 hours outside them.
We tell you when there’s a better way.
The payroll team at a US nurse-staffing company spent 16 to 20 hours a week retyping timesheets into payroll. We could have proposed an elaborate system connecting its visit-tracking software to payroll. The team already exported a file each week. So we built a small Windows app that turns that export into a payroll file for QuickBooks Desktop, QuickBooks Online or ADP. Now they drop in the export, check a preview and import the file.
Read the timesheet converter case
How we build and check the software
Agents write the code inside a workflow of specs, scoped tickets, tests and separate reviews. We call this workflow AI-native engineering. You and Mihir decide what the software does. Here is each step, who does it and who reviews it.
The spec
You and Mihir agree on the spec in the Blueprint. The spec says what the software must do, and we check everything after it against the spec.
- Done by:
- you and Mihir
The screens
We design each screen for every width. You and Mihir review each screen.
- Done by:
- Designer and Agents
- Reviewed by:
- you and Mihir
The tickets
Agents cut the spec into small, scoped tickets. Each ticket says what done means for it.
- Done by:
- Agents
- Reviewed by:
- Mihir and the Lead Engineer
The code
An agent builds each ticket in its own copy of the code, together with the tests that check it.
- Done by:
- Agents
The reviews
A separate agent, on a different model, reviews each change against its ticket and tries to break it. The Lead Engineer reviews the change too. Their findings are fixed or answered before the change moves on.
- Done by:
- Agents and the Lead Engineer
The merge
The Lead Engineer merges a change once its tests and checks pass.
- Done by:
- the Lead Engineer
Working software
You use the software while we build it and tell us what to change.
- Done by:
- you
Smart contracts get stricter testing.
A mistake in a deployed contract can cost real money and is hard to undo. So engineers co-write smart contracts with the agents instead of leaving them to the workflow. Engineers test smart contracts with fuzz, invariant, integration and mutation tests. Certain projects need formal verification as well.
Launch and handover
We check the software against the spec.
The spec from the Blueprint says what done means. Before launch, we go through the finished software against it with you.
You own your accounts and code.
The accounts stay yours from the start. On a build from a Blueprint, the code is yours on full payment. You already know how it works, because we explained each choice as we built it.
Support after launch
After launch, you can message the people who built the software. We agree and quote support and any further work separately, before we start them.
A worked example
We built a free-to-play prediction-market prototype in three days to pitch an idea. It runs on live Polymarket markets, and players trade with points instead of money.
The brief
A slide deck could not show the idea. The prototype had to show real markets, moving prices, a filled order and a settled market, on the phones of the people it was pitched to.
The screens
We designed every screen first, at laptop, desktop and phone widths, and Mihir approved each one before anyone wrote code.
The build
We cut the spec into scoped tickets and built them through the workflow above. Three days after the first commit, the prototype was fully working on live data.
One review finding
Each market has two order books, one per outcome, and one price update can change both. A review found that the code refreshed the two books one at a time. Code reading them could then see one book updated and the other still stale. The fix refreshes both before anything reads them. A test proves it: undo the fix and the test fails.
Tell us what you need built
30 minutes with Mihir.