Documentation

Appearance

Should we build the post-shipment connected-product stack ourselves or buy it? ​

Build the parts that differentiate your product. Buy the parts that are expensive to operate but do not make the product meaningfully better because you built them yourself.

For many Linux hardware companies, that means keeping the hardware, embedded application, domain algorithms, and commercial system in-house while buying the post-shipment operating layer: connectivity, fleet inventory, remote support, product data/control plumbing, customer tenancy, and customer-facing operations.

The decision is not really “build or buy everything” ​

A connected product usually contains several very different systems:

  • hardware and electronics;
  • Linux image and product application;
  • device identity and connectivity;
  • fleet inventory;
  • remote diagnostics and support;
  • configuration and software lifecycle;
  • telemetry and device controls;
  • customer/site/user tenancy;
  • customer-facing portal or application;
  • APIs and integrations;
  • monitoring, alerting, audit, and incident operations;
  • your own ERP, billing, CRM, analytics, and domain systems.

There is no requirement that one organisation own every layer.

The useful question is:

Which layers are our source of product advantage, and which layers are recurring infrastructure we will have to maintain forever?

What building it yourself really commits you to ​

The initial prototype is rarely the expensive part. The permanent commitments are.

If you build the full stack yourself, somebody owns:

  • secure device enrolment and identity;
  • reconnect behaviour across hostile customer networks;
  • access control and support permissions;
  • remote shell/file/diagnostic tooling;
  • fleet search, grouping, jobs, and drift visibility;
  • customer and site isolation;
  • portal authentication and role management;
  • device data ingestion and control semantics;
  • UI for devices and customer workflows;
  • audit logs;
  • API authentication and rate limiting;
  • backups, incident response, observability, and upgrades;
  • security fixes and dependency maintenance;
  • documentation and support for all of the above.

That is a software product and an operating function, not a one-off development project.

When building in-house is the right answer ​

Build more of the stack yourself when:

  • the connected software is itself your core product differentiation;
  • you need a highly unusual data or control model that generic platform primitives cannot express;
  • your organisation already operates a mature device/cloud platform successfully;
  • regulatory or deployment constraints require architecture a third-party platform cannot satisfy;
  • your scale and economics justify a dedicated permanent platform team;
  • deep ownership of the full runtime is strategically important enough to accept the cost.

A company with an experienced platform organisation and millions of tightly standardised devices may rationally choose to build more than a specialist equipment manufacturer shipping a few thousand high-value machines.

When buying the platform layer is usually rational ​

Buying is attractive when:

  • your differentiation is the hardware, embedded software, service model, or domain expertise;
  • you need to get from prototype to a supportable product quickly;
  • you have an existing Linux product and do not want to rebuild it around a new OS or cloud architecture;
  • remote support and fleet operations are necessary but not strategically unique;
  • customers now expect logins, sites, device views, data, and controls;
  • you would otherwise need to create frontend, backend, identity, DevOps, security, and support infrastructure teams around the product;
  • the installed base will live for years and operational maintenance matters more than initial coding cost.

What Dataplicity is intended to remove ​

Dataplicity is most valuable when it removes the repeated, non-differentiating post-shipment work around a Linux product.

It can provide:

  • outbound device connectivity;
  • engineering remote access and support tooling;
  • device inventory and fleet operations;
  • Device Classes for a stable product model;
  • streams, settings, and actions;
  • product software/container orchestration where appropriate;
  • Customer Portal tenancy and customer-facing product pages;
  • Product Applications for bounded connected-product workflows;
  • APIs and operational visibility.

You still own the product itself: hardware, Linux/application behaviour, safety, domain logic, commercial model, and any external system of record.

See What does Dataplicity actually replace?.

A useful economic model ​

Do not compare only licence cost against developer salary.

Compare the lifecycle cost of the internal platform, including:

  1. initial implementation;
  2. security and architecture review;
  3. frontend/backend/device integration;
  4. on-call and incident response;
  5. support tooling;
  6. cloud infrastructure;
  7. customer identity and access management;
  8. upgrades and dependency maintenance;
  9. documentation and training;
  10. opportunity cost of product engineers working on undifferentiated infrastructure.

Then compare that with the platform subscription plus the integration work you still need to do.

A platform can be more expensive than raw cloud primitives and still be much cheaper than owning the complete organisational function those primitives require.

Do not buy a platform that forces a worse architecture ​

Buying only makes sense if the platform fits the product.

A low licence price does not compensate for:

  • replacing a mature Linux image unnecessarily;
  • rewriting a stable application into a new runtime;
  • losing control over safety or offline behaviour;
  • adding unacceptable data residency or compliance constraints;
  • creating more integration work than the platform removes.

For a brownfield estate, migration cost is a first-class part of the decision.

See Can I add Dataplicity to an existing Linux product without replacing it?.

A practical architecture split ​

A common healthy boundary is:

text
YOUR PRODUCT
- hardware
- Linux image
- device application
- safety and offline behaviour
- domain logic
- commercial / ERP / billing systems

DATAPLICITY
- device connection and identity
- fleet operations and remote support
- product data/control contract
- customer/site/device tenancy
- customer-facing product UI
- bounded product workflows

That boundary can change over time. Start with the capability that removes the clearest pain, then expand only where the platform earns its place.

Questions to ask before deciding ​

  • What would we still need to build if we chose this platform?
  • Does it work with our existing Linux/application architecture?
  • What happens offline?
  • Who owns final device authority?
  • How do we migrate existing devices?
  • How do we leave later?
  • Which operational functions would still require our own team?
  • Does the platform remove enough permanent organisational work to justify dependency on it?

Those questions matter more than the size of a feature checklist.