Launch fast, then last: SaaS, AI, and the moment to own your stack

Today, you can launch a product in a weekend. The front end and functions on Vercel, the database and authentication on Supabase, background jobs on Trigger.dev, one service for emails, another for files, a third for logs. And AI writes the code that ties it all together. It's wonderful, and for a prototype it's often the right call: nothing to install, nothing to watch, generous free tiers.

But a prototype is not a product. The day the project gets serious, with paying customers, data that matters and a growing team, the question changes. It is no longer "how do we launch fast?", it is "how do we last?".

What sprawl costs

The data is everywhere. Every provider keeps part of your users' data: the database, of course, but also the emails sent, the files, the logs, the content of the jobs. That many data processing agreements, regions, access keys in environment variables, and doors in case of a leak. For a Swiss or European company, each one has to stand up to the FADP and the GDPR. The more providers there are, the more it takes only one to cause a problem.

Latency adds up. The functions run in one region, the database in another, often because that was the default. Within one network, a round trip to Postgres takes under a millisecond; across continents, close to a hundred. A page that chains six queries goes from a few milliseconds to half a second, without a single line of code changing.

The bill follows usage, and the margins stack up. Free tiers are generous, then come the plans: per active user, per run, per gigabyte transferred, per seat. Each provider takes its margin on machines it often rents from a big cloud itself. A stack you run yourself starts more expensive, because you need servers and above all the know-how to operate them. But it grows slowly: one more machine costs little.

Leaving gets more expensive over time. The lock-in is almost never the database: Supabase is Postgres, and the project is open source, just like Trigger.dev, which you can host yourself. The lock-in is in the glue: each platform's own features, access rules written in its format, the team's habits. The longer you wait, the more of it there is.

The trap. Switch too early, and you spend your weeks on infrastructure instead of the product. Switch too late, and you pay twice: the bill, then a migration under pressure. The right moment is prepared from day one, by picking open building blocks: PostgreSQL, Docker, OpenTelemetry, Temporal.

Owning your stack is a job

Owning your stack doesn't mean doing everything yourself. A managed Postgres at your host, in the same region as the application, is often the right trade-off, and email sending stays an external service. It means knowing what runs, where, and why.

That is Filetable's choice. The application, its workers, Temporal (self-hosted, since it is open source) and observability run in one Kubernetes cluster, in Switzerland, next to the data. But it takes someone who knows how: upgrades, backups and restoring them, zero-downtime deploys, priority queues, the slow query you need to understand before guessing. At some point, a stack has to be run by professionals.

And AI in all this?

AI learned from millions of public projects: tutorials, demos, starter templates, weekend projects. Very few of them ever saw a second version, a data migration or a night on call. So it excels at producing what impresses on the surface: a 3D game in WebGL, a stunning landing page, a demo that works the first time. What keeps a product standing lies below the waterline.

Above all, AI always takes the fastest path. To it, a task is done when the check turns green. If a test fails, the shortest path is to edit the test; if a type won't fit, to force it; if a function already exists elsewhere, to write a second one. It isn't malice: it's what "done" means from where it stands. Nor does it know where the project is going, what volumes it will have in a year, or what the live version will tolerate during a deploy.

So you need a senior engineer next to it: to challenge what it proposes, understand where the project is going, and make sure you aren't building yet another throwaway app, beautiful in a demo and fragile from the first real customer.

How I work with AI

I use it to the full: code, tests, migrations, documentation, reviews. It saves me weeks. But never on autopilot. Every project has its written rules, which the AI reads before writing a line; automatic guardrails refuse what we've already seen go wrong; and nothing goes to production without review. Every mistake caught becomes one more rule.

Signs it's time to take back control

• The bill grows faster than the number of users.
• A page makes several round trips to a database in another region.
• Nobody can say anymore where all the data is, or who has access to it.
• Features bend to a provider's limits: timeouts, quotas, maximum sizes.
• The code was written fast, with AI or not, and nobody dares touch it anymore.

What I take away

• Launch fast with SaaS, yes, but with open building blocks, so leaving stays possible.
• The tipping point exists, and it often comes sooner than people think. Crossing it takes know-how: running a stack is a job.
• AI to the full, but as a tool. It isn't autonomous, and it will always take the fastest path. You need an engineer to frame it, review it, and decide what goes to production.