Development Approach
A structured process, with the client involved at every stage
Software projects fail more often on communication than on code. Our process is designed so that expectations are written down, progress is visible, and problems surface early enough to be dealt with.
Delivery stages
Seven stages from first enquiry to long-term support
Each stage produces something tangible. Nothing moves forward on the strength of a verbal understanding alone.
- 01
Consultation and project discovery
Understand the situation before proposing anything.
We begin with a conversation about what is happening now: the process in question, who is involved, what is working, and what has prompted the enquiry. We look at the tools currently in use and, where practical, watch the work being done rather than only hearing it described. The purpose of this stage is to establish whether software is the right answer and, if it is, roughly what shape it should take.
Deliverable · A short written summary of the problem, the constraints identified, and an indicative scope.
- 02
Requirements analysis
Turn a description of the problem into a specification that can be built from.
We document the processes in detail — the records involved, the rules that govern them, the roles that act on them and the points where work moves between people. Requirements are separated into what the first release must do and what can follow. Anything ambiguous is raised and resolved here, where it costs a conversation, rather than during development, where it costs rework.
Deliverable · A requirements document with prioritised functional and non-functional requirements.
- 03
System design
Decide how the software will be structured, before code is written.
We design the data model, the application structure, the permission model and any integrations with existing systems. Interfaces are worked through as wireframes or clickable outlines so the client can react to something concrete. Technology choices are made and explained at this point, with attention to what will still be supportable in several years’ time rather than only what is quickest now.
Deliverable · Data model, architecture notes, interface designs and an agreed technology stack.
- 04
Software development
Build in reviewable increments, not in one long silence.
Development is organised into milestones, each producing working software that can be seen and used. Code is version controlled with peer review before changes are merged, and each milestone is deployed to a staging environment for the client to try. Progress is reported at an agreed interval, including anything that has turned out to be harder than expected — early notice of a problem is more useful than a reassuring report.
Deliverable · Working software at each milestone, deployed to a staging environment for review.
- 05
Quality testing
Establish that the software does what was specified, under realistic conditions.
Testing runs throughout the build and intensifies before release. Automated tests cover the logic that matters most and run on every change. Alongside those, we test manually across browsers and devices, check keyboard and screen-reader accessibility, review handling of invalid input and permission boundaries, and assess performance with data volumes representative of real use. The client carries out acceptance testing against the agreed requirements.
Deliverable · Automated test coverage, a documented test pass, and recorded client acceptance.
- 06
Deployment
Put the software into service with the least possible disruption.
Deployment is planned in advance: hosting and environment configuration, data migration with verification, backup arrangements, monitoring, and a rollback route if it is needed. Where a system is replacing an existing one we agree a cutover approach, which may include a period of parallel running. Staff receive handover and written documentation appropriate to their role before the system goes live.
Deliverable · Live system, migrated and verified data, documentation and handover to users.
- 07
Ongoing updates and maintenance
Keep the software dependable for as long as it is in use.
After launch we provide corrective maintenance, dependency and security updates, monitoring, and a defined route for reporting issues. Organisations change how they operate, and software that is not adjusted gradually stops fitting, so we schedule periodic reviews to discuss what has changed and what should be adapted. Further development is handled as smaller, planned pieces of work rather than accumulating until another full project is required.
Deliverable · A maintenance arrangement with agreed response expectations and scheduled reviews.
Working together
Milestones and collaboration
Regular contact through the project, with an agreed decision point at the end of each milestone.
Every project is broken into milestones with a stated scope, a target date and a defined outcome. At the end of each one there is a review: the client sees the working software, confirms it matches what was agreed, and either signs it off or raises changes. Where changes affect scope or timescale, we quantify the effect before proceeding rather than absorbing it silently and reporting a delay later.
Between reviews the client has a named point of contact and a written progress update at an agreed frequency. We use a shared issue tracker so that reported problems, decisions and outstanding questions are all visible in one place with their current status, which removes the ambiguity of tracking a project through email threads.
We also ask clients to nominate someone who can make decisions on process questions. Most delays in software projects come from waiting for an answer about how an organisation actually works, and having a clear route to those answers is the single most effective thing a client can do to keep a project moving.
Standards
Engineering practices we hold to
Consistent practice is what makes software maintainable after the original team has moved on.
- All work is version controlled, with changes reviewed before they reach the main branch.
- Automated tests cover business logic and are run on every change, not only before release.
- Environments are separated into development, staging and production, with production data protected.
- Dependencies are tracked and updated on a schedule, with security advisories monitored.
- Access control, input validation and encrypted transport are treated as baseline requirements.
- Backups are configured and their restoration tested, not merely assumed to work.
- Code, data models and deployment procedures are documented so the software can be handed over.
Start with a consultation
The first stage costs nothing but a conversation. Tell us what you are trying to improve and we will give you an honest view of whether custom software is the right answer and what delivering it would involve.