Your weekend project just got real users. Now what?

It started as a weekend thing. You used an AI tool to build a little app, put it online, shared it in a group chat. Someone shared it further. Then someone you’ve never met signed up, and then 20 more, and now you check the stats and 200 people used your app last week.

Congratulations. Also: you have a problem.

That problem isn’t technical. You don’t need to learn microservices or read a DevOps book. The problem is simpler and more urgent: your app is now holding other people’s data, and you probably have no plan for what happens if something breaks.

The three things that change when strangers show up

1. Their data is your responsibility

When it was just your friends, losing the database was embarrassing but fixable. You’d say sorry, rebuild it over the weekend, everyone would re-enter their stuff.

When 200 strangers use your app, losing their data is a different story. They trusted you with their email addresses, their bookings, their preferences, maybe their payment details. In Europe, you might have legal obligations under GDPR the moment you store a person’s email address.

You need backups. Real ones, tested ones, not “I think the platform keeps something for 14 days.”

2. Downtime matters now

Your running club’s signup page going down for an hour on a Thursday night? Nobody notices. A booking tool that 200 people rely on going down at noon on a Saturday? You’ll get emails. If people are paying through it, you’ll lose money.

You need monitoring, something that tells you when your app goes down before a user has to.

3. You need a way to fix things without breaking other things

When you were the only user, you could push a code change and see if it worked. If it broke, you’d fix it and push again. Five minutes, no harm done.

With 200 users, a bad push can break the app for everyone, during their lunch break, while they’re trying to use it. You need a way to update your app without gambling with their experience.

What you don’t need to do

Let’s get this out of the way. You do not need to:

• Learn Docker, Kubernetes, or Terraform
• Set up a “CI/CD pipeline”
• Hire a developer
• Read a 400-page book about system administration
• Move to AWS

These are tools for teams building software at scale. You’re one person with a side project that got popular. The solution should match the problem.

What you actually need (and what it costs)

Here’s the honest minimum for an app with real users:

Daily backups with tested restores. Your database should be copied every day, and someone should have actually tried restoring from a backup at least once. (You’d be surprised how many “backup systems” have never been tested. They’re digital security blankets.)

Monitoring. Something that pings your app every few minutes and tells you if it’s down. This can be free (Uptime Kuma, or even a simple cron job), but someone needs to set it up and someone needs to receive the alert.

A deploy process that doesn’t require bravery. Push your code, it builds, it goes live. If the build fails, the old version keeps running. No “I hope this works” deployments.

HTTPS everywhere. Your app should serve traffic over a secure connection. This protects your users’ data in transit. It’s also required by browsers now, basically.

Here’s how that maps to our plans, honestly. Every plan, from Hobby at €9, gives you push-to-deploy, health-checked releases where a failed build never goes live, and HTTPS. Launch (€19/mo) adds a human who answers within 4 business hours. Backups are where it changes: on Hobby and Launch your data stays wherever it already lives, usually Supabase, so its backups are that provider’s. From Growth (€59/mo) we run a Postgres database for you, back it up automatically, and test the restores. Upgrading is a plan change in the dashboard.

The questions to ask yourself

If you’re not sure whether your project has crossed the line from “hobby” to “thing people depend on,” run through these:

• Do people I don’t know use it? If yes, you’re past the hobby line.
• Does it store personal data? Email addresses, names, locations, payment info? If yes, you have compliance obligations, at minimum in the EU.
• Would I feel bad if the database disappeared? If the answer is “my users would be upset,” you need tested backups now, not next month.
• Do people use it during specific hours? A booking system, a scheduling tool, a class signup page? If it’s down during those hours, it’s not “a bug,” it’s a broken service.

If you answered yes to two or more of these, your project isn’t a hobby anymore. It’s a small product, and it needs hosting that matches.

The two paths forward

Path 1: Learn ops yourself. Set up a VPS, configure backups, install monitoring, manage deployments, patch the server. This works if you enjoy it and have the time. Budget 10 to 15 hours for the initial setup and 2 to 4 hours a month for ongoing maintenance. Our blog has guides for every step if you want to go this route.

Path 2: Let someone handle it. This is what we do. You keep building your app with whatever AI tool you like. We keep the server running and the deploys safe from €9 a month, add a human on call from €19, and take over your database and its backups from €59.

There’s no shame in either path. But there is shame in the third option: doing nothing and hoping the free tier holds together until you figure it out. That’s how databases get lost.

One thing to do today

If your hobby project has real users and you haven’t done this yet: export your database. Right now. Download a copy to your computer. It takes two minutes and it means that no matter what happens to the platform, the server, or the free tier, your users’ data exists somewhere you can reach it.

Then, when you’re ready for a proper setup, get a free audit. We’ll look at your project, tell you what’s solid and what’s risky, and give you a plan. No charge, no obligation, and no jargon in the report.