Software development is the work of turning a business need into working software and keeping it working. It runs through a life cycle: discovery, requirements, design, build, testing, release, then operation and maintenance. The delivery model a team uses, such as waterfall, agile or continuous delivery, decides how often it goes around that cycle.
This guide is for the person who commissions software rather than writes it: a founder, an operations manager, an owner with a budget and a problem. It walks through each phase with what you provide and what you should receive, compares the delivery models, shows where security belongs, and covers build versus buy, what drives cost and time, what a good brief contains and how to judge a development partner. If you want to learn to write code yourself, our tips for new coders are the better start.
What the software development life cycle is
The software development life cycle (SDLC) is the set of activities that takes software from an idea to a system people use, and on to its retirement. The international reference is ISO/IEC/IEEE 12207, whose second edition was published in April 2026. It covers the whole life of software, from conception through development, operation and support to retirement, including how it is bought and supplied. It deliberately does not prescribe a life cycle model: its processes can run concurrently, iteratively and recursively, and the 2026 edition notes that agile methods are the most widely used.
That point matters more than any diagram. The phases below are kinds of work, not calendar blocks. In a waterfall project each phase happens once, in order. In an agile project all of them happen in every short cycle, on a thin slice of the product. Either way, skipping a phase does not remove its work. It moves the work to a later and more expensive moment, usually after launch, when real users and real data are involved.
Two related terms come up often in conversations with suppliers:
- Custom software development is building software around one organization's own workflow, data and rules, instead of adapting the business to a product.
- Software engineering is the discipline behind it: the methods that let a team keep changing a system for years without breaking it.
The phases of software development, and what you give and get at each
Every phase needs something from the business, and every phase should hand something back that you can inspect. If a supplier cannot tell you what you will receive at the end of a phase, you cannot tell whether it happened.
| Phase | What happens | What the business provides | What the business receives |
|---|---|---|---|
| Discovery | Users, the current process and constraints are researched | Access to the people who do the work, examples of today's process, its costs | A problem statement, research findings, a rough size and a go or stop decision |
| Requirements | What the first release must do is written down and made testable | Decisions on priorities, business rules and edge cases; one person who decides | A prioritized scope (must, should, won't), user stories with acceptance criteria |
| Design | Screens, architecture, data model and security risks are worked out | Feedback on the prototype; hosting, integration and compliance constraints | A clickable prototype, architecture decision records, a data model, a threat model |
| Build | The software is written in short increments, each change reviewed | Quick answers to questions, and people at every demo | Working software on a staging environment after each increment, repository access |
| Test | Automated and manual tests prove it works, performs and is safe | Realistic test data, and staff for user acceptance testing | Test results, security scan reports and a list of known issues |
| Release | The software is deployed, data migrated and users switched over | A release window that suits the business, and trained users | A live system, a runbook, a rollback plan and a handover |
| Operate and maintain | The system is monitored, patched, fixed and improved | An owner and a budget after launch, and feedback from users | Incident and uptime reports, updates and a prioritized list of improvements |
Discovery
Discovery decides whether the problem is worth solving and what solving it would involve. The UK government's Service Manual describes it well: if you arrive with a solution ("we need an app that..."), reframe it as a problem first, research the users and the constraints (legislation, contracts, legacy systems), and work out what the problem costs today. It says not to start building during discovery, and that stopping at the end of discovery is not a failure when the research shows that is the right call. For government services it calls 4 to 8 weeks typical; a single internal workflow can take less.
Requirements
Requirements turn findings into statements a developer can build and a tester can check. Functional requirements describe behaviour ("a manager must approve refunds over a set amount"). Non-functional requirements describe qualities: speed, availability, security, accessibility and how easy the system will be to change. ISO/IEC 25010 defines a model of nine product quality characteristics that teams use as a checklist for these, and later to write acceptance criteria. Agile teams usually keep requirements as user stories in a backlog; the format matters less than agreeing what "done" means before the work starts.
Design
Design covers what people see (flows, screens and a clickable prototype) and what they do not (the architecture, the data model, the integrations and what happens when each one fails). Good teams record the big decisions with their reasons: which database, one application or several services, which parts are bought. The next team, or your own staff, can then understand why the system looks the way it does. Security design starts here too, with a threat model: a structured look at what could go wrong and who might try to make it happen.
Build and test
In a healthy team every change goes into version control, is reviewed by a second developer and runs through automated checks before it is merged. Testing is not a phase that starts when coding ends. Unit tests check small pieces, integration tests check the parts together against a real database, end-to-end tests drive the application the way a user would, and security scans check the code and its third-party dependencies. Our overview of test automation in 2026 covers the tools. User acceptance testing (UAT) is the part only you can do: people from the business run real tasks on a staging copy and confirm it does the job.
Release
Release moves tested software into production. The first release of a new system often includes data migration from spreadsheets or an old system, a cut-over plan and training. Later releases should be the opposite of an event: small changes, deployed by an automated pipeline, with a rehearsed way to roll back.
Operate and maintain
Launch starts the longest phase. Software needs monitoring, security patches, operating system and dependency updates, bug fixes, backups that have actually been restored, and a steady flow of changes as the business changes. Shortcuts taken during the build come due here as technical debt: every change takes longer and breaks more. Budget for this phase from the start and decide who is on call. If you would rather not run it yourself, hosting and maintenance keeps an application hosted, patched, backed up with restore drills and watched from the outside.
Waterfall, agile, Scrum and DevOps: how the delivery models differ
Waterfall runs the phases once, in sequence: requirements are signed off, then design, build, test and release follow. It suits work whose requirements are fixed and well understood, where change after sign-off is genuinely rare. Its weakness is timing: users see working software only at the end, which is also when misunderstandings surface and cost the most to fix.
Agile is a family of methods built on the Manifesto for Agile Software Development, written in 2001, which values working software over comprehensive documentation and responding to change over following a plan. Its twelve principles ask teams to deliver working software frequently, from every couple of weeks to every couple of months with a preference for the shorter, and for business people and developers to work together daily. For a buyer the consequence is practical: progress arrives as software you can use rather than status reports, and priorities can change between cycles.
Scrum is an agile framework with fixed roles and a fixed rhythm. The Scrum Guide, whose current edition (as of September 2026) dates from November 2020, calls it a lightweight framework. Work happens in Sprints of one month or less. A Scrum Team, typically 10 or fewer people, has one Product Owner, one Scrum Master and the Developers, and each Sprint includes Sprint Planning, a Daily Scrum, a Sprint Review and a Sprint Retrospective. The Product Owner orders the Product Backlog, and the guide is explicit that this is one person, not a committee. Work counts only when it meets the team's Definition of Done, a written description of the quality every increment must reach.
Kanban drops the fixed cycle. The Kanban Guide defines it as a strategy for optimizing the flow of value through a process: make the workflow visible, actively limit work in progress, and keep improving the flow. It suits support and maintenance work that arrives continuously rather than in planned batches.
DevOps and continuous delivery carry agile past the developer's desk into deployment and operation. The people who build the software also deploy and run it, and automation does the repetitive parts. DORA defines continuous delivery as the ability to release changes of all kinds on demand, quickly, safely and sustainably. It is not the same as continuous deployment, which pushes every change to production as soon as possible. Continuous delivery applies to all kinds of software, including firmware, mainframe systems and highly regulated environments.
| Model | How scope is planned | When you see working software | Fits when |
|---|---|---|---|
| Waterfall | All up front, then signed off | At the end | Requirements are fixed and well understood |
| Scrum | An ordered backlog, re-planned every Sprint | Every Sprint (one month or less) | A new product or workflow, where you will learn as you go |
| Kanban | A continuous queue with limited work in progress | As each item is finished | Support, maintenance and a steady stream of small changes |
| Continuous delivery | Small batches, alongside any of the above | Whenever a change is ready | Any system you plan to keep changing after launch |
Most real projects mix them: a fixed-price discovery and first phase, Scrum for the build, Kanban-style flow after launch, and continuous delivery throughout.
How to measure software delivery: DORA's five metrics
DORA, a research program run by Google Cloud, measures software delivery performance with five metrics in two groups:
- Throughput: change lead time (from a commit in version control to production), deployment frequency, and failed deployment recovery time.
- Instability: change fail rate (the share of deployments that need immediate intervention, such as a rollback or a hotfix) and deployment rework rate (unplanned deployments caused by a production incident).
DORA's research has repeatedly found that speed and stability are not a trade-off: for most teams the metrics move together, and top performers do well on all five. Batch size is the practical reason. A small change is easy to review, test and roll back, so releasing often makes each release safer, not riskier. DORA's continuous delivery guidance points the same way: keep the software deployable at all times, fix a broken build before anything else, and keep branches short-lived.
For a buyer, these metrics are questions, not targets. Ask a prospective partner how long a one-line fix takes to reach production, how often they deploy and what happens when a deployment fails. DORA itself warns against turning the metrics into goals, which invites gaming (Goodhart's law), and against comparing very different systems such as a mobile app and a mainframe: the metrics are meant for one application or service at a time.
Where security fits: NIST's Secure Software Development Framework
Security is not a phase. It is a set of practices attached to every phase. The standard reference is NIST's Secure Software Development Framework (SSDF), SP 800-218, version 1.1, published in February 2022. It starts from the observation that few SDLC models address security in detail, so its practices are meant to be added to whichever model a team uses. It is also written for buyers: purchasers can use its vocabulary to discuss security with their suppliers.
The SSDF organizes its practices into four groups:
| SSDF group | Its aim | What a buyer can ask to see |
|---|---|---|
| Prepare the Organization (PO) | People, processes and technology ready for secure development | Written security requirements for your project |
| Protect the Software (PS) | Every component protected from tampering and unauthorized access | Who can change the code and release it; a record of the components in each release |
| Produce Well-Secured Software (PW) | Releases with minimal security vulnerabilities | The threat model, code review practice, security test and dependency scan results |
| Respond to Vulnerabilities (RV) | Remaining vulnerabilities found, fixed, and prevented from recurring | How to report a vulnerability, and how quickly fixes ship |
Version 1.1 added tasks for documenting security requirements (PO.1.2), collecting and sharing provenance data for every component of a release (PS.3.2), and tracking security requirements, risks and design decisions (PW.1.2). As of September 2026 it is still the final version: a draft version 1.2, SP 800-218 Rev. 1, was published for comment in December 2025. For what these practices look like in code, see our secure coding checklist.
Important
Put security requirements in the brief and the contract, not in a later audit. A penetration test before launch can find problems, but it cannot add an access-control design the system never had.
Build, buy or configure
Before commissioning anything, check whether you need to build at all. Accounting, payroll, e-signature and email are standard processes, and products already do them well. The real choice has four options, and it is made module by module, not once for the whole system:
| Option | Fits when | What you own | Trade-off |
|---|---|---|---|
| Buy a product | The process is standard | Your data, as far as the vendor lets you export it | Subscription fees, and the vendor decides the roadmap |
| Configure a platform | A common process with your own fields and steps, such as a CRM | A configuration inside someone else's platform | Hard limits at the edges, and moving off it takes a project |
| Extend with a custom module | A product covers most needs, and one workflow sets you apart | The module and the API contract it relies on | The module must follow every change the vendor makes |
| Build | The workflow, data or rules are the business, and no product fits | Everything: code, data model, infrastructure | You fund its upkeep for as long as it runs |
The UK government's technology guidance suggests mapping the components of a service (it names Wardley mapping as one technique) to see what to build and what to buy or get for free. It also asks teams to minimize the total cost of ownership, including the risk of being locked into long contracts, and to keep full control of the data they store. Those two tests are a useful check whichever way you lean.
Custom software pays off where the workflow, the data or the rules are what set the business apart, or where no product meets your compliance needs. If the real need is to connect systems you already run, so data is entered once and stays in step, that is an integration project rather than a new application. If what you need is a marketing site, that is web design and development, a different kind of project.
What drives the cost and timeline of software
No one can price software honestly from a paragraph. A quote that arrives before anyone has studied the workflow is a price on risk, not on work. The cost follows a small set of drivers:
- Workflows and user roles. Each role (customer, staff, manager, administrator) multiplies screens, permissions and tests.
- Integrations. Every outside system, such as payments, accounting, identity or email, adds an interface to learn, failure cases to handle and a dependency to monitor.
- Data migration. Years of spreadsheets or an old database are rarely clean, and cleaning them needs business decisions, not only code.
- Quality targets and compliance. Uptime, speed, accessibility, audit trails, privacy law and industry rules each add design and testing work.
- Uncertainty. A new product idea has more unknowns than automating a process you already run by hand.
- Running costs after launch. Hosting, licences, provider fees, monitoring and maintenance continue for the life of the system.
The risk is not evenly spread. A 2022 study of 5,392 IT projects, published in the Journal of Management Information Systems, found that cost overruns follow a power-law distribution: many projects overrun a little, and a fat tail overruns enormously. The authors trace the tail to interdependencies between technical components, where a problem in one part sets off a chain reaction in others. The practical lesson is to estimate in ranges, to release a small first phase before committing to the whole, and to keep the number of moving parts in that first phase low.
That first phase is often an MVP: the smallest working release real users can rely on that still tests the business idea. It is not a prototype, which shows how something would work, and not a proof of concept, which shows that it can be built. When time runs short, cut scope before stretching the date.
The commercial model shapes who carries the risk:
| Model | How it works | Suits |
|---|---|---|
| Fixed price | An agreed scope for an agreed price | A well-understood first phase, after discovery |
| Time and materials | You pay for time spent and steer the scope as you learn | Evolving products and requirements that are still moving |
| Dedicated team | Engineers assigned to your roadmap at a monthly rate each | Long-running products that keep growing |
What a good software brief contains
A brief is not a specification. It gives a development team enough to ask good questions and to produce a scope and a price. The US government's Digital Services Playbook starts every project with understanding what people need, and the same order works for a business:
- The problem, in business terms, and what it costs today in hours, errors or lost sales. Not the solution.
- The users: the roles, roughly how many people, and the devices they use.
- Today's process, with real examples: the spreadsheets, forms and email threads.
- What the first release must do, and what can wait: must, should and won't.
- The systems it must connect to, and who controls access to each one.
- The data: what exists, where it lives, how much there is and who owns it.
- Constraints: the privacy law that applies (in Canada, PIPEDA covers private-sector organizations handling personal information in commercial activity, and Alberta, British Columbia and Quebec have their own substantially similar laws), industry rules, where data may be hosted, and accessibility. For anything on the web, WCAG 2.2 level AA is a common target, and its success criteria are written as testable statements; our WCAG guide explains the levels.
- Budget band and deadline, and what drives the deadline.
- Who decides: one named person with authority over scope and priorities.
- How you will know it worked: the measure of success six months after launch.
Tip
Attach examples. One real spreadsheet, a completed form and a forwarded email thread tell a developer more about your process than pages of description.
How to judge a software development partner
A software development company designs, builds and tests software for clients, and often hosts and maintains it afterwards. Portfolios and day rates are easy to compare. How a team works decides the outcome, and most of it can be checked before you sign. The Digital Services Playbook is a useful checklist here even outside government: it asks for a budget that includes discovery and prototyping, frequent deliverables rather than multi-month milestones, software and data that stay under the buyer's control, a warranty period for defects and a transition-out plan, with a single product owner accountable on the buyer's side.
Questions worth asking:
- How often will we see working software? Ask for demos on a staging environment you can use yourself, after every increment.
- Who owns the code, the data and the accounts? The repository, cloud accounts and domain should be yours, or transfer to you, with everything needed to build and deploy the system written down.
- How is quality built in? Ask about code review, automated tests, the staging environment and what their Definition of Done includes.
- How do you deliver and recover? Ask for their DORA metrics, or more simply how long a small fix takes to reach production and how they roll back a bad release.
- How do you handle security? Ask which SSDF practices they follow, how dependencies are scanned, and how a vulnerability reported after launch is fixed.
- How do you use AI coding assistants? DORA's 2025 report found that AI acts as an amplifier of a team's existing strengths and weaknesses, so the real question is what review and testing surround it.
- What happens after launch? Agree the warranty period, support hours, who is on call, and the runbook and handover if the work later moves elsewhere.
Where the company is based matters less than these answers. Overlapping working hours, the law that governs the contract and where your data will be hosted are the location questions that count.
If you are weighing a build, our custom software development work starts with a short, fixed-price scope and architecture sprint: the first release defined, prototyped and priced, with a written scope, a clickable prototype and a fixed price for phase one. The plan is yours even if you stop there, and if a product fits better, we will say so and help you choose it.
