A software development process with no surprises
Our software development process has seven stages, starting with the first conversation and carrying on after launch. For each one, you'll see what we do, what you get in your hands and roughly how long it takes.
What is the software development life cycle?
The software development life cycle is the set of stages a piece of software goes through on its way from an idea to something people use every day. Most teams follow roughly the same stages. The difference you'll feel is how clearly each one is run, and how often you get to see real progress.
We use agile delivery. We build the software in small pieces that actually work and show you each one as it's finished. You can change your priorities as you learn more, and problems show up early, while they're still cheap to fix.
Before any of that starts, we agree a fixed estimate with you. Our guide on how much custom software costs explains what drives it.
Our software development process
Every stage ends with something you can see or use. How long each one takes depends mostly on the size of the product.
- DiscoveryWe learn your goals and your users.
- EstimateYou get the scope, timeline and a fixed price.
- DesignYou click through prototypes before we code.
- Key stepBuild in sprintsYou see a demo every two weeks.
- TestingEvery change gets tested.
- ReleaseWe try it on staging, then go live.
- SupportWe keep watch and add new features.
| Stage | What happens and what you receive | Typical timing |
|---|---|---|
| Discovery | We learn your goals, users, connected systems, rules such as data protection laws, budget and deadlines. You get a written summary of what we found. | A few days to two weeks |
| Estimate and proposal | A proposal covering the scope (what we will and won't build), our approach, the team, the timeline and a fixed estimate. Nothing starts until you say yes. | Usually within a week of discovery |
| Design | First wireframes (simple sketches of each screen), then prototypes you can click through. Behind the scenes, an architect plans the database, the hosting and the APIs (the connections that let systems share data). | The first weeks of the project |
| Build in sprints | We work in short, fixed blocks of time. Each one ends with a demo of software that works, and you tell us what you think. | Most of the project |
| Automated testing | Automated tests run on every change, and a person tests each new feature by hand. Before release we also check speed, security and how it behaves on different devices. | Every sprint, on every change |
| Release | It goes onto staging first, then live once you approve. We move your data across, set up monitoring and hand over the documentation. | When each version is ready |
| Support and improvement | We watch the system, fix bugs, apply security updates and build new features as you need them. | For as long as you need us |
After launch, most clients move to our software maintenance and support plan.
What happens inside a sprint?
A sprint is a short cycle of work, usually two weeks long, that repeats until the product is done. Because you see progress so often, you can change direction before much effort has gone the wrong way.
- PlanningWe agree which backlog items (the ordered list of work) to finish.
- Daily check inAbout fifteen minutes to sort out anything in the way.
- Build and reviewWe write the code and tests, and review every change.
- Key stepDemoYou try the real software and tell us what you think.
- RetrospectiveThe team looks at what worked and what to change.
Sprints repeat every two weeks.
How do you decide what to build first?
We put the backlog in order by value and risk, so the hardest questions get answered early instead of in the final weeks. Many projects aim first for a minimum viable product, or MVP, which is the smallest version real users can try.
Engineering practices we use
Every change goes through CI/CD, an automated route that builds it, tests it and releases it in small steps that are easy to undo.
The path every change takes
- Version controlGit records every change, who made it and why.
- Code reviewA second engineer checks for mistakes and security issues.
- Key stepAutomated testsTests for each small part, how parts connect and full user paths.
- StagingA private copy of your live system where you can try it first.
- ReleaseIt goes live once you approve, and can be rolled back quickly.
OWASP Top 10 is a widely used list of the most common web security risks, and we check against it. Infrastructure as code means your servers are set up from written files, so they come out the same way every time. There's more on our cloud migration services and application security services pages.
How we keep you informed
At the start, we agree how often you want to hear from us. Most clients pick a short weekly call and a written update that says what got finished, what's next, any risks we can see and any decisions we need from you.
We work in the tools your team already uses. Our teams cover 24 time zones, so meetings happen during your own working day. Our guide on working with a remote development team explains how.
What you can expect
- One point of contact: a delivery lead who knows your project.
- A demo at the end of every sprint.
- Written status reports you can forward to decision makers.
- Meetings in your hours, wherever you are.
- Replies within one business day from a real person.
What we need from you
On your side, we need one person who can make decisions. We also need honest answers during discovery and your feedback at each sprint demo. You shouldn't have to chase us for updates or manage the team day to day, because your delivery lead does that for you.
A typical first month on a smaller project
Your software process questions answered
It depends on how many features you need, how many types of user there are, which systems it connects to and which platforms it runs on (web, iOS, Android). You'll get a realistic timeline along with the fixed estimate, and you'll see working software from the first few sprints.
Yes. You can reorder your priorities at any sprint planning. If a change adds work, we'll tell you what it does to the cost and timing, and nothing moves until you agree.
Waterfall runs through each stage once, and you usually see the product near the end. Agile repeats the design, build and test loop in short sprints, so you can shape the product while it grows. We use agile, with a fixed estimate agreed at the start.
You'll mostly talk to your delivery lead. Behind them are the engineers, designers and quality engineers, and you'll meet them at the sprint demos.
We keep an eye on it, fix bugs, apply security updates and help plan what comes next. From there, you can choose a care and support plan, keep a dedicated team, or take the work in house using the documentation we hand over.
More answers are on our software development questions page.
Ready to start with discovery?
Tell us what you're building. We'll reply within one business day and suggest what to do next.