Software Development Process: How a Project Runs

Anyone who has been through a software development process knows the problem is rarely technical. It is decisional. A question left unanswered for three weeks costs three weeks, whatever the size of the team.

A custom software project has four moments that matter: discovery, iterative build, acceptance, and go-live. Everything else in the software development process is variation in method. Discovery defines the problem and the scope. The build runs in short cycles, each ending with working software. Acceptance is where someone on the client side decides whether what was built does the job. Go-live starts the system's life rather than ending the project.

This article describes what actually happens in the software development process between signature and go-live. It is not about choosing a supplier, which is an earlier and different decision. It is about what to expect once that choice is made.

Duration	Project	Typical scope
1–3 months	Tightly scoped MVP	One main flow, one user profile, no complex integrations
3–6 months	Mid-sized project	Several modules, one or two integrations, distinct access roles
6–12 months	Large project	Data migration, multiple integrations, audit requirements
12–24 months	Enterprise platform	Replacing systems in production, phasing is mandatory

The variable that stretches schedules most appears in none of these ranges: how fast decisions arrive from the client side.

What happens before anyone writes code?

Discovery, and it is the only part of the project where changing your mind is still cheap. Two to four weeks, typically. The goal is not to produce documentation. It is to answer a small number of questions precisely enough to build against.

1
What is the problem, specifically? Not "we want to digitise the process", but which process, run by whom, with what steps, and what fails today.
2
Who uses this and in what context? An internal user with training and an end customer with none produce different interfaces.
3
Which systems does it talk to? Every integration needs a name, an owner, documentation and a person who can grant access. Integrations without an identified owner are schedule risk.
4
What data exists and in what state? This is where migration stops being a line in the specification and acquires real size.
5
What has to be true for this to go live? Legal requirements, internal approvals, training, maintenance windows.

Discovery ends with a written scope, a proposed architecture, an estimate with stated assumptions, and a risk list. If any of those four is missing, discovery has not finished. Buying it separately is worth doing: paid discovery with the supplier you are considering costs a fraction of the project and produces something useful even if you decide not to proceed, namely a written scope you can take elsewhere. It is also the cheapest way to find out whether the team understands the problem, before a six-month contract is on the table.

How is the software development process organised after kick-off?

In short cycles, one to three weeks, each ending with software that works and can be seen. This is not a methodological preference. It is risk management. A two-week cycle means the maximum error that can accumulate unnoticed is two weeks. A project that shows nothing until month six accumulates six months of misunderstanding before anyone notices.

What one cycle contains

Planning

Selecting what enters the cycle, from a prioritised list, with the client owner in the room

›

Build

Development, code review and automated tests, owned by the technical team

›

Demo

What was built is shown working, to both sides, with real users where possible

›

Adjustment

The priority list is reordered with what was learned, and the client owner sets the order

The piece that usually goes missing is the last one. A priority list that never changes means nobody is learning from what has already been delivered, which removes half the value of working in cycles. Three roles also have to be assigned to named people rather than departments: one person on the client side who sets priorities and accepts deliveries, someone responsible for architecture with authority to say no, and someone responsible for access on both sides.

Have a project in preparation? Send us the problem rather than the specification.

Talk to our team →

Where does the software development process derail?

Five failures in the software development process, in rough order of frequency. None of them is technical.

Requirements that change without anything leaving. Adding is natural. The problem is adding without removing and keeping the date. The right conversation is not "can we include this?", it is "what does this replace?".

Access that does not arrive. The third-party test environment takes six weeks to approve and nobody asked at the start. The team sits idle with the cost running.

Acceptance without defined criteria. If "done" is not written before the feature is built, the argument about whether it is done happens afterwards, with both sides certain they are right.

Real data arriving late. The system works on test data and breaks on production data, because production data carries twenty years of undocumented exceptions. Loading real data early is the cheapest mitigation available.

Production treated as a final detail. Monitoring, backups, access management, recovery plan. Leaving this to the last week turns a delivery into an emergency.

What does "done" mean and who decides?

Done means the feature passes a criterion written before it was built, and that someone on the client side has confirmed in writing that it passes. A useful acceptance criterion is specific enough to be verifiable. "The user can submit the form" is not enough. "A user with the manager role can submit the form with required fields completed, receives confirmation, and the record appears in the listing in under two seconds" is verifiable.

