There’s a conversation I’ve had a dozen times, always in some version of the same room: a founder two or three years into their consultancy, finally profitable, finally paying themselves properly, and completely stuck on why the business feels like it’s stopped moving.
The revenue is fine. The team is good. Clients like them. But every dollar of growth still needs another billable hour, another hire, another person on a plane. They didn’t build a business so much as a very well-paid job that scales with headcount. Add a client, add a person. Add a person, add a manager. No lever anywhere in the system. Just more of the same, forever.
The strange part is that almost none of these founders did anything wrong. They did exactly what got them started — showed up, solved the client’s actual problem, made themselves useful. That’s not the trap. The trap is that nobody told them there’s a next layer, and that the exact skills that got them here are the ones that’ll keep them from ever leaving.
The four layers
Every tech consultancy sits somewhere on a four-layer ladder, whether it knows it or not:
Layer 1: retainer, time-and-material. You show up when the client calls. Rate-card pricing, ad hoc work, whatever’s on fire. Cheapest way into business there is — almost no capital, cash flow from day one, and it throws you into real proximity with real problems fast. Most consultancies are born here. Most never leave.
Layer 2: scoped project. You’ve moved from “whatever you need” to “here’s what we’re building, here’s the start date, here’s the end date.” Fixed scope, package price. Still linear — more projects, more people — but now you’re building a track record instead of just an invoice.
Layer 3: solution. You’ve run the same scoped project often enough that pieces of it are reusable. A pattern, a codebase, a way of doing things that gets redeployed instead of rebuilt. Pricing shifts to value-based packages. This is where real leverage starts to show up, and where most firms park it, because it’s comfortable. Good revenue, low risk, happy clients.
Layer 4: product. Standardized, versioned software. Setup fee, subscription, service-level agreement. Now you’re paid for value that scales without your headcount scaling alongside it.
The distance between layer 3 and layer 4 isn’t technical. It’s nerve. Layer 3 pays well and feels safe. Layer 4 means walking away from revenue you already have for revenue you don’t have yet, betting that what you learned across dozens of client engagements is a real product and not just a service with good margins.
Nobody makes that jump by accident.
The gravel road and the paved highway
Palantir is best known today as the data-analytics company that builds software for the CIA, the Pentagon, and a growing list of banks and manufacturers — the kind of client list that makes outsiders assume its playbook has nothing to teach a two-person shop. It doesn’t matter. Inside Palantir there’s a phrase for exactly this moment, and it’s more useful than most of what gets written about “productization.” They call it the path from the gravel road to the paved highway.
Engineers get embedded directly in a client’s environment — an intelligence agency, a bank, a factory floor — and build fast, ugly, tactical fixes for whatever’s broken that week. That’s the gravel road: functional, specific to one mess, not meant to last. A separate team watches for the same underlying problem across multiple clients. When it shows up enough, they turn it into a permanent feature of the platform. That’s the paved highway. Every future client hits pavement instead of gravel, and the platform gets a little stronger with each one.
Good metaphor. It’s also, almost exactly, how actual roads worked two thousand years earlier.
Roman engineers built three grades of road, and every settlement started at the bottom. A via terrena was a leveled dirt track — functional, unpaved, good enough for that week’s traffic. A via glareata added gravel over a compacted base: sturdier, still local, built from whatever stone was around. At the top was the via munita — four engineered layers, from a stone foundation up through broken rock and cement to a fitted stone surface — built to the same spec in Britain as in Syria. A soldier posted from Hadrian’s Wall to the Euphrates could read a Roman road the same way in either place, because Rome had turned “road” into a repeatable standard instead of reinventing it locally every time.
That’s not a coincidence. It’s the same discipline. You start local and improvised because that’s the only way to solve a real problem fast. You only get to standardize after you’ve done it badly, many times, and noticed what’s underneath the mess. Rome didn’t sketch the via munita first and go looking for somewhere to build it. The spec came from thousands of miles of dirt and gravel that came before — engineers hitting the same problem in different provinces and eventually writing down what actually held up.
Skip straight to “paved highway” without walking the gravel first, and you get a beautiful road to nowhere useful. That’s the trap consultancies fall into: building products from a whiteboard instead of from client scar tissue. Palantir calls it the customization trap — build something so specific to one client that it can never be sold, unchanged, to the next one. You end up with an expensive one-off wearing a license fee like a costume.
The lesson’s the same in both stories. Field-driven productization isn’t optional. The mess comes first. The standard gets pulled out of the mess. It doesn’t get imposed on it in advance.
It’s not just Palantir
Palantir had defense contracts and unlimited government budgets funding its R&D. Most founders have neither — which is exactly why the next two examples matter more than the first one. UiPath is now one of the biggest names in robotic process automation, the software that lets large companies offload repetitive back-office work to bots instead of people, and it trades as a multi-billion-dollar public company on the NYSE. It didn’t start that way. UiPath spent its first decade as DeskOver, a Romanian outsourcing shop writing contract code for IBM and Microsoft — paid by the hour, keeping none of the IP, growth capped by however many developers they could hire. In 2012, an Indian BPO client asked them to automate repetitive screen-based data entry. Three engineers went on-site for three months. When they came back, the founders didn’t upsell the client a bigger contract. They killed the outsourcing business, stopped signing new service deals, and bet everything on the pattern they’d just found. Three years later they rebranded as UiPath. By 2021, they IPO’d at $35 billion.
Atlassian tells the same story from a different angle. Today it’s the company behind Jira and Confluence, the project-tracking and documentation tools that run software teams at a huge share of the Fortune 500 — practically the default plumbing of modern tech work. But Cannon-Brookes and Farquhar didn’t even start as a consultancy in the classic sense — they were running IT support for other companies’ customer service teams, tracking their own tickets in Bugzilla, and getting annoyed enough with the tool that they built Jira instead. Funded on a $10,000 personal credit card. When American Airlines bought a license by fax without ever talking to a salesperson, they read that correctly: shut down the support business, sell licenses, and never build the enterprise sales force that would have quietly dragged them back into a linear cost structure.
Neither company got there from a good idea in a meeting. They got there by doing the unglamorous work first, noticing what kept repeating, and then having the nerve to cut the revenue that already worked before the revenue that would actually scale existed yet.
Where this leaves you
If you’re running a tech consultancy, the question isn’t whether you could technically build a product. Most people capable of running client engagements could build software if they wanted to. The real question is narrower and less comfortable: which layer are you actually in, and have you been mistaking layer 3 comfort for layer 4 progress?
There’s a tell. If every new client still needs meaningfully custom work before what you’ve built is useful to them, you’re in layer 2 or 3 with product language painted over it. If a new client gets real value from what already exists, with configuration instead of construction, you’re closer to layer 4 than you think — you just haven’t made the call to stop selling your time.
The exercise is small on purpose: name one problem that has shown up, in some form, across three or more clients. Not a one-off request — an actual recurring structural problem, the kind you’ve quietly rebuilt from scratch each time because that was faster than doing it properly. That’s your gravel road. The only question left is whether you’re willing to stop re-digging it every time you hit it, and pave it instead.
In my next posts, I will dive deeper into the technicalities of each layer and will share best practices on how to move up the ladder.