Buy vs Build Kiosk Software in USA

Sourcing comparison

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 are also subscription products for the most common journeys, such as the visitor management software, so the third route is described from both what we sell and what buyers report, and the verdict names the cases where the answer is not AtashiTech at all.

Side by side

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.

Packaged

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.

Custom

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.

Subscription

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.

Mixed

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.

Verdict

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.

Talk to an engineer See the packaged solutions

Frequently asked questions

A packaged solution is an existing application for a common journey, configured for your site: your fields, rules, branding, languages and integrations. A custom build starts from your journey as the specification and writes the application for it. The first is faster because the engine exists; the second fits exactly because nothing is being adapted.

When your requirement can be described as one of the well-explored journeys, such as visitor check-in, queue tokens, safety induction, collection, self-checkout or self-ordering, with a conventional peripheral list. The value is not the code; it is that the package has already met the exception cases every site eventually hits.

When the journey exists in one organisation and no package covers it, when the peripheral or integration list falls outside any product's boundary, or when the kiosk fronts a legacy system no vendor supports. It is also the honest answer when a package would need so much modification that its remaining value is only the demonstration.

It can work where the organisation already employs desktop engineers who have driven a payment terminal or a badge printer, and where those engineers will still be available when a printer model is discontinued. What usually defeats in-house kiosk projects is not the integration work but the service life: a kiosk is a product, and internal teams move on to the next project.

In three predictable places. A peripheral the vendor does not support is a boundary rather than a feature request; integration depth rarely goes beyond published connectors and a webhook; and offline behaviour varies sharply, because many subscription kiosks are a web page in a locked browser. Check all three before signing rather than after.

For a custom build, ownership is agreed up front and the code is normally handed over with the build. For a packaged solution, your configuration and your data are yours and ownership of the underlying application is set out in the contract. With a subscription you own neither the application nor, in some cases, a usable export of your own history.

Yes, and most real deployments end up that way. Common journeys ride on packages that other sites have already hardened while the part that is genuinely yours is built alongside. Both are monitored by the same fleet platform and covered by the same maintenance contract, so the mixture is easier to run than it sounds.

AtashiTech does not publish prices. For a package the drivers are the number of journeys, the peripheral list, the integrations and the number of sites. A custom build adds the engine the package would have supplied. A subscription is a recurring charge for the service life of the fleet, plus integration work that is often left out of the initial comparison.

Write the journey down step by step and mark each step standard, configurable or new. If almost nothing is new, take the package. If the new steps outnumber the standard ones, build. If the terminal count is small, the journey is common and the vendor already supports your devices and your connectivity is reliable, a subscription is reasonable.

No. There is a catalogue of packaged solutions configured per site and a kiosk application development service for custom journeys, both quoted per engagement. The subscription route is described here from what buyers report, and there are cases in the verdict where it is the better answer than anything we would build.