Build when software is a lasting competitive advantage for the company, the process is truly unique, and a permanent team can take responsibility for security and production operations for years. Buy when you need mature data flow, alarms, roles, and audit faster than your own product. Choose a hybrid model when you want to keep integrations or algorithms, but not maintain the entire platform yourself.
In brief
- A demo with a chart does not show the cost of a system that runs at night, after a failure, and after a configuration change.
- The comparison covers five years: development, security, maintenance, on-call, migration, and exit cost.
- "Buy" does not remove integration work; it moves it to a clearly defined data boundary.
- "Hybrid" often gives the best balance for integrators with their own measurement know-how.
- It is worth validating the decision with a pilot and exit criteria before sunk cost appears.
The first chart is the start, not the product
A technical team can receive data from a logger, store it in a database, and draw a chart within a few weeks. This is a valuable integration demo, but it is not yet a structural monitoring platform. Production starts when the client asks: what happens to a delayed sample, who changed the threshold, why did the notification arrive twice, can one organisation's user see another's data, and how can five years of history be reconstructed after a formula change.
FHWA describes a general monitoring system as at least a measuring device, a method for reading it, and a method for storing measurements. In practice, a remote solution adds transmission, configuration management, presentation, alerting, and production operations. Each layer has its own failure mode.
Build vs buy in monitoring is the decision about who is responsible throughout the life cycle for developing and maintaining the data layer between the measuring device and the human decision.
This is not a choice between "expensive" and "cheap". A proprietary platform turns the vendor invoice into salaries, on-call, infrastructure, and schedule risk. A ready-made product turns part of the control into dependence on the interface, the roadmap, and the contract terms. A hybrid model splits responsibility at a boundary that must be designed well.
If you first need the full picture of sensor, installation, and service costs, start with the five-year TCO of structural monitoring. Here we calculate only the software and operations layer.
Build / buy / hybrid matrix
There is no single correct answer for every organisation. The matrix below shows where responsibility usually sits. "Hybrid" means that the company maintains its own integration layer, domain calculations, or portal, and buys a ready-made core for storage, alarms, and user operations.
| Criterion | Build | Buy | Hybrid |
|---|---|---|---|
| Time to pilot | Depends on team and scope | Short with a compatible interface | Medium; an integration boundary is needed |
| Roadmap control | Full, with full responsibility | Limited by contract and product | Full for the in-house layer |
| Unique algorithms | No technical limits | Depends on configuration options | Algorithms remain on the company side |
| Alarms and on-call | Designed and maintained by the in-house team | The core is maintained by the vendor | The split must be explicit |
| Security | Entire cycle on the organisation's side | Shared responsibility of client and vendor | More boundaries and integrations |
| Initial cost | High and uncertain | Licence plus integration | Integration plus licence |
| Ongoing cost | Team, infrastructure, maintenance | Subscription and client administration | Both, but to a lesser extent |
| Key person risk | High without a permanent team | Lower on the client side | Applies to the in-house layer |
| Migration | Full control, own cost | Depends on export and contract | Requires testing on both sides |
| Best fit | Digital product is the advantage | Monitoring supports the core business | The company has its own integration know-how |
Build if all four conditions are met at the same time: the platform is to be a sold product or a critical advantage, the process is unusual and long-lived, you have budget for a permanent product and operations team, and the organisation accepts multi-year responsibility for security and availability.
Buy if the company's advantage is monitoring design, installation, interpretation, or asset management, and the software must reliably perform repetitive tasks. In that case, expert time is better spent on methodology and decisions than on logins, password resets, or queue handling.
Choose a hybrid model if you have an existing fleet of loggers, a proprietary protocol, unique calculations, or a customer portal, but do not want to build the entire multi-tenant layer yourself. The condition is a stable, documented interface and a single owner for each alarm.
Five-year calculator without made-up rates
The comparison starts with a common scope. Do not enter the cost of a complete product on the left and the cost of two developers building a demo on the right. Create a spreadsheet with the same categories for all variants and enter your organisation's own rates.
Year 0: reaching production
- Requirement analysis and measurement domain model.
- Device integration, validation, and handling of malformed frames.
- Migration of existing history and control of time and units.
- Roles, login, customer isolation, and administrative paths.
- Charts, dashboards, exports, and mobile access through a browser.
- Alarms, no data, notifications, acknowledgement, and silencing.
- Configuration audit and event history.
- Performance, security, restoration, and acceptance tests.
- Documentation, training, and support launch.
Years 1-5: responsibility that does not disappear after launch
- maintenance of the infrastructure, time-series database, and backups;
- monitoring of the platform itself, on-call, and incident response;
- dependency updates, security fixes, and regression tests;
- support for new devices, formats, and firmware versions;
- account, permission, and user-offboarding management;
- costs of email, SMS, transmission, storage, and transfer;
- user support and diagnosis of missing data;
- changes in regulations, security policies, and customer requirements;
- development of functions that were not "necessary" at the demo stage;
- periodic test of export, migration, and restoration after failure.
You can use a simple formula:
5-year TCO = launch + integrations + migration + 60 months of operations + change development + risk reserve + exit cost.
In the buy variant, "operations" includes the subscription, client-side administration, contract management, and integration. In build, it includes the full team and infrastructure. In hybrid, it includes both, but only within their actual scope. Do not subtract the time of your own experts just because it does not appear on an invoice.
Twelve areas that usually fall out of build estimates
1. Idempotency and late data
A device may repeat the same frame, return after a several-hour outage, or resend history. The system must distinguish a duplicate from a new measurement, preserve the original time, and not wrongly trigger a historical alarm.
2. No data as a state
A line ending on the chart is not enough. The rule must account for the real cadence, tolerance, delay, and a separate operating state. A way back after the data is filled in is also needed.
3. Alarm concurrency
Two processes can evaluate the same threshold at the same time. Without proper serialisation, duplicate transitions and notifications appear. Hysteresis requires remembering the previous state, and a delayed event should not roll back a newer assessment.
4. Notification delivery
Saving an alarm and sending an email or SMS are different operations. A gateway failure must not lose the event or block ingestion of the measurement. Retries, a wrong number, channel opt-out, and delivery history have to be handled.
5. Organisation isolation
A filter in the interface is not security. Every query, export, file, and event stream must respect the customer boundary. Negative tests are as important as the correct scenario.
6. Audit of result meaning
A change in threshold, formula, factor, reference, or geometry can change the interpretation of history. A record saying "configuration edited" is not enough; values before and after, and the period of validity, are needed.
7. Time and time zones
UTC storage, local presentation, daylight saving time changes, an incorrect device clock, and history resend create a separate design and test area. A time error can reverse the order of cause and effect.
8. Retention and series cost
Static measurements grow predictably, but dynamic events can be large. Compression, indexes, downsampling for charts, and full-resolution export require different paths.
9. Recomputing history
A calibration or algorithm change requires safe recomputation. Publishing results in batches can leave the user with mixed history. You must decide whether historical alarms are triggered and how to handle a failure halfway through.
10. Secure development
NIST SSDF reminds us that security must be built into the entire development cycle, not attached just before launch. OWASP ASVS provides a verifiable baseline of application security requirements, useful also in buying.
11. Production work
Monitoring, alerting on its own failure, backups, recovery, capacity management, and postmortem are product work. The Google Site Reliability Workbook organises these areas as SLOs, monitoring, alerting, toil reduction, on-call, and incident response.
12. Exit plan
Own code also creates lock-in: to people, language, library, and undocumented schema. A purchased product creates dependence on the vendor. Both variants need regular export, documentation, and a handover plan.
Illustrative example: an integrator with a good algorithm and a small team
Illustrative example. An integrator has its own calculation algorithm for one sensor type and relationships with logger manufacturers. Three engineers can prepare a demonstration portal. However, the company does not have a 24/7 operations team, an application security process, or a product for managing multiple customers.
The build variant preserves maximum control, but requires building the twelve areas from the previous section. The buy variant shortens the path, but may force the domain algorithm to be moved into the vendor's configuration. The hybrid variant keeps the adapters and calculation on the integrator's side, and sends standardised values with metadata to the platform.
The team scores each variant on a 1-5 scale for time, five-year cost, uniqueness, security, operations, and exit. The result is illustrative only; more important than the sum is each score of "1", which may mean a disqualifying condition. If the algorithm is a company secret, buy without the ability to keep it on your own side is out, regardless of the total score.
What it looks like in Inclify
Inclify can be purchased as a standalone platform for existing devices, as part of a turnkey deployment, or as a limited pilot. Automatic data arrives through HTTP/JSON; history can be resent through the same channel with the original UTC time. The platform does not import series from CSV or XLSX files and does not have a form for manual readings.
The ready-made scope includes customer isolation, three organisational roles, dashboards, per-channel alarms with OK / WARNING / ALARM / NO_DATA states, hysteresis, email, SMS and in-app notifications, acknowledgement, and temporary silencing. It also includes versioned chain inclinometer profiles, dynamic event analysis with FFT and 21 third-octave bands, and quality and data analysis reports. There are no alarms for rate of change, minimum exceedance time, or an automatic escalation chain.
In the hybrid model, it is worth defining before the pilot where responsibility for the device and recomputation ends, and where responsibility for data acceptance and alarms begins. A practical description of integration can be found in the guide to connecting existing loggers.
The final cost depends on the integration, support, and responsibility scope set out in the specific offer.
Decision checklist for CTO and executive team
- [ ] Is the software the company's product, or support for its core business?
- [ ] Which processes are truly unique and confirmed by users?
- [ ] Do we have a permanent product, security, and operations team, not just a project team?
- [ ] Who is on call when alerting or ingest stops working?
- [ ] Do both variants cover the same scope of functions and five years?
- [ ] Have we counted the time of domain engineers on our side?
- [ ] Does the TCO include security fixes, dependencies, and regression tests?
- [ ] Have we counted email, SMS, storage, transfer, and backups?
- [ ] Do existing devices have a stable, documented interface?
- [ ] Can unique calculations stay in our own layer?
- [ ] Does each system boundary have one owner for the alarm?
- [ ] Is the required hosting model available and agreed?
- [ ] Does full export work without the vendor's software?
- [ ] How will we close the solution if the pilot does not meet the criteria?
Before requesting quotes, it is worth comparing this list with the platform selection checklist. Build should not get a discount just because it is created by your own team.
Limitations: when the matrix does not give a clear answer
The matrix does not replace estimation of a specific scope or a conversation with the team. In a regulated organisation, the cost of audit and vendor approval may tilt the decision towards build. In a small company, the lack of on-call may immediately rule out build. With complicated data legacy, the greatest cost of any variant may be migration, not the product itself.
Do not assume that SaaS automatically means no control, or that an in-house server means security. Control is created by the contract, interface, roles, audit, tests, people, and exit plan. The hosting architecture should be assessed separately; the comparison of cloud and on-premise monitoring helps here.
Inclify is not a fit if manual field series are required, if native support for a specific closed protocol is needed without an adapter, if alarms on rate of change are required, or if a standard installation in the client's infrastructure is expected. A local deployment is technically possible, but requires individual agreement and is not a standard offer model.
FAQ
Is an in-house platform always cheaper with a large number of sensors?
No. The number of channels affects storage, processing, and licence cost, but internal TCO also grows through the team, security, on-call, migration, and development. Large scale may justify build if it spreads a fixed cost across many deployments. First, however, you need to calculate the full five-year scope and compare it with a volume offer, not a catalogue price.
How long does it take to build a monitoring platform?
Without a specific scope, there is no honest number. A demo with ingest and a chart can be built quickly, but a production platform includes alarms, roles, customer isolation, audit, retention, export, backups, security, and maintenance. Instead of asking for one date, price the milestones: pilot, secure production, migration, operations, and domain functions.
When is a hybrid model best?
When the company has valuable device adapters, algorithms, or customer process, but does not want to maintain the entire multi-tenant application. Hybrid works well if the boundary has a stable data contract, clear SLA, and alarm owner. It works poorly when the error moves between three vendors and none is responsible for the final result.
Does a purchased platform remove vendor lock-in?
No. Lock-in can result from the format, data model, lack of export, contract, or operational knowledge. It can be reduced by an open interface, stable identifiers, full metadata, a trial data release, and a short pilot with exit criteria. A proprietary product also creates dependence on specific people, libraries, and undocumented decisions.
How do you compare the security of build and buy?
Use the same list of requirements and evidence. For both variants, assess the threat model, authentication, access control, customer isolation, encryption, vulnerability management, updates, logging, backups, and incident response. NIST SSDF organises the development process, and OWASP ASVS the technical application requirements. The statement "our team knows the code" is not a test.
How should a pilot be planned so that it really settles the decision?
Choose one representative asset, an existing logger, delayed data, a controlled gap, and real users. Define criteria in advance: integration time, completeness, latency, alarm, change audit, export, and operational effort. Add a stop criterion and a way to release the data. A pilot without metrics easily turns into an endless demonstration project.
Sources and further reading
- FHWA-HRT-09-040, Chapter 2: State of the Practice, Federal Highway Administration.
- NIST SP 800-218 - Secure Software Development Framework 1.1, NIST.
- OWASP Application Security Verification Standard, OWASP Foundation.
- Site Reliability Workbook - table of contents, Google.
- Site Reliability Workbook - Eliminating Toil, Google.
- Practical Alerting from Time-Series Data, Google SRE.
Next step: compare architecture before you compare prices
In a one-hour conversation, we can sketch the device-integration-platform boundary, point out costly functions hidden outside the demo, and suggest pilot criteria for build, buy, or hybrid. Book an architecture review. You will leave with a list of assumptions for your own TCO spreadsheet, even if you finally decide to build.