How software development works — from idea to live product

Starting a software project feels like a black box to many clients. You know what you want — a platform, an app, an internal system — but you do not know exactly how to get from that idea to a working product. Or what needs to happen in between.

What follows is an honest walkthrough of the entire journey: what happens in each phase, how long it takes, what you as a client need to contribute, and where most surprises come from.

Phase 1: Discovery and requirements (2–4 weeks)

Before a single line of code is written, it must be clear precisely what needs to be built — and why. That sounds obvious, but most projects that go wrong already go wrong here.

In the discovery phase, the agency investigates your business context, your users, the technical environment (existing systems, connections, data structures), and the actual scope of the project. The result is a detailed specification: who the users are, which flows they go through, which decisions they need to be able to make in the system, and what the technical architecture looks like.

What you do in this phase: be available. Interviews with you and your team members, sometimes also with customers or end users. Providing documents about your current situation. Giving feedback on draft scopes. This is not a passive phase for the client.

What you get out of it: a specification that also forms the basis for the quote. Agencies that skip this phase give estimates based on assumptions — and those almost never hold.

Phase 2: Design and UX (2–4 weeks, sometimes parallel to development)

Once the requirements are clear, the product is worked out visually. This goes beyond colours and logos: a good UX phase determines how users move through the system, what information they see at what moment, and how the interface makes complex functionality understandable.

In practice, a designer produces wireframes — schematic versions of each page or screen — and then visual prototypes. Modern tools like Figma make it possible to click through a prototype as if it already works, long before a developer has been involved.

What you do in this phase: give feedback on wireframes and prototypes. This is the moment to say what you do not understand, what does not seem right, or what is missing. That is free now; if it has to be adjusted in the build phase, it costs time and money.

Common mistake: clients in this phase look at the visual style rather than the logic. "The colours look nice" says nothing about whether the system works logically. Focus on the flows.

Phase 3: Development (8–24 weeks depending on scope)

The build phase is the longest phase, and for most clients the most opaque. Developers work on the frontend (what the user sees), the backend (the logic and data behind it), and integrations (connections with other systems).

In an agile approach — nowadays the standard at serious agencies — developers work in sprints of one or two weeks. At the end of each sprint you see working software. Not a report or a presentation: actual, clickable functionality.

What you do in this phase: attend sprint reviews, answer questions when something is unclear, and set priorities when the scope comes under pressure. You do not need technical knowledge, but you must be available. A client who does not respond for two weeks is blocking a team of four developers.

What teams encounter: unforeseen technical complexity (an integration that works differently than documented, a data structure that requires adjustment), scope expansion that does not fit the original planning, and dependencies on external parties (payment providers, government APIs) that cause delays.

Phase 4: Testing and quality control (2–4 weeks)

Testing is not a phase you add at the end; it starts with the first sprint. But before software goes live, a more intensive testing period follows.

Professional agencies work with automated tests (code that tests other code), manual acceptance tests (a tester goes through all scenarios), and user tests (real users or internal testers trying the product). Bugs are registered, prioritised, and resolved.

What you do in this phase: conduct user acceptance tests (UAT). You and your team test the system from your own reality — with real data, in real scenarios. You know the edge cases that an external tester will never think of.

Realistic expectation: there are always bugs. The question is not whether you find bugs, but how quickly they are resolved and how serious they are. A system is never one hundred per cent error-free; the point is that the critical paths work and the rest is prioritised.

Phase 5: Deployment and go-live (1–2 weeks)

The software goes live. This sounds simple, but there are multiple steps: setting up the production environment, migrating data (if there is legacy data to be transferred), loading the system incrementally, and monitoring whether everything remains stable.

Good agencies do a "soft launch" or "staged rollout": the system goes live for a small group of users before the broader population can access it. This catches problems at scale early.

What you do in this phase: handle communication to your users or employees, make training or documentation available, and be present when questions or problems arise directly after go-live.

Common mistake: clients expect go-live to be the end point. It is not. The first weeks after go-live are intensive: users discover things that testers never tested, peak load reveals bottlenecks, and feedback flows in.

Phase 6: Management and further development (ongoing)

Software is not a product you buy and forget. It needs maintenance: security updates, updates to libraries and frameworks, monitoring of availability and performance, and adjustments as the business changes.

Good agencies offer a maintenance contract or retainer arrangement: a fixed monthly amount for management and an agreed capacity for further development. This prevents you from having to request a new quote every time for small adjustments.

The three questions to ask upfront:

Who owns the code and the infrastructure?

What are the costs if you want to expand later or switch to another provider?

How does the agency handle security vulnerabilities discovered after the fact?

Timeline and budget: realistic expectations

A typical project for a medium-sized software project (a web application with user accounts, data management, and a few integrations) takes four to eight months from first conversation to go-live, and costs €60,000–€200,000 depending on scope.

Simple apps or internal tools are faster and cheaper. Complex platforms with multiple user groups, real-time functionality, and many integrations take longer and cost more.

What clients often do not expect: the internal time investment from their own team. On average, a client actively spends two to four hours per week on an ongoing project — feedback, decisions, content, test data. Factor that in.

The three surprises that almost every first-time client encounters

Scope always grows. As the product becomes more concrete, you think of more things you want. Agile makes this manageable — you add it to the backlog and determine priority — but it has budget implications.

Integrations are unpredictable. Connections with external systems (payment providers, accounting packages, government systems) are sometimes technically more complex than expected. Documentation is outdated, APIs behave differently than described, or interim solutions must be built.

Users use it differently than expected. However carefully you have thought about the UX, real users do things nobody anticipated. Plan budget after go-live for a first round of adjustments based on actual usage.

A software project is a collaboration, not an order. The agencies that deliver the best results treat the client as a partner in the process — not as someone who submits a specification and picks up a product three months later. And the clients who achieve the best results understand that their involvement is one of the most important success factors.