Why is kiosk software designed differently from a website?
The person using a kiosk is standing, has a queue behind them and is seeing the screen for the first time. So what we measure is how many seconds and taps a transaction takes. Large touch targets, a single main action and a way back at every step are the foundation of the design.
How long does kiosk software take to build?
A single-flow kiosk, such as a queue ticket, application or check-in screen, can be up and running in 3-5 weeks. Baskets, orders routed to the kitchen and above all payments add time: a kiosk with payment runs to 6-10 weeks, and much of that depends on the integration method your bank or payment provider offers.
| Kiosk type | What it includes | Time |
|---|---|---|
| Single-flow kiosk | Queue ticket, application or check-in screen | 3-5 weeks |
| Ordering kiosk | Catalogue or menu, basket, orders routed to the kitchen or warehouse | 5-8 weeks |
| Kiosk with payment | Payment terminal integration, receipts and invoices | 6-10 weeks |
| Remote management panel | Content, prices and status across several kiosks | 2-4 weeks |
A typical budget for this service is US$3,500-12,000, excluding VAT (as of October 11, 2026). Where you land in that range depends on the number of user types, the systems to connect and how much design work there is; the exact figure comes as one price once the scope is written down.
Cost and timeline guide
Every budget band, our rates by role and the timeline for each scope tier, on one page.
Pricing
The four engagement models, payment terms and what the price covers.
Devices in the field fail in the field
A kiosk is a device standing on its own: the connection drops, the printer runs out of paper, someone walks away halfway through. We plan how each of these is handled from the start, and provide a panel where you can monitor every kiosk remotely, so you see that a device has a problem before a customer complains.
How a self-service order moves through the kiosk
The customer completes the order alone, from choosing to paying, and walks away with a receipt and an order number. Taking orders and payments is no longer a job for your staff. The team sees the order on the kitchen or warehouse screen and gets on with preparing it.
On paper these five steps look simple. The work is in the small cases between them. What happens if a customer fills the basket and walks off? Where does the order go if the payment is declined? How does the customer get an order number if the printer fails? We write each of these down during design.
- After a set time with no touch, the screen resets and the basket is cleared, so one customer’s choices never carry over to the next.
- If a payment fails, the basket is kept and the customer can try another method or is sent to the till.
- If the receipt can’t print, the order number is shown in large type on screen and an alert opens in the management panel.
- Each screen has one main button, and "Back" and "Start again" sit in the same place on every screen.
Choosing hardware for a kiosk project
Software and hardware limit each other, so we suggest choosing the device once the flow is clear. If you already have devices, we build the software around them. If you don’t, these are the points to go through with your supplier.
Screen
Size and orientation (portrait or landscape) shape the interface from the start. At sunny entrances, brightness matters too.
Receipt printer
Decide what the kiosk does when paper runs out, and who changes the roll.
Payment terminal
The integration method your bank or payment provider offers sets the scope and the timeline.
Scanner
If you need a barcode, QR or card reader, we test how it talks to the device before building on it.
Connection
Wired, wireless or a mobile line. What the kiosk does when the connection drops is defined in the software.
Enclosure and mounting
Cable routing, ventilation and a service hatch. Someone should be named to open the unit when it fails.
Ask your supplier how long spare parts take to arrive, whether there is on-site service for faults, and whether they provide developer documentation for the connected hardware. That last answer has a direct effect on how long the software takes.
How a kiosk project runs, step by step
We don’t start coding until every screen and every failure case is settled on paper. Development then happens on the real device, and the kiosk runs with real customers at one branch or entrance before it goes out to every site. From start to finish, one product owner is your single point of contact.
- 01
Scoping call
30 minWe talk through where the kiosk will stand, who will use it and what they need to do on it. It’s free.
- 02
Flow and screen design
We map every screen and every failure case, and cut the number of taps at this stage.
- 03
A working version on the device
WeeklyEach week you get a version you can try on the real screen. The task list stays open to you.
- 04
Pilot at one site
The kiosk runs first at one branch or entrance with real customers. This is where the sticking points show up.
- 05
Roll-out and support
30 daysThe other sites are connected to the remote management panel. Bug fixes are free for 30 days after launch.
The tier you pick in the table above sets the overall timeline. If the scope changes along the way, we send you the effect on time and budget in writing within 24 hours.
Is a kiosk the right answer for you?
If a short transaction, done the same way every time, is causing a queue at the till or front desk, a kiosk is worth it. When the transaction needs a member of staff to explain something or check documents, a queue forms at the kiosk too, because the customer still has to call someone over.
A kiosk makes sense when
- The same short transaction repeats many times a day
- The till or front desk becomes a bottleneck at peak times
- The choices are limited and can be explained on screen
- You offer the same service at several sites
Something else may suit you better when
- The transaction needs a long explanation or advice
- Customers could do the same thing on their own phone via a QR code, which is usually cheaper
- There are only a few transactions a day and no queue
- A member of staff has to check ID or documents
Frequently asked questions
Will it work with our existing kiosk hardware?
In most cases, yes. The first step is reviewing the device’s operating system, screen and connected hardware (printer, payment terminal, scanner); the software is designed around that review.
Can the kiosk take payments?
Yes. Payment terminal integration is its own scope tier and is planned around the integration method your bank or payment provider offers.
How do we manage kiosks across several branches?
Through the remote management panel: menu, price and content changes go out to every kiosk from one place, and you can see whether each device is online and when it last completed a transaction.
Does the kiosk work without an internet connection?
The kiosk is set up to keep taking transactions when the connection drops. Records are held on the device and sent to the centre once the connection is back. Steps that need online approval, such as card payments, depend on the payment terminal’s own connection, so we agree up front what the screen shows in that situation.
What drives the cost of kiosk software?
The tier is the biggest factor: a single-flow queue screen and an ordering kiosk that takes payments are very different jobs. Connecting to your existing till, stock or booking system and the number of kiosks also affect the scope. Our rates are US$25-60 per person-hour, depending on the role, and projects start from US$1,000. The firm figure comes once the scope is clear in the scoping call.
Who owns the kiosk software’s source code?
The source code stays with Pepechura; you get a perpetual licence to use the kiosk software, and your data is always yours. If you want the source code transferred to you, that is available for an additional fee, set out separately in the quote, so you could develop the kiosks further with another team later. If Pepechura ever ceases trading, the source code is handed over to you.