Clients commissioning software for the first time usually have one of two pictures in their head: “developers sit and type code” (too simple) or “agile methodology with ceremonies, retrospectives, and scrum masters” (too complicated). The real process is somewhere in between — structured but not bureaucratic, predictable but flexible.

This post breaks down what the software development process actually looks like, from the first conversation to production. What happens each week, who’s involved, what decisions get made, and where time is most often lost. If you’re preparing for your first development project, this is the map of the terrain.

The full process at a glance

A standard development project for a web application has 7 clear phases:

Phase	Duration	Key questions
1. Initial conversation	1 hour	Who you are, what you’re building, is this a fit
2. Discovery	1 – 3 weeks	What we’re building and why
3. Design	2 – 6 weeks	How it’ll look and behave
4. Development	6 – 24 weeks	The actual build
5. QA and testing	1 – 3 weeks	Does it do what it should
6. Launch	1 – 2 weeks	Move to production
7. Stabilisation and support	1 – 6 months	Real usage, fixes, evolution

Phases overlap partially — design and development run in parallel after the first two weeks, QA happens continuously through development plus a dedicated block at the end, and support starts immediately after launch.

Phase 1: Initial conversation

What happens: the first conversation between you and the team. Typically 45 to 60 minutes. The purpose isn’t sales — it’s checking the fit.

Who’s involved: you and the founder / tech lead from the team. On serious projects, sometimes the product lead too.

What you should be talking about:

Your business, what you do, who your customers are
The problem you’re solving with the product
What’s already built, what already exists
A real budget (don’t hide this)
A real deadline
Who’ll be your point of contact

What you should be asking:

Do they have similar projects in their portfolio?
Who specifically would work on your project?
How are they structured — internal team, freelancers, mix?
What’s their specialty?

Red flags in the initial conversation: a team that knows exactly what the project will cost before you’ve described in detail what you’re building. A team that proposes technology before they’ve understood the problem. A team that pressures you “to sign quickly.”

Green flags: a team that asks uncomfortable questions (“why do you think this is a good idea?”), suggests discovery before a serious quote, and is transparent about what they don’t do.

Phase 2: Discovery

What happens: detailed conversation about the problem, users, flows, and technical decisions. The goal is to land on a document that precisely describes what you’re building and what you’re not building.

Who’s involved: you (as product owner), product manager or tech lead from the team, possibly a UX designer for early sketches.

Typical flow (10 working days):

Days 1 – 2: Workshop or 2 to 3 sessions. Goals, users, key flows are mapped.
Days 3 – 5: The team does internal analysis. Detailed technical specification, risk identification.
Days 6 – 7: Draft presentation back to you. Conversation about trade-offs.
Days 8 – 10: Document finalisation. Agreement on scope, cost, timeline, “not doing.”

Concrete outputs of this phase:

A scope document (3 – 10 pages)
A map of user flows
A technical architecture (high-level)
A “not doing” list for v1
A realistic estimate of duration and cost
A communication and decision plan

Cost: $1,800 – $6,000 depending on project size. Often partially credited if you continue with development.

The biggest trap: skipping discovery “to save time.” The week you save here usually turns into 4 to 8 weeks of later problems when decisions have to be made on the fly. Discovery isn’t bureaucracy — it’s the highest-ROI investment in the entire project.

Phase 3: Design

What happens: turning scope into a visual solution. Three sub-phases that run in order:

Wireframes (1 – 2 weeks)

Low fidelity. Boxes and text. The goal isn’t to look good — the goal is to define structure and layout. Which elements go where, in what order the user moves through the product, what information shows up.

Wireframes get done fast and revised fast. Five iterations in two weeks isn’t unusual.

UI design (2 – 4 weeks)

High fidelity. The final look. Colours, typography, photography, icons, micro-animations. This is what you’ll show colleagues, what goes into the portfolio, what gives the product its personality.

Typically the team designs 3 to 5 key screens first, you review, give feedback. The designer iterates, finalises, then moves to secondary screens.

Clickable prototype (1 week, parallel)

In Figma, the screens get linked into a clickable prototype — you can walk through the entire user flow “as if it were the real product,” even though there’s nothing functional underneath.

The point of the prototype: testing with real users before any code is written. Five conversations with real users at this stage can save 10 weeks of building the wrong functionality.

Who’s involved: UI/UX designer, you, product manager, possibly tech lead for feasibility checks.

The biggest trap: designing every screen before development starts. Development can begin once enough screens are done to cover the core user flow. Secondary screens get designed in parallel with the build.

Phase 4: Development

The biggest block. Structured in two-week sprints. A typical project goes through 4 to 12 sprints depending on size.

Sprint structure

Every sprint has the same structure:

Monday of week 1: Sprint planning. Agreement on what gets built.
Through both weeks: Development happens. Daily syncs (15 minutes) among developers.
Friday of week 2: Demo. The team shows what was built.
Friday of week 2 (later): Retrospective. What worked, what to improve.

A typical sprint plan

For a standard B2B application (8 to 10 sprints):

