Note: This is most applicable to startups automating back-office work in operations-intensive verticals such as healthcare, logistics, and procurement, etc.
AI-native service companies are having a moment. Y Combinator is encouraging more founders to start one*, and the latest batches featured a crop of service startups in legal, health, and accounting. This wasn't the trend when I went through YC two years ago with Andy AI.
In winter 2024, we were one of the first YC companies working on a service business supercharged by LLMs. Surrounded by companies offering AI tools, talking about a service business felt odd. A lot has changed since then. Models became agentic, which unlocked the automation of multi-step office work, and pursuing labor budgets became far more common. And since services account for 80% of US GDP, with plenty of businesses still lagging in adopting AI, the opportunities look abundant and even obvious.
The playbook now seems to be: start or acquire a service-heavy or operations-intensive business and throw tokens at it. But vibe-coding an MVP and doing things that don't scale can be dangerous in services. It can set you on the wrong path, and you won’t realize it until you are trying to scale.
It's been eight months since I left Andy, and I've spent time talking with other founders building AI-native companies. This two-part series covers a few things I've learned about picking a service and scaling it.
Go after work that's essential but not core.
"Essential" means the work has to get done no matter what. "Not core" means nobody inside the business treats it as their identity or their moat. You're looking for both at once: important work that no one will fight you for.
The best services to automate share one of two signals: the work has already been outsourced to a third party (e.g. medical billing), or it's handled internally by a role with high attrition (e.g. receptionist).
Outsourced work is often standardized, and businesses are already handing it off to strangers. There are usually existing handoff processes and clear expectations around deliverables. A high-churn internal position often means the work is repetitive, lacks career progression, and leaves business owners stuck in a re-hiring loop. Nobody is defending the turf, and a passionate team focused on automating work can quickly win the contract and the business's goodwill.
Think carefully about pricing. The comparable labor cost usually sets your ceiling. Work that requires little training or is frequently outsourced to low-wage countries has a lower ceiling. Keep in mind that you likely won’t be able to charge above that rate (at least initially), and you might need to discount to get people to switch vendors.
Pricing helps you estimate the account value and the total addressable market. Whether you can actually win it comes down to the work itself. Map the full lifecycle of a single “unit of work” to the specific workflows it touches. To hit 60-80% margins, you have to automate most of them. Assume it will take longer than you initially think to get there, and plan to actively manage human capacity for the human-in-the-loop steps (more on this in the next post). Be cautious about contracts that are too heavily weighted toward complex, edge-case work. You will likely lose money on those units. Eventually, you will have to maintain a healthy distribution of work complexity that does not kill your margins. It is hard to do when you are just starting out and still building the core automations, so you may end up taking on customers you later have to let go. That is OK.
Scaling a service business will always be bottlenecked by hiring, training, and managing labor for the non-automated part of the workflow. Aim to limit human involvement from day one.
Example: When building Andy AI, we started with a time-consuming clinical documentation workflow that impacts clinical care, agency quality ratings, and insurance reimbursement. Because it's frequently outsourced, we only needed to prove we could outperform the incumbent vendor. We broke the unit of work (a completed medical chart) into discrete steps: extracting patient history from referral PDFs, transcribing nurse-patient audio interactions, pre-filling charts using LLMs, and routing outliers to human reviewers. We put engineering into automating the core pipeline, and just as much into internal software that made our human reviewers fast. Charting also sits directly adjacent to other high-value workflows, such as medical coding and billing. Which brings us to the next point.
Your wedge must earn trust and unlock the automation chain.
As you map out workflows, you will find a dozen different things you could automate. Don't try to build all of them. Pick one or two initial entry points where you can perform dramatically better, faster, or cheaper to earn your customer's trust and prove immediate ROI to their bottom line.
Ideally, that initial wedge is linked to other high-value workflows. This lets you expand your account value with minimal sales effort. The customer already trusts you with their data and some of the operations, making it easy to offer attractive pricing on bundled services. In verticals where workflows are linked sequentially, moving along the chain is the most natural expansion path.
Example: In healthcare back-office operations, patient intake and scheduling are common wedges. Wedge acts as the front door to revenue cycle management. Once you've integrated with the clinic’s EHR, you can tackle adjacent workflows, such as insurance eligibility verification and prior authorizations.
The system-of-record game: integrate today, replace tomorrow.
Most service businesses run on some system of record: the operational backbone where work gets done. Customers are entered, services get scheduled and documented, and invoices are generated. In manufacturing and distribution, that system is an ERP. In healthcare, it's an EHR. In restaurants, it grew out of the POS. Whatever it's called in your vertical, your software will need read and write access to it.
Don’t underestimate the engineering complexity of these integrations. Many incumbent systems either don’t offer the required level of API support or require formal partnerships that are hard to establish as an early-stage startup. You may need to build your own integrations, so examine the system-of-record landscape when defining your GTM.
Markets dominated by two or three major platforms imply high-leverage integration targets. You build the integration once, and it unlocks a massive segment of your TAM.
Conversely, markets that are deeply fragmented require constant custom integration work, forcing small engineering teams away from core automation work. This slows your onboarding velocity and eats away at the software-like margins you are trying to achieve.
Also, a concentrated system-of-record landscape makes it easier to eventually displace the incumbent system of record and own the workflow layer entirely with an AI-native one.
Example: The clearest version of this motion comes from vertical SaaS, not services, but it's worth mentioning. Toast started with point-of-sale hardware for restaurants, then added software for kitchen and guest management, and eventually became the single system of record for restaurant management.
Don’t overfit to your first customers.
Typically, your first customers are highly entrepreneurial business owners. They are willing to experiment with new tech and are comfortable partnering with an early-stage startup. Often, they have strong opinions about what they want from the relationship. This makes them great design partners: your product gets built on real data, real workflows, and real people using your service. But it also makes it incredibly easy to overfit your product to a single customer.
The danger of building alongside just a handful of early adopters is the risk of one-off feature requests. Early on, it is hard to tell which of these requests will generalize to your next ten customers. And sometimes you do know a feature won't generalize, but you end up building it anyway just to keep the customer happy and avoid early churn.
To survive this phase, you have to enforce strict product discipline. While AI makes it easy to ship small, custom feature requests quickly, you must learn to say no to anything major outside your core unit of work. Saying "no" doesn’t have to mean a flat refusal. You can punt the request down the roadmap, agreeing to revisit it only after you’ve completely nailed their primary workflow. Better yet, dig into the 'why' behind the request; perhaps you can solve their underlying operational pain without spending engineering time.
Example: At Andy, one of our early design partners wanted our product to integrate with the messaging app back office used to communicate with nurses. It was so obviously off our core product that we said no. Instead, we found a more generalizable way for communicating with nurses that satisfied the customer. The other time, though, we weren’t as successful. Our largest customer once decided to migrate away from a well-established legacy EHR, for which we had already built an integration, to an obscure platform from a small startup. They wanted us to integrate with them. Fearing we would lose our biggest account, we caved. We burned six months of engineering time building the custom integration, only for the customer to realize the new EHR wasn’t as easy to migrate to and decided to stay on the legacy system anyway.
Product discipline and getting the foundation right is how you prove your initial wedge. But even after picking the perfect workflow, nailing the integrations, and building a service that generalizes, you can still stumble in the scaling phase. As volume ramps up, you still need to hire, train, and retain people to handle the non-automated edge cases without crushing your margins. You will need to become an operational expert and go all-in on AI to build a culture of efficiency. That is the topic of Part 2. Follow so you don't miss it.
