Kiosk Software Cost Factors in USA

Scoping and quoting

How we scope and quote kiosk software

AtashiTech does not publish prices, rate cards or ranges. This page explains what a quotation is built from, so you can judge a proposal before you receive one.

The most common first question is what kiosk software costs, and there is no honest single answer. Two visitor-management projects that read identically in a brief can differ enormously in effort, because one drives a badge printer and sends an email while the other reads passports, screens a watchlist, opens a turnstile, synchronises a directory and runs across many buildings. What this page can do is set out the variables that decide the size of a piece of work, the engagement models we use, and what arrives in a proposal. If you would rather skip to the conversation, describe your journey on the contact page.

Scope drivers

Six things that decide the size of a kiosk project

These are the questions we ask first, because the answers move the effort more than anything else does.

The number of journeys

One journey is a project; five journeys sharing a screen are five projects with a shared shell. Each journey brings its own screens, its own rules and, more importantly, its own exception cases: the visitor with no identity document, the worker whose induction has lapsed, the payment that fails after the note is stacked. We count journeys, not screens.

The peripheral list

Every device attached to the kiosk is a piece of integration work with its own SDK, its own failure modes and its own test cycle on real hardware. A screen and a printer is a short list; a scanner, scale, cash recycler, document reader, card terminal and gate relay is a long one. The categories we already drive are on the integrations page.

The systems behind it

A kiosk that stands alone is straightforward. A kiosk that must read and write a hospital information system, a core banking system, an ERP, a POS or a student information system inherits that system's API, its test environment and its owner's release calendar. Field mapping with the incumbent vendor in the room is a work package, not an assumption.

What must survive an outage

Offline-first is our default for anything public-facing, and it is not free. A journey that must complete with the network down needs local state, a synchronisation design and a reconciliation rule that guarantees a transaction posts once. Deciding which steps genuinely need that, and which can fail politely, is part of scoping.

Sites, languages and variants

The second site is cheap; the second variant is not. Gates, formats, tenants or departments that each need different rules multiply configuration and testing, as does every extra language with its own audio. A single-site pilot and a national rollout are different engagements even when the software is identical.

Life after go-live

Kiosks stay in service for years while content, rules, billers, rosters and device models change. An annual maintenance contract through consulting and AMC support covers fixes and changes, and it is quoted alongside the build rather than discovered later.

Method

From first conversation to a proposal

Four steps. The first two produce the facts a quotation needs; nothing is priced before they exist.

Discovery

We talk to the people who own the counter, the gate or the lane, and to the IT team who will own the integration. We walk the site where that is possible, which is straightforward from our base in Bengaluru, and watch the process at a busy hour, because that is where the exception cases live. The output is a written journey, step by step.

Specification

Each step is marked standard, configurable or new. Devices are named by make and model, integrations by system and field, languages by screen, and offline behaviour step by step. This is also where a packaged solution is confirmed as the right route, or ruled out; the buy versus build comparison sets out that test.

Proposal

You receive scope, assumptions, exclusions, the engagement model, deliverables and support terms, phased so you can start and stop. Anything that cannot be estimated yet is named as an open item rather than buried in a contingency.

Build, pilot, roll out

The application is developed under the kiosk application development service, tested against real devices and your test systems, and piloted on one unit with the old process still running beside it. The rollout follows in batches.

Engagement models

The four shapes an engagement takes

The right model depends on how well defined the work is, not on which one sounds safer.

Fixed scopeWell-defined work

Time and materialEvolving requirements

Dedicated teamLong programmes

Retainer and AMCAfter go-live

Fixed scope suits work whose boundaries are genuinely known: defined screens, a named device list, confirmed integrations. It gives certainty and demands discipline on both sides, because every change is then a change request.

Time and material suits requirements that will move as they are discovered, which is usual when a kiosk fronts an old system nobody has documented. You get flexibility and visible effort; the end point is a direction rather than a line.

A dedicated team suits a programme rather than a project: several journeys, several sites, a roadmap that will run for a long time, with priorities set by you.