Sprint 0: Environment setup, infrastructure, database, deployment pipeline
Sprint 1: Authentication, core user flow end to end
Sprint 2: Secondary features, first integrations
Sprint 3: Admin area, reports
Sprint 4: Payments, email, notifications
Sprint 5: Optimisation, polish, edge cases
Sprint 6: Final features, integration testing
Sprint 7: QA and bugfixing
Sprint 8: Launch preparation

Questions that come up every sprint

What’s blocking the team and needs your input? Has to be answered within 24 hours.
What assumption turned out to be wrong? The reset has to happen early.
What needs to be deferred to the next sprint? Better to know early than late.

Who’s involved: developers (frontend, backend), tech lead, project manager, you (as decision-maker), QA engineer.

Your obligation during development: showing up to demos (every sprint), making decisions quickly, being available for questions, being open to scope adjustment when data calls for it.

Phase 5: QA and testing

What happens: dedicated testing of the entire system. Functional, performance, security, accessibility.

What specifically gets done:

Functional testing: walking through every feature, every screen, every action. Checking it all works as it should.
Cross-browser and cross-device testing: Chrome, Safari, Firefox, mobile, tablet.
Performance testing: how fast key pages load, how the system behaves under load.
Security review: input validation, authentication, authorisation, common attacks.
Accessibility: keyboard navigation, screen readers, contrast.
User Acceptance Testing (UAT): you and your team try the application as users.

Who’s involved: QA engineer, developers (for bug fixing), you and your team for UAT.

Duration: 1 to 3 weeks depending on size.

The biggest trap: squeezing QA when development was running late. If QA gets compressed from 12 days to 3, the critical bugs that should have been caught here surface in the first week of production — and cost 5 to 10 times more to fix.

Phase 6: Launch

What happens: moving the system from staging to production.

Steps:

Production environment setup: server, database, CDN, email
DNS and SSL configuration: your domain points at the new server, HTTPS active
Monitoring setup: uptime, error tracking, performance baseline
Backup procedures: tested and confirmed
Internal training: how to use admin
User documentation: ready instructions for users
Communication plan: how launch is announced, what support you provide in the first days

Who’s involved: DevOps / tech lead, project manager, you for final sign-off.

Duration: 1 to 2 weeks.

The biggest trap: treating deployment as “just flipping a switch.” Real production behaves differently from staging — real traffic, real data, real users. A week dedicated to preparation typically saves three weeks of post-launch firefighting.

Phase 7: Stabilisation and support

First 30 days: typically “warranty support” — the team fixes any bugs they introduced, no extra charge. Fast response to issues real users discover in real usage.

Week 1 post-launch: triage. The team logs everything that happened, prioritises urgent issues, fixes critical bugs within 24 hours.

Weeks 2 – 4: collecting feedback. User conversations, data review, identifying things that don’t work the way they thought.

Month 2 onward: shift to retainer or planned development. Product iterations happen based on what the real data shows.

The biggest trap: thinking the project ends at launch. Real products are never “done.” Applications without a support plan typically become unstable within 6 to 12 months because nobody’s running security updates, responding to performance drift, or fixing minor bugs before they grow into bigger ones.

Things that happen across all phases

Three activities aren’t tied to a single phase — they run through the whole project:

Project management

Someone has to coordinate: plan sprints, run meetings, escalate blockers, keep budget and timeline in check. On smaller projects, this falls to the tech lead. On larger ones, you have a dedicated project manager. Without this role, projects typically slip 30 to 50 % without any specific “bad event” — just slow loss of focus.

Communication with you

Weekly statuses (5 minutes of writing), demos at the end of sprints, Slack-style channel for real-time questions. Communication isn’t bureaucracy — it’s the reason you, as the client, know what’s happening at all.

Documentation

Technical (how the system works), user-facing (how a user uses the app), runbook for your team (what to do when something breaks). Done through the project, not as a forgotten task at the end.

How you affect the speed

Half the impact on project duration is in the team’s hands. The other half is in yours:

Name a single product owner — not a committee
Respond to questions within 24 hours — make this a commitment
Show up to demos prepared — actively click, give feedback
Make decisions once and stick with them — reversing decisions is the biggest velocity killer
Keep all questions in one place — Slack, Notion, Trello — pick one

Clients who do this typically have projects that run 30 to 50 % faster. Clients who don’t — the project slips, even if the team is doing everything right.

The bottom line

Software development is 7 phases that overlap partially: initial conversation, discovery, design, development (in sprints), QA, launch, stabilisation. Each has its own purpose, participants, concrete outputs, and typical traps.

Development itself is only half the work. The other phases aren’t bureaucracy — they determine whether the product actually works in the hands of users, how much you’ll pay later for fixing what was missed, and how long the application will last before needing a major rebuild.

The biggest trap we see: clients who want to skip discovery “because it’s obvious what we’re building.” Then during development, 5 ambiguities surface, each costs a week, and a project that should have been 12 weeks runs to 18. A week in discovery saves a month in development — almost every time.

Considering development and want a clear picture of the process? We can walk through the entire process with you — from discovery to launch — and help you realistically estimate scope, duration, and the level of involvement you’ll need. Get in touch. More about our approach on the Software Development page.

What the Software Development Process Actually Looks Like (Step by Step)