There is a second layer often confused with the first. A feature can be functionally accepted and still not be production-ready, because test coverage, documentation or error handling are missing. In regulated sectors, quality evidence is not optional: someone will ask for the test report during an audit.

What happens on delivery day and after?

Go-live is a date, not a final state. The three weeks around that date usually include final data migration, user training, a period of heightened support, and fixing the first wave of problems that only appear under real use. That wave always happens, and a plan that does not expect it is planning badly.

After that the system enters normal life, which costs money. Public references place annual maintenance between 15 and 20 per cent of build cost, with hosting and infrastructure adding €200 to €1,500 a month. That budget buys no new features. It buys updated dependencies, security fixes, compatibility with operating systems that change, and legal requirements that change too.

The decision to make on delivery day is who does that work: the team that built it, an internal team receiving the code, or a mixed model. Any of them works. None works if the decision is only taken six months later, when nobody remembers why that module was built the way it was.

What role does AI play in the software development process?

A real role in building and none in deciding. According to the 2026 Tech Talent Trends report, 54 per cent of developers already use AI tools in their regular workflow, which speeds up writing code, generating tests and exploring technical alternatives.

What does not change is everything this article describes as the hard part. Discovery still depends on someone being able to explain the problem. Acceptance still depends on someone deciding. Data migration still needs a human decision about what gets lost. Projects fail on these things, not on how fast code gets typed.

How should a client prepare for the software development process?

Most delays in a project trace back to something the client could have prepared before kick-off. None of it is technical. All of it is cheaper to arrange early.

Name one person who can decide. Not a committee, and not someone who has to check with a committee each time. Scope questions come up every week. The project moves at the speed of the answers.

Give the team access to real users. Ten minutes with the people who will use the system every day settles questions that a requirements document leaves open for weeks.

List what already exists. Systems the new software has to talk to, data that has to be migrated and the people who own each one. Integrations found halfway through the build are the most common source of unplanned cost.

Book the review time in advance. Each build cycle ends with a demonstration that needs someone from the business in the room. Put those dates in the calendar at kick-off, before other commitments fill them.

A client who arrives with these four things ready usually shortens discovery by weeks. The software development process does not get faster because the team works harder. It gets faster because fewer questions wait for an answer.

Frequently asked questions

Timing and phases of the software development process

How long does custom software development take?

Public references point to 1 to 3 months for a tightly scoped MVP, 3 to 6 months for a mid-sized project, 6 to 12 months for a large one and 12 to 24 months for an enterprise platform. Client-side decision speed affects the schedule as much as technical effort does.

What is the discovery phase and is it really necessary?

It is the opening phase, typically two to four weeks, where the problem, scope, architecture and risks are defined before any code exists. It is the only point where changing your mind is cheap, and it produces a written scope that stays useful even if you choose a different supplier.

Decisions and acceptance

Who decides what goes into each phase of the project?

One named person on the client side, with authority to set priorities and accept deliveries. Committees decide slowly and shift position between meetings, which is the most common cause of delays that have no technical origin.

What does it mean for a feature to be done?

That it passes an acceptance criterion written before it was built and objectively verifiable, and that someone on the client side has confirmed it. In regulated sectors a second layer applies: test coverage and documentation that hold up in an audit.

After go-live and commercial terms

What happens after the software goes live?

A period of heightened support for the first wave of real problems, then the system's normal life. Public references place annual maintenance between 15 and 20 per cent of build cost, before any new features.

Fixed price or time and materials?

Fixed price works when scope is closed and will not move, which is rare in custom software. Time and materials works where there is trust and transparency about what is being done. The most common hybrid is fixed price for discovery and a tightly bounded first phase, then time and materials.

Caixa Mágica Team

Caixa Mágica Software is a Portuguese software company with 20+ years of experience delivering custom software, AI solutions and nearshore development teams for European businesses.

Software Development · Caixa Mágica Software

Talk to a team that delivers and then maintains

We build custom software for Portuguese and European clients, and stay with systems in production for years alongside the same client. If you have a project in preparation, send us the problem rather than the specification. You get a discovery proposal with the scope we can close in two to four weeks.

Custom software development Start a conversation