Week one produces a drawing. Not a commit.
Most of what goes wrong in software was decided before anyone wrote code. So we spend the first week reading and drawing, and nobody starts building until there is a picture everyone has signed.
Thirty minutes · no predetermined package
Diagnose, architect, build, run.
The third one is what everybody buys. The second one is what decides whether it works.
Diagnose
We watch the work happen before proposing anything. Not a workshop — the actual floor, on an actual Tuesday. The constraint is rarely where the brief says it is.
Architect
What connects to what, who owns which step, and where each number comes from. Drawn and signed off before a line is written, because scope creep here is an architecture failure rather than a schedule risk.
Build
Working software in front of real users early — usually the intake path first, because that is where being wrong is cheapest to correct. Tests, logging and error reporting ship alongside, not afterwards.
Run
The engineers who built it are the ones who run it. There is no handover to a support tier you have never met, because there is no support tier.
Six questions worth asking any firm.
Including us. The answers tell you more than a portfolio does.
The commitments most firms will not put in writing.
The repository is yours
Created in your organisation from the first commit — not transferred at the end, which is the arrangement that goes wrong.
No software commission
No commission, referral fee or partner margin on anything we recommend. That is what makes the recommendation worth having.
Export rights, always
Your data leaves in a usable form whenever you ask, without a project to make it possible.
What people ask before starting.
What does the discovery phase actually produce?
Two drawings and a boundary. The current state, the intended state, and a written agreement about what gets built versus what stays configured. All three signed before any code.
How long before we see working software?
Weeks. We ship in slices, so a real user is working in real software early — usually the intake path, because that is where being wrong is cheapest to correct.
Do you work fixed price or time and materials?
Either, and the honest answer depends on how well the boundary is understood. Fixed price on a vague scope prices the risk into the number and everyone loses.
What is in a software development contract with you?
Ownership from the first commit, export rights, no software commission, and a named team. Those four are non-negotiable in our direction, not yours.
What happens when the scope changes mid-build?
It gets discussed against the signed architecture rather than argued about. That document exists precisely so a change is a decision rather than a dispute.
Who owns the code?
You do, from the first commit. The repository is created in your organisation at the start rather than transferred at the end.
Do you use agile, waterfall or something else?
Architecture up front, delivery in slices. The label matters less than whether the drawing exists before the code and whether a real user sees it early.
Can we use our own developers alongside you?
Yes, and it usually works better. The boundary document exists for exactly this reason — everyone needs the same picture.
What if we decide not to build after discovery?
That is a good outcome and it happens regularly. You keep the drawings and the finding, which are useful whoever does the work.
Who runs it after launch?
The engineers who built it, unless you would rather take it in-house — in which case the handover includes documentation, a runbook and a defined period of questions.