Can AI really let anyone build a SaaS?

Ever since Cursor, Lovable and Bolt showed up, you hear the same line everywhere: “AI now lets anyone build a SaaS.” It's partly true, and that's partly what makes it dangerous.

True, because you can now build in a few hours what used to take weeks. An entrepreneur can ship a prototype, automate a slice of a process or stand up a small app without a technical team. It's a real shift, and we use it ourselves every day.

Misleading, because it depends heavily on what you mean by “a SaaS”. And not everyone means the same thing.

Not all applications are the same

We often lump together three very different things: the personal tool you hack together for yourself, the MVP you ship to test an idea, and the production application that runs every day for real clients.

For the first two, AI changed everything. You describe what you need in plain language, you generate an interface, a database, a couple of automations, and you have something working that same evening. To validate an idea or solve a one-off problem, it's a small revolution.

An application used every day by your clients or your teams is another story. And that's where the opening line gets tricky.

A production app isn't just code

The moment an app goes into production, code is only the visible part. Behind it, you have to hold up real users, sometimes sensitive data, roles and permissions, payments, integrations with other systems, regulatory constraints, security, updates, tests, monitoring, service availability. And all of it has to keep holding as the company grows.

As long as nobody uses it, a bug is a line to fix. In production, that same bug becomes lost revenue, a halted operation, an unhappy client or a security hole. The setting changes completely.

An example from our own work. A health startup contacts us to manage its patients, practitioners, appointments and payments. The easy reflex would have been to generate the app right away. Except the real challenge wasn't the code: it had to hold up to the confidentiality constraints of healthcare (HIPAA compliance in the United States) while staying usable by teams who aren't engineers. It was those constraints, not generation speed, that drove the choices that mattered.

The real issue isn't code quality

Most debates about AI revolve around one question: “is the generated code good?” In reality, that's not the main issue. Even excellent code doesn't make a good application.

The projects that hold up rest first on something else: a fitting architecture, good data modelling, rigorous permission handling, a coherent security strategy, automated tests, a real understanding of the business needs. AI massively speeds up executing all of that. It doesn't replace a global understanding of the system.

We saw it with an endowment fund whose tools, patched together over the years, had become unmanageable. The reflex would have been to regenerate everything. The real problem ran deeper: their data model no longer matched the way they worked. No AI was going to figure that out for them. We had to put the foundations back straight before touching anything else.

What's really changing

For a long time, knowing how to write code was THE differentiator in building software. Today, code is gradually becoming a commodity. The value shifts elsewhere: to designing the system, understanding business processes, architecture decisions, data quality, and the ability to frame the right problems before you start the machine.

So the question is no longer just “who can code?” but “who actually understands the system they're building?” It's a quiet shift, but it changes everything.

New hybrid profiles

It's also why the lines between certain roles are getting blurrier. We see hybrid profiles emerging that combine several hats: highly technical product managers, product engineers, designers who code, product-minded CTOs.

What sets them apart isn't so much tool mastery as their ability to connect three things: business stakes, technical constraints and user needs. That's exactly what we call Product Thinking, and it's precisely what AI can't do in your place.

What it means for an SMB

For a company, the point isn't to use AI to produce faster. It's to build the right systems. AI is driving down the cost and time of creating digital tools, and that's a real opportunity for SMBs looking to digitize their operations or launch new services.

But a project's success still depends on the same things: understanding the real need, designing a fitting solution, structuring the data properly, securing the processes, and thinking about scalability from the start. Nothing new, and that's exactly the point.

AI transforms how applications are built. It doesn't remove the need for expertise, it shifts it toward those who can combine product vision, business understanding, architecture and execution. That's probably where the real edge lies today, for those who know how to make the most of it.

About the author

Julien Andrieu. 20 years of experience in Product Management and digital product development. After working in startups, SaaS vendors and international groups, he now helps SMBs design digital solutions built around real business needs.

Want to talk it over? Write to us: hello@capamoon.com. Or if you're in Barcelona, reach out for a coffee ☕