Responsibility matters more than technology.
Service as software is a delivery model in which a customer buys a defined service or result, while the provider operates software that performs most of the work and remains responsible for delivery and correction.
The customer is not merely renting a tool and taking responsibility for using it well. The defining test is who operates the work and who must fix it when it is wrong, not whether the product uses AI.
A software product can contain advanced AI and still be ordinary SaaS. A service can include human review and still be software-led. Start with the contract and the operating reality:
- What exact service, output, or result is the customer buying?
- Who runs the production system each day?
- Who finds and corrects poor work?
- What evidence proves that a unit was accepted or a result occurred?
- What remedy applies when delivery is late, wrong, unsafe, or unavailable?
If the customer must operate the tool, judge every output, and repair the workflow, it is usually SaaS or a copilot. If the provider performs most of the work through people, it is usually an agency, BPO, or managed service. If provider-operated software performs most of the defined work and the provider owns correction, the offer may fit service as software. If the facts are mixed, call it a hybrid.
This responsibility test is consistent with Foundation Capital's distinction between selling platform access and owning service delivery. Windward's glossary likewise says customers mainly interact with the service while software works behind the scenes, sometimes with human oversight. These are useful public definitions, not independent standards.
Service as software vs SaaS, copilots, managed services, agencies, and BPOs.
SaaS remains useful when buyers want control. Agencies help when judgment is hard to specify. Managed services help when buyers want specialists to run a function. The problem begins when a label conceals who performs the work or carries the risk.
SaaS
- BUYER PURCHASES
- Access to a hosted application
- DAILY OPERATOR
- The customer
- QUALITY AND CORRECTION
- Usually the customer, with vendor support for product defects
- COMMON PRICE BASIS
- Seat, subscription, or usage
- CLASSIFICATION CLUE
- The buyer uses the tool to produce the result
AI copilot
- BUYER PURCHASES
- Suggestions, drafts, analysis, or recommended actions
- DAILY OPERATOR
- The customer or its employee
- QUALITY AND CORRECTION
- The customer
- COMMON PRICE BASIS
- Seat, usage, or credits
- CLASSIFICATION CLUE
- A person remains the operator and final quality owner
Managed service
- BUYER PURCHASES
- An ongoing function
- DAILY OPERATOR
- Provider staff using process and software
- QUALITY AND CORRECTION
- The provider
- COMMON PRICE BASIS
- Retainer, capacity, or service level
- CLASSIFICATION CLUE
- People may remain the main production system
Agency or BPO
- BUYER PURCHASES
- Delivered work or an outsourced process
- DAILY OPERATOR
- Provider staff
- QUALITY AND CORRECTION
- The provider
- COMMON PRICE BASIS
- Retainer, project, time, or output
- CLASSIFICATION CLUE
- Labor performs most of the work and software assists
Service as software
- BUYER PURCHASES
- A defined service, accepted output, transaction, or bounded result
- DAILY OPERATOR
- Provider-operated software, with disclosed human oversight where needed
- QUALITY AND CORRECTION
- The provider
- COMMON PRICE BASIS
- Base fee, usage, accepted output, transaction, outcome, or a hybrid
- CLASSIFICATION CLUE
- Software performs most of the defined work and the provider owns operation and correction
Hybrid
- BUYER PURCHASES
- A combined tool and service, or software-led delivery with substantial human work
- DAILY OPERATOR
- Shared or varies by stage
- QUALITY AND CORRECTION
- Shared under stated rules
- COMMON PRICE BASIS
- Mixed
- CLASSIFICATION CLUE
- The contract must identify which party owns each step
HFS Research describes services delivered primarily through technology with reduced human intervention. Thoughtworks focuses on systems that automate reasoning and are sold around impact. Both support the software-led idea, but neither means every agent or AI feature qualifies.
Who works, who checks, who fixes
Two default flows show where operation, quality control, and correction sit.
SaaS FLOW
- 01NeedCUSTOMER
The customer needs a business result.
- 02Tool access and setupPROVIDER SUPPLIES / CUSTOMER CONFIGURES
The vendor runs the application. The customer fits it to the workflow.
- 03Production and qualityCUSTOMER
The customer operates the tool, reviews the work, and corrects failures.
- 04ResultCUSTOMER
The customer remains responsible for producing the business result.
SERVICE AS SOFTWARE FLOW
- 01Defined serviceSHARED DEFINITION
The parties define the service boundary, inputs, output, and reserved approvals.
- 02Operating contextPROVIDER
The provider integrates and operates the production system within agreed authority.
- 03Production and qualityPROVIDER
Software performs most of the defined work. The provider detects, reviews, and corrects failures.
- 04Accepted outputPROVIDER DELIVERS / CUSTOMER ACCEPTS
Evidence connects the delivered unit to the acceptance rule and any correction or credit.
These are default responsibility patterns. Managed SaaS, outcome-priced software, agencies, and mixed delivery can be hybrids.
A provider description is not proof of reliable delivery.
This guide uses three evidence labels:
- PROVIDER / INVESTOR CLAIM
- A provider or investor says a system performs the work. This proves the statement was made, not that the service works reliably.
- ILLUSTRATION
- A hypothetical scenario that explains the model. It is not a real market example.
- INDEPENDENTLY VERIFIED
- A named customer's end-to-end delivery is supported by an inspectable method, measured results, and independent corroboration or audit.
The public source set reviewed for this guide contains no independently audited end-to-end example. That absence does not prove the model cannot work. It means named companies should be presented as claims or possible hybrids, not as settled proof.
Expel
PROVIDER / INVESTOR CLAIMDecibel describes a managed detection and response service powered by automation software.
Careful classification: A plausible managed-service hybrid. The source does not quantify software work, human work, or audited outcomes.
Dropzone AI
PROVIDER / INVESTOR CLAIMDecibel describes a system designed to investigate security alerts autonomously.
Careful classification: A design and demonstration do not establish reliable production delivery.
AirMDR
PROVIDER / INVESTOR CLAIMFoundation Capital says its portfolio company is building a virtual security analyst.
Careful classification: A named candidate, not independently verified customer delivery.
Wizia
PROVIDER / INVESTOR CLAIMFoundation Capital says its portfolio company covers the outbound email workflow, including research and sequences.
Careful classification: The workflow claim does not prove qualified opportunities, signed customers, or service-level performance.
ConverzAI, Docket, and Tennr
PROVIDER / INVESTOR CLAIMFoundation Capital describes recruiting calls, buyer questions, and data or fax work handled by AI.
Careful classification: Useful candidates for diligence. The source is an investor thesis, not an independent audit.
MAI Expert
PROVIDER / INVESTOR CLAIMWindward says its own agent processes maritime information for route planning, risk management, and operations.
Careful classification: A first-party description without independent end-to-end verification in the reviewed material.
Invoice-processing service
ILLUSTRATIONSoftware receives invoices, validates fields, enters approved records, routes exceptions, and corrects rejected entries under a service commitment.
Careful classification: Fits if the provider operates the system, owns correction, and discloses human review.
Security-alert triage service
ILLUSTRATIONSoftware investigates alerts and a provider specialist reviews high-risk exceptions before a documented disposition.
Careful classification: Can fit as a software-led hybrid if the provider owns delivery and the human role is disclosed.
Clear non-examples
- GitHub Copilot or Cursor used as coding assistance. The developer operates the tool, reviews the code, and owns correction.
- A standard CRM subscription. The customer configures and operates the system to perform sales work.
- A chatbot that drafts replies. If the buyer's staff must validate, release, monitor, and correct every answer, it is assistance.
- A human agency hidden behind an AI interface. It may be a valid agency or managed service, but the labor model must be disclosed.
- A one-off automation script. Automating one step without ongoing operation, quality control, correction, and service commitments does not create a service model.
- Outcome-priced SaaS operated by the customer. Pricing alone does not transfer operating responsibility.
- APIs or infrastructure automatically placed in the category. The contract and service boundary must be examined first.
Follow responsibility, not the label.
The interface, use of AI, and pricing unit cannot classify an offer on their own. Follow the operator, the primary production system, the owner of correction, and the evidence for acceptance.
Classify the offer by responsibility
A candidate still requires contract and operating evidence. Marketing language is not enough.
- QUESTION 01Is an exact service unit or result defined?CONTINUE IF YESIF NOCLAIM INCOMPLETE
Ask for the service boundary, output, and acceptance rule.
- QUESTION 02Who operates the production system day to day?CONTINUE IF PROVIDERIF CUSTOMERUSUALLY SaaS OR A COPILOT
The buyer remains the operator.
- QUESTION 03What performs most of the defined work?CONTINUE IF SOFTWAREIF PROVIDER STAFFUSUALLY A MANAGED SERVICE, AGENCY, OR BPO
Software may assist, but people remain the main production system.
- QUESTION 04Who detects and corrects bad work?CONTINUE IF PROVIDERIF CUSTOMERAUTOMATION OR SOFTWARE TOOL, NOT SERVICE AS SOFTWARE BY DEFAULT
The customer still owns correction.
- QUESTION 05Are acceptance evidence and recourse defined?IF YESIF NOHYBRID OR UNPROVEN CLAIM
Ask how bad work is found, corrected, credited, or refunded.
Confirm the contract, operating evidence, human work, and limits.
Outcome pricing is optional.
A sensible price follows the unit the provider can define, measure, and influence. Do not call an activity an outcome merely because it is countable.
Base subscription or retainer
- WHEN IT CAN WORK
- Capacity, readiness, and monitoring must exist even at low volume
- MAIN RISK
- Paying during low use or weak delivery
- CONTRACT DETAILS TO REQUIRE
- Included capacity, availability, review, support, and termination rights
Usage
- WHEN IT CAN WORK
- An input or resource is countable
- MAIN RISK
- More activity may not create value, and retries may inflate the bill
- CONTRACT DETAILS TO REQUIRE
- Billable event, failed attempts, retries, limits, and overage approval
Accepted output
- WHEN IT CAN WORK
- Quality can be tested at delivery
- MAIN RISK
- Acceptance may be subjective or easy to game
- CONTRACT DETAILS TO REQUIRE
- Acceptance test, review window, duplicates, rework, credits, and dispute path
Transaction
- WHEN IT CAN WORK
- The service completes a discrete action
- MAIN RISK
- A completed action can later be reversed, fraudulent, or wrong
- CONTRACT DETAILS TO REQUIRE
- Completion point, reversal, refund, fraud, and chargeback rules
Business outcome
- WHEN IT CAN WORK
- The result is observable and sufficiently attributable
- MAIN RISK
- External causes and long time windows create disputes
- CONTRACT DETAILS TO REQUIRE
- Baseline, attribution window, exclusions, evidence, caps, and shared dependencies
Hybrid
- WHEN IT CAN WORK
- The provider has fixed operating cost plus variable delivered value
- MAIN RISK
- Complexity can conceal a conventional software fee
- CONTRACT DETAILS TO REQUIRE
- Separate readiness, consumption, output, and outcome charges
A sales service, for example, may control research, outreach, follow-up, and record keeping. It cannot fully control the buyer's product quality, approval speed, inventory, price policy, or a prospect's budget. Charging for a signed customer may sound aligned, but the contract still needs attribution rules and a clear division between controllable delivery and external business conditions.
Pricing is a design choice, not the category test.
Moving right increases attribution and dependency complexity. It does not automatically increase value, quality, or provider responsibility.
- 01BASE OR CAPACITY
- BUYER IS CHARGED FOR
- Readiness and included capacity
- CONTRACT MUST DEFINE
- Included volume, availability, support, and termination
- 02USAGE
- BUYER IS CHARGED FOR
- A countable input or resource event
- CONTRACT MUST DEFINE
- Billable event, retries, failed attempts, limits, and overage approval
- 03ACCEPTED OUTPUT
- BUYER IS CHARGED FOR
- A unit that passes an acceptance test
- CONTRACT MUST DEFINE
- Test, review window, rework, duplicates, and dispute path
- 04TRANSACTION
- BUYER IS CHARGED FOR
- A completed discrete action
- CONTRACT MUST DEFINE
- Completion, reversals, fraud, refunds, and chargebacks
- 05BUSINESS OUTCOME
- BUYER IS CHARGED FOR
- An agreed result with observable evidence
- CONTRACT MUST DEFINE
- Baseline, attribution window, exclusions, shared dependencies, and caps
Inspect the full cost stack
A low model bill does not make the service economical. Estimate contribution by accepted unit:
contribution per accepted unit = price per accepted unit - compute cost - data and tool cost - human review cost - support and integration cost - expected correction cost
Ask for the assumptions behind exception and escalation rates, human review, errors and rework, integration and support effort, third-party charges, peak latency and capacity, incidents and refunds, and the time between work, acceptance, outcome, and payment. The buyer needs enough detail to predict the invoice and understand what makes cost rise.
A service still needs a controlled launch.
The provider cannot call every operating problem customer usage and walk away. Define the job, measurable unit, baseline, data, authority, integration, acceptance tests, shadow mode, bounded pilot, records, expansion rules, billing evidence, and exit before dependency grows.
- Define the job. State the service boundary, inputs, outputs, prohibited work, recipients, and excluded cases.
- Define the unit of value. Separate an attempt, completed task, accepted output, transaction, business outcome, and payment event.
- Set a baseline. Record current volume, cost, cycle time, quality, exception rate, and failure rate.
- Map data and authority. Identify lawful data access, retention, credentials, system roles, action limits, and approvals that must remain human.
- Integrate the operating context. Connect source systems, destinations, identity, logs, escalation channels, and rollback paths.
- Create acceptance tests. Use normal cases, edge cases, known failures, adversarial cases, and explicit pass or fail thresholds.
- Run in shadow mode. Compare decisions with real work without permitting irreversible action.
- Start a bounded pilot. Limit duration, volume, territory, spend, recipients, and action types. Keep a stop control and a named escalation owner.
- Operate with inspectable records. Record inputs, actions, approvals, outputs, corrections, incidents, and final disposition while protecting personal data and confidential reasoning.
- Expand authority deliberately. Increase volume or action rights only when quality and incident data justify it. Preserve rollback.
- Reconcile billing to delivery. Every charge should map to an inspectable usage event, accepted output, transaction, or agreed outcome.
- Prepare exit before launch. Test export, access revocation, deletion, transition support, and continuity before dependency grows.
Earn authority in bounded steps
Evidence, safety, rollback, and exit controls remain active from definition through review.
- 01DEFINE THE JOB
Boundary, inputs, outputs, prohibited work, and recipient.
- 02SET VALUE AND BASELINE
Attempt, completed work, accepted output, outcome, cost, time, quality, and failure rate.
- 03PREPARE CONTEXT AND AUTHORITY
Data rights, roles, integrations, action limits, approvals, logging, and rollback.
CONTROLS START BEFORE LIVE ACTION - 04TEST ACCEPTANCE
Normal, edge, and adversarial cases with explicit pass or fail thresholds.
- 05RUN IN SHADOW MODE
Compare decisions with real work without permitting irreversible action.
- 06RUN A BOUNDED PILOT
Limit time, volume, territory, spend, recipients, and action types.
- 07REVIEW THE EVIDENCE
Expand authority, correct and retest, pause, or exit. Reconcile every charged unit.
- EVIDENCE LOG
- Inputs, actions, tool calls, approvals, outputs, corrections, incidents, and final disposition
- SAFETY CONTROL
- Least privilege, escalation, spend and volume caps, circuit breaker, and rollback
- EXIT READY
- Export, credential revocation, retention, deletion, transition, and audit access
CONTROLS REMAIN ACTIVE THROUGH EXIT
What a bounded pilot should answer
- Does the system handle representative work, not only easy cases?
- Which cases require people, and how often?
- Does the provider detect its own errors before the customer does?
- Are acceptance and rejection decisions consistent?
- Can every billable unit be traced to delivery evidence?
- Do latency and quality remain stable as volume increases?
- Can the buyer stop action immediately and recover safely?
- Does the service improve a real baseline, or only generate more activity?
Expand only when measured operation meets pre-agreed thresholds.
Measure accepted work separately from business outcomes.
A provider may deliver a correct output even when an external business result does not occur. The reverse is also possible: a lucky outcome can hide poor work.
- Attempts
- How much activity began?
- Completed units
- How much work reached the provider's completion state?
- Accepted units
- How much passed the agreed customer test?
- Rejection and correction rate
- How often was work wrong or incomplete?
- First-pass acceptance
- How much passed without repair?
- Human-review rate
- How much work still required provider staff?
- Escalation rate
- How often did the system reach its authority or confidence boundary?
- Cycle time and tail latency
- How fast were normal and slow cases completed?
- Cost per accepted unit
- What did usable work actually cost?
- Availability
- Was the service ready when required?
- Incidents and unresolved cases
- What failed, and what remains open?
- Business outcome
- Did the downstream result occur?
- Verified value or payment event
- Was the agreed value event confirmed?
Also require versioned rules, least-privilege access, deterministic checks for hard constraints, risk-based review, random sampling, regression tests, source links, duplicate detection, spending and volume limits, incident notice, and drift checks. Thoughtworks specifically recommends interpretable systems, guardrails, review processes, and operational circuit breakers.
Make every obligation land somewhere.
A label does not replace legal review. Contracts should address confidentiality, data location, retention, subprocessors, unauthorized actions, discrimination, regulated decisions, downtime, incident response, insurance, indemnity, credits, refunds, liability caps, audit access, and continuity.
Provider responsibility covers operating and correcting the defined service. It does not erase customer policy, data, approval, or external business dependencies.
| Obligation | Customer | Provider | Shared or note |
|---|---|---|---|
| Define service boundary and acceptance rule | Accepts business need and reserved approvals | Proposes measurable delivery specification | SHARED before launch |
| Truth, legality, and rights for supplied data | PRIMARY OWNER | Validates required format and access | Provider must still reject unsafe or unauthorized use |
| Operate the production system | Not the silent operator | PRIMARY OWNER | Includes model, tool, workflow, and subcontractor operation |
| Set business policy and reserved approvals | PRIMARY OWNER | Enforces the approved boundary | SHARED when conditions change |
| Monitor quality and exceptions | Receives agreed evidence | PRIMARY OWNER | Human review should follow risk, not an autonomy claim |
| Detect and correct bad work | Reports observed issues | PRIMARY OWNER | Includes rework, incident handling, and agreed credit or refund rules |
| Protect credentials and customer context | Protects access it controls | Protects access it administers | Least privilege and separation apply to both parties |
| Attribute business outcomes | Supplies customer-side facts | Supplies service-side evidence | SHARED because external causes may affect the outcome |
| Reconcile billing to evidence | Can inspect and dispute | Maps each charge to the agreed unit | SHARED audit and dispute path |
| Exit, export, revoke, and delete | Requests and validates transition | Executes secure offboarding | Define retention and post-termination access before launch |
Red flags during procurement
- The provider cannot define a billable unit in plain language.
- Autonomous means your staff must approve or repair nearly everything.
- Human work is hidden or the review rate is treated as confidential.
- Only successful cases are shown, with no method, denominator, or failure record.
- A demo is presented as customer-level performance.
- Activity metrics are offered instead of accepted work and business outcomes.
- Pricing depends on an outcome the provider cannot influence or attribute.
- Failed attempts, retries, and duplicate actions can all become billable.
- The provider will not name third-party models, data sources, or subprocessors.
- The system has broad credentials but no action limits, approvals, or immediate stop control.
- Correction, refund, incident, and response obligations are vague.
- The customer cannot export a usable record of work and decisions.
- Termination does not clearly revoke access and delete or return data.
- The provider calls an investor description or its own case study independent proof.
Questions to answer before signing.
Service and classification
- What exact service, output, transaction, or outcome am I buying?
- Which steps does software perform? Which steps do provider staff perform?
- Who operates the system after launch?
- Who finds, corrects, and pays for errors?
- Is this actually SaaS, a copilot, a managed service, an agency, or a hybrid?
Authority and safety
- What data and systems can the service access?
- Which decisions and actions can it take without approval?
- What actions are prohibited?
- Can I cap spend, volume, contact frequency, and irreversible actions?
- Who receives an escalation, and within what response time?
Measurement and evidence
- What counts as an attempt, completion, accepted unit, and billable unit?
- What baseline and acceptance test will the pilot use?
- Can I inspect logs, approvals, sources, corrections, and final disposition?
- Are provider claims supported by named customers, a clear method, or independent audit?
- Are output quality and downstream business outcomes reported separately?
Price and responsibility
- How are base, usage, output, transaction, and outcome charges separated?
- Who pays for retries, rejected work, correction, and service failure?
- Which customer actions or external events affect attribution?
- What credits, refunds, warranties, and liability limits apply?
- Which duties stay with my team?
Data, people, and exit
- How are customer data and learned context isolated?
- Which people, models, data providers, and subcontractors are involved?
- What is retained, for how long, and for what purpose?
- Can I export records in a documented, usable format?
- Can I revoke access, require deletion, and move to another provider without losing operational history?
Plan the exit before the pilot.
A service that works deeply inside a business can create stronger dependency than a stand-alone application. Write the exit plan before granting access.
- List every account, credential, integration, webhook, inbox, data store, and delegated permission.
- Specify export formats for inputs, outputs, decisions, corrections, audit records, configurations, and unresolved cases.
- Name the system of record that will survive termination.
- Set a transition period, service level, and price for handover support.
- Define how open work, disputes, refunds, and incidents will be resolved.
- Revoke tokens, keys, accounts, and delegated authority on a tested schedule.
- Return or delete data, then provide confirmation subject to lawful retention duties.
- Preserve only records required for audit, dispute, security, or regulation, with access controls and deletion dates.
- Test continuity if the provider fails suddenly, not only if both parties plan a calm transition.
The buyer should leave with a usable operating record, not screenshots from a closed interface.
This is not a universal replacement for software or human services.
- Some work is too ambiguous, rare, high-stakes, or context-dependent to specify and test reliably.
- Human judgment may remain necessary. Buyers need disclosure of what people do and how often.
- Provider responsibility does not eliminate hallucinations, bias, fraud, outages, or regulatory duties.
- Business outcomes may occur months later and have several causes.
- Deep integration can increase security exposure and switching cost.
- Outcome pricing can reward gaming, avoidance of difficult cases, or aggressive behavior.
- A low compute cost can be overwhelmed by exceptions, review, support, and correction.
- Buyers may prefer tools when control, customization, or internal capability matters more than outsourced delivery.
Ask which failures are compensable, how much human work makes the label misleading, who can audit the system, how changes are retested, which decisions must never be automated, how easy and difficult cases compare, and what happens when a critical provider disappears.
Questions buyers ask about the model.
What is service as software?
Service as software is a model in which a customer buys a defined service or result while the provider operates software that performs most of the work and remains responsible for delivery and correction.
How is service as software different from SaaS?
SaaS usually gives the customer access to a hosted tool that the customer operates. Service as software gives the customer a defined service while the provider operates the production system and corrects failures.
Is an AI agent automatically service as software?
No. An AI agent may be a feature, tool, or copilot. It fits service as software only when the provider operates it to deliver a defined service and owns correction under clear terms.
How can service as software be priced?
It can use a base fee, usage, accepted output, transaction, business outcome, or a hybrid. The contract should define the billable event, evidence, exclusions, correction, disputes, and spending limits.
Is service as software the same as a managed service or BPO?
Not always. Both can make the provider responsible for delivery. Service as software is software-led, while a managed service or BPO may rely mainly on people. Mixed delivery should be labeled as a hybrid.
What should a buyer measure in a pilot?
Measure attempts, completed and accepted units, rejection and correction rates, human review, escalations, cycle time, cost per accepted unit, availability, incidents, and downstream outcomes separately.
What should happen when the contract ends?
The buyer should be able to export usable records, transition open work, revoke credentials, confirm data return or deletion, preserve required audit records, and continue essential operations.
What is service as a software example?
A clear illustration is an invoice-processing service in which the customer submits invoices and receives validated, entered records. The provider operates the software, routes exceptions, corrects rejected work, and charges for accepted records under a defined test. A named company should not be called a proven example unless its end-to-end delivery has been independently verified.
What is replacing SaaS?
No single model is replacing SaaS wholesale. Service as software is an adjacent option for work that can be defined, measured, operated by a provider, and corrected under a service commitment. SaaS, copilots, managed services, agencies, BPOs, and hybrids will continue to coexist.
Is ChatGPT considered SaaS?
Access to hosted ChatGPT can reasonably be treated as SaaS: the user operates a hosted application to produce work. AI alone does not make it service as software.
Does SaaS still exist?
Yes. SaaS remains a widely used way to deliver software. Service as software changes who operates a defined job in some offers. It does not erase subscriptions, customer-operated tools, or the reasons buyers may prefer them.
What is the opposite of SaaS?
There is no single opposite. On-premise software differs by hosting. Custom software differs by ownership and development. Outsourcing differs by who performs the work. Service as software differs mainly by who operates and owns delivery.
How Ernesta Labs uses the idea.
After the broader buyer model, one narrower thesis is worth separating. Ernesta Labs calls its responsibility thesis Reverse SaaS: the customer buys the service while the provider remains responsible for the software that performs it.
Its proposed NIKO implementation is unavailable and remains under an ongoing, unresolved test. See Watch for current state rather than relying on totals in an evergreen guide.
That thesis does not establish ownership of the broader term, prove the model, or change the buyer's duty to inspect delivery, quality, risk, price, and exit.
Continue with the proposed Forward Deployed Software delivery model, the AI sales role guide, the source-dated product comparisons, or the Experiment Zero manifesto.
Public definitions, not independent audits.
This guide reviewed public material from Foundation Capital, Decibel, HFS Research, Thoughtworks, and Windward. The sources include investor theses, company-authored analysis, an analyst positioning page, and a vendor glossary. They help document how the term is used. They do not constitute an independent comparative study or an audit of named providers.