Choose a mature IoT SaaS when the priority is a fast launch with standard device onboarding, alerts, and reporting, and the buyer does not have a permanent platform team. Choose managed private deployment when data must stay inside the buyer's cloud or network but the supplier should remain responsible for agreed upgrades, monitoring, and incidents. Choose source code delivery only when the buyer must keep changing core workflows, control releases, reduce long-term supplier lock-in, and can fund its own platform engineering and security operations.
The weak version of this decision says that SaaS is cheap but insecure while delivered source code is expensive but controlled. Neither statement is reliable. A SaaS product can provide strict isolation, auditability, and export controls. A repository inside the customer's Git service does not automatically provide reproducible builds, patch response, tested recovery, or device migration. The useful question is who can change the system, who must respond when production fails, and whether the system can continue if the supplier leaves.
1. The three models transfer different kinds of control
An IoT SaaS is a standardized platform operated by the supplier. The customer typically configures tenants, device models, rules, users, and APIs but does not operate the underlying cluster, database, middleware, or release system. This fits a project with relatively standard requirements, a short launch window, an unproven fleet scale, or a deliberate decision to outsource baseline platform operations. Its tradeoff is not zero control; it is a modification boundary set by the product roadmap, APIs, quotas, and service terms.
A managed private deployment runs in a customer-designated cloud account, VPC, data center, or dedicated resource boundary while the supplier retains the operational duties defined in the support contract. This model addresses runtime location and delegated responsibility. It does not necessarily include full source code, and it does not permit the supplier to bypass the customer's change process. For an organization with data residency, network isolation, or integration constraints but no mature platform team, it is often the most practical middle path.
Source code delivery transfers modifiable software assets, build knowledge, and some release control to the customer. It creates production control only when the handover also includes reproducible builds, deployment configuration, dependency inventory, database migrations, tests, runbooks, and an upgrade boundary. A repository archive by itself grants inspection and potential modification; it does not prove that another team can operate the system.
| Decision condition | SaaS | Managed private deployment | Source code delivery |
|---|---|---|---|
| Initial launch | Usually fastest | Depends on network, infrastructure, and acceptance | Depends on handover quality and takeover capability |
| Core workflow changes | Limited to supported extension points | Contracted changes, usually released by supplier | Customer can modify, but owns regression and compatibility |
| Runtime control | Mostly supplier | Customer owns environment boundary; duties are shared | Customer ultimately owns environment and releases |
| Patches and upgrades | Supplier manages platform cadence | Governed by maintenance contract | Customer needs intake, validation, deployment, and rollback |
| Exit difficulty | Depends on data, device, and API portability | Depends on environment, licenses, and knowledge transfer | Depends on build, dependencies, secrets, and an independent team |
Equivalent feature lists therefore do not imply equivalent delivery value. Source delivery adds a maintenance surface that a standard device-management team may not need. SaaS configuration can become an early constraint when device protocols, authorization, and business workflows are part of the buyer's own product.
2. Write the responsibility ledger before calling a model secure
Security and reliability are not properties of a deployment location. They emerge when every operational responsibility has an owner and a verified response path. The AWS Shared Responsibility Model separates security “of” the cloud from security “in” the cloud. An IoT platform needs the same analysis: who configures, monitors, patches, approves, and gets paged for each layer?
flowchart TD
A("Define business and compliance boundary"):::blue --> B{"Must the customer keep changing core workflows?"}
B -- "No" --> C{"Must runtime stay in the customer network?"}
C -- "No" --> D("Evaluate SaaS first"):::green
C -- "Yes" --> E("Evaluate managed private deployment"):::orange
B -- "Yes" --> F{"Can the customer build, release, secure, and operate on-call?"}
F -- "Yes" --> G("Evaluate source code delivery"):::violet
F -- "No" --> H("Build the team or use a managed transition"):::slate
D --> I("Test data export and device migration"):::cyan
E --> I
G --> J("Run a supplier-absent exit test"):::cyan
H --> I
classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;
The ledger should cover identity and keys, infrastructure, databases, middleware, application code, device protocols, data models, alerting, backup, vulnerability remediation, and incident response. Under SaaS, the supplier operates more layers, but the customer still owns device credentials, user access, data use, and business actions. In a managed private environment, infrastructure may belong to the customer while the supplier owns application releases and first-line operations. After source delivery, those duties move toward the customer unless a separate maintenance service preserves them.
| Responsibility | Typical SaaS boundary | Typical managed private boundary | Minimum customer duty after source delivery |
|---|---|---|---|
| Cloud account, network, hosts | Supplier | Customer boundary with agreed operator access | Customer |
| Application releases and schema migration | Supplier | Supplier executes, customer approves | Customer builds a controlled delivery path |
| Device identity and key lifecycle | Shared | Shared | Customer defines and executes; supplier may support |
| Dependency and vulnerability updates | Supplier policy | Maintenance contract | Customer tracks, tests, deploys, and rolls back |
| Monitoring and on-call | Supplier platform scope | Contract defines first and second line | Customer names a production owner |
| Data classification, retention, and export | Customer decides; supplier provides controls | Customer decides | Customer decides and validates recovery and migration |
The most dangerous gap in a source-delivery deal is not that the code is difficult to read. It is that nobody owns production change. When a critical dependency advisory appears, someone must determine exposure, merge or replace the component, run device compatibility tests, approve the release, and observe rollback signals. If one link has no owner, source control becomes patch debt.
NIST's Secure Software Development Framework integrates security practices into the software lifecycle and addresses both software producers and acquirers. For a buyer, that turns supplier build protection, release provenance, vulnerability handling, and source information into acceptance evidence rather than procurement language. Delivered source code increases the buyer's freedom to act, but it also increases the software supply chain the buyer must govern.
3. A five-year cost model must include the years after handover
Comparing only the first-year subscription with a one-time source delivery fee undercounts the source option. A more useful model is:
Five-year TCO = subscription or license + implementation and migration + cloud and network + platform engineering + security and compliance + upgrade regression + device migration and exit
SaaS pricing may scale with devices, messages, storage, API traffic, product tier, or support. Its structural benefit is that the supplier spreads infrastructure and platform-version work across customers. When business requirements stay inside supported extensions, this can remove substantial organizational complexity. When device protocols, authorization, and workflows persistently diverge from the product, adapter services, external systems, and export limits become a different cost center.
Managed private deployment costs more when dedicated infrastructure, network access, release windows, backups, and incident response must be managed separately. It is justified by real constraints. If an organization requests an isolated environment only because it sounds safer, without a residency, isolation, latency, or integration requirement, the deployment can add change and recovery complexity without reducing risk. When production networks cannot reach a public service or data must remain in a defined boundary, a lower SaaS entry price does not resolve the architecture conflict.
Source delivery moves its largest costs after acceptance. The customer maintains development environments, CI/CD, images or installers, database upgrades, dependency vulnerabilities, observability, capacity, backups, keys, documentation, and team continuity. The Kubernetes Production Environment guidance notes that production clusters require more availability, secure access, and resource planning than test environments, and asks how much management should be retained or handed to providers. The platform does not have to use Kubernetes for the principle to apply: self-hosting is an ongoing operational capability, not a deployment event.
Do not claim one model is universally cheaper. Put all three through the same five-year scenarios: fleet growth, message and storage growth, one major platform upgrade, one security incident, at least one staff transition, and one data or device migration. A source option that wins only if nothing is upgraded, no incident occurs, and the original engineer never leaves is not a useful business case.
Opportunity cost belongs in the model. Time spent by a platform team on database patches, capacity, and failed releases cannot also be spent on device protocols, customer workflows, and data products. If infrastructure operations do not differentiate the business, SaaS or managed service may be the better allocation. If device semantics, industry rules, and the platform itself are core intellectual assets, controlling source and release paths can compound over time.
4. Source delivery needs a supplier-absent exit test
Do not accept source delivery by counting files. Ask a customer team to run one exit test without the supplier operating the environment. Starting from a clean machine, the team should fetch an identified release tag, resolve locked dependencies, produce a traceable artifact, deploy a new environment, restore sanitized data, rotate every secret, and reconnect test devices through registration, telemetry, alerts, commands, and an OTA or configuration update. It should then inject a failure and prove that monitoring detects it, an owner responds, and the release can be rolled back.
This test verifies that executable knowledge has moved. A repository may be complete while a private dependency is unavailable. Deployment automation may exist while production settings remain undocumented on one engineer's workstation. Backup jobs may be green even though restoration has never succeeded. Devices may reconnect but fail commands because certificate, topic, or model versions drifted. Each failure separates legal possession of code from operational control.
CISA's SBOM FAQ defines an SBOM as a formal record of software components and their supply chain relationships. In a source handover, the SBOM helps a new team identify open-source and commercial components, licenses, affected versions, and update duties. It is not a substitute for buildability. Pair it with lockfiles, artifact digests, image provenance, a vulnerability process, and license boundaries.
| Acceptance object | Required evidence | What failure means |
|---|---|---|
| Source and version | Repository, release tag, locks, third-party licenses | Production cannot be traced to delivered source |
| Build and artifact | Clean build, digest, image or installer | Only the supplier workstation can build |
| Deployment and config | Environment manifest, config contract, migrations, rollback | Operations depend on memory and manual edits |
| Security | Secret inventory, rotation, SBOM, response target | Supplier credentials or patches remain hidden dependencies |
| Observability | Metrics, logs, traces, alert owner and severity | Failure can occur without an actionable signal |
| Data protection | Backup policy, timed restore, retention and deletion | Backup files exist without recovery capability |
| Device compatibility | Protocol, identity, telemetry, command and upgrade regression | Platform starts but field devices cannot operate safely |
| Exit capability | Export, migration and supplier-absent exercise | Lock-in has only been postponed |
This article package includes delivery-acceptance-contract.json and a validator. They do not claim that a customer deployment has passed acceptance. They turn “control through source” into twelve controls with an owner, required evidence, and an explicit failure condition. A real contract can add controls, but it should not remove reproducible build, credential rotation, restore, device compatibility, and exit testing.
The interface illustrates why an IoT platform handover is more than backend services. Device identity, tenancy and space, protocol source, service ownership, command permissions, alerts, and audit records carry long-lived semantics. If a source delivery omits these data contracts, authorization rules, and compatibility tests, a seemingly small field or state-machine change can break the device operations path.
5. Use failure modes to make the final choice
The first failure mode is buying source without a platform team. The initial deployment succeeds because the supplier is still present. Six months later, a critical dependency needs replacement, the database needs an upgrade, or the original engineer leaves, and the buyer discovers that nobody can recreate the release. Such an organization should start with SaaS or managed private deployment and contract for data export, configuration export, and migration assistance before taking full source responsibility.
The second is staying on SaaS after core differentiation has exceeded its extension points. The customer moves device models, permissions, work orders, billing, or industry algorithms into surrounding services. Every platform release requires another integration cycle. The organization carries custom engineering cost without controlling the core release cadence. When durable differentiating logic belongs in the platform and the supplier cannot offer a stable API boundary, source delivery or a sustainable joint-development model deserves evaluation.
The third is treating private deployment as a security conclusion. Moving the system into a customer VPC or data center leaves patches, keys, backups, logs, and incident response in need of owners. If supplier access is prohibited while the customer has no on-call team, recovery may take longer. Private deployment creates value when data, network, latency, or integration boundaries require it and the operating permissions and support path are explicit.
The fourth is negotiating ownership without an upgrade relationship. After the customer changes core code, future supplier releases may not merge cleanly. If the supplier retires a branch, the customer may remain on aging dependencies. Define the baseline, customization boundary, upstream patch delivery, compatibility window, change review, merge duty, and end-of-maintenance behavior. Without those terms, long-term control can become a permanent fork.
Internal ZedIoT materials cover private deployment, source delivery, multi-protocol onboarding, edge computing, and business customization. That model fits organizations with varied devices, a defined data boundary, and continuing product-specific development. When evaluating the ZedIoT IoT Platform, separate platform capability from the exact contracted deliverable: identify source scope, third-party components, target environment, operations term, upgrade term, migration, and intellectual-property boundaries. If the earlier question is whether a private platform is warranted at all, read the ZedIoT private deployment and device management guide.
The final decision is concise. Choose SaaS for standard requirements, speed, and no permanent platform team. Choose managed private deployment when the environment must be dedicated but the supplier should remain accountable for operations. Choose source code delivery when core workflows require continuing modification, exit capability matters, and the customer can own the full SDLC and on-call path. Test data and device migration in every model, because control is not where the code sits; it is the ability to restore, upgrade, and continue service after people, suppliers, or infrastructure change.