Loading
Process
This is how an engagement actually runs, including the parts where we tell you not to spend money.
30 minutes · free
You describe the problem. We ask questions and tell you whether it sounds like something worth building. Roughly a third of these calls end with us saying the honest answer is a process change rather than software.
You end up with
A straight answer about whether to keep talking.
2 weeks · $3,500 fixed
We measure where the hours actually go — interviews, observation, and a look at your systems. You get a ranked list of opportunities with hours, build cost, run cost, and risk against each one.
You end up with
A costed roadmap you own, whoever builds it. Credited against a build within 90 days.
~1 week
We pick one thing and define it precisely: what it does, what it does not do, what "done" means, and how we will know it works. Fixed scope, fixed price, milestone billing.
You end up with
A written scope and a number that does not move unless the scope does.
3–16 weeks
Weekly demos against real data — not slides. You see it working, or you see exactly why it does not yet. Code lands in your GitHub organization from the first commit.
You end up with
Working software, tested, in production.
Part of the build
Verification against ground truth before anyone relies on it. Accuracy measured on your documents, the complete workflow exercised end to end through the real interface, error handling deliberately triggered.
You end up with
Measured numbers you can point at, including the weak spots.
1 week
A runbook written for your staff rather than for engineers, training for whoever will own it, and monitoring that alerts you rather than us. Everything already lives in your accounts.
You end up with
You can operate it without us. Support retainer optional, never required.
Two things we do differently
Demos run on your real data, not fixtures. A demo against invented sample data proves the code runs. It proves nothing about whether the system works, because your real documents are messier than any fixture anyone would think to write.
We verify that our checks can actually detect failure. A green test that would pass even if the feature were broken is not a test. Before trusting any verification, we make sure it fails when it should — an unglamorous habit that has caught defects every green build in the pipeline was quite happy about.
No. If you already know exactly what you want built, we can go straight to scoping. The assessment exists for the common case where a business knows something is wrong but not which thing to fix first — and it is a great deal cheaper than building the wrong thing well.
Fixed scope means fixed price. If we underestimated, that is our problem. If you change the scope mid-build, we price the change and you decide — nothing gets added quietly and invoiced later.
More than you would like, and it matters. Expect a few hours a week from whoever knows the process best, mostly in discovery and at demos. Projects where the client disengages produce software that does not match how the business actually works.
A support retainer is available and genuinely optional. Some clients take one; others hand it to their own IT people or leave it running. It is your software either way.
Few. One engineer means a real capacity limit, and we would rather say "not until March" than take your money and under-deliver in December.
A 30-minute call where we work out whether there is anything here worth building. If there is not, we will say so — that is a useful outcome too.