Software Development Process: The Seven Steps Behind Every Project We Ship

A software development process is the order a project moves through — requirements, architecture, design, build, testing, release, support. A methodology is the rule set you run on top of that order: Waterfall, Agile, iterative, or a hybrid nobody has a name for. Teams argue endlessly about the second one and quietly lose money on the first, which is why two vendors running the same software development process can quote you numbers that are nowhere near each other. We have closed a $5,000 estimate at $3,000 and watched a $3,000 one finish at $12,000. The methodology was not what moved either number.

What moved them was how much of the system existed on paper before anyone opened an editor. That is the honest version of this topic, and it is the version most guides to development methodologies skip because it makes for a shorter article. Below: the seven steps as we actually run them with durations and costs attached, what belongs inside an srs document, how to split requirements so the split survives development, and where each methodology earns its keep.

What Is Software Development Methodology, And Where Teams Confuse It With Process

Ask five vendors what is software development methodology and you get five definitions that all orbit the same idea. A methodology is an agreement about how work gets organised: who decides scope, how often it can change, when the client sees something running, and what counts as done. It answers questions about coordination.

The process answers a different question — what happens, in what order, to turn a requirement into shipped code. Every project has one whether or not anyone wrote it down. The projects that go badly usually have a very confident methodology sitting on top of a software development process nobody defined.

That distinction matters commercially. Development methodologies are free to swap. You can run the same backlog through Scrum or Kanban and the cost barely moves. Changing the process — adding a discovery phase, writing specs before the build, freezing scope at a checkpoint — changes the bill by multiples. When founders shop around for software methods and pick a vendor on "we're fully Agile," they are choosing the variable that matters least.

The Software Development Process Steps, In The Order They Happen

Here is the software development process we run, end to end. Durations and prices come from our own delivery practice, not from a market average.

1. 1
   Discovery & requirements$1k–1.5k · 5 days
2. 2
   SRS & scope agreementinside discovery
3. 3
   Architecture & environment setup~$2k · 5 days
4. 4
   UI/UX design (runs in parallel)2–3 weeks
5. 5
   Iterative build → MVP$2k–10k · 2–8 wk
6. 6
   QA — parallel, on request$20/hour
7. 7
   Support & iteration$700–1.5k/mo

Those are the software development process steps in the order they appear on a real invoice. A few of them deserve more than a line.

Discovery Is Not A Formality

Five business days, $1,000 to $1,500. We spend it on product analysis, competitor work, and picking the technical approach. Clients sometimes ask to skip it and start building on Monday. We have done that, and it is where the real-estate project below went from $3,000 to $12,000.

Design Runs Beside The Build, Not In Front Of It

Design takes two to three weeks on a typical project, and the clock starts when development starts — the two run in parallel rather than one waiting on the other. Screens land ahead of the engineers who need them, and nobody sits idle for a fortnight waiting on a Figma file.

QA Does Not Wait For A Release Date

We bring QA in on request or when the scope calls for it, at $20 an hour covering manual testing and basic automated coverage. In our software development process QA runs alongside development instead of sitting as a phase at the end — a feature gets checked as soon as it is built. That is why our timelines have no two-week testing block bolted onto the finish. A bug caught the same week costs an hour. The same bug caught after a launch date has been promised costs a renegotiation.

The Build Is The Part Everyone Overestimates

An MVP runs two to eight weeks at $2,000 to $10,000. That is a smaller share of a project than most founders expect. Coding is the cheap part when the specification holds. It becomes expensive only when the team has to stop and ask what a screen is supposed to do.

The SRS Document Is Where Your Budget Actually Gets Decided

A software requirements specification — the srs document — is the written description of what the system must do and how it must behave. It is not paperwork for a compliance file. It is the artefact that decides whether your team builds a feature once or rebuilds it twice.

We saw this at its cleanest on an automation project for a food producer. They arrived with page structures mapped, workflows written out, and a database schema ready. We had estimated $5,000 over three weeks. It closed at $3,000 in one week. Nothing clever happened during that build. There was simply nothing left to guess about, so there was nothing to re-do.

What Belongs Inside An SRS Document

• Scope and system boundaries — what the software does, and explicitly what it does not
• User roles and permissions — who touches what, and what each role cannot reach
• Workflows end to end — the full path of each process, including the states nobody likes to think about
• Data model and sources — where data comes from, what shape it arrives in, who owns it
• Integrations — every external system, with auth method and rate limits
• Acceptance criteria — the condition under which a feature counts as finished

An srs document does not need to be beautiful. It needs to be specific enough that two engineers reading the same paragraph build the same thing.

