Launch a SaaS Product Checklist: The Legal and Tax Bits
Orkosi Team · · 12 min read
Search for a launch a SaaS product checklist and you will mostly find onboarding emails, Product Hunt timing and pricing page copy. The items that can genuinely stop you taking money, or claw it back six months later, rarely make the list: published terms, a privacy notice that matches your database, a cancellation link, receipts, VAT, sales tax and a way to delete an account. This article covers that half, and it assumes you do not have a lawyer on retainer.
The part of the launch checklist that isn't in the demo
Building the product is no longer the bottleneck. An agent or a competent builder can ship authentication, a billing integration and a dashboard in days, which means the real launch blockers have migrated from code to obligations. The constraint is not "can we build it" but "can we charge for it, in these countries, to these people, and prove what we did".
Founders under-invest here for a rational reason: none of it is visible until someone asks. No user complains that your privacy policy is generic. Then a customer requests deletion under GDPR, a card network opens a chargeback and wants your refund policy, or a US state sends a nexus questionnaire, and the cheap version of the work becomes the expensive version.
So separate two categories before you start. Legally required day one means a rule applies the moment you take money from a stranger over the internet. Theatre means it looks professional, or it unblocks an enterprise deal you do not yet have. SOC 2 is theatre at launch. A cancellation link is not. Mixing them up is how pre-revenue founders spend six weeks on a trust page.
(None of this is legal advice. It is the operating list that most self-serve SaaS businesses converge on, and the places where a one-hour lawyer consultation actually pays.)
Launch a SaaS product checklist: what must actually be live the day you take money
Each item below is hours of work now and a mess later.
Terms of service and privacy policy you've read
Publish both at stable URLs, link them in the footer and in the checkout flow, and record acceptance with a timestamp and version. A generated or templated set of terms is fine. An unread one is not.
The failure mode is not "my terms are generic". It is terms that contradict the product. A template that promises a 30-day refund while your billing page says no refunds, or one that claims you do not use subprocessors while you call a model provider on every request, is worse than nothing, because you have now published a false statement about your own service.
For the privacy notice, GDPR Article 13 sets out what you must tell people at the point you collect their data: who you are, why you are processing, the legal basis, who receives the data, how long you keep it, and their rights. Write that section from your actual schema and your actual vendor list, not from a template's guesses. Then read both documents line by line against the product once, out loud if necessary. That hour is the whole exercise.
A real company identity and contact route
Put a legal entity name, address and working contact email on the site. Many jurisdictions require seller identity disclosure for distance selling, payment processors require it for underwriting, and chargeback adjudication goes badly when the merchant is anonymous.
A sole trader or an unregistered individual can take payments in plenty of places, and a limited company or LLC is often a week and a few hundred dollars. Do it before launch if you can, because switching the entity behind a payment account after you have live subscriptions is genuinely annoying.
A cancellation path a customer can find
One link, inside the logged-in app, that cancels the subscription without an email to support. Not a contact form, not a retention call.
This is the single highest-return item on any SaaS launch legal checklist. It removes the most common trigger for chargebacks, it satisfies the direction of travel in consumer-protection rules on both sides of the Atlantic, and it takes an afternoon.
Billing is a legal surface, not a feature
Subscription mechanics are regulated commerce. Price, renewal cadence, and what happens when the card fails are disclosures, not UX choices.
Click-to-cancel and auto-renewal disclosures
Before the charge, state the price, the billing interval, the fact that it renews automatically, and how to stop it. After the charge, send a confirmation email containing the same facts. Regulators in the US, EU and UK have converged on the same shape: clear pre-purchase disclosure, express consent, and cancellation that is at least as easy as signup.
Build cancellation before you build upgrade flows. Upgrades earn you money; cancellation protects you from refunds, disputes and regulator attention. Founders consistently do this in the wrong order.
Receipts, invoices and proration
Every charge needs a receipt the customer can retrieve later, and your accountant needs an invoice record with the fields their jurisdiction requires. If you serve EU business customers, that means a VAT-compliant invoice showing your VAT number, theirs, and the reverse-charge note when it applies.
Decide proration policy once and encode it: what happens on mid-cycle upgrade, downgrade and cancellation. "We will figure it out when someone asks" means your first ten support tickets are refund arguments.
Your emails are also regulated. The FTC's CAN-SPAM guide requires accurate sender identification, a physical postal address and honoured unsubscribes within ten business days, which applies to the launch announcement, not the receipt.
Dunning, chargebacks and the refund promise
Failed payments are normal, roughly 5 to 10 percent of recurring charges in the wild, and they need a retry schedule, a dunning email sequence and a defined point where access is suspended rather than silently continued.
For chargebacks, your defence is documentation: terms accepted at timestamp X, product used on dates Y, cancellation link present, refund policy published. Keep an audit log from day one. You cannot retrofit evidence of what a user saw in March.
Write the refund promise you can actually live with. "14 days, no questions" is cheaper than the support conversations caused by "case by case".
Tax: the thing that accrues quietly while you ship
Tax surprises people because it accrues in the background, in jurisdictions where you have never been, and nobody sends a warning email.
EU VAT on digital services and OSS
For business-to-consumer sales of digital services, EU VAT is due where the customer is, at that country's rate, regardless of where you are. A business in Lisbon selling to a consumer in Dublin charges Irish VAT.
EU-established sellers get a cross-border threshold (currently €10,000 across all other member states) below which they can charge home-country VAT. Sellers established outside the EU get no such threshold and are in scope from the first sale. The One Stop Shop (OSS, or non-Union OSS for non-EU businesses) lets you file one quarterly return for all member states instead of twenty-seven registrations. Selling B2B to a VAT-registered business usually shifts the liability to the buyer under the reverse charge, provided you validate and store their VAT number.
US sales tax nexus after Wayfair
Before 2018, a state could only tax sellers with a physical presence. South Dakota v. Wayfair ended that, and states now assert economic nexus based on sales volume alone, commonly $100,000 in revenue or 200 transactions into that state in a year, with the specifics varying.
Two complications for SaaS. First, whether SaaS is taxable at all differs by state: a meaningful minority tax it, others do not. Second, nexus is tracked per state, so you can cross a threshold in Washington while being invisible in Oregon. At early revenue you are almost certainly below every threshold, which is exactly why the only job today is measurement, not registration.
Automated tax vs merchant of record
| Approach | What you handle | Fees | Who is liable |
|---|---|---|---|
| Roll your own | Rates, geolocation, VAT number validation, registrations, filings | Accountant time | You |
| Automated tax (e.g. Stripe Tax) | Registrations and filings; the tool calculates, collects and monitors thresholds | Per-transaction fee on top of processing | You |
| Merchant of record | Almost nothing; the reseller sells to the customer | Commonly around 5% plus a per-transaction fee | The MoR |
Automated tax handles the part founders get wrong: determining the right rate for the customer's location, applying reverse charge, and alerting you when you approach a registration threshold in a new state or country. It does not file returns for you by itself.
Under roughly $10k MRR, pick based on customer mix. Global B2C or prosumer, with customers in a dozen countries and small ticket sizes: use a merchant of record and accept the 5%, because the alternative is twelve registrations you will administer badly. Mostly US or mostly B2B: use automated calculation, keep your margin, and register only when thresholds say so. Rolling your own is defensible only if you sell in one country.
What you collect decides what you owe
Your data obligations are set by architecture, not by policy text. Every extra form field, analytics script and model provider expands the surface, and a privacy policy written after the fact just documents a mess you chose.
A one-page data map
One page, four columns: what data, where it lives, who touches it, how long you keep it. Email addresses in Postgres on eu-west-1, retained until deletion. Prompt contents sent to a model provider, retained 30 days on their side. Session recordings, retained 90 days, if you really want them.
Writing this page usually deletes two or three data collection decisions, which is the point. The cheapest compliance move available to a startup is collecting less.
Subprocessors, regions and the DPA question
Name your subprocessors publicly: hosting, email, payments, analytics, model providers, error tracking. Pick one primary region and stick to it. If most of your users are European, deploying in an EU region removes a whole category of transfer questions.
You do not need signed, negotiated data processing agreements with every customer at launch. You do need the standard DPA offered by each vendor in your stack, which is usually a checkbox in their dashboard. Note also the AWS shared responsibility model: AWS secures the infrastructure, you own configuration, access control, encryption choices and the data itself. A managed deployment does not inherit compliance for you.
Deletion and export as product features
Ship account deletion with a proper cascade, and a data export endpoint, before launch. GDPR Article 17 gives people a right to erasure, and handling that manually through SQL at 11pm is how production accidents happen.
Deletion is harder than it looks because of the places data leaks to: your email provider's contact list, your analytics tool, your backups. Decide the backup policy now (for example, deleted from live systems immediately, purged from backups within 35 days) and write it in the privacy notice.
What you can honestly defer, and the trigger that ends the deferral
| Item | Defer until |
|---|---|
| SOC 2 Type II | First enterprise procurement process that blocks on it, usually a deal above $20k ARR |
| Penetration test | Enterprise security review, or handling health or financial data |
| Trademark registration | You have product-market fit, or someone else files in your class |
| Cyber liability insurance | First contract requiring it, or first employee |
| Entities in other countries | Local hiring or a tax adviser telling you to |
| Negotiated customer DPAs | First customer whose legal team redlines yours |
| Security questionnaire library | Third identical questionnaire |
| Sales tax registrations | Crossing a state's economic nexus threshold |
The pattern is the same: all of these are reactive, and all arrive with a counterparty willing to wait a few weeks. None should consume launch time.
Making the agent do the boring parts
Most of the day-one list is ordinary engineering, which makes it a good fit for AI agents working as queued tasks against a deployed app.
Tasks worth queueing before launch
- Billing settings page with plan, next renewal date, invoice history and a working cancel button
- Transactional emails: receipt, renewal reminder, payment failure, cancellation confirmation, with sender identity and unsubscribe handling
- Account deletion endpoint with a documented cascade and a confirmation step
- Consent record table: policy version, timestamp, IP, what was accepted
- Append-only audit log for billing and access events
- Legal pages rendered from versioned files, with an effective date and a change log
- Tax-inclusive versus tax-exclusive price display, decided by customer region
- A data export endpoint returning everything tied to a user ID
On Orkosi, these are the kind of tasks you queue against a running product rather than a prototype: the app is already deployed on AWS, with hosting and billing in the box, so "add a cancel button and a confirmation email" is a task, not a sprint. The templates and features pages cover what each app type ships with, and pricing explains how task credits work. The honest trade-off: an agent is excellent at mechanical, well-specified work and poor at ambiguous judgement, so the quality of the output tracks the quality of your decisions.
What still needs a human decision
An agent cannot choose your jurisdiction, your retention periods, your refund policy, your pricing model or whether to use a merchant of record. It also cannot read your terms against your product and notice the contradiction, because it does not know which one you meant.
Spend your hour on those five decisions and one consultation with an accountant who understands digital services. Hand everything downstream of them to the build queue. The docs describe how to scope tasks so the agent implements your decision rather than improvising one.
FAQ
Do I need a registered company before I launch a SaaS?
Not everywhere, but you need a legal identity you can publish and a bank account the processor will accept. Many founders start as a sole trader or individual and incorporate once revenue is steady. Incorporating first is usually easier, because moving live subscriptions to a new entity later means a new processor account and new tax registrations.
Is a generated terms of service good enough for launch?
For a straightforward self-serve SaaS, yes, provided you read it and fix the places it contradicts your product. The risk in a template is not its genericness, it is the clauses describing a business you do not run: wrong refund window, wrong governing law, promises about subprocessors or data retention you do not keep. Pay a lawyer to review before your first enterprise contract or before you touch regulated data.
Do I have to charge VAT or sales tax on my first sale?
Sometimes yes. If you sell digital services to an EU consumer and you are not EU-established, VAT is generally due from the first sale at the customer's local rate; EU-established sellers get a €10,000 cross-border threshold. For US sales tax, economic nexus thresholds after Wayfair mean most early-stage sellers owe nothing yet, but you must track sales per state to know when that changes.
What's the minimum GDPR work for a solo founder with EU users?
Four things: a privacy notice covering the Article 13 points, a lawful basis for each processing activity, vendor data processing agreements for your stack, and working deletion and export. Add a cookie or tracker consent banner only if you actually run non-essential trackers, and keep a one-page record of processing activities. That is a day of work, not a quarter.
Ready to stop reading checklists and start shipping the items on them? Start free and queue the billing, deletion and legal-page tasks against a real deployed app, or review pricing to see how credits map to the work you need done.