Software Development Process: From Idea to Production, Step by Step

The software development process usually runs through six phases: discovery, design, development in short sprints, testing, launch, and ongoing maintenance. Below is how a project actually runs when I build a web app for a client, what happens in each phase, and what you'll need to contribute on your side.

You'll also see it called the software development life cycle (SDLC). The order is much the same for a customer portal, an internal tool and a SaaS MVP. What changes is how long each phase takes, and how much it costs you to skip one.

The short answer: six phases at a glance

Treat the durations as a rough guide for a mid-sized web app, such as a customer portal or an internal tool with a few integrations. A small tool can be done in weeks; a large platform takes longer. The phases also overlap: design continues while the first features are built, and testing runs from the first sprint to the last.

This guide is the overview. Each phase raises its own questions, and I link to deeper articles along the way. If you hit a term you don't know, my plain-English software development glossary explains it.

Before any code: discovery and design

These are the two phases people most want to skip, because they don't produce code. They're also the ones that decide whether the rest of the project stays on budget. A misunderstanding caught on a wireframe costs a conversation. The same misunderstanding caught after launch can cost weeks of rework.

Step 1: Discovery and scoping

Discovery is about understanding the problem before anyone proposes a solution. Who will use the app, and what do they need to get done? What are you using today (spreadsheets, email threads, an aging system) and where does it break? Which other tools does the new app need to talk to?

For larger builds, I always start with a paid discovery phase at a fixed price. It's a short, bounded engagement where you and I turn your idea into something concrete enough to price and plan. A good discovery phase typically produces:

• A requirements document describing what the software must do. My software requirements specification template shows what belongs in one.
• User stories: short descriptions of what a specific user needs to do, and why.
• A prioritized backlog (the ordered list of work), split into must-haves for version one and things that can wait.
• The big technical calls, such as choosing between a browser-based app, a native mobile app or something in between. I compare the options in web app vs native app vs PWA.
• An estimate and plan for version one, so you know exactly what you're agreeing to.

Why pay for it? Because the alternative is a quote built on guesswork. Without discovery, a developer either pads the price heavily or takes a gamble, and either way the cost usually lands on you. A discovery document is also useful if you're collecting quotes from several vendors, possibly in different countries: everyone prices the same brief, so you compare like with like.

Step 2: Design and prototype

Once the requirements are clear, they become something you can see. Design usually starts with simple wireframes of the key screens and user flows: how a customer logs in, finds an order and contacts support. They're deliberately plain, so the discussion stays on content and flow rather than colors.

The next step is often a clickable prototype in a tool like Figma, which you can put in front of a few real users before any code is written. If you have a designer or agency handling the visual side, this is where they come in.

In parallel, the technical foundations get laid:

• The data model: what the app stores and how it fits together.
• Roles and permissions: who can see and change what.
• The architecture. For almost every web app at the scale I work on, I recommend a single well-structured application over a set of small services. My reasoning is in monolith vs microservices.
• The stack. I typically build with Laravel and React or Next.js, and I've compared them in Laravel vs Next.js. If the term itself is new to you, start with what a tech stack is.

Two EU requirements belong in design, not in a fix-up round after launch. The first is accessibility: if your product serves consumers in the EU, the European Accessibility Act may apply, and designing for it is far cheaper than retrofitting. My guide to EU Accessibility Act requirements covers who's in scope. The second is personal data: what you store, where it's hosted and who can access it. If a vendor processes personal data on your behalf, GDPR Article 28 requires a binding contract covering that processing, usually called a data processing agreement (DPA).

Building it: sprints, demos and testing

With discovery and design in place, the build starts. It's the longest phase before launch, and it's where a good process and a bad one feel most different.

Step 3: Development in sprints

The build happens in sprints: fixed-length cycles in which a defined chunk of work gets built, tested and shown to you. The Scrum Guide caps a sprint at one month. I recommend one to two weeks, because you see progress often enough to change course before much is lost.

Every sprint follows the same rhythm:

1. Planning: you and I pick the most important items from the backlog and agree on what "done" means.
2. Building: I build and test the features and push them to a staging environment (a private test copy of the app) where you can follow along.
3. Demo: at the end of the sprint, I show you what's been built, in working software rather than slides.
4. Adjusting: your feedback and new ideas go into the backlog and get prioritized for the next sprint.

New ideas mid-project are normal. What matters is that they're weighed against what's already planned, not piled on top. On a fixed-price version one, a new feature either replaces something else or gets priced on its own. Why this usually beats a plan locked on day one is the subject of agile vs waterfall.

Throughout, you deal directly with me, the developer writing the code. There's no account manager in between, and I reply within one business day. I'm based in Denmark (Central European Time), which overlaps almost entirely with UK and EU business hours and with mornings on the US East Coast. The code is yours from day one, and it should live in a repository you can access.

Most projects also need to talk to other tools: Stripe for payments, HubSpot or another CRM, Xero or whichever accounting system you use. That happens through an API, which I explain without the jargon in what is an API. Integrations are where estimates most often slip, because third-party systems rarely behave exactly as documented.

Step 4: Testing and acceptance testing

Testing isn't a phase that starts when development ends. It runs in three layers throughout:

• Automated tests are written alongside the code and run on every change. They catch the new feature that quietly breaks an old one. I explain the business case in why automated testing saves money.
• Security and performance get checked continuously: login, permissions, input validation and how the app copes with realistic data volumes. The OWASP Top 10 is the standard starting point for common web vulnerabilities, and my web application security checklist makes it practical.
• User acceptance testing (UAT) is yours. You and a few real users run through the tasks the app was built for, with real data, and sign off that it works.

UAT isn't clicking around to see if anything looks off. It works best when the acceptance criteria are written up front, usually straight from the user stories in discovery: "As a support agent, I can find an order by the customer's phone number." Either you can, or you can't.