Here is how we handle ours. The spec is written to roughly 50% before development starts — enough to lock scope, architecture, and the data model — then it fills in as the build progresses and questions get answered by working software. The srs document lives in Notion, described down to individual pages and buttons, so a client can look up what a screen does without booking a call with an engineer.

Functional Requirements vs Non Functional Requirements

The functional requirements vs non functional requirements split is the one clients most often get wrong, and it costs them at the worst possible moment — after the build, when the system works but does not hold.

Functional requirements are easy to collect because clients already know them. Non-functional ones need dragging out with direct questions. How many users on day one, and after a year of growth? What happens if a third-party API is down for six hours? Who is legally responsible for the data? We ask these during discovery because the answers shape architecture, and architecture is the thing you cannot cheaply change later.

Development Methodologies, And Which Project Each One Suits

Every vendor claims Agile. Most run something looser. Here is the practical version of the four approaches you will actually be offered.

Agile Methodology Steps, Stripped Of The Ceremony

The agile methodology steps are simpler than the certification market suggests: build a backlog, order it by value, pull a slice into a fixed-length cycle, ship something usable at the end of it, review with the client, reorder, repeat. Everything else — the ceremonies, the boards, the terminology — is decoration around that loop.

On our projects a sprint runs one or two weeks, set by how long the whole engagement is. That cadence is closer to iterative development than to textbook Scrum. Stand-ups happen daily or every second day. The team posts written status in Slack every day, so nobody has to ask where things stand. Each sprint closes with a demo and a written summary of what shipped and how the project is tracking overall.

Agile earns its cost when the client is genuinely available. Sprint reviews with nobody in the room turn into a vendor guessing at priorities on the client's behalf, which is the most expensive form of guessing there is.

Where Iterative Development Earns Its Money

Iterative development means you get something running early and grow it in passes instead of waiting for a complete system. On AI work iterative development is the only sane approach — a retrieval system's real behaviour on your data is not something anyone can specify in advance. You build a thin version, look at what it returns, and adjust.

The failure mode is treating iteration as permission to start vague. It is not. Iterative development narrows uncertainty about behaviour. It does nothing for uncertainty about scope, and scope is what inflates budgets. Our fintech MVP ran iteratively and came in under estimate precisely because the scope was pinned down before the first iteration.

A Software Development Methodology Example From Three Of Our Builds

Theory is cheap. Here is a software development methodology example in three versions — same company, same engineers, very different outcomes, and the variable is always how much was decided up front.

One pattern holds across all three. When the client arrives with an incomplete product vision, undefined workflows, or missing architecture, cost and timeline climb. When requirements are settled at the start, projects land on estimate and sometimes under it.

Building A Software Development Strategy That Survives First Contact

A software development strategy is not a methodology choice. It sits above the choice of methodology: a set of decisions about what you pin down before you start spending, and where you deliberately leave room to move. Get the software development strategy right and the framework underneath it stops mattering much.

1. Write the workflows down. A workflow that lives in a founder's head becomes a rework loop the first time it meets code. This is the single highest-return hour you can spend.
2. Answer the non-functional questions early. Load, uptime, data ownership, compliance. These shape architecture, and architecture is not cheap to revisit.
3. Fix the boundary, float the details. Lock what the system is and is not responsible for. Leave individual screens open to change — that is what iteration is for.
4. Buy discovery before you buy development. A $1,000–$1,500 research phase routinely saves several times that. It is the least glamorous line on an invoice and the one with the best return.
5. Name a decision-maker. One person on the client side who can approve scope inside a day. Projects stall on availability far more often than on engineering.

How Our Team Runs This

We are not methodology purists and we will not pitch you a framework. What we do is refuse to give a stable estimate for an unstable project — the message we send during early alignment is usually some version of: the idea is clear at a product level but not yet at a system level, so any number we give you now will move during the build.

So our software development process starts with workflows, data structure, and integration points, and the quote comes after them. A team assembles and starts inside three to seven days, project management is included at no extra cost, and roughly 70% of our engineers carry five or more years of corporate experience — which mostly shows up as fewer questions needing escalation. Fifty-plus engineers across the stack below.

We track work in our own system rather than Jira. Same idea, with one difference that matters to clients: the project's budget and scope live inside the tracker next to the tickets. You can see what has been spent against what was agreed without waiting for a status report to be assembled. No methodology on the list of development methodologies gives you that — it is a tooling decision, and it is the one clients notice first.

Related reading: what a mobile build costs stage by stage, how long each phase actually takes, and AI development cost. For automation work specifically, see business process automation.