Most failed software projects were not badly coded. They were badly sequenced. Someone started building before the problem was understood, or froze the architecture before the requirements settled, or scheduled testing for the fortnight before go-live and discovered a fundamental flaw with no time left to address it.
The lifecycle below describes what a competently run project looks like from first idea to a system running in production. Durations assume a mid-sized project of six to nine months, which covers most Mittelstand development work. Adjust proportionally for smaller or larger efforts, but keep the sequence.
Before anything: validating that the problem is real
The cheapest phase is the one where you write nothing but notes.
Spend a week establishing three facts. What does the current process cost, expressed in hours or euro rather than in frustration? Who would use the new system, and would they actually switch? What happens if you do nothing for another year?
That last question sorts genuine priorities from wishes. A project driven by an expiring vendor contract or a compliance deadline has an owner and a budget. A project driven by “our system feels outdated” often loses funding in month four when something more urgent appears.
If the answers are thin, stop here. Killing a weak idea in week one is the highest return activity in the entire lifecycle.
Discovery: converting intentions into specifications
Discovery typically runs two to four weeks and should be paid work, whether performed internally or by a partner. Its purpose is to reduce uncertainty enough to produce a defensible estimate.
Four deliverables come out of it. A domain model naming the entities and their relationships, which sounds academic but prevents the classic problem of three departments using the same word for different things. User journeys covering the main paths, including the awkward ones nobody mentions in workshops.
A risk list ranking what could go wrong, with the riskiest item scheduled first. And a phased estimate with explicit exclusions. Domain workshops are where most value gets created here, and industry familiarity shortens them considerably.
Teams doing Softwareentwicklung in Hamburg for logistics and trade clients, for example, will already know why a shipment can have several statuses simultaneously, which removes a session or two from the schedule. Ask about the exceptions during discovery, since exceptions are where the actual complexity lives.
Architecture: decide what is expensive to change
Not every technical decision needs making upfront. The ones that do are those that would require a rewrite to reverse.
Data model structure belongs in this category, as do integration boundaries, authentication approach, and the hosting environment, particularly where DSGVO obligations or public sector tenders require German or EU infrastructure. Framework choices, library selections and most interface details can wait, and deciding them early only reduces your options later.
Write the significant decisions down in short records: the decision, the alternatives considered, and the reasoning. Two years later, when somebody asks why the system uses message queues instead of direct calls, that half page saves a week of archaeology.
Design and prototyping: test the interface before building it
A clickable prototype costs a fraction of working software and answers the questions that matter most. Put it in front of six real users and you will learn which screens confuse people, which steps they skip, and which feature you were proud of that nobody notices.
Six users is usually sufficient for interface problems. Beyond that, findings repeat.
This phase pays for itself most clearly in internal tools, where adoption is the actual risk. A system that works perfectly but irritates the twelve people who must use it daily will be circumvented within a quarter. Teams handling Softwareentwicklung in Berlin generally run this step as standard practice, since the city’s product sector has spent years learning that assumptions about user behaviour are usually wrong.
Design also needs to address accessibility now rather than later. The Barrierefreiheitsstärkungsgesetz brought consumer-facing digital services into scope, and retrofitting accessible markup, contrast and keyboard navigation into a finished frontend costs several times what building it correctly would have.
Build: increments, not phases
The build should produce something usable early rather than everything at once. Aim for a working slice in production, even with a small user group, within eight to twelve weeks of starting development.
Effort distributes roughly as follows across a typical project:
| Phase | Share of total effort |
| Discovery and design | 15 to 20 percent |
| Development | 45 to 55 percent |
| Testing and fixes | 20 to 25 percent |
| Deployment and launch support | 5 to 10 percent |
Teams that plan only for the development row are the ones who run out of budget in the final month.
Team composition changes during this phase. Early on you need senior people making structural decisions. Once patterns are established, additional developers become productive quickly, which is when scaling capacity through Softwareentwicklung Outsourcing or a dedicated nearshore team makes sense. Adding people before the architecture is settled slows things down, because everyone waits on the same unanswered questions.
Keep two practices non-negotiable throughout: every change reviewed by a second developer, and an automated pipeline that runs tests on every commit. Both feel like overhead in month one and save the project in month five.
Testing: several different activities, not one
Testing is often written into plans as a single block, which hides the fact that it involves distinct types of work happening at different times.
Automated tests run continuously and catch regressions. Integration testing against real external systems belongs early, since interfaces behave differently from their documentation. User acceptance testing needs real users doing real tasks with realistic data, not a demo walkthrough, and it should happen at least six weeks before go-live so findings can be addressed.
Two further activities are frequently skipped and frequently regretted. Load testing matters if your system has predictable peaks, such as month-end reporting or seasonal ordering. A security review, whether an external penetration test or a structured code audit, is advisable for anything handling personal or financial data.
Under a Werkvertrag, formal Abnahme has legal consequences: warranty periods begin and payment obligations trigger. Define the acceptance criteria in writing at the start, not during the acceptance meeting.
Pre-launch: the checks that are not technical
Several items must be complete before go-live and none of them involve code.
The Verzeichnis von Verarbeitungstätigkeiten needs updating, and where the system processes sensitive data at scale, a Datenschutz-Folgenabschätzung may be required. Confirm this with your Datenschutzbeauftragter early, since it takes weeks rather than days.
If the system can produce data about individual employee performance, the Betriebsrat needs to have agreed the arrangement. Raising this two weeks before launch is a reliable way to delay a launch.
Operationally, decide who receives alerts outside working hours, where users report problems, and what the rollback procedure is. Write the rollback steps down and test them, because the moment you need them is the worst moment to work them out.
Go-live: staged, not sudden
Big-bang launches create unnecessary risk. Better patterns exist.
A pilot group of ten to thirty users for two weeks surfaces most issues at low cost. Parallel running, where old and new systems operate simultaneously, suits finance and operational systems where errors are expensive, though it doubles workload temporarily. Feature flags allow shipping code while keeping functionality switched off until you are ready.
Plan hypercare for the first two to four weeks: faster response times, daily check-ins, capacity reserved for fixes. Users encounter edge cases in the first fortnight that no test plan anticipated, and a quick fix during that window builds more confidence than any amount of pre-launch communication.
After launch: the phase with the longest duration
Go-live is roughly twenty percent of a system’s total cost. The rest arrives over the following years.
Budget annual maintenance at 15 to 20 percent of the build cost for security patches, dependency upgrades and small changes. Assign a named owner internally, because systems without an owner accumulate neglect until an upgrade becomes a migration project.
Measure whether it worked. Return to the numbers from the validation phase and compare. If the process took nine hours weekly before and takes three now, that is the result worth reporting. If nobody can produce that comparison, the project delivered software but not evidence.
Then keep iterating in small increments. The systems that stay useful are the ones that receive attention every quarter, not the ones that were perfect at launch.