Software Development Process: What to Expect
· DigifyNow
At DigifyNow, the software development process follows set steps. A workshop narrows down the core process. That becomes a written scope with testable acceptance criteria. We build in short sprints, and after each sprint you see working software in a test environment. First comes an MVP covering the core process, then acceptance, go-live and maintenance. On your side, you need one point of contact who can make decisions, plus real sample data.
Hiring a software developer: what are the phases of the software development process?
At DigifyNow, every software development project has the same basic structure, whether we're building a web app, a mobile app or an internal tool. Each phase builds on the one before it. Every phase ends with something you can check for yourself, not just a status report.
- Initial assessment: a free conversation where we work out whether custom software is worth it at all, or whether an off-the-shelf tool will do.
- Workshop: with the people who actually handle the process today. The output is a process sketch and a list of must-have features.
- Scope and acceptance criteria: put in writing, with one testable sentence per feature, such as "A quote can be exported as a PDF."
- Short sprints, each ending with a demo in the test environment. We deliberately keep sprints short so that a wrong turn gets caught while it's still small.
- Acceptance and go-live: testing against the agreed criteria, migrating the data, rolling out access to users.
- Operations: updates, monitoring, further development.
An MVP is the smallest version that real users can work with. How long a specific project takes depends on its scope, the number of integrations and the data migration. A firm date only becomes possible after the workshop, once the must-have features are in writing. What fits into a first release like that and what drives the timeline is covered in our article MVP development: cost and timeline.
What do I need to prepare as the client for software development?
Most delays come from questions only the client can answer. The code is rarely the problem. These five things should be ready before the first sprint starts:
- One point of contact with decision-making authority who answers questions within a few business days.
- Real, anonymized sample data: customer lists, orders and forms exactly as they look today, warts and all.
- Access to the systems that need to be connected, along with the API documentation or at least a sample export.
- A few future users who join the sprint demos.
- Accounts in your company's name: domain, hosting and, for mobile apps, the developer accounts with Apple and Google.
If we work with your customers' personal data for testing or in production, the GDPR requires a data processing agreement. Whether your overall setup is appropriate is for you or your data protection officer to assess. That depends on how you use the software, not on the software alone.
If the software is going to include AI features, such as an assistant that drafts text, the EU AI Act comes into play as well. Among other things, it requires providers and deployers to take measures that support the AI literacy of the staff who work with the system, and it includes transparency obligations for AI-generated content. High-risk systems are subject to additional, stricter rules. Whether your project falls into that category belongs in the workshop, before the scope is locked in. That does not replace a legal assessment.
Contract for work or service contract: which contract fits a software development project?
The German Civil Code (BGB) has two basic contract types. Under a contract for work (Werkvertrag), the developer owes a result, meaning working software with the agreed properties. Payment becomes due on acceptance. Under a service contract (Dienstvertrag), what's owed is the work itself, billed on a time-and-materials basis, with no specific result promised.
Both have weaknesses. A contract for work requires a scope that is clearly defined up front. If the scope shifts every sprint, every change becomes a change order. A pure service contract is flexible, but the client then carries the risk of the project spiraling. That's why in practice a mix is common: a clearly defined first package with acceptance criteria, followed by further development on a time-and-materials basis with a fixed budget per sprint.
One detail many people miss: German law provides for deemed acceptance. If the developer sets a reasonable deadline and the client doesn't refuse acceptance by citing a defect, the work can be treated as accepted. This is not legal advice. Which model fits your project is something we discuss in the initial assessment.
Why do software projects fail at small and mid-sized businesses?
Failed projects rarely have technical causes. These are the patterns we see again and again in our project work, each with its real root cause:
- No decision-maker on the project: questions sit for days, sprints run half empty and the team builds on assumptions.
- The wish list replaces the core process: every department adds its features, and none of them is fully tested by go-live.
- Test data instead of real data: duplicate customers, empty required fields or special characters in names only surface in production.
- Underestimated integrations: the legacy system has no API, only a CSV export, or the API limits the number of requests per minute.
- No planned data migration: old records don't fit the new data model and end up being entered by hand.
- Users don't see the software until go-live: workflows that looked logical on paper don't match the real working day.
Almost all of these issues can be spotted before the first sprint. That's why we ask specifically about edge cases and exports in the workshop, before any scope is locked in. One example: if the legacy system only offers a CSV export, we check a real export file to see whether umlauts and other special characters come through correctly and whether customer numbers are unique. If the real issue is workflows between existing programs, it's worth looking into business process automation for small businesses. Often a webhook connection is enough there, instead of a new application.
What happens to the software after go-live?
Software that runs today doesn't stay runnable on its own. Every application depends on libraries, frameworks and runtimes with their own life cycles. Runtimes like Node.js have fixed support periods per version. Once a version reaches end of support, there are no more security updates. If you go a long time without updating, you'll eventually face a major rebuild instead of many small updates.
On top of that come recurring deadlines. TLS certificates for the encrypted connection have a limited lifetime and need to renew automatically, otherwise the browser shows a warning. Apple and Google regularly require apps to be built against newer SDK versions, otherwise you can no longer submit updates. We store backups in multiple copies on separate media, one of them at a different location. Whether a backup is any good only becomes clear with a test restore.
We label versions using Semantic Versioning in the MAJOR.MINOR.PATCH format. The number tells you whether an update only fixes bugs or changes existing workflows. How we handle this on an ongoing basis is described on our page about ongoing digital support.
When is custom software development not worth it?
Custom software development isn't the answer to every problem, and we say so in the initial assessment. It usually isn't worth it when your process works the same way it does at lots of other businesses, such as accounting, payroll or a standard online store. There are mature products for those, and their vendors keep up with changes in the law. With an in-house build, that effort falls on you.
It also gets difficult when the process itself isn't settled yet. If you build software to figure out how you want to work, you'll be rewriting the requirements after every sprint. And if nobody at the company has time for demos and questions, you end up with software that misses what users actually need.
Custom development makes sense when a process is what sets you apart, when several off-the-shelf programs are patched together with Excel spreadsheets, or when per-user license costs grow with your team. The detailed trade-offs are in our comparison custom software vs. SaaS.
Software development company in the Westerwald: what should I look for?
DigifyNow GmbH is based in Unnau in the Westerwald region of Germany. Our team includes Jesper Schmidt, Christian Schiebl and Miles Pandel, who write the code themselves. We work throughout Germany, but our focus is the Westerwald, Koblenz and the Siegerland. For businesses in the region, that has a practical advantage: we can run the workshop on site, in the warehouse, the workshop floor or the office. That's where you see how a process actually runs, not just how it's described. You'll find more about our Westerwald service area on the corresponding page.
Wherever a development company is based, check three things. First, who writes the code: their own team or subcontractors? Second, are the domain, hosting, app store accounts and code repository in your name? Third, are there references you can look at? For us, those are the custom back office with CRM for Mundo Marketing and the party game app Festino, a product of DigifyNow, available in the Apple and Google app stores. The first step is a free assessment of your project.
Frequently asked questions
What determines how long software development takes?
The timeline of a software development project comes down mainly to three drivers: how many third-party systems need to be connected, whether legacy data has to be migrated, and how quickly the client answers questions. An MVP covering only the core process is done much faster than a system with several integrations. The larger system is then developed further in sprints instead of being delivered in one piece. A firm date only comes after the workshop.
What's the difference between a requirements specification and a functional specification?
The requirements specification (in German, Lastenheft) describes what the client expects, meaning the requirements from a business perspective. The functional specification (Pflichtenheft) is written by the contractor. It sets out how those requirements will be implemented technically. In agile development, a prioritized feature list with one testable acceptance criterion per feature often replaces the classic functional specification.
Do I own the source code of my software?
Software is protected by copyright. Under German law, the copyright initially stays with the developer, and you receive usage rights. Exactly which rights, meaning whether they are exclusive, unlimited in time and include the right to modify, has to be stated in the contract. Also make sure the code repository is in your name or is handed over to you regularly. Only then can another developer pick up the work later.
What does software development include besides programming?
Programming means writing code. Software development covers more: requirements analysis, data model, programming, testing, acceptance, data migration, operations and maintenance. In a typical client project, the programming itself is only part of the work. The workshop, testing and alignment with users also take a lot of time, and that's where it's decided whether the software will actually be used.