Guide · 3 min read

Commercialising an AI-built app: the checklist before your first paying customer

The app runs, the first testers love it, now money should flow. Between “works” and “sellable”, however, lie a number of points an AI assistant won’t raise on its own. This checklist sums them up.

By Danilo Santagata ·

The list is grouped by area. Not every point needs to be perfect on day one. Those marked Must, however, should be done before the first customer pays. The rest belong on the roadmap for the growth phase.

Architecture and data model

  1. Must: company accounts. If you sell to businesses you need more than individual logins: an organisation with several users, roles and a contract status. Without this layer you can neither bill nor cancel cleanly. More in the article on the architecture of AI-built apps.
  2. Must: data on persistent storage. The database survives every deployment and restart.
  3. Must: tests for the core logic. What makes the app unique – calculations, rules, imports – is protected by automated tests.
  4. Versioned database migrations. Every schema change is traceable and repeatable.
  5. Separated layers. UI, business logic and data access aren’t knotted together in one file – otherwise every customer request becomes a risk.
  6. Sessions not in memory. Users stay logged in after a restart, and a second server process is possible.
  7. Load test with realistic usage. You know the limit before your customers find it.

Security

  1. Must: access rules verified. A customer never sees another customer’s data – proven with two test accounts. For Supabase apps there’s a guide.
  2. Must: no secrets in the frontend or repository. All keys live in environment variables on the server. Anything ever committed has been rotated.
  3. Must: proven authentication. An established service or library instead of a home-made one, with password reset for customers.
  4. Rate limits and cost caps for login, forms and above all for AI features that cost money per call.
  5. Dependencies audited, and a process to keep them current.

Operations

  1. Must: backup outside the production server – and a restore that has actually been tried at least once.
  2. Must: monitoring with alerting. You hear about an outage before a customer calls.
  3. Error tracking (e.g. Sentry) instead of digging through log files.
  4. Separate test and production environments. New versions aren’t tried out on customers first.
  5. Automated deployment from version control, with the ability to roll back a release.

These points don’t replace legal advice. They show you where to look.

  1. Must: legal notice. Anyone offering services online must clearly state who is behind them, including address and contact (Swiss UWG Art. 3(1)(s)).
  2. Must: privacy policy under the Swiss Data Protection Act (FADP) – and under the GDPR if you serve customers in the EU.
  3. Must: data processing agreements. Hosting, email, payment provider and above all AI providers process your customers’ data. That needs contracts, and for providers abroad a review of the data transfer.
  4. Must: terms and conditions covering scope of service, liability, termination and how customer data is handled after the contract ends.
  5. Rights to third-party data and licences. May you commercially pass on the data, images or content your app uses? And do the licences of the libraries you use permit your business model?
  6. Deletion and retention rules that are implemented technically, not just on paper.

Money

  1. Billing. For the first customers a manual invoice is fine, as long as the account status is tracked cleanly in the system. From a few dozen customers on, a payment provider with automatic activation and suspension pays off.
  2. Keep VAT in view. In Switzerland VAT registration becomes mandatory from CHF 100,000 annual turnover – counted worldwide. If you sell digital services to consumers in the EU, those countries’ rules apply as well.

How to proceed

Work through the Must points first, in this order: legal sellability, company accounts, secure operations, tests. Only then are bigger investments in architecture and scaling worth it – based on real usage data rather than guesses.

If you’re unsure about more than a handful of points, an outside view is usually faster than searching your own code.