Ghost Kitchen Software: Stay on Otter and Deliverect, or Build the Layer Above Them?
Count your brand by channel by location combinations, because that number decides this and nothing else does.
On this page
Count your brand by channel by location combinations, because that number decides this and nothing else does. Under about eight combinations, meaning three or fewer kitchens, four or fewer brands and under roughly 250 orders a day, buy: Otter, Deliverect or ItsaCheckmate alongside Toast or Square costs a few hundred dollars a month per location and solves most of the problem. Past eight combinations the middleware becomes the bottleneck it was supposed to remove, because it models items rather than ingredients and routes by brand rather than by station. Most operators reading this are still on the buy side.
When is off the shelf genuinely the right call here?
If you run one to three kitchens, four brands or fewer, under roughly 250 orders a day, and your menus are stable, do not build. Otter, Deliverect and ItsaCheckmate all inject DoorDash, Uber Eats and Grubhub tickets into Toast or Square and keep menus in step, and they do it for a few hundred dollars a month per location. Anyone recommending a six figure build at that scale is selling rather than advising.
Buy the register and the payment rails permanently, at any scale. Nobody in this category should be building a point of sale (POS) or touching card data directly. Toast and Square hold the register, the tax handling and the payment processing, and keeping cardholder data inside a payment provider's hosted fields keeps your compliance scope small. A custom layer sits above that and writes to it, which is both cheaper and the only version that survives your next location opening on a different contract.
Buy also if your bottleneck is demand rather than throughput. Software does not create orders, and a build that makes an underused kitchen more efficient is an expensive way to be efficient at nothing.
The test that settles it: can your general manager get through a Friday lunch without pausing a channel from a tablet. While the answer is yes, the middleware is doing its job and you have not outgrown what you can buy.
When does a custom build actually pay off?
The signals are specific to multi brand operations and they show up on the line before they show up in a report.
Someone on payroll spends more than a day a week reconciling payouts or updating menus across merchant portals. You are past roughly eight brand by channel by location combinations, so menu drift is now a permanent condition rather than an incident. Your direct channel is past a fifth of volume and the commission you avoid is worth real engineering. You license your brands into third party kitchens and need per licensee reporting the middleware cannot give you. Or a general manager pauses a brand on one marketplace during a rush and forgets to restore it, which costs you ninety minutes of a channel dark during peak and happens two or three times a week per location.
Two structural gaps cause most of this. The first is that packaged middleware models items, not ingredients. It will snooze the exact item you name across channels, and it has no idea that two of your brands share a fryer basket or a braised protein. When one component runs out at 7:40pm, a human has to find every affected listing across four portals from memory. The second is that every packaged kitchen display routes by order and by concept, because it was designed for a dine in restaurant with one menu. Ghost kitchens are stations wearing brand costumes, and a fryer screen showing six tickets from six brands in arrival order runs at half basket utilisation.
The decisive signal is different from any of those. It is having a repeatable operating advantage, such as station batching across brands or daypart pricing, that a packaged product will never ship because it only makes sense when many brands share one line. That is when the build stops being a cost centre.
How do they compare on the things that matter in this industry?
- Item model versus ingredient model. This is the central difference. Middleware maps channel items and pushes menus. A build maps every channel item to a bill of materials, so taking one component down walks the dependency graph and snoozes every affected listing on every channel in about a second, then restores when the next prep batch is logged.
- Ticket routing. Packaged displays sequence by arrival and by brand. A build explodes each order into station level tasks, batches like tasks across brands inside a courier arrival window, and sequences backward from the latest allowable ready time. No vendor ships this, because it is only coherent in a shared line kitchen.
- Per brand economics. Restaurant365 and MarginEdge do good back office work and reconcile to a location and a vendor invoice. Otter reports revenue per brand and stops, because it never saw your invoice. Neither can attribute labour by station seconds, which is what makes a brand level contribution margin real rather than allocated.
- Payout reconciliation. Deposits land net of commission, promo participation, adjustments, error charges and chargebacks, formatted differently by each platform, with dispute windows measured in days. Matching every payout line to the order in your own system is the piece that recovers money and the piece no middleware attempts at order level.
- Offline behaviour. A kitchen with a dead connection still has to cook. Local first capture with reconnect reconciliation is about a third more work than a cloud only display and it is the difference between service continuing and a screen going blank at 12:10 on a Friday.
What does total cost of ownership look like at your scale?
From Digital Heroes delivery experience, a focused first release runs $60,000 to $130,000 and ships in 12 to 16 weeks. That covers unified order intake from two or three marketplaces, the component and bill of materials layer with cross channel snooze propagation, a station routed kitchen display with offline handling, and payout reconciliation. A full platform adding per brand costing from parsed vendor invoices, prep par forecasting, a direct order channel with your own couriers and multi tenant support for licensed kitchens runs $150,000 to $400,000 phased over 6 to 12 months.
A worked shape: four kitchens, six brands, roughly 700 orders a day, three marketplaces live, Toast on the register. The first release lands near $123,000 across about 15 weeks, split as order intake and menu publishing $34,000, component and bill of materials layer $26,000, station routed display $31,000, payout reconciliation $18,000, and Toast integration with a divergence checker $14,000. Phase two adds vendor invoice extraction and per brand margin at $32,000, forecasting at $21,000, a direct channel at $44,000, multi tenant licensing at $26,000 and hardware across four sites at $17,000, taking the platform to $263,000. Strip the direct channel and licensing and the same operator lands near $193,000.
Running cost is 15 to 20 percent of build a year, so roughly $18,000 to $25,000 on that first release. Most of it is a development retainer, and here it is genuinely not optional: marketplaces change fields and deprecate endpoints on their own schedule, and a menu push that silently stops working costs you a channel during peak. Screens and label printers live in a hot, greasy room and need a replacement cycle per site. And somebody has to work the reconciliation exception queue, because a dispute engine nobody reads recovers nothing.
Compare that against your current total rather than your subscription. Add middleware across every location, the point of sale and its modules, any separate display tool, then the payroll that exists because the software cannot do the job, then the leaks: undisputed error charges, channels left dark after a manual pause, refunds on items that stayed live after their protein ran out, and fryer capacity wasted on brand ordered tickets.
What does the hybrid look like, and when is it the honest answer?
The hybrid is not a fallback here, it is the architecture. Keep the point of sale. Keep the marketplaces. Build the layer that sits between them and your line.
The split is clean. Toast or Square owns the register, tax and payments. The marketplaces own demand and courier dispatch. The custom layer owns the component and bill of materials model, the station routing, the payout reconciliation and the per brand margin. Everything reads and writes through partner interfaces, and a divergence checker compares your source of truth against what is actually live on each channel, which is what catches a menu push that half succeeded.
There is a smaller hybrid worth naming for operators who are near the threshold but not over it. Build payout reconciliation alone and keep the middleware doing everything else. It is the least interesting feature in the category and it recovers money inside the first month, because the usual reason an error charge goes undisputed is that the statement sat unread until the window closed. It needs nothing from the kitchen and disrupts no service.
Stage the rest honestly. Certify the two marketplaces carrying most of your volume rather than four. Scope the component catalogue to the twenty or thirty ingredients that actually cause an item to go down mid service, usually proteins, prepped sauces and anything fried to order, and let your own staff extend the long tail. Roll hardware into one kitchen first, because proving station routing in your busiest site costs a fraction of proving it in four at once. And take vendor invoice extraction before forecasting, since forecasting built on guessed component costs produces confident numbers that are wrong.
Which should you choose, by operator size and stage?
One to three kitchens, four brands or fewer, under 250 orders a day, stable menus: buy. Otter, Deliverect or ItsaCheckmate with Toast or Square, and put the savings into demand. Nothing else on this page applies yet.
Anyone whose constraint is orders rather than throughput: buy, at any size. Efficiency software applied to an underused kitchen is the most expensive way to solve the wrong problem.
Four to eight brand by channel by location combinations: buy, then measure two numbers. Hours a week spent updating menus across portals, and the total of undisputed error charges in your last twelve months of payout statements. If those two together are small, keep configuring what you own.
Past eight combinations, or with someone spending more than a day a week on reconciliation and menus: build the layer, starting with payout reconciliation and the component model. Keep the register and the marketplaces exactly where they are.
Operators licensing brands into third party kitchens: build, and put multi tenant separation into the architecture from the first commit. Per licensee reporting and data separation are structural decisions rather than a screen, and retrofitting them costs more than doing it once.
Operators whose direct channel is past a fifth of volume: build the direct channel, but build it last. Payments, address handling, refunds, promotions and courier dispatch are a product of their own, they depend on nothing else in the platform, and they carry the most product decisions.
When the shortlist is down to two and you need a tiebreaker, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. Nothing about that commits you to the build.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Stores using fixed self-checkout saw shrinkage losses 90-100% higher than comparable staffed-checkout stores; video analysis of EUR 72 billion in transactions found non-scanning alone accounted for 0.44% of self-checkout sales, roughly 9.5% of all recorded store shrinkage. Source: ECR Retail Loss (research led by Prof. Adrian Beck / University of Leicester) (2022) →
- The average documented online shopping cart abandonment rate is 70.22% (based on 50 studies), and large ecommerce sites can achieve a 35.26% increase in conversion rate through better checkout design. Source: Baymard Institute (2024) →
- Companies in the top quartile of McKinsey's Developer Velocity Index had 2014-18 revenue growth four to five times faster than bottom-quartile peers, showing that software-building capability is a driver of business performance, not just a support function. Source: McKinsey & Company (2020) →
- Per the Standish Group CHAOS 2020 report (reviewed at this URL), across tens of thousands of software projects roughly 31% end successfully, about 50% are 'challenged', and roughly 19% fail outright; small projects succeed far more often than large ones, and Agile approaches succeed at markedly higher rates than Waterfall. Source: The Standish Group (2020) →
Frequently asked questions
What does it cost to migrate off Otter or Deliverect without going dark?
The migration itself is cheaper than operators expect, because menus and item mappings export well enough to seed a new system. The cost is in parallel running and attention rather than in engineering.
Run both systems side by side and cut over one channel at a time, starting with your lowest volume marketplace on one location. Budget three to five weeks of overlap, use a divergence checker to catch drift between your source of truth and what is live on each channel, and cut over during a slow daypart, never at 11:30 on a Friday.
What happens if a marketplace changes its commission plan or its interface?
Commission changes are a commercial event you cannot engineer around, and any tool that claims otherwise is decorating. What a build changes is that you can see the effect at order level and per brand the same week rather than discovering it in a quarterly review.
Interface changes are the operational risk. Marketplaces add fields and deprecate endpoints on their own schedule, so a retainer that owns those breakages is not optional here. A menu push that silently stops working costs you a channel during peak, which is why the divergence checker earns its place.
How long does a ghost kitchen build take to go live?
Twelve to sixteen weeks for a first release, and the pacing item is marketplace partner approval rather than engineering. File those applications in week one, before code, because their review runs on their calendar and money does not compress it.
The pattern that works is certifying the two marketplaces carrying most of your volume first and adding the third in phase two once the team knows the process. Hardware install lands in the final fortnight, in one kitchen, during a slow daypart.
Can Otter or Deliverect 86 an ingredient across every brand and channel?
Not in the way you need, and this is the clearest functional line between buying and building. Both will push a snooze for the exact item you name, across channels, quickly and reliably. Neither knows that two items on two different brands share a braised protein, because there is no recipe layer and therefore no dependency graph.
So when one component runs out mid service, a human holds the graph in their head and toggles listings across four portals. A build maps items to a bill of materials and makes that one event, which is the difference between four refunds and none.
Do we have to replace Toast or Square to do this?
No, and you should not. The register, tax handling and payment rails stay where they are, and the custom layer reads and writes through the partner interface. Budget around $14,000 for that integration plus a divergence checker.
Keeping cardholder data inside a payment provider's hosted fields also keeps your compliance scope small, which matters most if you later add a direct order channel. A developer who says they will just use a payment provider without explaining how card data stays out of your systems has not thought it through.
Which part of a build pays back first?
Payout reconciliation, and it is the least interesting thing in the project. Ingesting every payout report, matching each line to the order in your system and flagging variances against your contracted commission rate recovers money inside the first month, because the usual reason an error charge goes undisputed is that the statement sat unread until the window closed.
Station routing pays back second and larger, though it takes a few weeks for the line to trust the screen. Forecasting pays back last and only once component costs come from real invoices rather than estimates.
How much of the budget is hardware rather than software?
On a four kitchen rollout, around $17,000 for ruggedised screens, label printers, mounts, network work and installation. That is a small share of a full platform and a meaningful share of a first release, which is why it belongs in the estimate rather than in a surprise a fortnight before go live.
It also recurs. Screens live in a hot, greasy room and get touched with gloves thousands of times a week, and label printers fail. Budget a replacement cycle per site rather than treating the original install as one off.
Who owns the code and the marketplace partner credentials?
You should own the source code, the infrastructure accounts and the marketplace partner relationships, with the repository in your organisation from the first commit. At Digital Heroes that is standard rather than a priced extra.
Be particularly careful about the partner credentials in this category. If a developer holds the DoorDash or Uber Eats partner relationship rather than you, leaving them is functionally impossible regardless of what the code ownership clause says, because the integration stops working the day the relationship ends.
We run multiple restaurant locations on Toast. Would switching to a custom POS actually save money?
Usually only at 8 or more locations, where per-terminal software fees, add-on modules like online ordering and loyalty, and processing markup commonly total $8,000 to $20,000 per location per year in the statements Digital Heroes reviews for restaurant groups. A custom system converts that into a one-time build of $100,000 to $250,000 plus maintenance, which models out to 18 to 30 month payback for most groups. Under five locations, stay on Toast and put the money into operations.
How do I calculate whether custom software will pay for itself?
Divide the build cost by the monthly benefit, where benefit is hours saved times loaded hourly cost, plus subscription fees replaced, plus any revenue the software unlocks. Three staff saving 10 hours a week each at a $40 loaded rate is about $62,000 a year, which pays back a $60,000 build in roughly 12 months. Across Digital Heroes internal-tool projects, 12 to 24 months is the normal payback range, and anything projecting under 6 months usually means the spreadsheet is hiding costs.
How many people should be working on my software project?
Three to five for a typical focused build: a project lead, one or two engineers, a designer, and part-time QA, which is the standard shape across 2,000+ Digital Heroes projects. Larger platforms justify 6 to 10, but a ten-person team on a small first version usually signals bill padding rather than horsepower. What predicts success is whether a senior engineer is writing your code daily, not the headcount on the proposal.
How do I vet a development agency for a POS project specifically?
Ask to see a live POS or payments product they built, then ask exactly how they handled offline mode, receipt printing, and PCI scope, because those three areas expose anyone who has only built ordinary web apps. A competent agency will name the payment SDKs they used, such as Stripe Terminal or Adyen, and describe their terminal certification process without checking notes. If the portfolio is all marketing sites and dashboards, keep looking.
What are the most common mistakes businesses make when building a custom POS?
The top three Digital Heroes sees: treating offline mode as a later feature when it must shape the architecture from day one, rebuilding payment processing instead of integrating a certified provider, and copying every Square feature instead of the 15 workflows staff actually use. A fourth is skipping real hardware testing, since receipt printers and barcode scanners fail in ways emulators never show. Each of these is cheap to avoid in week one and expensive to fix in month six.
What questions should I ask a development agency on the first call?
Ask who exactly will build it, what happens when scope changes mid-project, what their maintenance terms are after launch, and what they will need from you every week. Then ask them to describe a project that went wrong and what they changed afterward; teams that have shipped at real volume have war stories, and teams claiming a perfect record are hiding something. The scope-change answer matters most: a disciplined shop describes a written change-order process, not a vague promise to be flexible.
Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?
Yes, and connecting your existing tools is one of the main reasons to build custom: mainstream platforms like QuickBooks, Stripe, Shopify, and Google Workspace all publish documented APIs. Budget 1 to 3 weeks of work per integration depending on API quality and how much data flows in both directions. Ask any vendor whether they have integrated with your specific tools before, because quirks like QuickBooks' OAuth token handling and API rate limits get learned on someone's project, and it should not be yours.
How long does it take to build a custom web or mobile app from scratch?
Plan on 8 to 16 weeks for a focused first version and 4 to 9 months for a larger platform, which is the typical spread across Digital Heroes builds. The first 2 to 3 weeks go to discovery and design before any production code ships. The two things that stretch timelines most are integrations with legacy systems and slow feedback from your side, not developer speed.
Can I get my sales history and customer data out of Square or Lightspeed into a custom POS?
Yes. Square and Lightspeed both provide exports and APIs covering transactions, catalog, customers, and inventory, and migrating them is a standard 2 to 4 week workstream inside a POS build. The usual gaps are stored card tokens, which cannot leave the original processor without a formal token migration request, and gift card balances, which need careful reconciliation. Plan to run both systems in parallel for one or two weeks during cutover.
What happens to a custom POS when the internet goes down?
A properly built POS keeps ringing sales offline: orders, catalog, and pricing live in a local database on the register, and completed transactions queue and sync once the connection returns. Card payments are the real constraint; certain certified terminals support store-and-forward offline card acceptance with a per-transaction risk limit you set, and cash always works. Confirm your agency designs offline-first from day one, because bolting it on later means rewriting the data layer.
Should I use a freelancer or an agency to build my POS system?
A POS build needs backend, client app, payments integration, and hardware testing skills running at the same time, which is more surface area than one freelancer reliably covers. Freelancers make sense for narrow additions, like a reporting module on an existing system, at typical rates of $30 to $90 per hour. For a ground-up build, an agency with a dedicated QA function is the safer choice because a register failure stops your revenue at the counter in real time.
Who owns the code when an agency builds my software?
You should, completely, through a written intellectual property assignment that transfers everything on final payment; without that clause, copyright stays with whoever wrote the code by default. Insist that the repository lives in your own GitHub organization from day one and that hosting, domains, and third-party accounts are registered to you. Also check for licenses to the agency's proprietary frameworks buried in the contract, because those can make switching vendors practically impossible even when you own your own code.
Who can build a custom POS software system?
Digital Heroes builds custom POS software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other POS software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
More from Saanvi.
Senior Shopify Engineer · B2B · Delhi · 1 post on the site
Published · Last updated .
