Saas, Platforms and the Forward-Deployed Model
A practical explanation of how Saas, MSPs, agencies, consultants, platforms, and forward-deployed engineering differ when companies modernise or enable the organisation with AI.
TLDR
- AI enablement is not just a tooling decision; it is a choice about how the organisation will become legible to software.
- Saas, MSPs, agencies, and consultants each solve useful parts of modernisation, but they do not automatically create the operating layer agents need.
- A forward-deployed platform is the right model when the work depends on the organisation's own data, workflows, judgment, and edge.
When companies say they want to modernise, or enable the organisation with AI, they are often talking about tools. The harder question is about operating model.
AI does not become useful across an organisation just because people have access to a model, a copilot, or a new application. It needs the organisation to become legible to software: the work has to be captured, normalised, stored, retrieved, permissioned, and acted on through tools.
That is why the buying decision matters. Saas, MSPs, agencies, consultants, platforms, and forward-deployed teams are not interchangeable ways to buy "AI transformation." They are different ways to change how work happens.
Saas can standardise a workflow. An MSP can operate and support systems. An agency can execute a defined brief. Consultants can diagnose, design, and guide change. A platform can provide reusable primitives for data, workflow, interfaces, permissions, and tools.
A forward-deployed platform is different because it starts from the operating problem and builds close to the work. It is justified when the organisation's own data, judgment, workflows, exceptions, and domain language are part of the value.
The Modernisation Options
| Route | What it is best at | What it usually does not solve |
|---|---|---|
| Saas | Standardising a known workflow inside a product category | Cross-system operating context and unique workflow logic |
| MSP | Running, supporting, securing, and monitoring systems | Redesigning how the organisation thinks and works |
| Agency | Executing a defined project or specialist deliverable | Owning the long-term operating model unless explicitly structured that way |
| Consultant | Diagnosing problems, designing programmes, managing change | Leaving behind a durable operating system unless paired with build capability |
| Platform | Providing reusable primitives for data, workflow, interfaces, permissions, and tools | Discovering the exact operating model without close implementation work |
| Forward-deployed platform | Building the operating system close to the work | Low-touch procurement, standard onboarding, or commodity use cases |
This table matters because AI has made the old modernisation categories less sufficient. A company can buy tools, support, execution, and advice and still lack the thing agents need most: a durable representation of how the organisation actually works.
Saas As A Delivery Model
The National Institute of Standards and Technology defines Software as a Service as access to a provider's applications running on cloud infrastructure, where the consumer does not manage the underlying infrastructure and usually has only limited application configuration. That is the power of Saas: the provider handles hosting, upgrades, reliability, and product development, while the customer pays for access.
This model works well when the workflow is already familiar across many organisations. Email, payroll, CRM, accounting, HR, ticketing, analytics, project management, and document management all benefit from standardisation. A company should not have to build its own email service or payroll engine unless there is an unusual reason.
Saas also has a clear cost logic. The customer usually pays a subscription or usage fee instead of funding a bespoke software build. The vendor spreads product and infrastructure costs across many customers. The customer receives faster time to value, lower maintenance burden, and a product roadmap maintained by someone else.
The tradeoff is that the product has to generalise. A Saas product can support configuration, integrations, and custom fields, but its economics depend on being useful to many customers at once.
MSPs, agencies, and consultants
MSPs, agencies, and consultants sit beside Saas in many modernisation decisions.
An MSP, or managed service provider, usually takes responsibility for a defined technology service: infrastructure, devices, cloud operations, security monitoring, backups, help desk, compliance support, or ongoing administration. ITPro describes managed IT services as outsourcing IT infrastructure and operations to third-party providers that often work through recurring contracts and continuous support. This is valuable when the problem is reliability, coverage, technical operations, or access to specialist skills.
But the centre of gravity is operating and supporting a service, not discovering the unique workflow logic of the business.
Agencies solve another problem. A good agency can move quickly around a defined brief: design a new site, build a workflow automation, connect a set of tools, produce content, improve conversion, ship a prototype, or deliver a specific digital experience. That craft and execution speed can be valuable.
The limitation is scope. Agency work is often organised around projects, deliverables, retainers, or campaigns. That can be exactly right when the goal is a specific output. But enabling an organisation with AI is not only a deliverable problem. It requires durable data models, permissions, retrieval paths, workflow tools, review boundaries, and ownership.
Consultants are useful when the organisation needs diagnosis, strategy, process redesign, governance, procurement support, change management, or executive alignment. In AI programmes, that can be important: many failures are not model failures, but operating failures. The organisation does not know which workflow matters, who owns the decision, where the data lives, what should be automated, or what must stay under review.
The limitation is that consulting can stop at the design layer. A good strategy deck can name the problem without making the organisation more legible to software. Unless the work is paired with a durable build layer, the result can be recommendations, workshops, and roadmaps rather than a system people and agents can use.
Platforms As A System-Building Layer
A platform is different from a single Saas application.
In this article, a platform means the reusable layer that lets bespoke workflows be built without bespoke foundations. It provides primitives for building an operating system around an organisation: data models, permissions, workflows, interfaces, APIs, search, automation, review queues, deployment infrastructure, and tools for people or agents to act.
The platform is not only a place where users click buttons. It is the system-building layer underneath the operating model.
That difference matters when the work is not reducible to a standard application category. A law firm, a finance team, a care organisation, a property practice, and a relationship-led business may all need documents, tasks, finance records, client context, approvals, and reporting. But the meaning of those objects changes with the practice.
The same "task" can mean very different things depending on evidence, risk, client relationship, deadline, regulation, owner, and approval boundary. The same "client update" can be routine in one context and sensitive in another. The same "renewal" can be a small admin item or a strategic operating decision.
A platform is useful when the organisation needs shared infrastructure but not a one-size-fits-all workflow.
The forward-deployed model
Forward-deployed engineering is a delivery model where engineers work close to the client environment to understand, build, adapt, and deploy systems in operational context.
Palantir popularised this model through Forward Deployed Software Engineers. Business Insider describes Palantir FDSEs as engineers who embed with clients and adapt software in real time, combining technical work with direct customer problem-solving. MarketWatch has also reported that major AI companies have been adopting similar forward-deployed approaches as they try to drive enterprise AI usage.
The important part is not the job title. The important part is the posture.
Instead of assuming the product is already finished and the client only needs onboarding, the forward-deployed model assumes the first version of the system has to be discovered through the work itself. Engineers and operators learn the vocabulary, data, constraints, review points, edge cases, and success criteria of the organisation.
That creates a different engagement.
| Model | Customer buys | Engagement | Best fit |
|---|---|---|---|
| Saas | Access to an existing product | Configure, integrate, train, adopt | Standard workflows |
| MSP | Ongoing management of a defined service | Monitor, support, secure, administer | Stable technology operations |
| Agency | Specialist execution against a brief | Design, build, integrate, launch | Defined deliverables |
| Consultant | Expertise, diagnosis, and change capacity | Assess, advise, design, coordinate | Strategy, transformation, governance |
| Platform | Reusable system primitives | Model, assemble, extend, govern | Cross-functional operating systems |
| Forward-deployed platform | Platform plus embedded implementation | Discover, build, deploy, iterate | Unique or high-leverage workflows |
The forward-deployed model should leave behind working software, structured data, operating models, and tools the organisation can keep using. It is judged on whether the organisation becomes more legible, operable, and improvable.
It also should not mean bespoke forever. The best version of the model converts client discovery into reusable platform capability. The specific workflow is configured around the client; the foundations become stronger for every future deployment.
The cost difference
Saas is usually cheaper to start, but the useful comparison is not "cheap versus expensive." It is what the buyer is paying for.
Published Saas pricing gives a sense of the order of magnitude. Salesforce Sales Cloud lists plans from $25 per user per month for Starter Suite to $550 per user per month for Agentforce 1 Sales, billed monthly or annually depending on edition. A 50-person team therefore sees a visible subscription line somewhere from $1,250 per month at the low end to $27,500 per month at the high end, before implementation, add-ons, integration work, data migration, and internal administration.
That is the value of Saas. The customer pays for seats or usage, and the vendor spreads product development and infrastructure costs across many customers. The entry cost is knowable. The customer can often begin with a department, expand later, and avoid funding a bespoke build.
The forward-deployed model has a different cost structure. The buyer is funding a team to understand the operating area, map the data, build the interfaces, connect systems, deploy workflows, and iterate with users. Even before vendor margin, a small implementation team is materially more expensive than a Saas subscription. The U.S. Bureau of Labor Statistics reported a May 2024 median annual wage of $133,080 for software developers. Three developers at that median wage represent about $33,000 per month in wages alone. Once product, design, delivery leadership, benefits, overhead, security, infrastructure, and vendor margin are included, a serious forward-deployed engagement commonly belongs in the tens of thousands per month for a focused pilot, and can move into six or seven figures annually when the work spans multiple systems, teams, and governed production workflows.
Large public platform programmes show the upper end of that logic. NHS England's Federated Data Platform contract with Palantir has been reported at about £330 million over seven years. That is not a benchmark for a normal client engagement, and it is politically contested, but it does illustrate the category difference: a platform programme that connects fragmented operational data across a national institution is not priced like department Saas.
The practical way to think about it is by stage.
| Spend level | Saas example | Forward-deployed platform example |
|---|---|---|
| Department start | 20 users on a $25/user/month tool is $500/month before implementation | Usually too small unless the workflow is unusually valuable |
| Serious team rollout | 50 users on a $175/user/month enterprise CRM is $8,750/month before add-ons | A focused pilot may be tens of thousands per month because it pays for product and engineering time |
| AI-heavy enterprise tier | 50 users on a $550/user/month AI CRM tier is $27,500/month before services | A production operating layer can reach six or seven figures annually when it spans several systems and workflows |
| National or institution-scale platform | Not the normal Saas motion | Public platform programmes can be much larger, such as the reported £330m NHS FDP contract over seven years |
MSPs, agencies, and consultants sit differently again. MSP costs are often recurring and predictable because the buyer is paying for coverage: support hours, service levels, monitoring, administration, cybersecurity, and ongoing operations. Agency costs are often project-based or retainer-based because the buyer is paying for specialist execution and deliverables. Consulting costs are often project-based or retainer-based because the buyer is paying for expertise, analysis, programme delivery, and change capacity. All can be valuable, but none automatically creates the operating layer AI needs.
There are hidden costs across all routes. Saas can become expensive when tools multiply, seats are underused, integrations are fragile, and teams work around the product because it does not match how the organisation actually operates. MSPs can become expensive when the provider becomes another dependency without improving the operating model. Agencies can become expensive when outputs accumulate without shared architecture. Consultants can become expensive when recommendations do not turn into durable systems. Forward-deployed work can become expensive when scope is unclear, custom work is not turned into reusable platform capabilities, or the vendor leaves behind a system the client cannot operate.
The right model depends on the value of fit. If the workflow is generic, Saas usually wins. If the workflow needs reliable operation, an MSP may be enough. If the need is a defined output, an agency may be right. If the problem is diagnosis and alignment, consulting may be right. But if the workflow contains the organisation's edge, fit is not a luxury. It is the product.
| Cost area | Saas | MSP | Agency | Consultant | Forward-deployed platform |
|---|---|---|---|---|---|
| What the money buys | Access to a general product | Ongoing operation of a service | Specialist execution and deliverables | Expertise, diagnosis, and change capacity | Discovery, modelling, integration, deployment, and iteration |
| Cost shape | Seat, usage, and add-on pricing | Recurring service fees and service levels | Project or retainer fees | Project, retainer, or programme fees | Build and deployment fees, often higher upfront |
| Internal time | Training, configuration, procurement, migration | Vendor management and service review | Briefing, feedback, approvals | Stakeholder time, workshops, governance | Stakeholder interviews, data access, workflow review, decision-making, user testing |
| Fit to existing workflow | Often partial | Usually supports existing systems | Depends on brief and architecture | Can redesign the workflow | Designed into the engagement |
| Main risk | Under-adoption, tool sprawl, shelfware | Outsourced dependency without operating change | Deliverables without operating system | Strategy without durable software | Scope creep, bespoke debt, unclear ownership |
| Long-term value | Efficient standardisation | Reliable operations | Useful shipped assets | Better decisions and alignment | Compounding operating model |
Why AI Changes The Calculation
AI makes the forward-deployed model more important because AI systems need context, not just access.
A generic Saas workflow can standardise what users do inside one product. An MSP can keep systems operating. An agency can ship defined digital work. A consultant can help leaders decide where AI should matter. But an AI-enabled operating system has to understand what is happening across the organisation.
It needs access to evidence, owners, permissions, commitments, deadlines, documents, decisions, and tools. It needs to know what it can read, what it can prepare, what it can update, and what requires human review.
The organisation has to become legible to software. Important work has to enter from emails, documents, meetings, databases, finance tools, case systems, task boards, calendars, and operational records, then be structured into stable concepts such as client, matter, owner, source, approval, risk, renewal, action, review, and outcome.
The resulting operating state needs durable storage, auditability, and controlled interfaces: search, retrieval, APIs, editors, queues, review surfaces, controlled write paths, and workflow controls.
This is closer to building a digital operating layer than buying a tool, outsourcing support, commissioning a deliverable, or writing a transformation plan.
AI also changes the value of uniqueness. In previous software cycles, unique workflows were often treated as friction. The advice was to standardise, simplify, and use the product as designed. That is still right for many commodity workflows. But in high-value work, the uniqueness of the organisation can be the point: its judgment patterns, client relationships, evidence standards, operating cadence, and proprietary context.
AI can use that edge if the system can represent it.
The Wall Street Journal has reported that AI startups are reviving forward-deployed engineering because generative AI often needs more hands-on implementation: teams embed with customers both to teach enterprises how to use AI and to teach AI how to act in specific customer environments. That is the core point. AI is not only software adoption. It is organisational translation.
Why forward-deployed rather than one-size-fits-all
Each organisation has a different shape.
Two firms can both describe a process as "client onboarding" and mean very different things. One may care most about compliance evidence. Another may care about relationship history. Another may care about budget authority, operational handover, or partner review. The surface workflow is the same. The operating meaning is different.
A one-size-fits-all product has to flatten those differences. A forward-deployed platform tries to model them.
That does not mean everything should be custom. Good platform work should avoid bespoke software for its own sake. The goal is to separate what should be reusable from what must be specific.
Reusable parts include authentication, permissions, data connectors, retrieval, audit logs, workflow primitives, review queues, interface components, and deployment infrastructure. Specific parts include the client's ontology, workflows, source systems, approval logic, operating cadence, and domain language.
The forward-deployed model works when it turns client specificity into a structured system, not when it produces one-off scripts.
What the engagement feels like
A Saas engagement usually starts with the product: here is what the software does, here is how to configure it, here is how users adopt it.
An MSP engagement usually starts with the service boundary: which systems are supported, what service levels apply, what incidents are handled, what is monitored, and how escalation works.
An agency engagement usually starts with the brief: what needs to be designed, built, launched, integrated, written, or improved.
A consulting engagement usually starts with diagnosis and design: what is the problem, who needs to align, what should change, and how the programme should be governed.
A forward-deployed platform engagement starts with the operating area: what work matters, where does evidence live, who owns decisions, what changes every week, what is blocked, what is sensitive, what can be automated, and what must stay behind review.
The early work is therefore more collaborative. It usually involves interviews, workflow observation, data access, system mapping, prototype review, and iterative deployment. The client is not just a buyer. The client is the source of operational truth.
That can feel heavier than Saas onboarding. It should. The work is closer to building a system than installing an app.
The payoff is that the system can fit the organisation more closely. Instead of asking users to translate their work into generic software categories, the platform can learn the categories of the organisation.
What clients should expect
A good forward-deployed engagement should have visible stages.
Discovery
The team should identify the operating area, the users, the source systems, the important decisions, the current pain, and the criteria for success.
Pilot
The first deployment should prove value in a narrow workflow. It should not try to model the whole organisation at once.
Deployment
The system should connect to real data, support real users, and handle the approval boundaries that matter in daily work.
Iteration
The model should improve as the team learns which fields, workflows, searches, automations, and review surfaces are actually useful.
Handover and governance
The client should understand what was built, what is reusable, who owns which decisions, what requires review, and how future changes are made.
What should not happen
The forward-deployed model can fail if it becomes unmanaged bespoke work.
It should not become endless consulting with no durable system. It should not leave behind one-off scripts that only the vendor understands. It should not create unclear ownership between product, implementation, and client operations. It should not make every client request a custom branch of the product.
The goal is not to avoid all customisation. The goal is to make customisation disciplined. Specific workflows should sit on reusable foundations.
When Saas is still the right choice
The forward-deployed model is not always the right answer.
Saas is better when the workflow is standard, the stakes are moderate, implementation speed matters more than operating fit, and the organisation is happy to adopt the product's default model. Many teams should choose Saas for commodity workflows because it is cheaper, faster, and lower maintenance.
An MSP is better when the main need is reliability, security, support, and operational coverage for existing systems. An agency is better when the need is a defined deliverable: a site, campaign, integration, prototype, automation, content system, or digital experience. A consultant is better when the organisation needs strategy, diagnosis, governance, procurement help, or change leadership before it knows what should be built.
Forward-deployed platform work is better when the workflow is high-value, cross-functional, context-heavy, data-fragmented, or central to how the organisation differentiates. It is especially relevant when AI or agents are expected to support the work, because those systems need more than access to a single application. They need an operating model.
The Argument For The Forward-Deployed Platform
The argument for a forward-deployed platform is not that every company needs custom software, or that Saas, MSPs, agencies, and consultants are bad models. They are good answers to different questions.
Saas is designed to generalise. MSPs are designed to operate and support. Agencies are designed to execute specialist briefs. Consultants are designed to advise, align, and guide change. Platforms are designed to compose. Forward-deployed engineering is designed to discover the real operating shape of the organisation and turn it into working software.
For AI, that difference matters. Agents cannot act responsibly inside an organisation they cannot read. They need context, tools, permissions, evidence, and review boundaries. Building that layer requires more than a subscription. It requires modelling the organisation.
That is why we use a forward-deployed model. Not because Saas, MSPs, agencies, or consultants are wrong, but because AI-enabled operating systems have to be built close to the work.
Sources
- NIST Special Publication 800-145: The NIST Definition of Cloud Computing
- Salesforce: Sales Cloud pricing
- U.S. Bureau of Labor Statistics: Software Developers, Quality Assurance Analysts, and Testers
- ITPro: What is a managed IT service?
- ITPro: MSP 3.0: Managed services enter a new era
- Business Insider: The Palantir job that grows startup founders
- MarketWatch: Anthropic and OpenAI are following Palantir's playbook
- Wall Street Journal: AI Startups Have a New Secret Weapon: Forward Deployed Engineers
- Financial Times: Inside Palantir's fight over the future of the NHS
- IBM: What is workflow automation?
- IBM: What is business intelligence?
/ Start
Start with one operating area. Expand from there.
Begin with a focused review rhythm, workflow, or team where better operating context would immediately change the quality of preparation and judgment.