The salon owner wants clients to book a haircut. Before that can happen, the software asks them to design a page, choose fields and configure a workflow. Every unanswered product decision has become the owner’s setup task.
A narrow audience can make that setup much shorter. When the product understands the work, it can supply a useful starting point instead of asking the customer to invent one. That is the advantage I used in KRI, a booking SaaS for salons, barbershops and solo beauty specialists.
It is also easy to draw the wrong lesson: a niche does not automatically make software simple, and a horizontal product does not automatically need a configurable builder.
Audience and Configurability Are Two Different Decisions
Vertical SaaS serves a particular industry or group of related industries. Horizontal SaaS serves a function across industries. A scheduling tool used by salons, consultants and tutors can be horizontal even if it has almost no settings. A salon management suite can be vertical and still contain a complicated workflow builder.
Configurability is a separate choice. It determines how much of the product’s behaviour the customer can change. The useful question for a first version is: which decisions can we safely make because the first customers share a workflow?
| Decision | Question to answer |
|---|---|
| Initial audience | Who has the problem, and how will we reach them? |
| Shared workflow | What do those customers do in substantially the same way? |
| Defaults | Which setup choices can we make on their behalf? |
| Necessary flexibility | Which differences would prevent them from using the product? |
A niche helps when it produces concrete answers to those questions. Narrowing the marketing label without narrowing the workflow will not remove much implementation work.
What KRI’s Defaults Remove
KRI offers 13 business types within beauty and personal care. Choosing one supplies a starting list of services and prices. The owner can edit it, but they do not have to create the whole catalogue from an empty form.
Four designs replace a page editor. Onboarding groups the necessary setup into four steps: business type, name and city, services, and team. The team step includes the people clients can book and their working hours; ‘four steps’ does not mean only four data fields.
These choices remove specific work from both sides. The owner adjusts a starting point. The product avoids maintaining a general page editor, arbitrary layouts and every combination of configurable booking fields. The service defaults are suggestions to review, not a promise that one price list fits every market.
That is the concrete scope reduction. It comes from shared needs plus deliberate limits, rather than from the word ‘vertical.’
Test the Defaults Before Building the Settings
A useful early exercise is to put the proposed setup in front of several intended customers. Ask them to prepare their own services, hours and first bookable appointment. Watch where the defaults help and where they prevent the task from being completed.
If owners mostly change names and prices, a template may cover the common workflow. If every business needs a different booking unit, resource model or approval process, the proposed niche may still be too broad, or the product may need a narrower first use case.
This is a validation method, not a claim about measured KRI onboarding results. The current product shows which implementation choices I made; proving that those choices improve completion or conversion requires observing customers.
Before adding a setting, identify the real task it enables. A request to rename a label is different from a requirement to book several resources together. The first may be a small preference; the second can change the scheduling model. Treating both as ‘more customisation’ hides the cost.
A Narrow Audience Does Not Require a Large Launch
KRI also has 32 languages and an application-owned billing layer. Those are separate scope choices. They are not a checklist for a first vertical SaaS, and narrowing the industry does not make them cheap.
A first release can serve one reachable market in one language. A provider-managed subscription may cover its billing needs. Add countries, locales and custom billing only when the intended launch and customer requirements justify them. Scoping an MVP means making those boundaries explicit.
Multi-tenancy needs the same precision. If one running product serves several independent businesses, their data must be isolated from the start. That does not mean the first release needs enterprise account hierarchies, elaborate roles or every team-management feature. Tenant isolation and a large collaboration suite are different requirements.
What Still Has to Be Correct
A smaller feature set still needs to do its core job reliably. KRI’s clients choose a specialist and an available time; concurrent client bookings must not silently claim the same slot. Its owner-facing workflow deliberately permits manual overlaps, which introduces a separate concurrency boundary.
Billing still needs an explicit owner for invoices, payment status and access decisions, whether that owner is application code or a managed billing system. Supporting multiple languages creates review and consistency work. Supporting time zones introduces calendar and DST decisions.
The scope choice is how many of those capabilities the first market requires. Correctness inside the chosen scope remains necessary.
When a Broader Product Makes Sense
A horizontal approach can be a good first product when the same small workflow repeats across industries, or when you already have a credible route to customers in several segments. A configurable approach makes sense when adapting workflows is itself what customers need and will pay for. Neither case requires choosing the other automatically.
For a niche-first product, write down the workflow that becomes simpler because of the niche. For a broader product, write down what genuinely stays the same across its audiences. If neither answer is concrete, a larger potential market will not settle the product decision.
Start with the customers you can reach and the task you can make easier. Let those facts determine how narrow and how configurable the first version should be.
