The Forward-Deployed Company
The clean SaaS dream was simple: build software once, sell it many times, keep humans away from the margin line, and let customers implement the product themselves.
That model produced extraordinary companies. It also created a reflex that is now becoming dangerous: treating services as evidence that the product is not good enough.
In many AI and workflow-heavy categories, the opposite may be true. The company that refuses to touch the customer’s messy reality may never learn what the product needs to become. The company that embeds deeply, solves the ugly last-mile problems, and turns those lessons into software may build a stronger business than the company protecting a beautiful gross-margin spreadsheet while customers quietly fail.
The future of software may look more like an elite consulting firm with software margins than a classic SaaS company with light onboarding and a help center.
Not because consulting is glamorous. It is not. Consulting businesses are hard to scale, hard to standardize, dependent on talent, and vulnerable to becoming labor arbitrage with a logo.
The point is different: the last mile of software adoption is becoming the market.
The old boundary is breaking
The old SaaS boundary said: product builds, sales sells, customer success supports, implementation configures, and services should remain small enough not to embarrass the investor update.
A forward-deployed company redraws that boundary, but it should not erase the distinctions. Product still owns the reusable system. Services still own delivery discipline. Customer success still owns adoption and account health. Consulting still describes paid problem-solving for a client. Forward deployment is narrower: it is field work with a productization mandate.
That boundary works when the product category is mature, the workflow is standardized, the buyer understands the problem, and the value path is obvious.
It breaks when the product changes how work gets done.
AI products especially break it. They do not simply add buttons. They often require new review loops, new exception handling, new escalation paths, new trust rules, new data hygiene, new operating rhythms, and new definitions of quality. The buyer may understand the pain but not know what a working system should look like. The user may want the outcome but distrust the automation. The executive may approve the budget but still need proof that the system will survive contact with their actual organization.
That is not a “customer success problem.” That is the product.
Forward deployment is not customer support
A forward-deployed company sends people into the field not merely to rescue accounts, customize features, or absorb implementation pain. It sends people into the field to learn what the product cannot yet know from a distance.
The job is to observe the real workflow, identify where trust breaks, translate domain expertise into product requirements, build the first version of repeatable playbooks, and bring back patterns that become software.
The field team is not a separate services appendage. It is a sensing organ.
If it works, each deployment teaches the company something reusable:
- which customer conditions predict success;
- which integrations are actually necessary;
- which objections are trust problems rather than feature gaps;
- which steps can become templates;
- which expert judgments can become evals, rules, or review queues;
- which workflows are too idiosyncratic to serve profitably;
- which customers are teaching the future product versus dragging the company into bespoke work.
This is the difference between forward deployment and professional services. Professional services deliver work. Forward deployment converts delivery into product intelligence, then forces the product organization to use it.
The software-margin test
The phrase “consulting with software margins” should make operators nervous. It is easy to say and hard to earn.
A company does not get software margins because it uses software during consulting. It gets software margins when the human work declines per deployment while value, trust, and repeatability increase.
That means the company needs a conversion engine. Field work must become product capability. Implementation notes must become onboarding flows. Expert judgment must become evaluation criteria. Common integrations must become packaged connectors. Repeated explanations must become sales proof and customer education. Risk reviews must become trust artifacts. Agent prompts must become bounded workflows with review queues and audit trails.
If that conversion does not happen, the company is not forward-deployed. It is selling custom work.
There is nothing morally wrong with custom work. Many excellent businesses are services businesses. The problem is pretending the economics are different.
Why founders get pulled back into the field
Forward deployment often starts founder-led because the early version requires judgment the organization has not yet encoded.
The founder can sit with the customer, see the mismatch between pitch and reality, change the product narrative, rewrite the roadmap, decide which edge cases matter, and make promises carefully because they understand the whole company.
That is powerful. It is also dangerous.
Founder-led forward deployment can create the first learning loop. It cannot remain the permanent operating model unless the founder wants to become the most expensive implementation consultant in the company.
The founder’s job is to discover the pattern, not to personally carry it forever.
A good test: after five serious deployments, can someone who is not the founder run the sixth one with better materials, clearer boundaries, stronger proof, and fewer surprises? If not, the company may be collecting stories rather than building a model.
The real bet
The forward-deployed company is a bet that proximity compounds.
Proximity to workflow creates better product judgment. Proximity to users creates sharper trust design. Proximity to implementation creates better packaging. Proximity to domain experts creates stronger evals. Proximity to customer failure creates better selection. Proximity to messy data creates more realistic automation.
But proximity only compounds if the company has discipline.
Without discipline, proximity becomes indulgence. Every customer feels special. Every edge case becomes urgent. Every implementation becomes heroic. Every services leader asks for more headcount. Every product manager complains that the field keeps creating exceptions. Every salesperson learns that anything can be promised because “the deployment team will figure it out.”
That is how a software company becomes Accenture by accident.
The winning version is narrower and harder: choose the right customers, deploy deeply, learn aggressively, productize quickly, measure whether human effort declines, and refuse work that cannot teach the product something valuable.
The last mile is no longer just where software gets installed. It is where the company discovers what the market actually needs.
