“How long does it take?” comes up in every first conversation. The honest answer: between six weeks and six months – depending on scope, complexity and how much preparation you bring. What many underestimate: development itself is only part of the work. Workshop, concept, tests, data migration and training together often take more than half of the project time.
This article shows how a typical Klarspur project runs – with concrete timings, tasks and the pitfalls I know from practice.
Phase 1: first call (30 minutes, free)
Before anything happens we get to know each other. In 30 minutes we clarify four questions:
- What do you specifically want to achieve?
- What do you use today and where does it really hurt?
- What ballpark do you have in mind (budget, users, time)?
- Does custom software fit – or should off-the-shelf be checked first?
After that there are three possible paths: often a workshop follows. Sometimes the honest recommendation is to evaluate off-the-shelf software first. And if someone needs something I don't offer (e.g. pure hardware), I refer them to suitable partners.
Phase 2: workshop (1–2 days)
The workshop is where the real detail work happens. It is free of charge for you; everything the later fixed-price proposal includes is set out on the page about custom-built software. Typical schedule for a 2-day workshop, on site or by video:
Day 1 morning: as-is analysis
We look together at how your processes run today. Which Excel files are floating around? Which tools are in use? Which workflows happen where? I talk to the people who work with this every day – not just management.
Day 1 afternoon: pain points and wishes
What works today? What is painful? What would the dream state look like? In workshop rounds we collect problems and wishes – and prioritise them as “must”, “should” and “nice to have”.
Day 2 morning: modular architecture
From this comes the first sketch: which modules are needed? How do they connect? Which interfaces are required (DATEV, ERP, inventory, web shop, etc.)? Which roles and permissions?
Day 2 afternoon: roadmap
We clarify the order: what goes into the MVP (minimum viable product)? What comes in stages 2 and 3? This avoids the classic IT-project mistake of having nothing in production after six months.
Within one to two weeks the workshop produces a binding fixed-price proposal with module description, timeline and a click prototype – not PowerPoint, but a real interactive sketch you can test.
Phase 3: concept and fixed price (1–2 weeks)
In this phase I work out the workshop results. You receive three documents:
- Specification with all modules, features and interfaces (typically 20–40 pages)
- Click prototype you can navigate in the browser
- Fixed-price proposal with a payment plan and timeline
Important: at this point you can still walk away freely. If the proposal doesn't fit or the risk feels too high, you leave without further obligation. I factor in the workshop effort – it is part of the trust-building phase.
Phase 4: development (4–16 weeks, depending on scope)
Now the building begins. I develop in two-week sprints. At the end of each sprint you see a working slice of software – and can give feedback that flows into the next sprint.
What you do in this phase
- Every 2 weeks a 30–60-minute meeting (sprint review)
- Use test access and give feedback
- Prepare data from legacy systems (I help)
- Be available for detail questions
What I do in this phase
- Build modules and ship a little more in each sprint
- Build interfaces (DATEV, mail, inventory, etc.)
- Run security and performance tests automatically
- Send brief weekly status updates by email
Typical pitfalls in this phase:
- Scope creep: new wishes appear during development. I handle this transparently: small ones flow in, larger ones go to “stage 2”
- Interface surprises: external systems often behave differently than documented. I plan buffer in
- Legacy data quality: the migration test often reveals how many duplicates and gaps the old data has
Phase 5: data migration and tests (1–2 weeks)
Before going live I move all data from the legacy systems (Excel, CRM, accounting) into the new one. This happens in several runs:
- Trial migration with real data into a test environment
- Data check: are all records present? Are the relationships correct?
- Data cleaning: duplicates, typos, missing fields
- Final migration shortly before go-live
In parallel acceptance tests run: you and your team go through every important workflow and report what doesn't fit. I fix errors promptly.
Phase 6: go-live (1 day)
The actual go-live is mostly unspectacular – if the prep work was right. I recommend a soft launch on a Wednesday or Thursday. Benefits:
- Everyone involved is rested (no weekend stress)
- You have two working days to settle in
- If something does jam, everyone is reachable
On go-live day I am there – on site within 50 km (straight-line) of Husum, otherwise by video and remote access. In the first days after launch I keep a particularly close eye on the system.
Phase 7: training (parallel to go-live)
Training doesn't happen in a 4-hour marathon, but spread out: short module introductions (30–60 minutes), written quick-start guides for common tasks, video recordings for later. That makes it stick, and new employees can review later themselves.
Phase 8: operations and evolution (ongoing)
From go-live I take over hosting, backups, security updates and support. You have one fixed contact – me – who knows your system. Evolutions are agreed in monthly calls and shipped in small releases – usually an update every 4–6 weeks.
Sample timeline: 6-month project
| Phase | Duration | What happens |
|---|---|---|
| First call | 30 min | Get to know each other, rough estimate |
| Workshop | 2 days | As-is analysis, roadmap |
| Concept & proposal | 2 weeks | Specification, prototype, fixed price |
| Development | 16 weeks | 8 sprints of 2 weeks |
| Migration & tests | 2 weeks | Trial, cleanup, acceptance |
| Go-live & training | 1 week | Soft launch, training, stabilisation |
Total: about 6 months from first call to productive operation – on a mid-size project with 4–6 modules.
For smaller projects (1–2 modules, clear requirements) 8–12 weeks is realistic. For large platforms (10+ modules, many interfaces) it can be 9–12 months.
What you need to contribute as the customer
- Availability for the workshop and sprint reviews
- A main contact in your team who can make decisions
- Access to legacy data and existing systems
- Willingness to test the new software together with your team
- Patience – good software takes time, you'll feel it in the result
Conclusion
A custom SaaS project is no mystery and no endless construction site. With clear methodology, fixed timings, visible interim results and honest communication even large projects can be delivered predictably. The workshop at the start is an important lever – clean work here makes the rest of the project much calmer.
Considering a project? Let's have a first call. I'll honestly assess whether 6 weeks or 6 months is realistic – and whether custom development is even the right path.