How it works
We start with the business problem, not the software.
Most people arrive knowing exactly what is broken and not at all what should be built. That second part is our job. Here is what the whole engagement looks like, including the part most shops leave vague: when you actually start paying.
Where it usually starts
Three reasons people call us.
Almost every engagement begins as one of these, and often as a combination of the last two.
01
A business problem, no obvious fix
Something is bottlenecking the business and you know the symptoms precisely: the double-bookings, the re-keying, the report that takes two days. What you do not have is a clear picture of which software solves it, or whether software is even the right answer. That is the conversation we are best at.
02
Software that costs too much
Per-seat licences that climb every time you hire, platform fees that scale with your volume, or a maintenance contract on a system nobody has improved in years. The bill has quietly grown past what the software is worth to you.
03
Software that delivers too little
You have bent your business around a product and still use a fraction of what it does, working around the parts that do not fit. Often it is both problems at once: paying a lot, getting a little, and unable to change either.
You do not need to arrive with a spec. Plenty of clients come to us describing a problem in plain business terms and leave the first call with a clear idea of what software would fix it, what it would cost, and sometimes that they should not build anything at all.
The engagement
From first call to a platform that keeps improving.
- 01
A one-hour conversation
Day oneWe start with the business problem, not a feature list. What is slowing you down, what it is costing you, what you have already tried, and what would have to be true for it to be fixed. You do not need to arrive knowing what the software should be. Working that out is our job.
- 02
An initial demo
About a week laterRoughly a week after that call you see a working demo, not a proposal document. It exists for one reason: to confirm we understood the problem correctly before anyone commits months to it. If we got it wrong, we find out in week one instead of month four.
- 03
Bi-weekly reviews
Until version 1.0From there we build in two-week cycles, and every review is a working version you can click through. You steer with real feedback on real screens, so the thing that reaches launch is the thing your team will actually use.
- 04
Version 1.0 goes live
Billing starts hereYour platform goes into production, with your data migrated, hosted, secured, and monitored. This is also the point where billing begins. You are not paying a monthly fee while we build toward that first release.
- 05
A 12-month roadmap
Just after launchWith version 1.0 live and real people using it, we plan the year together. Now the conversation is grounded in how the platform is actually being used rather than what everyone guessed at the start.
- 06
Support, security & enhancements
Every month afterMaintenance, support, and security updates are part of the fee, along with dedicated hours each month that go into enhancements from the roadmap. The platform keeps moving instead of freezing the day it launched.
Why billing starts at launch, and not before
Because the risky part of custom software is getting to a first release that people actually use, and that risk should sit with us rather than with you. It also keeps us honest about pace: we have every reason to get you to a working version 1.0 quickly, and none at all to let discovery drift. Plans run from $1,000/mo once you are live, on a 12-month partnership. AI usage (model and token costs) is billed separately at cost, outside the monthly fee.
See what it costs →Questions about the process
What if we do not know what we need built?
That is the normal starting point, and honestly it is the better one. Most clients arrive with a business problem rather than a specification: the schedule falls apart every week, the quoting process takes three days, the software bill keeps climbing. Working out what should be built, and whether it should be built at all, is the part we do before anyone writes code.
Do you ever tell people not to build something?
Regularly. Sometimes the fix is a configuration change in software you already own, sometimes it is an off-the-shelf product that genuinely fits, and sometimes the problem is a process rather than a tool. We would rather give you that answer in the first hour than sell you a platform you did not need.
When exactly does billing start?
When version 1.0 goes live and your team is using it in production. You are not paying a monthly fee during discovery, the initial demo, or the build cycles leading up to that release. It means we carry the risk of getting to a working launch, which is the correct way round.
How long does it take to reach version 1.0?
A focused tool is often live in about a month or two. A platform running a real slice of your operation usually takes longer, and a system the whole business depends on can run six months or more. You see a working version every two weeks throughout, so you always know where it stands.
What happens after the 12-month roadmap is set?
It gets built, a piece at a time, using the dedicated hours included in your monthly fee. The roadmap is revisited as the business changes rather than treated as a contract; if something more valuable appears in month three, we build that instead.
Who do we actually talk to?
The people building it. There is no account manager in between, no ticket queue, and no handoff to a team you have never met. That is a deliberate consequence of staying small.
Start with the problem. We'll work out the software.
One hour, no charge, no obligation. Come with what is broken and we will tell you what would fix it, even when the honest answer is that you should not build anything.
One monthly fee · Built, hosted & improving · You own the code