Custom POS With a Kitchen Display System: What It Really Costs to Build
A kitchen display system bolted onto an existing POS (Point of Sale) typically runs $15,000 to $60,000. A POS plus KDS as a first release runs $50,000 to $130,000 in 10 to 16 weeks. A full multi-location platform with offline payments, inventory and franchise reporting runs $150,000 to $350,000 over 6 to 12 months. Those are Digital Heroes delivery bands across 2,000+ projects. The number is driven almost entirely by two things: whether tickets must survive a network outage, and how many ways a single order can be modified after it hits the line.
What a POS with a kitchen display system looks like once real tickets hit it
Friday, 7:40pm. A server rings in table 12: two burgers, one with no onion. Thirty seconds later the guest changes their mind, so the server voids the no-onion burger and fires a chicken sandwich instead. The Wi-Fi access point near the walk-in reboots. The KDS at the grill station never receives the void. The expo screen does, because expo is on the wired drop.
The grill cooks two burgers. Expo sees one burger and one chicken. The ticket cannot close, the line is arguing, and the manager is manually bumping tickets to clear the queue, which destroys every ticket-time metric the system was sold on.
The bug is not the Wi-Fi. The bug is that the build treated the KDS as a view of POS state instead of an independent consumer of an ordered event stream. Once you accept that the KDS holds its own copy of the truth and can fall behind, everything below follows.
Offline is the product, not a feature flag
Restaurants lose network, and not rarely. A busy quick-service location drops connectivity for 30 seconds to several minutes multiple times a week, usually from a saturated uplink rather than a hard outage. The register must still take orders and the kitchen must still see them.
What a competent build does: the terminal writes to a local durable store first (SQLite with WAL mode on Android or iOS; IndexedDB is workable on Electron but you will fight quota eviction), assigns a client-generated ULID or UUIDv7 as the order id, and pushes an append-only event log to the server. Every mutation is an event: OrderOpened, ItemAdded, ItemVoided, ItemFired, TicketBumped. Never a full order object PUT, because full object PUTs are how a stale snapshot clobbers a void.
Last-write-wins is acceptable for exactly one class of data: cosmetic fields like table name. For anything on the line it is wrong. Use per-aggregate sequence numbers so the server can reject out-of-order writes, and make every event idempotent on its client id so a retry after a timeout does not double-fire an item. The most common bug we find in a KDS someone else built is a duplicate ticket caused by retrying a request that actually succeeded but whose response was lost.
Decide on paper, before code, what happens when two terminals edit the same open check offline. The answer that holds up for most operations: item-level adds merge so both sets appear, voids win over adds regardless of timestamp, and discounts require a manager touch on reconnect. That is a business rule, not a technical one, and a vendor who has not asked you for it has not shipped this.
The routing and modifier matrix is where the estimate explodes
"Send food to the kitchen" is a routing engine. A single item may route to grill, fry and expo simultaneously. A modifier can change the route: a burger with no bun still goes to grill, but a side salad substituted for fries removes the fry ticket entirely. Combos route their components separately while appearing as one ticket on expo. Coursing means holding appetisers and firing mains later, either on a timer or on a manual fire from the server.
The rule we use: route on the item plus modifier set, not on the item alone, and persist the routing decision on the ticket line at fire time. Resolve routing dynamically at render time on the KDS and a menu change at 4pm silently reroutes tickets already on the line.
Prep pacing is the next layer. Fries take 3 minutes, a steak takes 12, and a ticket where both land together means the fry station should not see the item for 9 minutes. That is a scheduling problem with a real algorithm behind it, and it is a genuine differentiator, but every hour spent there is an hour nobody quoted. If your build does not need coursing or pacing, say so loudly and take the money off the estimate.
Payments will consume more of the budget than the KDS
If the POS takes cards, the security scope changes shape. Do not touch card data. Use a semi-integrated P2PE terminal so card data never enters your application: Stripe Terminal, Square Terminal, Adyen, or a Verifone or Ingenico device driven through middleware such as Datacap NETePay. Your app sends an amount and receives a token and a result. That keeps you in PCI DSS SAQ C-VT or SAQ P2PE territory instead of a full SAQ D, which is the difference between a questionnaire and a compliance programme.
The failure mode nobody quotes: the terminal approves the card and the network drops before your POS hears back. Now there is a charge and no order. Every card interaction needs an idempotency key and a reconciliation job that queries the processor for orphaned transactions on startup and on reconnect. Tips, especially tip-adjust after the fact, add a second settlement window and a reporting surface.
Offline card acceptance (store and forward) is a business decision, not a technical one. You are accepting decline risk in exchange for not turning guests away. Set a per-transaction floor limit and a per-terminal cap, and be explicit with the operator about who eats the declines.
The hardware is a real project inside your project
Kitchen printers still matter, because most kitchens want a paper backup or a runner ticket. That means ESC/POS over TCP on port 9100 to an Epson TM series or Star device, static IPs or mDNS discovery, and treating an out-of-paper printer as a first-class order state rather than a swallowed exception. If a ticket fails to print and the KDS shows it, fine. If the KDS is down and the print failed, the order is gone.
Cash drawers open via the printer's kick port. On Android, kitchen tablets go into kiosk mode via COSU device-owner provisioning with a managed launcher, otherwise a line cook will find YouTube. Screen burn-in on an always-on KDS is real, so the UI needs subtle pixel shifting. Grease and gloves mean touch targets around 64px minimum and a bump bar (a USB HID keypad) as the primary input, not the screen.
Budget for a physical dress rehearsal in an actual kitchen before go-live. Every KDS we have shipped had at least one defect that only appeared with heat, steam, gloves and noise in the room.
What this costs and what moves the number
These are Digital Heroes delivery bands from more than 2,000 projects, not market averages.
A focused KDS added to an existing POS: $15,000 to $60,000. The order model exists and payments are solved. The low end is one station, no coursing, online only, manual bumping. The high end is multi-station routing, bump bars, prep timing and offline tolerance.
POS plus KDS as a first release: $50,000 to $130,000 over 10 to 16 weeks. Menu and modifier management, order capture, semi-integrated card payments, routing, KDS, receipt and kitchen printing, end-of-day reporting.
Full platform: $150,000 to $350,000 over 6 to 12 months. Multi-location, inventory depletion, franchise reporting, online ordering, delivery aggregator ingestion.
What drives this capability up, in order of impact. First, offline write support: retrofitting conflict resolution and a durable local event log onto a build that assumed connectivity adds 3 to 5 weeks, because it touches every write path and doubles the test matrix. Second, modifier and combo depth: a 40-item menu with 3 modifier groups is a week, while build-your-own with conditional pricing, nested groups and route-altering modifiers is a month. Third, coursing and pacing. Fourth, delivery aggregator integrations at roughly 1 to 3 weeks each for DoorDash Drive, Uber Eats or Deliverect, each with its own cancellation semantics that fight your ticket state machine. Fifth, hardware variety: every additional printer or terminal model is real integration and QA time.
When you should not build this
If you are an operator with fewer than about 15 locations and a conventional service model, do not build a POS. Buy Toast, Square for Restaurants, Lightspeed or SpotOn. Toast sells its KDS per screen per month on top of hardware, and their offline mode, payment compliance, printer certifications and 24/7 support already exist. You will not beat a fifteen-year head start on hardware drivers with a $120,000 budget, and you will own the on-call phone at 7:40pm on a Friday forever.
Build when one of these is true. The POS is your product, not your overhead. Your service model genuinely does not fit the incumbents: ghost kitchens with multi-brand ticket splitting, high-volume stadium or festival concessions, a production line with real manufacturing constraints, or a regulated vertical such as cannabis where Metrc integration is mandatory and the majors will not touch you. Or you already have a strong product, an ordering app or a loyalty platform, and the KDS is the piece that makes the rest defensible. That last case is exactly the $15,000 to $60,000 band and it is usually the right call.
Middle path worth knowing: Fresh KDS and similar run standalone alongside an existing POS for a low monthly fee. If the complaint is only "our KDS is bad", that may be a subscription problem rather than a $60,000 one.
How to brief and vet a developer for this
Brief them with what they cannot guess: peak tickets per hour per station, your full modifier tree exported from your current system, your exact card processor and terminal model, whether you course, and what should happen when the network dies mid-order. Give them a photo of the kitchen. Better, bring them into the kitchen at peak.
Then ask these. They separate the shipped from the confident.
"Two terminals are offline and both edit the same open check. Walk me through your merge, including a void racing an add." If the answer is "last write wins" or "that will not happen", stop.
"The card terminal approves but the response times out. What happens?" You want idempotency key, reconciliation on reconnect, orphan transaction sweep.
"Are you semi-integrated, or does card data touch your app?" The only acceptable answer is semi-integrated, with a named terminal.
"A modifier changes the routing station. Where is that resolved and when?" Correct answer: at fire time, persisted on the ticket line.
"How does the line bump a ticket?" If they say "they tap the screen" and have not mentioned a bump bar or gloves, they have never stood on a line.
"What is your recall flow?" A cook bumps by accident every shift. No unbump means the system is unusable by week two.
"How do you handle the printer being out of paper?" You want a queued ticket state and an alert, not a caught exception.
"Show me your ticket state machine." If it exists on paper, they have shipped this. If they draw it live during the call, they have not.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Global retail loses an estimated $1.73 trillion annually to inventory distortion (out-of-stocks and overstocks), equal to about 6.5% of global retail sales, despite $172 billion spent on improvements in the past year. Source: IHL Group (2025) →
- U.S. retailers lost an average of 1.6% of sales to shrink in FY2022 (up from 1.4% the prior year), equating to $112.1 billion in inventory losses - the benchmark case for POS-integrated loss prevention and inventory accuracy. Source: National Retail Federation (NRF) (2023) →
- Total US training expenditure rose 4.9% to $102.8 billion; learning management systems were used at 89% of organizations (90% of large, 97% of midsize, 84% of small companies), with average training at 40 hours per employee and $874 spent per learner. Source: Training Magazine (2025) →
- This World Bank report argues that digital technology adoption raises SME competitiveness, productivity and resilience, while documenting that smaller firms consistently lag larger ones in digital adoption - a gap that constrains their growth and market reach. Source: World Bank (2022) →
Rohan advises mid-market and enterprise teams on ERP, CRM and custom software, and has led delivery on dozens of business-software builds.
Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.