Who am I?
I'm Stephan Moerman. I've been building software products for over a decade, from enterprise platforms to startups, from infrastructure to product. I've seen the full stack, literally and figuratively.
When AI coding tools started getting good (Cursor, Claude Code, Copilot), I was one of the first to go all in. I wanted to believe in the "describe it and ship it" dream.
And for small things, it works. A utility function. A component. A script.
But for anything real, like a SaaS product or a platform with auth and billing and teams, I kept hitting the same wall.
The problem I couldn't unsee
Every time I prompted an AI tool with "build me X," it would generate something. Fast. Impressive. But wrong in ways that took longer to fix than building it manually would have.
The auth flow assumed the wrong user model. The database schema missed relationships I hadn't specified. The API routes didn't match the frontend. And when I tried to fix one thing, it would rewrite something else.
I realized the AI wasn't the problem. My input was the problem.
I was giving it a one-liner and expecting it to read my mind. No one builds a good product from a vague prompt, not humans and not AI. Senior engineers don't start coding from a one-liner. They think through the data model, the user flows, the constraints. They build a mental spec before they write line one.
AI needs the same thing. Except it can't build the spec itself. It needs you to provide it.
What Kommit actually is
Kommit is the missing layer between your idea and what AI builds.
You describe your product on a visual canvas: connected nodes for project scope, target audience, features, tech stack, database schema. Each node has its own AI conversation that asks the right questions and extracts structured data as you talk.
When you're done, Kommit generates a complete PRD. A production-ready spec that any AI coding tool can execute. Not a vague doc. A structured, typed, unambiguous specification.
The result: AI builds it right the first time. No back-and-forth. No lost features on re-generation. No "it vibes but it doesn't work."
Building in public
I want to document the entire process of building Kommit: the decisions, the mistakes, the things that worked and the things that didn't. Not a highlight reel. The real thing.
Every Build Log will cover what I shipped, what I learned, and what I'm thinking about next. If you're building a product with AI tools, I hope these posts save you some of the dead ends I've already hit.
This is Build Log #001. There will be many more.
What's next
I'm working on the decision graph (version history for your spec), smarter project-level embeddings, and MCP export so you can pipe your spec directly into Claude Code or Cursor.
If you're a founder building with AI and tired of the prompt-fix-reprompt cycle, request access. I'd love to hear what you're building.
— Stephan Moerman
