Buy or build kiosk software: three routes and where each one breaks
A packaged solution, a custom build and an off-the-shelf subscription are not three prices for the same thing. They are three different bets on how much your journey resembles everyone else's.
Every self-service project reaches the same fork. Somebody has found a product that demonstrates beautifully, somebody else has a list of things it cannot do, and a third person wants to know why the in-house team could not just write it. The honest answer turns on a question that rarely gets asked early enough: how much of your journey is standard, and how much of it is yours.
AtashiTech sells on two of these routes, so the position is worth stating plainly. There is a catalogue of packaged kiosk solutions configured per site, and a kiosk application development service for journeys no package covers. There is no subscription product, so the third route is described from what buyers report rather than from something we sell, and the verdict names the cases where the answer is not AtashiTech at all.
Packaged, custom or subscription, criterion by criterion
Eight criteria that decide the route. Each card gives the practical position for all three.
Fit to your journey
- Packaged: excellent where the journey is a common one, because the package was shaped by the same journey elsewhere; configuration covers screens, fields, rules and languages.
- Custom: exact, because the journey is the specification rather than a variation of one.
- Subscription: good until the first requirement the vendor's roadmap does not share, after which it is a feature request.
Time to a working unit
- Packaged: the shortest route, since the engine exists and the work is configuration, integration and content.
- Custom: the longest, because the engine is written for you.
- Subscription: fastest to a demonstration, slower than it looks to a production unit once peripherals and integrations are attached.
Peripheral coverage
- Packaged: the devices the package already drives are proven; a new model is a scoped addition.
- Custom: whatever your parts list contains, integrated one device at a time.
- Subscription: the vendor's supported list, which is the hard boundary of the route; an unsupported reader is usually the end of the conversation.
Integration depth
- Packaged: connectors to the common system categories, with field mapping done in the engagement.
- Custom: anything with an API, a file drop or a database view, including the system nobody outside your organisation has heard of.
- Subscription: the vendor's published connectors and a generic webhook; deep two-way sync is rarely on offer.
Offline behaviour
- Packaged: offline-first by design, because the packages were written for gates, lobbies and factory floors.
- Custom: whatever the requirement says, which should be offline-first for anything public-facing.
- Subscription: varies sharply; many are browser-delivered and stop when the page does. Test it before signing.
Who owns the source
- Packaged: the configuration and your data are yours; ownership of the underlying application is agreed in the contract.
- Custom: agreed up front and normally handed to you with the build.
- Subscription: you own neither the application nor, in some cases, the export format of your own history.
Changing it later
- Packaged: configuration changes are yours to make; behaviour changes go through a maintenance contract.
- Custom: anything is possible and everything is a change request against a team.
- Subscription: configuration is instant, anything else waits for the vendor's roadmap and its other customers.
What drives the cost
- Packaged: the number of journeys, the peripheral list, the integrations and the number of sites.
- Custom: the same drivers plus the engine itself, which the package would have supplied.
- Subscription: a recurring charge per terminal that never stops, plus the integration work nobody counted at the start.
When a packaged solution is the right answer
Standard journeys are standard for a reason: thousands of organisations have already argued about the edge cases.
Visitor check-in, queue tokens, safety induction, bill collection, self-checkout and self-ordering are well-explored problems. The screens, rules and languages differ; the shape of the journey does not, and neither do the exceptions: the visitor with no identity document, the token holder who left the building, the worker whose induction expired yesterday, the payment that failed after the note was stacked. A package that has already met those cases is worth more than a clean codebase that has not.
Choose this route when your requirement can be described as one of the journeys in the solutions catalogue with your fields, rules, branding and integrations. Configuration covers far more than logos: service categories, badge layouts, approval rules, priority handling, languages, receipt formats and which systems are written to. What it does not cover is a journey that is genuinely different, and pretending otherwise produces a package bent so far out of shape that nobody can upgrade it later.
The practical test is to write the journey down step by step and mark each step standard, configurable or new. If almost nothing is new, a package is the efficient answer and the effort moves to integration and content, where it belongs.
When a custom build earns its cost
Custom is not a failure of the market. It is the correct answer when the journey is the differentiator.
Some journeys have no package because they exist in one organisation. A kiosk that reads an identity document, captures a photograph and produces a pre-filled account-opening application for one lender's onboarding process. A concourse directory whose tenant data, offers and routes come from a mall operator's own systems. A driver check-in that combines a token, a consignment record, a safety briefing and a dock assignment. A screen that fronts a legacy application nobody will replace for years. These are built, and the kiosk application development service exists for them.
Custom is also the honest answer where a package would need so much modification that its remaining value is only the demonstration. The signal is the size of the exception list produced in the test above. When the new steps outnumber the standard ones, the package is being used as a starting position rather than a product, and starting from the requirement is cleaner and cheaper to maintain.
Building in-house is a variant of this route rather than a separate one. It works where the organisation already employs desktop engineers who have driven a payment terminal or a badge printer, and where they will still be there when a printer model is discontinued. What defeats in-house kiosk projects is rarely the peripheral integration; it is that a kiosk is a product with a service life, and the team that built it has moved on.
Where an off-the-shelf subscription fits, and where it stops
A per-terminal subscription is a real option, and for a narrow set of journeys it is the sensible one.
Sign-up is quick, the vendor carries the maintenance, and for a small number of terminals running a common journey with the vendor's own supported hardware, that is a good trade. Single-office visitor check-in with a tablet and a badge printer is the clearest example. If that describes your requirement, take it, and do not commission software.
The route stops in three predictable places. The first is the peripheral list: a cash acceptor, a weighing scale, a document scanner, a vital-signs instrument or a gate controller that the vendor does not support is not a feature request, it is a boundary. The second is integration depth, because a webhook and a nightly export are not the same as writing into a hospital information system or a core banking system with the field mapping your operations team expects. The third is offline behaviour, and it is the one buyers discover last; a great many subscription kiosks are a web page in a locked browser, which is fine in an office and not fine at a factory gate. Our Windows versus Android comparison covers why that architecture behaves the way it does.
One slower consideration belongs in the comparison too. A subscription is a recurring commitment for the service life of the fleet, on terms the vendor may change, and it deserves to sit beside the one-time cost of the other two routes rather than be left out because it arrives monthly.
Most real deployments are a mixture
The routes are not exclusive, and treating them as exclusive is how projects get stuck.
A hospital typically takes packaged registration and token software and commissions a custom screen for a scheme that exists only in that state. A manufacturer takes packaged induction and contractor modules and has a yard check-in built on top. A retailer takes packaged self-checkout and builds an endless-aisle front end on its existing commerce platform. The common journeys ride on packages other sites have already hardened, and the effort goes into the part that is genuinely theirs. That mixture is easier to run than it sounds: one kiosk management platform monitors packaged and custom units alike and one maintenance contract covers the estate, so deciding journey by journey beats deciding once for the whole programme.
How to choose
A neutral reading of the criteria above.
Choose a packaged solution when your journey is one of the well-explored ones, your peripheral list is conventional, and your effort should go into integration, content and rollout rather than into an engine somebody has already written. This is the majority case.
Choose a custom build when the journey is yours, when the peripheral or integration list falls outside any product's boundary, or when the kiosk fronts a system that no vendor supports. Expect to spend more of the engagement on specification, and insist on the source-code position in writing.
Choose a subscription when the terminal count is small, the journey is common, the vendor's hardware list already covers your devices, and the site has reliable connectivity. Read the offline behaviour and the data-export terms before signing, not after.
Do not choose yet if the journey has not been written down step by step. Sourcing is a consequence of the requirement, not a starting point. Our scoping and quoting process exists to produce that list, and the kiosk versus tablet comparison settles the question that usually comes before this one.
Not sure which route your journey needs?
Send the journey, the peripheral list and the systems it must talk to. We will tell you whether a package fits, where it does not, and when a subscription would serve you better than we would.
Frequently asked questions
Tell us the journey, the sites and the hardware you already have — every engagement is scoped and quoted individually.