The full story
The Foundation
I started coding at 15 — a World of Warcraft website that got DDoS'd on day one. By 18, I was building bots and learning how production systems resist external interaction. After university, I chose the hard path: Java development in regulated finance. Three years at Finologee building systems for the banking sector, where every deployment is audited and every mistake has legal consequences. That's where I learned that production-grade isn't a feature — it's a discipline.
Building kodehyve
In 2020, I co-founded kodehyve as CTO. We set out to build the operating system for real estate developers — a multi-module, multi-stakeholder platform covering project management, CRM, financial management, compliance, and investor lifecycle.
I was the sole developer for the first year. I wrote the code, chose the stack, designed the architecture. As the company grew, I built the entire development process: environments, CI/CD, code review workflows, onboarding, training programs.
I scaled the dev team to 10+ engineers, introduced event-driven architecture, built a shared design system, and led a complete platform rebuild when we outgrew the original codebase — because rebuilding was faster than fighting the debt we'd accumulated under pressure.
On the side, I built an eSignature platform on Luxembourg's national trust infrastructure. It's used by 100+ real estate agencies today.
5+ years of building at this scale — from sole developer to a team of 20+ — taught me that every foundational decision compounds. The ones you get right carry you. The ones you get wrong haunt you.
The AI Shift
And then AI arrived. I spent a full year going deep — not building demos, but testing what happens when AI writes code inside a real, complex codebase. The answer: without guardrails, it creates beautiful chaos. With solid foundations and defined patterns, it becomes the most powerful tool I've ever used.
That insight became ITzWorking — my methodology, codified into an opinionated framework. Every foundational decision a SaaS needs, already made, already battle-tested. The architecture that makes AI a 10x senior instead of a 2x intern.
Building MVPs Right
Then I pushed the idea further. If solid foundations make AI powerful for building software — what happens when you apply the same discipline to every project?
I turned everything I'd learned — the architecture patterns, the production standards, the decisions that compound — into a methodology. Auth, billing, monitoring, multi-tenancy, deployment. Every problem a SaaS will face, already solved. Not a framework to sell. A way of building that guarantees production-readiness from day one.
That's when I understood what most MVPs get wrong. Not the idea. The foundations. Vibe-coded prototypes that break with real users. Freelancer code that needs rewriting at month six. Startups burning runway on technical debt they didn't know they were accumulating.
I build MVPs for founders who can't afford to get that wrong. Fixed price. Weeks, not months. Every project ships with the same standards I used to build platforms for institutional clients.
What I believe
“Most MVPs don't fail because of the idea. They fail because the first version was never built to survive real users. Foundations matter from day one.”
“Speed without discipline is just debt with a deadline. I've rebuilt enough platforms to know: the shortcuts you take in month one become the rewrites you face in month six.”
“Most people who call themselves CTO have only done one version of the job. I've done the complete path: sole developer, tech lead, HR, helpdesk, project manager, QA lead, mentor,... The role changes completely at every scale.”