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.
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.
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.
The four shapes an engagement takes
The right model depends on how well defined the work is, not on which one sounds safer.
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.
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.
Frequently asked questions
Tell us the journey, the sites and the hardware you already have — every engagement is scoped and quoted individually.