What do I need in place before my first paying customer?
Before anyone pays, you need five things: each customer's data kept separate from everyone else's, payment status checked on your server rather than in the browser, a backup you have restored once, a way to hear when something breaks, and a way for the customer to reach you. Everything else can wait for the second customer.
You do not need perfect code, a test for every screen, or a different host. A first paying customer is one person who trusts you. The list is about not losing their data, their money or that trust in the first week, and about hearing when something goes wrong before they tell you.
If you have the five in place and one customer paying, you probably do not need help yet. Keep going.
In founders’ words
“The customer did everything right. She filled in all the information, even more than required. Somewhere in my system, something silently broke.
Building the app was maybe 20% of the work. The other 80% is stability, edge cases, monitoring, bug fixing, and security.”
“I have no real idea what stands between "works on my screen when I demo it" and "12 colleagues use it every morning and it doesn't fall over.”
The five things, and how to check each one
- Separate data. Make two test accounts. Log in as the first, copy the address of one of its records, log in as the second and open that address. You should be refused. On Supabase, every table should show row level security turned on.
- Payments on the server. Use Stripe Checkout or a payment link. What marks a customer as paid must be the webhook on your server, never the browser coming back from checkout. Handle "payment failed" and "subscription cancelled" too. Run a purchase and a cancel in test mode.
- A backup you have restored. Turn on automatic backups, download one, and restore it into a second database. Time it.
- Alerts. Error reporting that emails or messages you, an uptime check every few minutes, and a billing alert on each paid service.
- A way to reach you. A support address you read, shown in the app and on the receipt, and a refund rule you decided before anyone asks.
What a first customer actually does
Real people do things you did not try. They double-click the pay button. They refresh during checkout. They type an apostrophe in their name, upload a forty megabyte photo, sign up with a typo in their email, and ask for a refund on day two. Before you launch, do each of those yourself on the live site in Stripe test mode and see what happens.
The failures that hurt most are silent. The customer finishes, nothing errors, and the result is empty because one step in the middle failed without telling anyone. After the checks above, open your database and look at the record of your own test purchase. Every field you expected should be there. If one is blank, you found the bug before a customer did.
Keys and secrets, the thing most AI-built apps get wrong
An AI coding tool will put a secret key into the browser code if that is the fastest way to make a feature work. The two that matter most are your payment provider's live secret key and your database's service role key. The service role key is a master key that ignores every data rule you set. Anyone who views the page source can read it.
Open the built site in a browser, view the source or the network tab, and search for "sk_live" and "service_role". If either appears, rotate the key today in the provider's dashboard and move that call to a server function. Then ask the coding agent to search the whole repository for any other key and to add a rule to its instructions file: secrets live in environment settings, never in code.
What you can leave until later
Scaling, a custom email domain, a design refresh, a second platform, and any rewrite. None of those protect a first customer. A privacy policy and terms are not on that list: have both, read both, and a template is fine to start.
Tests are worth having, but only two to begin with: one that signs up and logs in, one that completes a purchase. Ask the coding agent to write them and run them before every change. They catch the two failures a customer would notice first. The rest of the test suite can grow with the product.
When to bring someone in
Bring someone in when money is already moving through the app and you cannot tell whether the five are done, when the app holds health, financial or other people's customer data, or when your own business already runs on it. In those cases the cost of a quiet failure is higher than the cost of a second pair of eyes.
If none of that applies, do the list yourself. It takes a day or two for most apps, and you will know your product better at the end of it.
| Have in place | Why | Ten-minute check |
|---|---|---|
| Each customer sees only their own data | One leak ends the trust you are selling | Two accounts, swap a record address, expect a refusal |
| Paid status set by the server webhook | Browser-set status can be faked or lost on refresh | Complete a test purchase, then look at the database record |
| A backup restored once | Backups fail quietly until the day you need one | Restore into a second database and time it |
| Error and uptime alerts to your phone | The first report should not come from the customer | Break something on purpose in staging and wait for the alert |
| No secret keys in the browser | A service role key bypasses every rule | Search the page source for "sk_live" and "service_role" |
| A support address and a refund rule | Customers forgive bugs, not silence | Email yourself from the app's contact link |
Questions
Can I keep using Lovable, Bolt or Replit hosting with paying customers?
Yes, if the five things are in place. Connect the project to GitHub first so the code exists outside the tool, and turn on backups for the database wherever it lives.
Do I need a registered company before I charge?
That depends on where you live, and we are not lawyers. Payment providers ask for a legal name and tax details either way. Ask an accountant before the first charge, not after.
What if the first customer finds a bug?
Tell them, fix it, and refund if the product did not do what they paid for. A fast, honest reply keeps most first customers. Then add that case to your checks so it does not happen to the second one.
Do I need automated tests before the first customer?
Two: sign up and log in, and complete a purchase. The coding agent can write both. Run them before every change you ship.
How long does this list take?
A day or two for most apps, if nothing is badly wrong. The slowest step is usually the backup restore, and that is also the one most people skip.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.