Service
App Development
Software that holds up in daily use.
Once the prototype convinces, I build the real thing: a web or mobile app with clean architecture, real data storage, authentication, and billing. Kalender-Sync has been running that way since launch and serves over 3,000 users today.
- Web or mobile app, production-ready
- Database, auth, payments
- EU hosting
- Maintenance and ongoing development
The gap between a prototype and a product
A prototype has to work once, while someone watches. A product has to work for months while nobody watches, even when a provider goes down, a user does something unexpected, or the clocks change.
The effort rarely sits in the interface. It sits in error handling, data migrations, billing, access control, and operations. That work is invisible until it's missing.
How I know this
Kalender-Sync is my own product, publicly available since May 2026 and serving over 3,000 users. Five connected calendar providers, billing through Stripe, running on own infrastructure in Germany, all handled by one person.
The most instructive moments came not during the build but afterwards: recurring events without an end date that expand into the year 2085. Time zones that are wrong differently at every provider. A server migration where the old container kept running and two instances escalated against each other.
When I estimate how long something will take on your project, or which edge case gets expensive later, that comes from this experience rather than from a conference talk.
Where the time actually goes
The most common misjudgement in software projects isn't about total duration but about its distribution. The visible work, interfaces and core features, is usually finished faster than expected. What takes longer is everything after that.
At Kalender-Sync it looked like this: the basic function, reconciling two calendars, was ready early. Then came the cases the concept never mentioned. A user with recurring events without an end date, expanding into the year 2085. Time zones named differently at Microsoft than at Apple. A provider unreachable for twelve hours.
That work is invisible as long as it's done, and very visible the moment it's missing.
| Usually quoted | Comes on top | |
|---|---|---|
| Features | The flow the product is built for | Empty states, error messages, abandoning midway |
| Data | The expected format | Time zones, special characters, users with ten times the data |
| Access | Sign-up | Forgotten passwords, roles and permissions, account deletion |
| Third-party systems | The integration itself | What happens when the provider is down for twelve hours |
| After launch | Handover | Monitoring, updates, data migrations, support |
The right-hand column decides whether a demo becomes a product. I break it out separately in the quote, so you know in advance what's still coming rather than learning it as an add-on.
What I build
Web and mobile applications with clean architecture, real data storage, authentication, and billing. Plus monitoring and alerting, so a fault surfaces before a customer reports it.
Including less usual requirements: for GLOBE this meant an interactive 3D world for web and trade-fair kiosk, with an offline build and watchdog, because trade-fair Wi-Fi is not something to depend on.
Reference projects
All Projects
GLOBE H₂ 3D World
Interactive 3D world of the hydrogen value chain for trade-fair kiosk and web. Model data cut by 76 percent, running at 70 to 120 frames per second.
Kalender-Sync
Live SaaS for calendar synchronisation with over 3,000 users. Free/busy instead of event content, five providers, hosted in Germany. The product for individual users that the Ridian platform grew out of.
Frequently asked questions about this service
- What does app development cost?
- That depends entirely on scope and can only be quantified honestly after a conversation. What I can commit to: a breakdown into stages with their own prices, so you can decide after each stage whether to continue.
- Do you work alone or in a team?
- Generally alone, which is an advantage at this project size: no coordination loss, one point of contact, clear responsibility. Where specialist knowledge is needed, for legal or accounting matters, I bring it in and say so transparently.
- What happens if you're no longer available?
- A fair question with a solo provider. That's why the repository, hosting access, and documentation are yours from the start, and the code follows common standards rather than bespoke constructions. Another developer can take over. On the GLOBE project that's exactly what happened after sign-off.
- Do you take over existing projects?
- Yes, after a review. With existing code I first assess whether extending it makes sense or whether a rebuild works out cheaper. You get that assessment honestly, even when it's inconvenient.
Other services
Have a similar project in mind?
Tell me about it. I'll reply within 24 hours with an honest assessment.