Our process
Working with us, from the first call to a system in use
What actually happens, in what order, and what we need from you at each point — so you can judge whether this is a way of working you want before committing to it.
The situation
Most bad supplier experiences share the same shape
Not incompetence, usually. A brief nobody challenged, a long silence during build, and a delivery that met the specification without solving the problem.
- A fixed price quoted before anyone examined the process
- Months between kick-off and seeing anything working
- Progress reported as percentages nobody can verify
- Change requests for things you assumed were included
- A handover consisting of a login and a wish of good luck
- No named person accountable once the invoice was paid
What it covers
What you can expect from us
An expert reads your brief
Someone who has built this kind of system responds, not a salesperson working from a form.
An NDA if you want one
Signed before anything commercially sensitive is discussed, so you can be specific rather than talking around the problem.
A scoped proposal
Scope, estimates, timelines and the CVs of the people who would actually do the work.
Working software early
Increments you can use, so the design is corrected while correcting it is still cheap.
One accountable contact
A named person responsible for delivery, not a rota and a ticket queue.
A handover you could act on
Source, documentation and deployment in your accounts, written for a team that has never met us.
How we work
The five stages
Roughly this sequence, adjusted to the work. We will tell you when a stage is unnecessary rather than run it because it is on the list.
Talk
A conversation about the problem, not a demo. We will say at this point if we think we are the wrong people for it.
Discover and specify
Understand how the work runs today and write down what the system has to do, in language you and a developer can both use.
Build in increments
Regular working releases you can try, so feedback arrives while it can still change the outcome.
Launch
Migration, training and a cutover plan with a way back, rather than a date and optimism.
Support and improve
Someone accountable after go-live, and a steady flow of change rather than a project every three years.
Outcomes
What working this way gives you
- A brief that was challenged before it was built
- Software in your hands within weeks, not at the end
- Costs that change visibly rather than arriving as a surprise
- Code and infrastructure in your own accounts throughout
- A named person accountable for delivery
- The ability to change supplier without changing everything
Common questions
Questions we are usually asked
Both, depending on the work. Fixed price suits well-specified scope and is worth the premium you pay for certainty; evolving work priced fixed usually produces either a padded estimate or an argument about change requests. We will tell you which we think fits and why.
It depends on current commitments, and we would rather say so than promise a start date we cannot staff properly. Discovery can often begin sooner than build.
Yes. Substituting the team after the pitch is a common industry practice and not one of ours. If someone has to change, you will be told rather than discover it in a standup.
You can. Working in increments means there is something usable at each stage, and code sits in your repositories from the start, so stopping leaves you with what has been built rather than nothing.
Often. Adding capacity, covering a specialism, or taking a self-contained part of the estate are all common. It works best when the split of responsibility is agreed explicitly rather than assumed.
You find out early, which is the point of short increments and honest reporting. Projects fail slowly while the status stays green; the value of frequent working software is that it is very hard to misrepresent.
Talk to someone who has built this
Not a salesperson working from a form. Tell us what the problem looks like and someone who has delivered this kind of work will come back to you, usually within one working day.
Book a free consultationRelated
Where this usually connects
- Prototyping and specification writingDeciding what to build, and proving it before it is built.
- Agile software development methodologyHow we actually run delivery, and where we depart from the textbook.
- Rapid application developmentGetting something usable in front of people quickly, without disposable code.
- Technology stackWhat we build with, and how a stack gets chosen for a project.
- Business analysisMapping how the work actually runs before anything is built.
- Project managementDelivery run by people accountable for the outcome.