Our development process
Seven stages, each with an output you receive and can check. The purpose of a defined process is not ceremony — it is making sure the expensive decisions happen before they become expensive.
Delivery
From first conversation to long-term support
Discovery
A working session on the problem, the constraints and the people affected. We produce a written summary of what we understood — if it is wrong, it is cheap to correct at this stage.
- Problem definition
- Stakeholder map
- Success criteria
- Known constraints
Requirements & scope
Features written as outcomes, prioritised into what ships first and what waits. Anything deliberately excluded is written down so it cannot resurface as an assumption.
- Prioritised backlog
- Scope boundary
- Stage estimate
- Risk register
Architecture & design
Data model, service boundaries, integrations and deployment target decided together with the interface design. The expensive decisions are made here.
- System architecture
- Data model
- UI designs
- Tech stack rationale
Development
Two-week increments, each ending in something you can open and use. You get a demo, a changelog and access to the repository throughout.
- Working increments
- Code review
- Automated tests
- Sprint demos
Testing & QA
Functional, cross-device, performance, accessibility and security checks against the criteria agreed at the start — not a general 'we tested it'.
- Test plan
- Cross-device QA
- Performance budget
- Security review
Deployment
Environments, CI/CD, monitoring, backups and DNS configured and documented. Handover includes a runbook, not just a password.
- CI/CD pipeline
- Monitoring & alerts
- Backup policy
- Handover runbook
Support & iteration
Post-launch support at an agreed response time, plus a monthly block for improvements informed by how the software is actually being used.
- Response SLA
- Monthly report
- Improvement backlog
- Security patching
Getting started
What happens in the first two weeks
Two weeks in, you should have something concrete in hand — not a status meeting. Depending on the engagement that means an architecture document and staged estimate, a clickable prototype, or a first working increment deployed to a staging environment you can open.
If a development company cannot tell you what exists after two weeks, that is worth asking about before you sign anything, with us or anyone else.
Week one
Discovery sessions, access to the systems involved, and a written statement of the problem as we understood it. You correct it while correcting it is free.
Week two
Architecture, data model and scope boundary agreed. Staged estimate with assumptions listed next to each stage. Repository and environments set up in your accounts.
From week three
Two-week increments, each ending in a demo and a changelog, running until the agreed scope is delivered.
FAQ
Process questions
For a focused project, a few working sessions across one to two weeks. For a larger platform it can be a three to four week paid engagement producing an architecture document, scope boundary and staged estimate. That output is yours to take to another team if you prefer.
They usually do. Fixed-scope engagements handle it through priced change requests; time and materials and dedicated team models absorb it by reprioritising the next sprint. We will tell you which model suits the volatility of your requirements before you sign.
A written update weekly, a demo at the end of each two-week increment, and access to the repository and issue tracker throughout. Between those, direct access to the engineers on your project.
Tell us what you are trying to build.
Send the problem, the constraint or the half-formed idea. You will get a straight answer on whether we are the right team for it, and what it would take.