Implementation Phase of SDLC: Steps, Roles and an Example

The implementation phase of the SDLC is the part where engineers build what the design describes. They write the code and its tests one small piece at a time, and each piece reaches the main branch only after another engineer has reviewed it.

It's the fourth of the seven phases of the software development life cycle, after design and before testing. You'll also see it called the development phase or the coding phase. It's the same work.

The worked example is a made-up invoicing tool for a plumbing firm with a dozen staff, picked up on the day its design is signed off.

What the implementation phase is for

The implementation phase turns an agreed design into working code that has been reviewed and merged into the main branch, ready for the testing phase.

It isn't the place to make design decisions.

When the code exposes a question the design doc doesn't answer, someone with the authority to decide answers it the same day, and the answer gets written down.

Implementation versus deployment

Not every guide uses the word this way. The US Department of Justice's SDLC guidance from January 2003 has a development phase for coding and testing the software and, two phases later, an implementation phase in which the tested system is installed and made operational in production.

This series calls that second meaning the deployment phase. Here, implementation means writing the code.

Inputs and deliverable

The implementation phase starts from what the design and requirements phases handed over and ends with reviewed, merged code for the testing phase.

It needs four inputs.

• A ranked backlog - User stories with acceptance criteria, the top few estimated and meeting the team's definition of ready.

• The design doc - The data model, the architecture sketch and the API contract.

• Wireframes and a clickable prototype - What each screen shows and does.

• A definition of done - What finished means for a story, agreed before the first one starts.

The deliverable is code on the main branch that passes its automated tests, with a reviewer's approval on every change and a demo behind every finished story. Work that isn't ready for users stays switched off behind a feature flag.

Who leads and who takes part

The engineering lead runs the implementation phase, and the engineers do most of the work.

• Engineering lead - Sets the review rules and the branching approach, and settles technical questions. When the build breaks, fixing it comes first.

• Engineers - Break stories into tasks, write the code and its unit tests, and review each other's pull requests.

• PM - Answers questions the same day, keeps the backlog ranked and accepts each story at the demo against its acceptance criteria.

• Designer - Answers questions about the screens and checks what got built against the wireframes.

• QA - Writes test cases from the acceptance criteria while the code is written, so testing doesn't start from zero.

• The customer - Watches the demo. For the invoicing tool, that's the office manager.

The engineers I'd want in this phase ask why a story matters before they ask how to build it, which is what I mean by product thinking.

If you can read a pull request, you can catch a wrong assumption in review, days before it would show up at the demo.

Steps in the implementation phase

The implementation phase is a one-time setup followed by the same short loop for every story.

1. Set up the pipeline. The repository, a test environment and an automated build that runs the tests on every change.

2. Build a thin slice end to end. One screen, the tables behind it and a call to an outside service, running in the test environment. It proves the architecture before anyone polishes a screen.

3. Take the top story and branch. Keep the branch short-lived, measured in hours or a day, not weeks.

4. Write the code and its unit tests together. The tests go in the same pull request as the code they cover.

5. Open a small pull request. Google's public code review guide says 100 lines is usually a reasonable size for a change and 1,000 lines is usually too large, though it leaves the call to the reviewer.

6. Review and merge. The same guide says reviewers should favor approving a change once it definitely improves the overall health of the code, even if it isn't perfect. Changes requested go back to step 4.

7. Demo and accept. At the end of the sprint the PM checks each story against its acceptance criteria. A story that isn't done goes back on the backlog.

The diagram as text

• The top story from the ranked backlog goes to a short-lived branch.
• The code and its unit tests go up together as a small pull request.
• Review sends requested changes back to the code, or approves the change.
• Approved code merges to the main branch, behind a feature flag until it's ready for users.
• At the sprint demo the PM accepts the story; a story that isn't done goes back on the backlog.

Agile versus waterfall implementation

In waterfall the implementation phase happens once, for the whole system, while in agile it happens inside every sprint, one story at a time.

Waterfall signs off the full design before the build starts, and testing waits until the code is complete. A misunderstanding in the design can stay hidden until the code finally meets the tests.

