OutsourcingVN is operated by Netbase JSC, which runs discovery phases like this before most builds and would sell you one. The questions below are the ones that move scope and risk the most, grouped so a buyer can prepare them in advance.
Contents
- Why do SaaS products need a different discovery?
- Which questions should discovery answer?
- How do you run a discovery phase?
- Worked scenario: a scheduling product for clinics and salons
- What does the cloud ERP record show about these questions?
- Which vendor questions test a discovery offer?
- What goes wrong in SaaS discovery?
- Where AI fits in discovery
- How this guide is sourced and where it stops
- Common questions
- Bring your discovery questions
Why do SaaS products need a different discovery?
A single-customer application answers to one organisation. A SaaS product answers to many at once, and every decision is multiplied: one data model serves every tenant, one release reaches all of them, and one permission mistake exposes somebody else's records. Discovery for SaaS therefore spends less time on screens and more on tenancy, plan states and operating responsibility. The answers set the boundaries that the SaaS product development workflow then builds inside.
Which questions should discovery answer?
| Area | Question to answer | Evidence to bring | What changes if it is wrong |
|---|---|---|---|
| Customers | Which three organisations will use the first release, and what job does each hire it for? | Interview notes, a signed pilot or letters of intent | The feature set targets nobody in particular |
| Tenancy | Is data pooled, siloed or mixed, and which tenant needs separation first? | Customer security questionnaires, contract clauses | Isolation is retrofitted under a live data set |
| Roles | Which roles exist inside a tenant, and what may your support staff see? | A role-by-action matrix drafted with a pilot customer | Permissions are rebuilt after the first enterprise deal |
| Configuration | What varies between customers, and which variations are configuration rather than code? | The top ten requests from early prospects | Special cases become forks |
| Plans | Which plan states exist, and what may a tenant do in each? | A draft plan table with trial, active, past due and cancelled | Billing and access disagree |
| Integrations | Which external systems must connect at launch, and who maintains each connection? | API documentation and sandbox access | Launch slips on a dependency nobody owned |
| Data in | How does a new tenant bring existing data in? | Sample exports from the tools customers use today | Onboarding needs a person for every customer |
| Releases | How often will you release, and can a change be held back for one tenant? | A release calendar and a rollback rule | Every release is an all-or-nothing risk |
| Operations | Who monitors, patches and supports the platform after launch, and in which hours? | An on-call plan, support channels, response targets | The build team becomes the support desk by accident |
| Exit | How does a tenant export and delete its data? | Your privacy commitments and customer contract | Offboarding becomes a legal problem |
A shorter brief is still useful: the software project brief template covers what to send before discovery starts, and this table covers what discovery must finish.
How do you run a discovery phase?
-
Name the decision
Discovery ends in a go, a changed scope or a stop. Write down which, and who decides.
-
Collect the evidence first
Customer interviews, sample data, integration documentation and competitor products the pilot customers already use.
-
Draft the tenant model
Decide pooled, siloed or mixed storage per module, and name the tenant most likely to demand separation.
-
Write the role matrix
Every role against every sensitive action, including your own support staff.
-
Fix the plan states
List the states and what each allows; leave commercial numbers out of the software design.
-
Cut the first release
Choose the smallest release that a real tenant would pay for, and list what is deliberately excluded using scope boundaries.
-
Write acceptance
Each first-release capability gets a testable acceptance criterion.
-
Estimate and decide
Scope, milestones and risks go to the decision-maker named in step one.
Netbase's delivery lifecycle: discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; ongoing support. Discovery is the first of those stages, and its output is the scope the build contract is written against.
Worked scenario: a scheduling product for clinics and salons
A founder plans a booking product for small clinics and beauty salons. She arrives with forty screens designed and asks for a timeline. Discovery replaces the screens with questions.
Three pilot customers are named: two salons and one physiotherapy clinic. Interviews show the clinic needs patient notes that salon staff must never see, which turns tenancy from a detail into the first design decision, and makes a role matrix with a separate clinician role mandatory. The salons both ask for their own booking page colours and a deposit rule; both are configuration, not code. The clinic's existing records sit in a spreadsheet export, so data import becomes a first-release module rather than a later nice-to-have.
The plan table ends with four states and no commercial figures. The first release drops the loyalty scheme and the marketplace listing the founder wanted, because none of the three pilots asked for them. Acceptance is written for booking, reminders, deposits, roles and import. The founder leaves with a smaller first release, a named reason for each exclusion and a build scope she can hold a supplier to.
What does the cloud ERP record show about these questions?
The multi-tenant cloud ERP SaaS record is where Netbase's evidence for this guide comes from. Since 2020, Netbase has worked as offshore development and managing partner on that platform for a US client, and phase one, from 2020 to 2023, served agency SMEs with CRM, real-time messaging, HR, a knowledge base, custom fields and workflows, work and project management, and API integrations. Custom fields and workflows are the configuration answer to the "what varies between customers" question; API integrations are the answer to the integration row.
The recorded stack includes React and Next.js, Laravel and Strapi, PostgreSQL, MySQL, MariaDB and MongoDB on AWS, which shows why the operations row matters: every data engine is something to back up and patch for every tenant.
Which vendor questions test a discovery offer?
- What decision does your discovery end in, and who signs it off?
- Which of our customers will you speak to, and how many?
- How will you decide between pooled and separated tenant data?
- Will the output include a role matrix, plan states and acceptance criteria, or only an estimate?
- What will you exclude from the first release, and will you write the exclusions down?
- Who will be on the discovery team? Netbase project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles.
- How is the build contract agreed afterwards? Most Netbase projects are agreed as fixed-scope contracts after discovery; milestone-based arrangements are also available.
What goes wrong in SaaS discovery?
- Screens before questions. A polished prototype makes every feature look agreed.
- No real customer in the room. Discovery answers the founder's assumptions instead of a tenant's needs.
- Tenancy deferred. "We will add it later" is the most expensive sentence in SaaS planning.
- Commercial plans mixed into the design. Plan states belong in the software; the figures belong in a spreadsheet that can change weekly.
- No exit. Nobody asks how a tenant leaves until the first one does.
- Discovery that never ends. Without a named decision, it becomes unpaid design work.
Where AI fits in discovery
AI can summarise interview transcripts, cluster feature requests and draft a first role matrix for a person to correct. It should not decide the tenant model or the first release. Netbase works with commercial and open-source AI models chosen per project (model-agnostic); no vendor partnership is implied.
How this guide is sourced and where it stops
The question set is editorial guidance drawn from how Netbase scopes projects and from the tenant isolation vocabulary of the AWS Well-Architected SaaS Lens. The only delivery record behind it is the cloud ERP phase one described above: the client and product are not named, no usage, tenant or revenue figure is published, and the retail phase two was planned work when the profile was written and is not presented as delivered. The scheduling scenario is illustrative, not a client. How records are labelled is explained on the methodology page.
Plan the next step for your project
Common questions
Long enough to answer the table above with evidence, and no longer. For a focused first release with pilot customers available, that is usually a few weeks; waiting for customer interviews is the usual cause of delay.
Designs answer what screens look like, not how tenants, roles and plans behave. Keep the designs and run a shorter discovery on the questions they do not answer.
Ask that before discovery for a new build. The custom build versus SaaS guide compares the two routes.
You should. Ask for the role matrix, tenant model, plan states and acceptance criteria as documents you can take to any supplier.
Then it has done its job at the lowest cost. A stop decision with reasons is a valid result.
Bring your discovery questions
Send the three customers you would onboard first and the questions above that you cannot yet answer. A discovery milestone in Custom Product Engineering turns them into a scope, and the project delivery page describes how the build is governed afterwards.
OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with your pilot customers named, and a person will reply with what discovery would cover.
Related services and solutions
Custom product engineering for a bounded release outcome
One defined release of your product, built to named outcomes and handed over with acceptance evidence.
Learn More