The simple version
Some startups look like consulting firms or agencies but are actually software companies in disguise. The human work is temporary. The software that replaces it is the real product.
Why this pattern keeps getting dismissed
A friend of mine ran a company that helped mid-sized retailers build and manage their product catalogs. On paper, it looked awful. Fifteen-person ops team. Lots of spreadsheets. Gross margins that would make a venture investor quietly close the deck. He got passed on by a dozen funds who said some version of the same thing: “This is a services business. It won’t scale.”
They were right about what the company looked like. They were wrong about what it was becoming.
The ops team was building process knowledge that no competitor could buy. Every messy edge case they handled manually became a rule in the system. Every client onboarding that took three weeks taught them something they eventually automated down to three days. The software got better because the humans were doing the work first. The humans eventually became unnecessary because the software got good enough.
This is the pattern investors keep missing. They see the current state and penalize it. They miss the trajectory.
What “software-first” actually means, and why it’s often wrong
The startup world has a religion around software margins. Pure software, the story goes, scales infinitely. You build it once and sell it a thousand times. Services don’t scale because they require humans, and humans cost money.
This is true at maturity. It’s often backwards at the start.
The problem with going software-first in a complex domain is that you frequently don’t know what to build. You’re making guesses about workflows you haven’t experienced, edge cases you haven’t hit, and user needs you’re inferring from interviews rather than observing directly. Many technically elegant products fail because they solve the wrong problem cleanly.
The services-first approach, done deliberately, is a way of buying understanding. You get paid to learn. Every client engagement teaches you something real about the domain. The humans doing the work are essentially running expensive experiments that the software will eventually encode.
The risk is obvious: you can get stuck. Some companies stay services companies forever because they never actually systematize what they’ve learned. The learning never becomes software. That’s a real failure mode, and it’s why investors are right to be cautious. The question is whether the founders are deliberately building toward software or just running an agency and calling it a startup.
The companies that executed this well
Palantir is the clearest example at scale. For years it looked like an expensive consulting business, with “forward deployed engineers” embedded at client sites doing what looked like professional services work. Critics said it couldn’t scale. The embedded work was the product development. Every client deployment taught Palantir things that went back into Gotham and Foundry. The humans weren’t the business model, they were the R&D function.
Oscar Health built its insurance product with a call center full of care guides doing work that pure software couldn’t yet do. The call center was genuinely necessary at first. It also generated the data and process knowledge that made their software progressively more useful.
Stripe in its early years had engineers manually doing things that eventually became automated. The “do things that don’t scale” advice from Paul Graham isn’t just about getting early customers. It’s about learning the domain deeply enough to eventually scale.
The through-line is intentionality. The founders knew what they were doing wasn’t the final state. They were treating human operations as a research and development function with revenue attached.
How to tell the difference between a trap and a strategy
Not every services-heavy startup is secretly a software company in progress. Some are just services companies. Here’s what separates them.
First, watch what happens to unit costs over time. In a genuine software-in-disguise company, the cost to serve each customer should fall as the customer base grows. The humans are doing work that eventually gets systematized. If unit costs are flat or rising, the learning isn’t becoming software.
Second, look at what proprietary data or process knowledge is accumulating. The services work should be generating something no competitor can replicate quickly. If a competitor could hire a team and do the same thing next month, the moat isn’t forming.
Third, ask whether the founders can articulate specifically what the humans are doing that software can’t yet do. If the answer is vague, the transition plan is probably vague too. If they can point to specific workflows, edge cases, and timelines, they’re thinking about this the right way.
Fourth, look for evidence that automation is already happening inside the company. The ops team that started at fifteen should be doing more work per person every six months, even as the client base grows. If headcount grows linearly with revenue, that’s a services business.
The investor problem (and the opportunity it creates)
Because sophisticated investors often penalize services-heavy companies on gross margin, these startups frequently get passed on by the funds that would otherwise be a good fit. They raise less, at lower valuations, from investors who either understand the pattern or are willing to bet on the trajectory.
This is occasionally a real problem for the founders. More often, it means the cap table is cleaner and the valuation is lower when the company actually demonstrates software margins. The startups that stayed small longest and built real operational understanding before scaling sometimes outperform the ones that raised early on a vision and had to figure out the domain later.
The companies that get this right build something competitors can’t replicate by throwing engineers at the problem. The software is defensible not because of patents or network effects but because it encodes years of operational learning that no one on the outside can observe or easily reproduce.
That’s about as durable a moat as you can build. It just doesn’t look like one from the outside, which is, honestly, part of why it works.
