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. Sometimes the honest answer is a process change rather than software, and we will say so.
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.
You end up with
Working software, tested against the agreed scope.
Part of the build
Verification against ground truth before anyone relies on it. We measure accuracy on your documents, exercise the complete workflow end to end through the real interface, and deliberately trigger failure paths to prove the safeguards catch them.
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 the right people. If you chose client-owned infrastructure, everything already lives in your accounts. If we manage it for you, the ownership and handoff path are documented up front.
You end up with
A system you can operate with a clear ownership model. Support is optional, never required.
Two things we do differently
We test against your real data. Invented sample data can prove the code runs. It cannot prove the system works on the messy documents, edge cases, and exceptions your team actually deals with.
We prove the safeguards can catch failure. We deliberately create bad inputs and broken conditions to make sure the checks fail when they should. A green test is only useful if it can turn red.
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.
Support is available and genuinely optional. We can continue to maintain the system, or we can hand it to your internal IT provider or another developer. The ownership model is agreed before the build starts.
Few. One engineer means a real capacity limit, and we would rather give you an honest start date than overbook and under-deliver.
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.