In agile each sprint ends with working, reviewed code that the customer has seen. The Scrum Guide's rule is that work can't count as part of an Increment unless it meets the Definition of Done, and an item that doesn't meet it returns to the Product Backlog.

I think that rule is where the differences between agile and waterfall matter most, because it decides how long a wrong assumption can survive.

The invoicing tool at this phase

The engineers start the invoicing tool from the design doc's four entities (customers, jobs, invoices and payments) and the office manager's top story.

Sprint one is the thin slice. The job list shows a handful of the firm's past jobs loaded into the database, one button turns a job into a draft invoice, and the email service sends it to a test inbox.

Sprint two is the top story, turning a completed job into an invoice without retyping the customer's details. The tax and totals logic goes in with its unit tests in the same pull request, and the invoice goes out as a PDF by email.

Halfway through, an engineer finds jobs done at a rented house where the bill goes to the landlord. The design doc doesn't say which address the invoice carries.

The PM asks the office manager that afternoon. Her answer is the landlord's address at the top and the house's under the job. The PM adds it to the acceptance criteria, and the engineer carries on the next morning.

The invoice editor merges behind a feature flag that stays off until the release. A later sprint adds the payment link, once the office manager has sent real invoices, behind its own flag.

At each demo the office manager tries the build on a few of last week's jobs. The PM accepts a story only when it meets its criteria, so the tax rate has to be right and the PDF has to arrive.

The testing phase gets reviewed, merged code, unit tests on the tax and totals logic and a written list of known gaps.

Common mistakes in the implementation phase

Most of the implementation phase mistakes I'd watch for come from changes too big to review and questions nobody asks.

• Long-lived branches - A branch that lives for weeks turns the merge into its own project. DORA, a program run by Google Cloud, says its 2016 and 2017 data shows higher software delivery and operational performance in teams that keep three or fewer active branches, merge into trunk at least once a day and have no code freezes or integration phases.

• Pull requests too big to review - A reviewer handed a week of changes at once skims them. Split the story or split the change.

• Design decisions made in code - An engineer who guesses at a question the design doesn't answer has made a product decision nobody will review. Ask, then write the answer down.

• Over-engineering - Building the invoicing tool for every plumbing firm in the country when one firm will use it. The KISS principle says to build it only as complicated as one firm's invoices force it to be.

What AI changes in the implementation phase

AI coding agents can take a story and come back with a pull request, which moves an engineer's time toward specifying changes and reviewing them.

GitHub says Copilot on GitHub.com can research a repository, plan changes and implement them in the background, editing files and running tests and linters in a cloud environment.

The same page warns that Copilot can produce incorrect or suboptimal code, including code with security vulnerabilities, and says to review and test it before using it in production. Anthropic tells Claude Code users they're responsible for reviewing the code and commands it proposes before approving them.

The 2025 DORA report, drawing on survey responses from nearly 5,000 technology professionals, found that, unlike the year before, AI adoption was linked to higher software delivery throughput, and that it was still linked to lower delivery stability. DORA's reading is that without strong automated testing, mature version control practices and fast feedback loops, more change volume leads to instability.

I read that as the case for small pull requests, tests in the same change and short-lived branches. They give a reviewer a small, tested change to read, which matters more when an agent wrote it.

For the PM, the story becomes the spec an agent works from. Vague acceptance criteria used to cost a conversation. Now they cost a pull request that does the wrong thing.

If what you're implementing is itself an AI agent, the build also needs evaluation, which this cost breakdown for a custom AI agent prices as its own line item.

Implementation phase checklist

Run this implementation phase checklist before the first story starts and again before you hand over to testing.

Before the first story:

• The top stories have acceptance criteria and estimates.

• The design doc answers the data model and API questions.

• The pipeline runs the tests on every change.

• The team has agreed what done means.

Before the handover to testing:

• Every story reached the main branch through a reviewed pull request.

• The unit tests pass on the main branch.

• Unfinished features sit behind a flag that's switched off.

• The PM has accepted each story at a demo.

• Known gaps are written down for QA.