Build vs buy: should a vending machine manufacturer write its own telemetry?
"It's a few weeks of work, it puts us ahead, and we'll give it away to lock customers in." A build-vs-buy reckoning for vending OEMs: the eight layers behind a telemetry platform, who the lock really binds, and why splitting payment from telemetry breaks reconciliation.
Sooner or later, every vending machine manufacturer we talk to says a version of this:
“We already build the machine. If we write the telemetry ourselves we get ahead of the competition, and we make money on the software too. We could even give it away and lock the customer in. It's a few weeks of work anyway.”
That is five claims in one breath, and each deserves to be tested separately: is it a few weeks, does it differentiate, does it earn, does it lock the customer in, and can you take just the telemetry half. Let's go through them — and let's be fair from the start: for some manufacturers the answer really is “build it.” The threshold is at the end of this article.
“It's a few weeks of work” — true for the part you can see
Three weeks does produce something. A database, a web panel, a sales chart, an endpoint that receives what the machine sends. You demo it, the room is convinced, the estimate feels vindicated.
The problem is that what ships to the field is not a demo. The gap is the same one you already know from your own product: turning a spiral motor is a day's work; turning it 200 times a day for three years in a dusty factory canteen, on a supply that browns out twice a week, is engineering. Software behaves the same way. Three weeks buys the visible box. Everything under it starts the day the first machine leaves the yard.
Each of those layers is a concrete field problem:
Protocols. You know your own board, so pulse or a serial line feels solved. But the operator who buys your machine runs a mixed fleet. One day a customer asks you to put three older machines from another brand on the same panel, and now MDB, dry contact and Modbus are your problem too.
Offline resilience. The machine in the basement has no signal; the one under the factory's steel roof has two bars on a good day. When the link drops the machine must keep selling, buffer the sale, and resync with ordering and replay protection when it returns. Writing that is not hard. Writing it correctly is. Duplicate rows, silently dropped sales and two reports that disagree all come from here.
Reconciliation. There is only one real test of vending management software: at close of day, does the revenue in the panel match the cash in the box and the settlement from the acquirer? The day it doesn't, the operator stops trusting the system — and trust breaks once.
OTA updates. With 400 devices in the field, “we found a bug” cannot mean 400 service visits. You need staged rollout, version tracking and rollback. A half-updated fleet is worse than one that was never updated.
Multi-tenancy. This gets its own section below. It is an architectural decision made on day one, not a feature added in year two.
Payment certification. Card and contactless live entirely outside the “few weeks” universe: terminal supply, EMV levels, PCI obligations, acquirer onboarding. That calendar is measured in months and it does not move at your development speed — it moves at somebody else's.
Cloud operations. Backups, monitoring, security patching, data protection obligations, a disaster plan. None of these are features; all of them are permanent work.
Support. At six on a Friday evening a route driver will call because the refill screen won't open. Someone has to answer, and that someone is on your payroll.
Software doesn't ship — it accrues
In manufacturing, a cost ends. You built the cabinet, you delivered it, the warranty clock runs. In software, the cost begins at delivery and grows with every unit in the field.
There is a structural mismatch underneath this. The cabinet, the cooling and the mechanics last a decade; the connectivity on it does not. Across one cabinet lifetime you will see two or three network generations come and go — 2G and 3G shut down, modules go end-of-life, security stacks fall behind. If the software is yours, every machine you sell is also a ten-year software commitment. In year five you will still be cutting releases for a 2019 model you stopped manufacturing in 2021.
Then there is the team. A machine builder's engineers sit in mechanical, electrical and electronics. Embedded developers, cloud engineers and DevOps are a different hiring pool with different retention dynamics and different management. If your “software team” is one talented person, your product stops the week they resign.
| What's finished | What isn't | |
|---|---|---|
| 3 weeks | Panel, sales list, a chart | Anything that happens in the field |
| 6 months | End-to-end flow on your own machine, one pilot site | Offline resync, reconciliation, other brands |
| 1–2 years | Stable telemetry, OTA, roles | Payment certification, a credible tenancy model, 24/7 support |
| 3+ years | An actual product | It never “finishes” — it is operated |
“It puts us ahead of the competition” — check the direction
The honest way to test this claim is to sit on the other side of the table, with the company that buys your machine.
That company does not run one brand. Its fleet has cold drink, hot drink, coffee and a few surviving mechanical units from three or four manufacturers. Because every maker pushes its own cloud, the buyer already carries a separate login, a separate panel and a separate mental model per brand. When you arrive with yours, what the buyer sees is not a feature. It is the fifth tab.
Two things follow.
Telemetry is table stakes, not a differentiator. Its absence loses deals; its presence wins none. What buyers actually compare is cabinet build, cooling performance, spiral reliability, lead time, price and service coverage — which happens to be exactly where you can pull ahead.
The buyer doesn't want your panel, they want one panel. Whatever consolidates the fleet wins; whatever fragments it loses. If your machine can join the panel the operator already runs, the hardest objection in the room disappears on its own.
“And we'll make money on it” — the hardest revenue you'll ever collect
A per-device monthly fee looks wonderful on a slide. Run it with your own numbers instead: write down the annual cost of three engineers plus cloud plus support, then divide by your intended monthly fee. The result is the number of live, paying devices you need just to break even. For most manufacturers that number is several years of total unit sales — assuming every one of them keeps paying.
Then collection. Your customer is trying to reduce the number of panels and vendors they pay; a subscription for the fifth one is the line item they resist hardest. Push it and the negotiation migrates to machine price, where you hand it back as a discount.
You plan the software as a profit centre. You operate it as a cost centre.
“We'll give it away and lock them in”
This claim quietly cancels the previous one — the revenue is gone, the cost is not. But the deeper problem is the direction of the lock.
Free software still has a price; it just moves into the cabinet. Engineers, cloud and support bill every month. If you don't collect it as subscription, you collect it in the machine price. A competitor with no software team quotes the same cabinet without carrying that load — so your “free” is their discount, and the buyer sees both numbers in the same table.
The real cost of a free product is that it stops being updated. Software with no revenue has no budget. Year two the requests queue up, year three there is no release, year four the customer says “that panel never worked properly.” That sentence attaches to your brand, not to your software, and it follows your cabinet into the next tender.
Free increases support load rather than reducing it. When a product has no price it has no boundary. Free users call more, ask for more and train less. The Friday-evening phone call is identical; you just aren't billing for it.
And you can never introduce a price later. In year three, when the cost is real, you'll want to start charging. To the customer that isn't a price change, it's a broken promise — delivered precisely to the customer you believed was captive. That is the day dependency turns into a risk item on their side, and the day a competitor's proposal gets read properly.
The lock binds you, not them. Look at which way the obligations actually run:
| The customer can | You cannot |
|---|---|
| Buy another brand of machine on the next order | Walk away from software already in the field |
| Write data export into the contract | Stop cutting releases for models you no longer sell |
| Ignore your panel and run their own VMS | Bill the customer for a network-generation migration |
| Outgrow you and move to an enterprise system | Exit the software business without burning references |
Every machine you sell becomes a software obligation that is paid for once and honoured for ten years. Your customer is free at the next purchase order. You are not.
A professional buyer sees the lock and negotiates it away. An operator with a hundred machines has bought software before and has migrated off software at least once. They will ask for data export, API access, price protection and an exit clause — and since their data has to reach their own accounting and ERP anyway, portability is a technical requirement, not a preference. The more explicit your lock, the harder those clauses get. You carry the cost; the lock gets struck out in the contract.
In a mixed fleet the lock is weak to begin with. Your customer already lives with four brand panels. A fifth is a habit, not a barrier. The next purchase is decided on price, lead time, cooling performance and service response. If your machine costs noticeably more or arrives three months late, they'll buy the competing unit and run it on yet another panel — because that is already their normal.
And the loss you never see: the customer who doesn't want the dependency will never tell you. You won't hear “I don't want my data sitting in my supplier's cloud.” You'll hear “your price came in high,” and the deal will close elsewhere. If you also operate machines yourself, that silent loss is the biggest line in the ledger.
Healthy stickiness comes from reorders, not from locks. Customers should come back because leaving isn't attractive, not because it's difficult. In vending the things that bring them back are well known: spare-part availability, response time, cabinet and cooling reliability, delivery dates. And one that is routinely underrated — your machine dropping into the panel the operator already uses, with zero onboarding. No new account, no new screen for the route driver: your unit is simply the lowest-friction option on the list. That is the only form of lock a customer signs up for willingly.
“We'll only do the telemetry — payment can come from someone else”
This is the most common retreat once the cost table is on the table. And it has one genuine benefit: you shed the certification, acquirer and terminal-supply burden. The trouble is that it splits the machine at exactly the wrong seam.
Sales data is the payment event. What an operator means by “telemetry” is product-level sales, revenue, payment method and refunds. That data is born at the moment of payment. If the terminal belongs to another company, your telemetry must either ask them for it — integration, API, contract, and their priorities — or infer it from vend pulses. Inferred sales never match the settlement figure, so your panel is permanently a little bit wrong.
Two devices, one bus. Payment and telemetry sit on the same line to the same controller. Split across two vendors, two devices now negotiate with your VMC. It works — until one ships a firmware change, or one holds the line, or a machine takes the card and doesn't drop the product.
Reconciliation ends up owned by nobody. When the panel and the settlement disagree, the operator calls someone. The payment vendor says the telemetry misread it; you say you only count pulses. That argument ends with whoever's logo is on the cabinet answering the phone — you.
There is no single owner in the field. Card charged, product not delivered: is it the terminal, the VMC, your board or the network? A technician standing at the machine needs exactly one party to call. In a three-vendor fault, what you lose isn't time, it's the customer's patience.
The payment vendor's portal already shows sales. Nearly every cashless provider reports transactions in its own back office. Your customer therefore already has sales visibility — from the payment side. Your telemetry panel isn't a new capability at that point; it's a second copy of the same data, and the copy that isn't tied to the settlement has no standing when a figure is disputed.
You also lose "ready out of the factory." The machine arrives but cannot trade: the buyer still has to source a terminal, wait for onboarding, schedule an installation. The delivery promise you control gets chained to a supplier you don't.
And seven-eighths of the load stays. You dropped certification. Protocols, offline resilience, reconciliation, OTA, multi-tenancy, cloud operations and support are all still yours. You kept most of the cost and gave away the part that carries the revenue and creates the data.
The seam is in the wrong place. Whoever sits on the payment line should carry the telemetry, because that layer already sees the sale, knows the device is online and reconciles against the acquirer. That is exactly why our device is fitted to the machine as a payment system and the management software rides along with it: one device, one bus, one panel — and one phone number when something goes wrong.
The real blocker: no operator shares data with a rival
This is the item manufacturers notice last and that stops deals hardest.
For the company buying your machine, revenue, product movement and site performance are commercial secrets. The mere possibility that another operator — or a manufacturer who also operates machines — could see that data in the same portal is enough to stall the contract. When the maker is also an operator, suspicion becomes the default: the customer wants to hide data from their own supplier.
“We wouldn't look” is not an answer. The answer has to be a separation defined in the system: a multi-tenant architecture, a separate account space per operator, role-based permissions, and a manufacturer view limited to device health, software version, faults and warranty. If you operate your own fleet, that fleet has to be its own tenant inside the same boundary.
The critical part: multi-tenancy cannot go on the “we'll add it later” list. It has to be in the data model, the authorisation layer and the reporting from day one. Starting with a single pool and partitioning it afterwards usually means rewriting — and a permissions mistake cannot be undone.
So when should you build it yourself?
Honestly, the arithmetic doesn't land the same way for everyone. Building your own platform is defensible in three situations:
- Scale. You ship thousands of machines a year and your live device count comfortably carries a software team.
- The product is the software. Your machine isn't a standard snack unit but a bespoke kiosk whose value sits mostly in the application.
- You're already a software company. You have a development team, release discipline and a 24/7 support structure today.
If one of those is true, the right move isn't the decision — it's the budgeting. Set it up as a product line with its own roadmap, its own team and at least three years of runway, not as a line item under the production plan.
Before deciding, ask your own people:
- When the link drops, what does the machine do and where is the sale buffered?
- When the panel's revenue and the settlement disagree, who reconciles them and against which record?
- How do we update 400 devices in the field, and how do we roll back a bad release?
- At which layer do we separate two operators' data — a query filter, or an account boundary?
- Can the fleet we operate ourselves technically see a customer's data?
- Will the buyer's other brands join our panel? If not, why would they use it at all?
- Who certifies card payment, and whose calendar is that?
- If payment comes from another vendor, where do we get sales data — an integration, or counting vend pulses?
- If the software is free, which line item funds the team and the cloud in year three?
- Who answers the route driver's call at six on a Friday?
If those ten don't have crisp answers, the “few weeks” estimate is an estimate for a demo.
The third path: don't write the layer, fit it
A manufacturer has three options — build your own VMS, buy an off-the-shelf telemetry box and solve payment separately, or fit a ready platform layer on the line.
We build the third one, and in practice it works like this: the DMS Tech device goes onto the machine leaving your line as a payment system, and the buyer gets payment, sales tracking and remote management in the same fitting. Inside the machine, Hero Nexus talks to your controller over pulse, MDB or Modbus — no change to your board. QuadC stores the data and runs OTA. The operator sees everything in HERO in a browser, on the same screen as their other brands. The panel, cloud, updates and support stay with us; you keep building machines.
There's a second commercial benefit: two product tiers out of one cabinet. The base fitting delivers payment and sales tracking; add VMC hardware — temperature monitoring, remote door release, a product-drop sensor, a touchscreen — and the same cabinet becomes an upper-tier model, with no change to the platform or the panel, only to the price tag.
And to be explicit: we don't build machines. We are not your competitor; we are a platform supplier. We have been at this since 1996 — the first domestic Mobitex product in Turkey in 1998, the first card payment on a vending machine in 1999, the QuadC cloud platform named in 2005. The problems we started solving before the word “telemetry” was attached to vending are precisely the eight layers sitting underneath that three-week estimate.
Bottom line
“A few weeks” is accurate for the visible part. The invisible part — protocols, offline resilience, reconciliation, OTA, multi-tenancy, payment certification, cloud operations and support — is measured in years and gets heavier with every machine you sell. What you get in return is a fifth panel your buyer didn't want.
Narrowing the scope to telemetry-only doesn't rescue it either: you shed certification but hand away the payment line where the sale is actually born, and you're left with a panel that never matches the settlement and a fault with no single owner. Giving the software away doesn't rescue it at all — it deletes the revenue, keeps the cost, and ties the far end of the “lock” to you.
Your edge is in the cabinet, the cooling, the reliability and the delivery date. Let the software layer arrive ready.
Let's pilot it on one machine: payment and sales tracking out of the factory, a separate account space per operator, one panel — running in the field inside a week. Get in touch. If you want the same question from the buyer's side of the table, why hardware independence matters is the other face of it.