In this guide 6 sections
Ask who owns the code and hosting accounts. Find out how one customer’s data is kept apart from another’s, how billing and plan changes work, what admin tools you get and what is tested. Then ask about handover and post launch support. Vague answers are the warning.
Who owns the code, the accounts and the data?
Ask this first. It matters most. The repository, the domain, the cloud account, the app store listing and the payment account should all be registered in your name from day one. A vendor holding them as a bargaining chip is a risk you cannot fix later.
Ask for the licence terms on any boilerplate or component library they reuse from earlier projects. Check whether an MIT or GPL package sits in the dependency list. A worrying answer is that the code is licensed to you, not owned by you, or that handover happens only after the final invoice.
- Repository created under your organisation
- Cloud and domain accounts in your name
- Written list of third party licences
- Source and database handed over on request
How is each customer’s data kept apart?
A SaaS product holds records for many customers in one system. Press on how a query for one customer can never return another’s rows. Good answers name a tenant_id column on every table, enforced in one shared place such as PostgreSQL row level security. They also run tests that deliberately try to cross the boundary.
If a customer wants to leave and take their data, what then? Export and deletion should be designed, not improvised.
A worrying answer is that developers remember to add the filter in each query.
What about billing and admin tooling?
Billing is where MVPs quietly grow. Proration on mid-cycle upgrades, dunning emails for expired cards and seat counts all arrive sooner than expected. Name the payment provider, then probe how trials, upgrades, failed cards and refunds are handled. Ask whether invoices and tax details are produced. Who writes the Stripe webhook handlers that keep subscription status correct? A missed invoice.payment_failed event leaves a dead account marked active.
Then ask about the admin side. You need a screen to list tenants, impersonate a user for support, reset a password, change a plan and read an audit log. Missing from the quote? You will run support from the database. Request screenshots from a previous build.
- Subscription states: trial, active, past due, cancelled
- Webhook retries and idempotency
- Admin screen for tenants and users
- Audit log of who changed what
Testing, hosting and handover
Ask what is tested automatically and what is checked by hand. A short Cypress or Playwright suite beats a long promise. Sign up, login, checkout and tenant isolation should have automated tests that run in a CI pipeline on every pull request.
Where will the product run, in Docker on a cloud server or on a managed platform? How are backups taken and restored? Is there a staging copy with its own database? Ask for a runbook, an architecture diagram, an environment variable list and a recorded walkthrough.
A worrying answer is that tests will be added later. They rarely are.
What happens after launch?
Launch is the start of the work. Plan for it, including error tracking in Sentry, uptime alerts and a rota for out of hours faults. Ask what support covers, how fast faults are answered and whether a named person is responsible. Check whether bugs found in the first month count as warranty or as new billed work.
Test how easily you could move to another team. A vendor confident in its code makes this easy.
Before you sign, send these questions in writing and compare the written answers across the companies you shortlist.
Vendor question sheet
A sheet of one page with eight rows: ownership, tenant isolation, billing, admin tools, testing, hosting, handover and support. Columns hold the question, the vendor’s answer, a red flag note and a score from one to three. The footer totals the scores for each company on the shortlist.
Open a blank worksheet to printQuestions owners ask
What should a SaaS MVP include?
Sign up, sign in, one core workflow, a way to charge, a basic admin panel and tenant separation. Extras can wait until real users ask for them.
Who should own the source code?
You should, from the first commit. Insist that the repository sits under your organisation and the contract states that the code is yours.
How do I check the quality of the code?
Have an independent developer read a sample module, run the tests and build the project on a clean machine following the handover notes.
Is a fixed price or hourly rate safer?
Neither is safe alone. Fix the scope of the first release in writing and agree how changes are priced, so surprises are visible.