SaaSChoosing a vendorContractsCode ownership
What a SaaS development agency should actually do
9 min read
A SaaS development agency has to do what a regular software agency does not: keep every customer's data apart on a shared platform, bill subscriptions, run the service continuously, and plan how a customer leaves as carefully as how one signs up. Before you compare quotes, one question settles most of the rest: who will be the publisher of the software, you or the agency?
This article does not rank agencies. It sets out the five skills specific to SaaS, the questions that reveal them in a first meeting, and what the contract should say about each. For general vendor selection (method, team, pricing), our guide on how to choose a software development company covers the basics.
Why SaaS needs a different skill set
A business application serves one company. A SaaS product serves dozens or hundreds of companies on one platform, each paying every month and expecting the service to work whenever they need it. That changes the supplier's job in three ways:
- One bug reaches everyone. A permissions flaw in an internal tool shows data to a colleague. In SaaS it can show one customer's data to a competitor.
- The software never stops. Updates ship while customers are working, and downtime is measured in churned accounts.
- The relationship lasts. Shipping version one is the start, not the end: fixes, security patches, new features and support continue for as long as the service exists.
An agency that has mostly built marketing sites or internal tools can learn all of this. You simply want to know before it learns on your product.
1. Isolating tenant data
This is the foundation. Each customer company (a tenant) must never see another tenant's data. AWS's whitepaper on SaaS tenant isolation strategies describes the main architecture families:
| Model | Principle | Strength | Watch out for |
|---|---|---|---|
| Pool | All tenants share the same database, filtered | Lower cost, one deployment for all | One missing filter exposes another tenant's data |
| Silo | Each tenant gets dedicated resources | Strong isolation, easier compliance | More infrastructure to run and update |
| Bridge | Pooled by default, siloed where needed | Flexibility | Two models to maintain |
The same paper is blunt: shared infrastructure is never a reason to relax isolation, because it raises the risk of cross-tenant access. This is not a theoretical worry. The OWASP Top 10 for 2025, the reference list of web application risks, ranks broken access control first and reports some form of it in 100% of the applications tested. One of its textbook examples is viewing someone else's account by changing an identifier in the URL.
What a competent agency shows you: one central mechanism that scopes every query to the right tenant, and automated tests proving that a user from tenant A gets nothing from tenant B. Our explainer on multi-tenant SaaS architecture goes further.
2. Subscriptions and billing
SaaS revenue arrives every month. The agency should know how to integrate a payment provider and handle plans, trials, mid-cycle upgrades and downgrades, failed payments and dunning, without rebuilding what those providers already do well. Integrate, do not reinvent.
Two topics get forgotten:
- The invoices themselves. Several countries now require structured e-invoices between businesses, and France is phasing in its own mandate. If your SaaS bills companies in those markets, the invoice format is part of the build.
- The link between payment and access. When a customer stops paying, what happens, and when? Those are business rules you decide, not technical details to leave to the developers.
3. Running the service around the clock
Delivering code is not enough. Someone has to run the service: hosting, monitoring (hearing about problems before customers do), backups tested by actual restores, dependency security updates, incident response and second-line support.
Ask who does what after launch, line by line. Three set-ups can all work:
| Set-up | What it requires from you |
|---|---|
| The agency operates | A service agreement with written commitments |
| You operate | In-house skills or a separate operations provider |
| Shared operations | A clear boundary: who gets paged at 3 a.m. |
An agency that already runs its own products in production knows what a night-time incident costs. LPR Studio publishes and operates two live products itself, Izi-Devis and Tubissime; this checklist comes from that work.
4. Planning the exit
SaaS products live for years, and suppliers change. Plan two exits:
- Yours from the agency. You should be able to take the product back or hand it to another team: code access according to the agreed rights, documentation, deployment scripts, and hosting accounts in your name or transferable to you.
- Your customers' from you. A customer who leaves must be able to take its data. If you serve European customers, the GDPR requires a processor, at the end of the service and at the controller's choice, to delete or return all personal data (Article 28(3)(g)).
An agency that designs data export into version one saves you a painful retrofit later. Our guide to avoiding software vendor lock-in lists the clauses that make an exit workable.
5. Knowing who the publisher is
Many founders discover this question too late. The publisher is the party that sells the software, answers to its customers for it and earns its revenue. Depending on the deal, that is you or the agency:
| Deal | Publisher | What to check |
|---|---|---|
| Fixed-price build commissioned by you | Usually you | The scope of rights transferred over the code |
| Agency builds and runs it for a monthly fee | Often the agency | What you can do with the product if you stop |
| Product the agency already publishes | The agency | Configuration options and data portability |
No deal is better in principle. A founder planning to raise money or sell the company will need to prove its rights over the product; a business that mainly wants a tool that works may prefer not to carry operations. Either way, each party's rights are defined case by case in the contract. Our article on who owns custom software source code explains assignment versus licence, and software development contract clauses lists what to read before signing.
How to check these claims without being technical
You do not need to read code to test an agency on these five points. Ask for a live demonstration rather than slides: log in as a user of one test customer and try to open a page belonging to another. Ask to see a recent incident report from one of the products the agency runs, and how it was handled. Ask for a sample of the operations documentation it hands over at the end of a project. Ask what a data export looks like for one customer. An agency that does this work every day can show you all of it within a meeting or two; one that cannot is telling you something useful too. If you want an independent opinion, a short paid review by an experienced CTO before signing costs little compared with the build itself.
Questions for the first meeting
| Question | A good answer | A red flag |
|---|---|---|
| How is each request restricted to one tenant's data? | One central mechanism, tested automatically | "We are careful" |
| Which SaaS products do you run in production today? | Live services you can look at | Only websites or mock-ups |
| Who receives the alerts after launch? | A name, a procedure, written commitments | "Call us if something breaks" |
| How does one of my customers export its data? | An export built into version one | "We will deal with it later" |
| Who is the publisher, and what rights will I have? | A written answer tied to the chosen model | A vague verbal answer |
| What will you show me before I commit? | A prototype or a concrete demo | A quote and nothing to look at |
What no agency will do for you
Even an excellent agency cannot tell you whether companies will pay for your product. Validating demand, setting the price, selling and choosing priorities stay with you. If you also need someone to own technical decisions at your side, you are really asking about a CTO, which we compare with a studio in fractional CTO or development studio.
Where LPR Studio fits
LPR Studio is a software publishing studio based in Rennes, France. We start with a free visual prototype, presented over video within 5 working days, so you see your SaaS product's main journey before committing to anything. Then there are three models: SaaS publishing (software we publish and run), subscription (we build and run your application without you paying for development, and we remain the publisher) and fixed price. We do not sell hours or staff. The models are described on our offers page.
We are not the right fit for everyone. If you want to build an in-house engineering team from day one, or if your product is primarily a research problem, a technical hire or cofounder will serve you better than a studio.