Complete projects from backend through frontend to dev environment — clean foundations, real production readiness, one accountable architect.
You're not looking for a developer to build a module — you're looking for someone who can take on or co-shape a complete software project: backend, frontend, database, CI/CD, monitoring. Without vendor patchwork, without becoming a project coordinator between three suppliers yourself. With clean foundations from the start so the system still holds up in two years — and a time-to-market that doesn't just look fast in the demo but holds up under load.
Why so many software projects disappoint
The typical pattern: you describe a need. The supplier shows a polished prototype — often already sprinkled with AI buzzwords. You see progress, the contract is signed, the project starts. Six months later you have a system that looks impressive and ticks all the modern pattern boxes — but it skips three central steps of your actual workflow because nobody fully understood them during discovery. Or you have a system that ran in the demo and collapses on the tenth concurrent request in production, because 'production readiness' kept getting pushed to the end of the sprint backlog.
The demo-wow trap
AI-generated prototypes look finished in the presentation — and break under real data, real load and real edge cases.
This isn't an exception, it's industry mechanics: speed at the demo moment gets rewarded, depth of analysis rarely gets honoured, clean foundations almost never get visibly sold. With modern AI toolchains, you can generate a prototype in days that looks like a finished product. Time-to-market sounds impressive — until you realise the prototype doesn't fit your actual use case, can't handle load, and nobody is really accountable when it doesn't hold up.
On top of that, many vendors only deliver parts. Backend comes from one, frontend from another, DevOps and monitoring will be 'sorted out later' — and you find yourself in the role of project coordinator, a role you're not a specialist in. Exactly that's where the architectural breaks emerge that cost a system years.
The patchwork problem
Backend from supplier A, frontend from B, DevOps 'someday' — and you become the coordinator between vendors instead of having one person owning the whole thing.
My approach starts differently: complete project ownership instead of partial tasks, clean foundations before visible speed, production readiness as the delivery state and not as phase two. That costs a little more in the first week than a generated click-dummy. In month six it's the difference between a system that works and one that has to be replaced.
My approach
Four principles that make the difference between a project that goes live on time and stays stable, and one that becomes visible in production for the wrong reasons:
01Discovery before code. Before a stack is chosen or a prototype is built, we look together at your process, your users, your constraints. Sometimes it shows that the right solution needs less software than initially thought — that's an honest answer, not a sales trick. You know at the end what gets built, why, and what gets deliberately left out because it doesn't help your business.
02Full ownership instead of partial tasks. Backend, frontend, database, tests, CI/CD, monitoring — one hand, one responsibility. You're not suddenly a project coordinator between four suppliers, but have one point of contact who keeps the overview and makes decisions consistently across all layers. The dev environment is also set up or co-shaped — not 'figured out later'.
03Clean foundations before visible speed. Thoughtful data modelling, clear domain boundaries, consistent error handling — these are the things that cost time in the first weeks and save money in the first years. Time-to-market done right doesn't mean: faster demo. It means: faster in stable production operation, with less emergency effort afterwards.
04Respect existing processes. Where your workflow works, the solution wraps around it instead of replacing it. Software that forces your team to think differently is rarely accepted — no matter how elegant the code underneath. Modern tools (including AI-assisted) are used where they measurably increase output; accountability for architecture, code and decisions stays with the human.
What you actually get
Full project ownership
Backend, frontend, database, CI/CD pipeline, monitoring, logging — all from one hand. Whether as full project takeover or as a senior architect who helps build up an existing team and its dev environment: you get one person making consistent decisions across all layers, instead of five specialists who only know their own slice.
Discovery phase before every project
Joint analysis of your use case before architectural decisions are made. At the end of this phase you know: what gets built, why, with what effort — and equally important, what doesn't get built because it doesn't help your business. No black-box quote, no promises into the blue.
Clean foundations, production readiness from day one
Data model, domain boundaries, error handling and observability belong in the architecture, not in the backlog. What's delivered runs in your environment — not just in the demo setup. Tests, monitoring and deployment pipeline are part of the delivery. So the system stays maintainable past the third release and doesn't lead to the typical question of who's on call at 3 AM.
Custom-fit solution, not template
Architecture and stack follow your use case, not the supplier's favourite framework. If your need is 'simple and stable', no microservices get built for the sake of patterns. If it's 'connecting multiple data sources coherently', you get a clean integration architecture — without overhead nobody benefits from.
Handover without vendor lock-in
Architecture Decision Records, automated tests, onboarding documentation. You can continue the system yourself after the engagement or evolve it with another team — without knowledge loss, without supplier dependency. Structural foresight, not a marketing phrase.
From the trenches
Quickmail Systems — when off-the-shelf software isn't enough
Swiss postal service provider with a special requirement for which no off-the-shelf product existed: mobile apps for delivery staff in mountain regions without stable mobile coverage. A standard solution would only have worked half the time — with data loss on every dead-zone stretch. Instead of glossing over the problem, what the use case required was built deliberately: a custom offline-first sync engine, three languages, clean integration into existing back-office processes. Over four years six independent solutions emerged, all still in daily use across Switzerland. No big-bang rollout, but step-by-step extension around the actual needs of the delivery staff.
„Ich kann Christian nur Empfehlen. Wir hatten ein tolles Projekt bei einem Technologie Konzern. Christian ist für mich der perfekte Freiberufler: flexibel, spezialisiert, clever und sympathisch. Ich hoffe wir arbeiten bald mal wieder zusammen!"
Marcel Theunissen — IT-Vermittler & Berater, Finance, HR und Engineering
Questions you might be asking
How long does the discovery phase take?
Depending on project complexity, between a few days and two weeks. For clearly outlined use cases a joint workshop plus two or three deep-dive conversations is often enough. For more complex setups with many stakeholders accordingly more — but always with a clear outcome at the end, not open-ended.
What if discovery shows the project should be done differently than planned?
Then I say so. That's exactly the point of discovery: figuring out before contract and effort whether the planned direction holds up. Better two days re-sorting than six months building in the wrong direction. That's part of the consulting responsibility, not just part of the project work.
You're solo — what happens if you're out?
Fair question. Every engagement is documented (Architecture Decision Records, automated tests, handover docs) so another senior can take over in an emergency — without days or weeks of reverse engineering. That's part of the delivery, not an optional extra. For longer engagements a team setup with trusted colleagues can additionally be arranged.
Where doesn't this way of working fit?
If you're looking for an off-the-shelf solution you can adopt 80% as-is, you're better served by a product vendor. If you need pure delivery capacity without architectural responsibility — body-leasing for isolated feature tickets — there are specialised providers with a junior/mid mix who do that more cheaply. What does fit: analysing, optimising or incrementally modernising existing systems. The discovery looks different there (stock-take instead of greenfield), but the approach stays the same — understand first, then change, with clear architectural responsibility.
What does it cost?
Day rate in the market range for senior cloud architects in DACH — transparently calculated, depending on engagement model (continuous, project-based, advisory). The discovery phase is small and predictable; afterwards there's a concrete offer with scope and timeframe, not an open-ended T&M project. If discovery makes clear that it doesn't fit, you only pay for the discovery — no obligation to continue.
Sounds like your project?
A few targeted questions instead of a rigid form — I'll understand what it's about in 2–3 minutes and get back to you personally.