AI Can Generate a SaaS Prototype. Building the Product Still Takes Months.

You’ve probably seen posts that make building a SaaS with AI sound almost effortless: Give Claude one prompt, wait a few hours, and launch. That wasn’t my experience.

I used Claude and other AI coding tools while building Infill, and they absolutely helped. I wrote code faster, found bugs sooner, and avoided a lot of repetitive work. But the product still took me more than three months to build. The reason is simple: generating code was never the hardest part.

The First Version Was Easy

Getting an early demo working did not take long. Infill is a browser extension that helps users fill repetitive forms. The basic idea sounds straightforward:

• Read the fields on the page.
• Match them with information from the user’s profile.
• Fill the form.

An AI model can help build that prototype quickly. The problems start when you ask what happens outside the happy path. Websites use strange labels. Some forms are split across multiple pages. Some fields already contain data. Others are hidden, disabled, sensitive, or designed to catch bots.

Then there are the questions that have nothing to do with generating another component:

• What information should be filled automatically?
• What should always require user approval?
• Where should profile data be stored?
• What happens when the AI makes the wrong match?
• How much will every form submission cost?

Those decisions became most of the work.

Calling an AI Model for Everything Was a Bad Idea

My first instinct was to let an LLM handle all the field matching. It looked good in a demo: send the form fields to the model, receive the mappings, and fill the page. But that approach would become expensive very quickly. Every form would create another API request. Larger forms would use more tokens. More users would mean higher bills and more latency.

There was also a bigger privacy problem. To let the model handle everything, I would need to send form fields and parts of the user’s profile to an external AI provider. Depending on the form, that data could include names, addresses, phone numbers, employment history, financial details, or other sensitive information. In other words, I would be exposing far more user data than necessary just to fill a form. The product might work, but the economics and privacy model would not.

So I changed the architecture. Infill now tries deterministic matching first. Common fields can be matched locally without an AI call. AI is only an optional fallback for cases where the normal rules are not enough. This is less exciting than saying the whole product is powered by an autonomous agent. It is also faster, cheaper, more private, and easier to reason about.

I Still Write the Important Code Myself

I do not hand the entire codebase to an AI agent and accept whatever it generates. For the important parts, I still write the code myself. That includes architectural boundaries, design patterns, data flow, privacy rules, sensitive-field handling, and the parts that could become expensive or dangerous if they are implemented badly.

AI can suggest five different abstractions in a few seconds. It cannot know which one will still make sense six months later. It can generate a service, a hook, or a repository pattern. It does not understand the trade-offs of adding another layer to the system unless I give it that context.

For routine work, AI is great. I use it for scaffolding, repetitive code, tests, refactoring suggestions, and exploring alternatives. But for decisions that shape the product, I slow down. I draw the boundaries. I choose the patterns. I review how data moves through the system. I decide what must stay local, what can be optional, and what should never be automated.

The more sensitive the code is, the less comfortable I am treating AI output as a finished answer. A generated function can look clean and still leak data, create an expensive API path, hide a race condition, or introduce a pattern that makes the codebase harder to maintain. AI can write code quickly. I still have to decide whether that code deserves to exist.

AI Made Me Faster, Not Finished

AI coding agents were useful throughout the project. They helped me explore approaches, generate tests, refactor code, and understand browser-extension issues faster than I could have on my own. But they didn’t decide the product architecture for me. They didn’t know which trade-offs mattered most. They didn’t know how much risk I was comfortable with, what users would trust, or what my API budget could support. And when the generated code was technically correct but wrong for the product, I still had to notice.

That is the part I think gets lost in the “one-prompt SaaS” conversation. AI can help you reach a prototype surprisingly quickly. Turning that prototype into something reliable, private, maintainable, and affordable still takes real engineering.

I’m not saying AI coding agents are overhyped. I use them every day. I just don’t think “AI built my SaaS” is the full story. A more honest version is: AI helped me build faster, but I still had to build the product.

You can check out Infill here:

• Website: https://useinfill.com
• Source code: https://github.com/KaiBelmo/infill