Launch and maintenance

The last two phases are about getting the app safely into users' hands and keeping it healthy afterwards.

Step 5: Launch

A good launch is boring. It's planned well enough that nothing dramatic happens. A typical sequence looks like this:

1. Write a launch plan with a date, clear responsibilities and a rollback plan for getting back to the old setup if something goes wrong.
2. Migrate data from the old system or spreadsheets. Do a trial run first, and check the result with someone who knows the data.
3. Set up production: hosting, domain, SSL certificate, transactional email, backups and monitoring. Everything is tested before launch day.
4. If you can, start with a smaller group of users before opening it to everyone.
5. Hand over access and documentation, so nothing depends on one person's memory. My software documentation checklist lists what should be written down.

My rule of thumb: launch early in the week, never on a Friday afternoon. Set aside time in the first days after launch for small fixes and user questions.

Step 6: Maintenance and ongoing development

Once the app is live, the longest phase begins. Software doesn't stand still: frameworks and packages get security updates, browsers change, and the services you integrate with get updated by people who aren't you. Maintenance typically covers updates, monitoring, backups that are actually test-restored, and fast help when something breaks. I go through what that involves in web application maintenance.

Ongoing development is the other half. A few months with real users usually teaches you more than all of discovery, and the backlog fills up with requests from actual use. This is where keeping the code healthy matters, so each new feature doesn't cost more than the last. That's what technical debt is about, and you can watch for the signs of a healthy codebase yourself, even without a technical background.

So agree on maintenance before launch, not on the day something goes down.

What you need to bring to the project

Your own input is the part of the budget that rarely appears in a quote, yet it sets much of the pace. Here's what needs to be in place on your side:

• A decision-maker. One person who knows the business, has the authority to say yes or no, and can answer within a day or two. Projects run by committee move slower.
• Time. As a rule of thumb, plan for a few hours a week during development for demos, questions and prioritizing. Discovery and acceptance testing need more.
• Business knowledge. The processes, exceptions and edge cases that only exist in your team's heads. They're what make software usable day to day.
• Access. To existing systems, data, your domain and the accounts that integrations need. Share passwords and API keys through a password manager, never by email.
• Content. Copy, images, help text, terms and email templates.
• Test users. A handful of real users willing to look at the prototype and take part in acceptance testing.

If you can't commit that time right now, it's better to wait than to start half-heartedly. A developer waiting a week for an answer either stops or builds on a guess, and neither is good for your budget.

How long it takes and what drives the cost

As a rough guide, a small internal tool with a handful of screens can be built in a few weeks. A first version of a customer portal, an MVP (the first, deliberately minimal version of a product) or an internal system with a couple of integrations often takes two to six months from discovery to launch. Larger platforms with many user roles take longer and are usually launched in stages.

The factors that push time and cost up most:

• The number of user roles, and how different their needs are.
• Integrations with other systems, especially older ones with patchy documentation.
• Migrating messy data from a legacy system.
• Requirements for design, accessibility, compliance and documentation.
• How quickly decisions get made.

That last one is the only factor you fully control, and it's often what separates a timeline that holds from one that slips.

Pricing follows the phases. Discovery has a fixed price. Once it's done, a fixed price or a narrow range for version one becomes realistic, because the guesswork is gone. Maintenance and ongoing work are usually billed monthly or by the hour. You can see how I structure my fees on my pricing page.

When this process isn't the right fit

Six phases sounds like a lot, and for some jobs it is. The process should scale to the work, and sometimes the honest answer is that you shouldn't build anything at all:

• Small, well-defined jobs, such as one new integration or a fix in an existing app, don't need a discovery phase. A short brief and an estimate are enough.
• If an off-the-shelf SaaS covers most of what you need, buying is often cheaper than building. An honest discovery phase should be able to reach that conclusion too.
• If design, copywriting, research and development all need to happen at once on a tight deadline, an agency or software house with a full team may suit you better than a freelancer. I'm one developer: that means direct contact and short decision paths, but not five people working in parallel.
• If you need daily real-time collaboration during US Pacific working hours, a developer in your own time zone will serve you better.
• If the software is your core business and needs full-time development for years, you should eventually hire your own team. A freelancer can still build version one and help with the handover.

Next steps: how to get started

You don't need a finished specification to take the first step. You'll get moving faster, though, if you've thought about the questions below.

If you can answer most of these, you're ready for a first conversation. If some are still open, that's exactly what discovery is for. On my page about custom web app development, you can see the kinds of systems I build and how a project with me gets started.

Frequently asked questions

Is the software development process the same as the SDLC?+

In practice, yes. SDLC stands for software development life cycle, the umbrella term for the phases software goes through from idea to retirement. Formal SDLC models such as waterfall, the V-model or iterative approaches name and group the phases differently. The six steps in this guide are a practical version of the same idea, tuned for small and mid-sized web app projects.

Do I need a full specification before I contact a developer?+

No. A short description of the problem, the users and what you use today is enough for a first conversation. The detailed requirements are written during discovery, where a developer can ask the questions that expose gaps. If you already have something in writing, send it along anyway, because it makes the first call more focused.

Who owns the code while the project is running?+

That's down to your contract, so settle it in writing before work starts. My clients own the code from day one. In many countries, copyright in code written by an independent contractor stays with the contractor unless the contract assigns it to you, unlike code written by an employee. This isn't legal advice, so have the contract reviewed if a lot is at stake.

Can a project go faster if more developers join?+

Rarely, once it's under way. New developers need time to learn the codebase and the business, and coordination takes time away from the people already building. What usually helps more is cutting version one down to essentials and making decisions faster. Starting with a larger team can work on big projects that split cleanly into independent parts.