A retainer or annual maintenance contract follows go-live, covering fixes, content and configuration changes, device replacements, new languages and the upgrades that keep a fleet supportable.

The proposal

What arrives in a proposal, and what you provide

A quotation is only as good as the facts underneath it, and some of those facts are yours.

What the proposal contains

The journeys in scope, written as steps, and the exception cases each one handles.
The device list by make and model, and what happens when a device is unavailable.
Each integration by system, direction and the fields it reads or writes.
Offline behaviour per step, and the reconciliation rule for anything involving money.
Deliverables: the application, the installer, lockdown and watchdog configuration, back-office screens where needed, documentation and handover.
The engagement model, the phase sequence, assumptions, exclusions and open items.
Support terms after go-live, and what the maintenance contract covers.

What we need from you

Someone who owns the process and can decide what the kiosk should do at each exception.
Access to a test environment for every system the kiosk must talk to, and a contact at each vendor.
The hardware, or the freedom to specify it with your vendor. AtashiTech writes software and does not manufacture enclosures.
Content that already exists: induction videos, menus, fee heads, badge layouts, receipt formats, languages.
A pilot site where the existing process can keep running beside the kiosk for a while.

Worked examples

If it helps to see the method applied rather than described, the illustrative scenarios follow the same path from situation to journey to integration list: contractor induction at a plant gate, supermarket self-checkout and shared self-ordering in a food court. None of them describes a named customer or carries results.

Source code and ownership

Ownership is agreed in writing before work starts rather than left to be discovered at the end. For a custom build, the source is normally handed over with the delivery. For a packaged solution, your configuration, your content and your data are yours, and the position on the underlying application is set out in the contract. Your data is exportable in either case; we do not treat it as a retention device.

Tell us the journey and you will get a scope, not a price list

Describe what happens at your counter, gate or lane today, which devices are involved and which systems sit behind them. We will come back with questions first and a proposal after.

Start a conversation Browse the solutions

Frequently asked questions

There is no single answer, and AtashiTech does not publish prices, rate cards or ranges. Two projects that read identically in a brief can differ enormously in effort. What decides the size of a piece of work is the number of journeys, the peripheral list, the systems it must read and write, what has to keep working offline, the number of sites and languages, and the support that follows go-live.

Because a published figure would be wrong for almost every reader, and a figure attributed to us that we did not quote does more damage than silence. Every engagement is scoped and quoted individually against a written journey and a named device list. Anyone quoting an AtashiTech price without that scope is guessing.

The journey written down step by step, the devices that must be attached by make and model, the systems the kiosk has to read from or write to, which steps must survive a network outage, the languages, and the number of sites and variants. Discovery and specification exist to produce exactly that list; nothing is priced before it exists.

Four. Fixed scope for work whose boundaries are genuinely known. Time and material where the requirement will move as it is discovered, which is usual when a kiosk fronts an undocumented legacy system. A dedicated team for a long programme across several journeys and sites. A retainer or annual maintenance contract for the period after go-live.

The journeys in scope as steps with their exception cases, the device list, each integration by system and field, offline behaviour per step and the reconciliation rule for anything involving money, the deliverables including installer and lockdown configuration, the engagement model and phase sequence, assumptions and exclusions, and the support terms.

It is agreed in writing before work starts rather than discovered at the end. For a custom build the source is normally handed over with the delivery. For a packaged solution your configuration, content and data are yours, and the position on the underlying application is set out in the contract. Your data is exportable either way.

No. AtashiTech is a software company and does not manufacture kiosks, enclosures or peripherals. You buy the unit from a hardware vendor, or we help you specify it, and we write the application, integrate the devices and lock down the machine inside.

Kiosks stay in service for years while content, rules, billers, rosters, regulations and device models change, so support is quoted alongside the build. An annual maintenance contract covers fixes, content and configuration changes, new languages and version upgrades, and fleet monitoring means a fault is known before a user reports it.