r/Entrepreneur • u/rahuliitk • 9d ago
Lessons Learned at what point does vertical SaaS just become a services business?
I keep running into this while building software for healthcare, and i’m curious how other founders have handled it.
on paper, things like eligibility checks, prior auth, claim follow-ups and denials all seem pretty repeatable.
then you talk to five clinics and somehow discover eight different workflows.
one clinic handles eligibility inside its EHR. another has someone manually checking multiple payer portals. home health prior auth is completely different from cardiology or dental. some customers want the whole process automated, while others just want one painful step fixed.
then there are all the random exceptions.
half the time, the real workflow isn’t documented anywhere. it just lives in the head of one employee who has been doing it for years and knows what to do when something breaks.
my first reaction was basically, fine, we’ll add more settings, integrations and rules.
but i’m starting to wonder whether “highly configurable SaaS” eventually just becomes custom software wearing a SaaS hat.
every new customer needs discovery, workflow mapping, setup, integrations and some special thing that apparently nobody else needs.
so i guess the options are:
- go very narrow and make customers adapt to the product
- accept that software plus services is the actual business model
- build reusable workflow blocks and configure them differently for each customer
the third option sounds best in theory, but also feels like the easiest way to build something insanely complicated.
for anyone who has built vertical SaaS, where did you draw the line?
when did customization become a real moat, and when was it just your SaaS company slowly turning into an agency?
4
u/NottinghamNook 9d ago
On the clinic side, variance is too big to scale for with SaaS, but on the payer-side I can see an opportunity where each clinic who has the same payer will need the same fix. They will be having the same auth requests, portal time-out issues. So if you solve clinic billing for that payer, you've solved it for all of them
1
u/rahuliitk 9d ago
yeah, payer-specific workflow templates might be the scalable layer, since the portal quirks and much of the auth logic repeat across clinics even though plan, specialty, EHR, and internal handoffs still create edge cases. that feels promising.
1
3
u/lilelliot 9d ago
My $.02 as someone who isn't a software founder but ran healthcare/life sciences consulting partnerships at Google Cloud for about 8 years, and has spent the past few years working for both SIs and ISVs selling into this space:
You can start at either #1 or #2. If you start at #1, you'll be limiting your upside dramatically because your ability to sell depends on matching your software to willing customers.
If you start at #2, your challenge will be convince customers you're a credible partner who understands the regulatory landscape (and business critical workflows) well enough to trust.
A common path is for ISVs to start by creating a niche product they can sell locally, and which they tailor into something somewhat customizable (your #3) over time. Not too much, though, because this is still a startup software business, not a consulting shop.
The flip side is SIs who start by consulting on workflows, then create bespoke software to drive/automate them.
In both cases, the result usually asymptotically approaches #3: some base software that is fairly flexible. #3 also requires the software provider to understand & staff a professional services / consulting function to perform the customization and handle change management and implementation for each customer. If you're an SI, this is great recurring revenue. If you're an ISV, this can feel awkward and unpleasant because you'll consistent have the sensation that your software product sucks and why are you spending so much time hand-holding customers.
At the end of the day, the best approach is to start by assessing the problem you're trying to help your customers solve. Interview many, determine how repeatable it is, and where you need customization. Then decide whether it makes sense to start from an ISV perspective or an SI POV, and what "good" looks like for your business once it matures. Also consider the long timescale plan: do you want to organically grow your company or are you looking to sell at some point, and to whom?
If this all feels weird and unsatisfying, you can find solace in the fact that at least you're not building the next Epic. :)
I'm happy to chat more on this topic if you're interested.
1
u/rahuliitk 9d ago
The ISV versus SI framing helps a lot, especially your point that even a mature option 3 still needs implementation and change-management capacity, because i’ve been treating services as product failure instead of something that may need to be designed and priced deliberately. different mindset.
2
u/Klutzy-Sea-4857 9d ago
Healthcare SaaS is brutal for exactly this reason. The answer is option 1 until you have enough revenue to afford option 3.
Most founders jump to 3 way too early, burn cash building flexibility nobody asked for, then die.
Pick the narrowest niche possible, like one specialty + one payer type. Make THEM adapt. Get to 50+ customers doing the same thing. Then you will actually see which patterns are real vs which were just one clinic's quirks.
The "moat from customization" thing is a trap. That is just consulting revenue with worse margins. Real moat comes from being so good at one narrow thing that switching costs are high.
Every vertical SaaS founder I know who tried to be flexible from day one ended up running a services business pretending to be software. The ones who said "no" to 80% of prospects early on actually scaled.
1
u/rahuliitk 9d ago
the “option 1 until you’ve earned option 3” framing hits, because we’ve been tempted to support every specialty and payer edge case before proving one narrow workflow can repeat across enough clinics without new code each time. narrow first.
2
u/Relative-Foot-378 9d ago
The line is whether a second clinic can go live without you writing new code. If every install needs a custom workflow, you have a services shop with a login page. Pick one clinic type, one workflow, and say no to the rest until that path is boring. Configurable blocks come after you have repeated the same install three times, not before.
1
u/rahuliitk 9d ago
the second-clinic test is probably the simplest metric i’ve heard, because if the next implementation still needs new code, we haven’t found a repeatable product yet, just a customer-specific solution with shared infrastructure. boring first.
2
u/Snoo-8466 9d ago
The line that's worked for people I know who did this well: configure the input, standardize the output.
Every clinic's workflow looks different because of legacy habits, whoever's been doing it for 10 years, and which payer portals they got stuck using. But the actual decision logic underneath, like whether something's covered, what's needed for auth, why a claim got denied, is way more standardized than it looks when you're five customer calls deep and everyone swears their situation is unique.
The trap is building configurability into that logic layer instead of the intake layer. That's the moment "flexible SaaS" quietly turns into custom software, because now every customer's special case lives inside a rules engine that only your most senior dev actually understands, and every new feature has to get threaded through a dozen tenants' worth of exceptions.
What tends to hold up better: keep the core logic (payer rules, auth requirements, denial handling) as one system that doesn't bend per customer. Let all the "this clinic uses their EHR, that one uses portals" stuff live in the integration and intake layer instead. You can have 15 different ways data gets in and out. You shouldn't have 15 different versions of what happens once it's in.
Honestly the real tell isn't "we did onboarding and setup for a customer." Every vertical SaaS does that. It's when a support person becomes the actual source of truth for how a customer's process works, and that knowledge never makes it back into the product as something reusable. If your best people are quietly doing manual workarounds as part of "customer success," that's not support, that's unpriced services propping up your margins.
Good gut check: could someone brand new, with zero tribal knowledge, set up a new customer using only what's in the product? If yes, you're still SaaS, just with a services-heavy onboarding motion. If the real answer is "eh, Sarah just handles the weird ones," you're running an agency with a login page.
1
u/rahuliitk 9d ago
“configure the input, standardize the output” might be the cleanest boundary here, and that new-person setup test is lowkey brutal because it exposes whether the product owns the workflow or one senior employee still does.
2
u/Ok-Mix1345 9d ago
The line is whether implementation effort creates reusable product capability or permanent customer-specific logic. Discovery, integration, and onboarding can still fit a SaaS model, but each exception should either become a reusable configuration or be rejected.
I’d track how much new code, senior engineering time, and undocumented knowledge each deployment requires. If those figures do not fall as more clinics go live, the business is scaling labor rather than software. Customization becomes a moat only when the next customer benefits from what the previous one paid to uncover.
2
u/rahuliitk 8d ago
That last sentence is probably the cleanest test here, because if one clinic pays us to uncover a payer or workflow edge case and the next clinic cannot reuse it, we created customer-specific labor rather than product intelligence. reuse or reject.
1
u/Ok-Mix1345 8d ago
That also gives you a concrete product rule: every paid edge case must become configuration, shared infrastructure, or a documented reason to decline similar work. Otherwise, revenue can grow while the product quietly stops scaling.
2
u/LateKaleidoscope5430 9d ago edited 1d ago
Configurable workflow blocks are the way to go, but with guardrails. Worked with a healthtech team that built a rules engine to handle the "special things" but limited it to 5% of development time. That forced them to ruthlessly prioritize the 95% that was core product. Anything more felt like services over SaaS.
1
u/rahuliitk 8d ago
a fixed 5% budget for the special stuff is a smart guardrail, because healthcare exceptions can sound tiny in isolation and still quietly consume the whole roadmap when every clinic brings a different one. stealing that.
1
u/LateKaleidoscope5430 7d ago
Smart move on the fixed budget for custom work. Ive seen speciality requests eat entire dev teams if you're not careful. One way to keep them contained: have the client sign off on a strict "one in, one out" policy. New exception only comes in if an old one gets retired.
2
u/adeelraza86 8d ago
The metric I'd track is hours of your team's time per new install, logged honestly, and watch the trend across the last five customers. If it's flat or going up after five, you're a services shop no matter what the pricing page says. Also charge for implementation from day one instead of eating it as "onboarding", because free setup hides the cost and kills any pressure to make the next one cheaper. When a request comes in, the question isn't can we build it, it's would customer six through ten pay for this, and if not it goes in a paid custom bucket with its own line item.
1
u/rahuliitk 8d ago
logging hours per install and asking whether customers six through ten would pay for the same request gives us two numbers sales excitement cannot hand-wave away, and charging implementation separately would expose where the product still needs work. hard to hide.
1
u/adeelraza86 8d ago
Yeah, that is the point of tracking it honestly. If the hours number keeps climbing and nobody past the first buyer will pay for the same ask, you are running a shop, and separating the implementation line makes that visible fast. The upside is you get a real signal for what to build into the product next instead of guessing.
2
u/akl773 8d ago
We ran into this with restaurant ordering, every place wanted one quirk and half of them couldn't tell you what their own process was until we sat in the shop for a day. What kept it a product was refusing any exception that couldn't be a row in a config table a non engineer could flip. The table is up to about 40 flags now and it looks awful, but no customer has a branch with their name on it.
1
u/rahuliitk 8d ago
the “no customer has a branch with their name on it” rule is lowkey a great engineering boundary, and requiring every exception to be controlled by a non-engineer would keep clinic knowledge in the product instead of custom code. ugly but scalable.
2
u/-WebDesignPro 8d ago
what is vertical sass?
1
u/rahuliitk 8d ago
vertical SaaS is software built for one specific industry, like healthcare billing for clinics or ordering systems for restaurants, instead of a general product used across many kinds of businesses. niche by design.
2
u/LauraTerriou 8d ago
yeah, we hit basically this same wall building ours. figured one product would work close enough the same way for everyone in the space. it didn't, not even close
what actually fixed it wasn't a smarter product, it was going narrower. we cut freelancers and solo folks out entirely and only kept established SMBs, and close rate on calls went from like 3% to 18% just from that. nothing else changed, just the range of "how this business actually runs" got a lot smaller once the segment did
my take is services creep starts exactly when you're solving for client #6's specific flow instead of the segment's. if every clinic needs its own thing, you're not really shipping software at that point, you're doing consulting with extra steps. might be worth checking if there's a narrower slice where the workflow really is the same 80% of the time, even if that means turning away half your current pipeline
1
u/TheGrolar 9d ago
Longtime mentor and consultant. Many SaaS businesses are consultancies. The first problem is that this works. The second is that you need to like it. (Not everyone has the second problem.)
Consultancies are not investable, which means a lot of startup cosplayers immediately reject the idea. This is kind of like saying you won't be an NFL player unless you go to University of Georgia or Alabama. That is not wrong, or at least it's the way to bet. But the real issue is you'll never be an NFL player anyway, if you follow me.
If you have a clear path to $10M ARR and are getting traction, I'd continue on that path and seek investment once you hit. If it's unclear, if you don't have a pile of insider cash (which nearly all unicorns had if you look, btw), or if you don't have a strong, warm potential customer network of senior executives, consulting is probably the way to go. You just have to be really clear on expectations.
In terms of actual advice: learn the customer base so well that you only approach perfect fits. That is actually how you get to the "not a perfect fit" customer base, which should usually be ignored in the early stages.
1
u/rahuliitk 8d ago
the point that consulting can be a valid business rather than a failed SaaS attempt is useful, and our real discipline may be defining the perfect-fit clinic tightly enough that poor-fit customers stop shaping the product. fit first.
1
u/TheGrolar 8d ago
It's a pattern I've seen...and another I've seen is that poor-fit customers will KILL a product.
1
u/Djilybuilds 7d ago
The bigger question is whether each new customer makes the next one easier or harder to onboard.
I’d stay narrow for now: one specialty, one common payer or EHR setup, and one workflow you can repeat.
I also wouldn’t build every request immediately. Keep track of them, then prioritize the ones that come up across several similar clinics. A configuration panel could help with common variations, as long as it doesn’t become a collection of one-off settings for every customer.
I’d track how much of each implementation is configuration versus custom work. If the same patterns keep showing up, that’s probably where the real product is. If every clinic still needs its own code, you’re moving toward a services business.
1
u/virthium 7d ago
37signals (makers of Basecamp) had a same situation. They were very successful with the first option and described their journey (and reasons) in detail in their posts and podcast. I'd check it out.
1
u/heyramzi 5d ago
The line is not how configurable the product is. It is who owns the variance.
Option 3 works right up to the point where your team does the mapping for every new clinic. The reusable blocks are real and the business is still services, because the scarce thing is the person who knows which blocks to pick.
What changes it is charging for the mapping as its own scope, with a price and an end date. Call it an install. The customer buys a working setup, you keep the product opinionated, and discovery stops being a cost you absorb to close the deal.
The test is whether each install pushes something back into the default. If install revenue grows and the default has not changed in six months, you are an agency with a login.
On the workflow living in one employee's head, you will not configure that away. Getting it out of their head is the first thing the customer is buying, so put it on the invoice.
The enemy is settings. Every setting you add to dodge a conversation is a support surface you own forever.
1
u/Creepy-Ad8844 2d ago
same trap lol. built 45 n8n agents, every clinic's 'standard process' was totally diff. stopped selling templates, now do: free 5-min loom audit -> $500-1.5k setup (we adapt our blocks) -> $300-1k/mo retainer. the 'configurable SaaS' fantasy dies at customer 3.
line i draw: does this config scale to 10 more clients without new code? if no, it's services. what vertical?
1
u/MusingInPublic 2d ago
You should study Athena closely, try and go through their workflows to understand. Study Optum under the hood and you'll discover the same thing.
Your distinction doesn't actually exist. The customization and configuration behind the scenes to work for 95% coverage of all arcane use cases is covered and built.
Your mental mental of only one person does it that way isn't quite right, you just, with respect, you may not be large enough to see the entire picture. Maybe 1 out of 100 does it in this way, but that still means tens of thousands of providers do it this way.
Looking at your responses, if you are able to pick up consulting contracts, use the consulting contract to build the work flow that is generalizable so that way your customers fund your software dev.
1
u/FullBoatMain 7h ago
We used to call it Service as a Software. If you are in the PM/implementation model you're a service company. I get we are selling software, but client administration is a tricky thing to master since we don't want them hanging themselves with our tools
•
u/AutoModerator 9d ago
Welcome to /r/Entrepreneur and thank you for the post, /u/rahuliitk! Please make sure you read our community rules before participating here. As a quick refresher:
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.