How to build an AI-native services company
Some of the biggest companies of the next decade won't sell software — they'll be law firms, insurers, and tax practices rebuilt from scratch with AI doing most of the work.
Jonathan
Founder
The opportunity isn’t a copilot — it’s the outcome
Some of the biggest companies of the next decade won’t be software businesses at all. They will be services companies — insurance carriers, law firms, tax and audit practices — rebuilt from scratch with AI doing most of the work. Call them AI-native services companies. The markets are enormous and boring in the best way: tax, audit, insurance, mortgages, parts of healthcare and logistics, each measured in the trillions.
This did not exist a couple of years ago. What changed is that the models got good enough to sell the customer an outcome instead of a copilot they have to operate themselves. That single difference — deliver the result versus deliver a tool — is why these companies look and feel unlike most startups. What follows is a playbook for starting one from scratch, aimed at people thinking about starting a company rather than those already running one. And one honest caveat before any of it: this is early, the ground is still moving, and the wins so far are enough to make it worth the risk, not a sure thing.
Pick a market with four specific traits
The usual startup advice still holds — pick a market you would happily spend a decade in, because these companies take that long — but the best markets for AI services share four traits that are genuinely new. The first is low trust: the work is already outsourced and the customer only cares about the final product, not how it was produced, so you are displacing a vendor rather than asking anyone to change their behavior. The second is low judgment at the task level: if every sub-step needs a human exercising real judgment you cannot scale, so you want most steps automatable with judgment concentrated in a few places where humans stay in the loop. The third sounds like a contradiction with the second, but isn’t — a high intelligence threshold: the overall work has to be genuinely hard, hard enough that models plus humans are required to deliver a result the customer will accept, because easy work has no moat. And the fourth is regulation, which can actually help: regulated industries carry higher expectations and legal accountability, and that raises the bar for everyone, which becomes a moat for whoever clears it. Panacea, for instance, provides FDA regulatory services for biotech and medtech — experienced FDA consultants paired with an AI platform to deliver faster, higher-quality approvals.
Two checks before you commit. The first is the Sam Altman test: as the models get better, does your service get stronger, or does the model commoditize you? You want to be in the first camp. The second is a question about your own honesty — are you using humans because the work genuinely needs judgment, or are you papering over product gaps with people? And steer clear of anything involving equipment and on-site labor; the software-margin math doesn’t apply when you own and operate physical things, so leave that to the robotics founders.
The team needs three kinds of fluency
Build with people you already know and have worked with — the standard advice — but for AI services specifically, the best founders share three attributes. Domain fluency comes first: you are selling to skeptical buyers in often-regulated spaces, so you have to bleed credibility; direct experience is best, but learned is acceptable. Model fluency comes next: you need to know what frontier models can do today and design the product to ride the curve as they improve, and people badly underestimate how much this matters. Operational rigor is the third — variance, throughput, cycle times, SOPs. None of those words are exciting, but you are fundamentally running an operation, and you have to at least respect that skill set, ideally enjoy it.
The General Legal Team, an AI-native law firm, is the example I keep in mind. The founders mix real law-firm experience at Cooley and Fenwick with years of technical leadership at CaseText — but the thing that stands out is how deeply they think about throughput. They built shift work into how they serve clients, which cuts cycle times and attracts strong lawyers at the same time.
The human is the interface; the product is the operation
Here the setup inverts everything you know from software. The human is the interface to the customer, not the product; the product exists to help that human scale their work nonlinearly. Three consequences follow. First, apply an operations mindset — find the bottlenecks and build for the bottlenecks, and treat throughput and cycle time as product metrics you track the way a SaaS company tracks daily active users. Second, treat variance as the existential threat, where variance means non-uniform output from your service: customers will fire you for inconsistency faster than for being a little slower or a little more expensive than the incumbent, because inconsistency destroys the trust the whole relationship runs on. Third, the humans in the loop have to scale nonlinearly — if revenue only grows in lockstep with headcount, you have a staffing agency, not a technology company. Those humans are also your users, so they need to genuinely like the software. Doing things that don’t scale is fine at the very start, but automating the process is the product.
Sell outcomes, and avoid the early demand trap
The biggest early mistake is what I’d call the demand trap. When you are new and have nothing, it is easy to sign a lot of pilots — and just as easy to drown serving them, which forces you to throw humans at the problem and never build the product that scales. It is a literal trap. Cap your first pilots at a small handful and resist the urge to sign too many too fast.
Pre- and post-sales look different here too. You sell outcomes, not seats or tokens — the pilot is the product. For the first handful of customers, don’t standardize too early; use the pilots to learn where AI gives you unique leverage versus where you are just automating the obvious, then build accordingly and fast.
Pricing is harder than in traditional software, because you are not competing with other software — you are competing with the cost of labor, internal or outsourced. Per-unit pricing (per return, per claim, per loan) is the cleanest and easiest to explain. Outcome-based pricing aligns incentives beautifully but is harder to forecast; Panacea prices on the completed consultant study rather than the industry-standard hourly. Two strategies are worth avoiding outright: cost-plus, which permanently caps your upside, and straight-line undercutting, which makes your work look cheap and low-quality. Price on value.
The P&L is where these companies live or die
Because you are competing against labor cost rather than software, the profit-and-loss statement is not back-office trivia here — it is the business model, and it is worth staring at directly. The structure is standard: revenue minus cost of goods sold gives gross profit, and gross profit minus operating expenses gives operating income. What matters is how each line behaves for an AI services company.
Revenue is the comparatively easy part — you will be able to sign contracts. The real question is whether you can deliver on them repeatedly, which depends entirely on your product and process. Expect early revenue to be spiky month to month; a strong product process smooths that lumpiness out over time, and predictable growth is the goal, not the starting condition. The line that decides everything downstream is cost of goods sold: every hour of human judgment you cannot automate lands here, so the trajectory of your margins is really the trajectory of how much of the work the system takes over. That is the number to watch, and improving it is the same work as everything above — pushing judgment into the few places it is truly needed, and letting the platform carry the rest.
Based on Charlie Warren’s YC Startup School talk on AI-native services companies. The playbook is his; this version is my synthesis and wording.
Related reading
- Build your company as an intelligence layer, not an org chart — the operating model these services businesses run on internally.
- How to pick a startup idea — why “sell the outcome, be the insurer” is the same instinct as verticalizing an idea.