You've run the process by hand for 50 clients. You know which step trips people up, which exception shows up in one engagement out of nine, which field the regulator actually reads. That knowledge is the business. The software is supposed to encode it.
Then a developer scopes the build as a list of entities with forms attached, and you watch your hardest-won judgment flatten into a CRUD app with your logo on it.
The trap is mistaking the records for the business
A service business that productizes into vertical SaaS has one job: take the part of the work that lived in a senior operator's head and make it executable by software, repeatably, for customers who don't have that operator.
The records are the easy half. Clients, projects, documents, invoices — every framework scaffolds those in an afternoon. If that were the product, your competitor would be a Notion template.
The business is the part between the records. The rule that says a Type 3 engagement skips step four but only when the client is in a regulated state. The ordering constraint where you cannot issue the certificate until two independent reviews agree. The escalation that fires when a deadline is 11 days out and a dependency is still open. None of that is a field. It's the logic that made customers pay you instead of doing it themselves.
Build the CRUD and skip the logic, and you ship a filing cabinet. Customers churn the moment they realize the software doesn't actually know anything — it just holds what they type.
Map the workflow before you model the data
The instinct is to start with the schema. Resist it. Start with the workflow, because the workflow is where your domain knowledge lives, and the schema should fall out of it — not the reverse.
A workflow map for vertical SaaS has to capture the things a service operator does without thinking:
- States, not statuses. A "status" field is a dropdown. A state machine encodes which transitions are legal. An engagement can go from
intaketoreviewbut never fromintakestraight toclosed— and the software should refuse the illegal jump, not log it and move on. - Conditional paths. The exceptions you handle by instinct. The 1-in-9 case. If your map has no branches, you haven't captured the business; you've captured the happy path a junior would draw.
- Roles and gates. Who can advance a step. What two-party approvals exist. Where a reviewer must be different from the author. These are the controls customers are actually buying.
- Time and deadlines. What's driven by a clock — SLAs, statutory windows, reminder cadences. Most service-business value is "we never miss the deadline." That has to live in the system, not in someone's calendar.
We do this map first because it's reversible. A bad schema is a migration. A bad workflow model is a rewrite, because every screen, every permission, and every report was shaped by the wrong skeleton.
Model the domain so the rules have a home
Once the workflow is honest, the data model has a job: give every rule a place to live where it can be enforced, not just described in a help doc.
That usually means a few decisions most "CRUD-first" builds skip:
A state machine table that records legal transitions and who triggered them — so you get an audit trail for free and the illegal transition becomes impossible at the data layer, not merely discouraged in the UI.
Versioned records for anything a customer or regulator might dispute later. When the rule was X on Tuesday and Y on Thursday, you need to answer "which rule applied to this engagement" with a timestamp, not a shrug. Soft-deletes and an append-only history table cost little up front and save a deposition later.
Configuration as data, not code. Your 1-in-9 exception varies by customer segment. Hardcode it and every new segment is a deploy. Model the rule as data — thresholds, eligibility, branch conditions in a table the product owner can reason about — and onboarding a new segment is a configuration change, not an engineering ticket.
The test: can the software say no? A filing cabinet accepts anything. A product that encodes your domain refuses the certificate when the two reviews disagree, blocks the transition that skips a mandatory gate, and flags the deadline before it's missed. If your build can't say no, you didn't productize the business — you digitized the paperwork.
The first ten customers are not the same customer ten times
Service businesses survive on bespoke handling. Every client got a slightly different process because you were there to flex it. Software doesn't flex unless you design for the flex — and over-designing for it is its own failure.
The move is to find the 80% spine that's identical across every engagement and build that as the rigid core, then expose the 20% variance through configuration, not forks. The failure modes sit on both sides. Build everything rigid and your first enterprise customer's one weird requirement forces a code branch that haunts you. Build everything configurable and you've shipped a workflow engine nobody can operate — you rebuilt your service business as a worse Salesforce.
The judgment about where the spine ends and configuration begins is the domain knowledge. It's the thing a generic dev shop cannot do, because they don't know your 50 clients. They'll guess, and they'll guess that everything is either uniform or unique, because those are the two easy answers.
Productized service businesses we've built
This is the category we build in repeatedly. One example: we built a unified operations platform for Cadrivit that replaced a stack of disconnected tools and manual reconciliation. They saved 70–80% of operational costs and we delivered 30% ahead of schedule. The savings came from encoding the workflow the operators were running by hand — the integration friction and the manual reconciliation between systems were the cost, and the product removed them.
The pattern repeats: the value isn't the forms. It's the logic between them that the previous process kept in people.
What fixed looks like
The product can run the engagement, not just store it. A new customer onboards in days because the spine is rigid and the variance is configuration. A new segment is a config change, not a deploy.
The software says no at the right moments — refuses illegal transitions, blocks ungated steps, flags deadlines before they slip. Customers feel that the system knows the domain, which is exactly why they stop doing the work themselves and pay you instead.
Disputes are answerable. "Which rule applied, and who approved it" returns a timestamped record, not a reconstruction from email. The audit trail is a byproduct of the state machine, not a feature you bolted on under pressure.
And your senior operators stop being the system. The knowledge that lived in their heads now lives in the model, which means you can scale past the number of clients a human can personally babysit. That's the entire reason to productize.
This is for you if
You run a service business with a repeatable, judgment-heavy process and you're turning it into software because demand outran your ability to staff it by hand. You've proven the process works — 50 engagements, real revenue, real retention — and now you need the build to carry the domain knowledge, not dilute it.
A vertical SaaS build that honestly encodes a non-trivial workflow — state machine, versioned records, configuration-as-data, role-based gates — starts around $100k+ and scales with how many exceptions your domain actually has. The number is driven by the branches, not the screens. A workflow with two paths is cheap. A workflow with the real exceptions is the engagement.
This is not for you if you haven't run the process yet and you're hoping the software will tell you what the process should be. It won't. Software encodes a known process; it doesn't discover one. Run it by hand first, find the exceptions the hard way, then build. And it's not for you if what you actually have is generic — if any competent operator could run your workflow off a template, you don't have vertical SaaS, you have a tool, and you should buy one.
< transmit >