How I built a SaaS without a traditional developer background - using AI and a QA mindset
A personal account of how NutriKompass came together, how I orchestrated AI during development and why a QA mindset mattered more than a classic coding background.
The idea behind NutriKompass
The idea for NutriKompass did not come from a classic startup brainstorming session. It came from a very concrete operational problem. In therapeutic facilities for young people with eating disorders, a large part of the daily workload revolves around meal planning, shopping lists, documentation and coordination.
A lot of that work was still manual, handled through paper, Excel or Word, even though time is scarce in that environment. When I saw that, my first thought was not that I should start a company. It was simply: this should be automatable in a sensible way.
My starting point
I am not a classic software engineer. My professional background is in IT consulting, test management, quality assurance and release management. I always had a good sense of what is technically possible, but for a long time I was not someone who built complete applications on my own.
That is exactly why NutriKompass started as more of an experiment than a safe plan. I could imagine building a small local tool. But a real web product with a database, authentication, billing and production-grade workflows initially felt much bigger than what I should realistically attempt.
The first step: using AI to think before writing code
My first step therefore was not to start coding right away. I began by exploring the idea with different AI systems: is there real demand, what kind of architecture would make sense, which technologies fit a product like this and which risks would need to be considered early?
Tools like Codex, ChatGPT and CloudCode were less code generators for me in that phase and more sparring partners. They helped me validate assumptions, compare options and move much faster from a vague idea to a more robust product concept.
My development process: orchestrating AI instead of delegating blindly
As the project progressed, I rarely worked with just one model. My workflow often meant describing a problem, asking several systems for approaches, comparing the results and letting one implementation be reviewed by another. Over time that felt more like a small AI team than like a single tool.
What helped most was that I never copied code blindly. I used cross-model reviews, compared alternative implementations and iterated deliberately on prompts. One especially useful lever was a small prompt-optimization step of my own that turned a rough idea into a clear instruction before any model started producing code.
Why my QA mindset was the real leverage
One of the most important lessons became obvious very quickly: AI can generate a lot of code, but it also breaks things on a regular basis. Features suddenly stop working after changes, established flows become unstable and small side effects often remain invisible at first.
That is exactly where my QA background made the difference. I introduced automated tests, smoke checks and simple quality loops early on. That created the gap between merely generated code and a reliable application, because after changes I did not have to guess whether core flows still worked.
The biggest challenges
In the end, the biggest challenge was not the code itself, but everything around it. Data protection mattered a lot because the product operates in a health-related context: secure storage, tenant separation and a clear understanding of which information can be processed at all.
On top of that came API cost control. If meal plans are generated automatically, requests cannot just grow unchecked. I had to learn how to formulate prompts efficiently, avoid unnecessary calls and shape the product so ongoing costs stay manageable. What turned out to be surprisingly straightforward, by contrast, were UI development, integrations and deployment once the core architecture was in place.
Pilot customers and the key learnings
The first users came directly from the therapeutic sector. That was ideal because it created immediate feedback from real day-to-day operations: custom portion settings, adjustments for individual residents and planning options that you would not have invented at a whiteboard. Those responses improved the product quickly.
My biggest takeaway from the project is therefore not that AI replaces developers. NutriKompass showed me something else: if you understand a real problem, think structurally, write precise prompts and take quality seriously, you can build far more yourself today than would have been realistic just a few years ago. AI does not replace product responsibility, but it does shorten the path from idea to working software.