Duty Free and Travel Retail Software: Extend Oracle Retail Xstore, or Build the Regulated Layer?
Jurisdiction count decides this, and one is the number.
On this page
Jurisdiction count decides this, and one is the number. A single small border or ferry shop with a narrow range and simple eligibility should extend a packaged till and keep a disciplined workbook, because the compliance surface is small enough that proportionate manual control is correct and a six figure build is not defensible. Past one jurisdiction, or once you hold bonded and duty paid stock of the same product in the same store, build the regulated layer and keep the till. Note the shape of that answer: it is buy the point of sale (POS), build eligibility and bonded accounting on top.
When is off the shelf genuinely the right call here?
If you run one small border or ferry shop with a narrow product range and simple eligibility rules, extend a packaged till and keep a disciplined workbook. The compliance surface is small enough that proportionate manual control is the correct answer, the volume of transactions a person can review is real, and a six figure build against that operation is not defensible. Say no to it and spend the money on stock.
If you are opening in a jurisdiction where a mature retail platform is already widely used and supported, buy it and extend. Oracle Retail Xstore is a capable enterprise point of sale with genuine depth in transaction handling, promotions and store operations. Cegid Retail is similarly strong with good international localisation. Neither is a bad choice and both belong in a travel retail estate. Whatever else you decide, you should almost certainly keep one of them.
Buy and stop, too, if your problem is really a configuration and process problem. If the till can hold a destination rule and nobody maintains it, that is a head office ownership question rather than a software gap. A second system beside a stale rule set gets you two versions of the truth and cashiers who trust neither.
The test that settles it: can you produce your bonded position from system records, without the workbook, and have it agree with what you declared last period? While the answer is yes, you have not outgrown what you can buy.
When does a custom build actually pay off?
The build case in travel retail is regulatory rather than commercial, and the signals are specific.
You operate in more than one jurisdiction, so no single platform configuration covers your rules. Each regime brings its own customs treatment, its own declaration format and its own allowance structure, and the second country is close to a second project rather than an increment. You have had a customs discrepancy you could not explain from system records, which is the clearest signal there is that your bonded ledger is a workbook rather than evidence. Your concession fee declaration is assembled by hand and your landlord has audit rights over the figure. You hold bonded and duty paid stock of the same product in the same store, so every movement needs a treatment rather than a quantity. Or your allowance rules change faster than your platform partner can deliver a change.
That last one is the deciding fact for many operators and it is worth being precise about. It is not a feature gap. It is a change lead time. When a destination rule shifts with two weeks of notice and your extension sits in a partner's release queue, the gap between the rule changing and your till reflecting it is sales you should not have made.
The structural reason is that two of the three core objects in this business are legal rather than commercial. Bonded stock is inventory the state has a claim on until a taxable event occurs. Eligibility is a decision made in four seconds at a counter that must be defensible months later. Neither can be approximated.
How do they compare on the things that matter in this industry?
- Rules as data. A platform extension holds rules as configuration inside the vendor's model, changed on the vendor's terms. Dated eligibility rules by origin and destination, editable by your head office with an effective date, is a design decision you make once and it is the whole argument for owning the layer.
- Bonded ledger integrity. If a movement can be edited, the ledger is not evidence. Append only with reversing entries and a visible reason on every adjustment is a specific requirement that general retail inventory modules are not built around.
- Connecting passengers. Treating a boarding pass barcode destination as final sells goods that should not have been sold. Handling a connection to a third country is a rules problem specific to your terminals, not a feature on a product roadmap.
- Offline behaviour. A till that stops trading when the network drops during a departure bank gets bypassed, and bypassed tills are how bonded stock goes missing. Offline eligibility decisioning with deterministic reconciliation is architecture, not a setting.
- Concession reporting. Fee calculation traceable down to transaction level, on a figure your landlord can audit, is not something a general retail reporting module produces. It is assembled by hand almost everywhere.
- Change lead time. Who is permitted to change a rule, and how fast, is the practical comparison. Ask a platform partner directly and use their answer.
What does total cost of ownership look like at your scale?
In Digital Heroes delivery experience a focused first release runs $110,000 to $240,000 and ships in 16 to 24 weeks. That covers boarding pass validation, an eligibility engine holding dated rules by origin and destination, and a bonded stock ledger that reconciles to your customs record. A full platform adding multi currency tender and cash office, concession fee calculation and declaration, transfers between bonded and duty paid stock, pre order and collection, and loyalty across a travel estate runs $280,000 to $750,000 phased over 10 to 18 months.
Jurisdiction count is the single largest multiplier. If you operate across a land border, a cruise terminal and an airport, treat those as three regimes until proven otherwise. Whether you build a till or a layer is the second, and it is the decision that keeps a first release inside the lower band. Offline tolerance is third and it is not optional in a terminal. Hardware is fourth: scanners that read a phone screen at six in the morning under poor lighting, sealed tamper evident bag printers and label printers each carry integration and testing time that proposals routinely omit.
On a $182,000 release, plan 15 to 25 per cent of build value per year, so roughly $27,000 to $46,000, and remember your retail platform licence continues because you are keeping it. Add hardware refresh on a predictable cycle, point of sale integration verification before each peak travel period rather than during one, and head office time maintaining the dated rule records. If the design is right, that last item is administrative rather than development cost, which is the entire argument for treating rules as data.
What does the hybrid look like, and when is it the honest answer?
In travel retail the hybrid is not a compromise, it is the recommendation for almost everyone above one shop. Keep Oracle Retail Xstore or Cegid Retail for transactions, promotions, cash office and store operations. Build eligibility, bonded stock accounting and concession reporting as your own system alongside it.
That split works because the boundaries are clean and the economics are obvious. Rebuilding the point of sale means taking on payment terminal certification, receipt printers, cash drawers and shift reconciliation, all of which are solved problems you would be re solving at considerable expense. None of them is the reason you started looking. The reason you started looking is that a spreadsheet holds your bonded position and a person assembles your concession declaration.
The smallest useful version of the hybrid is the eligibility engine and the bonded ledger, without concession reporting, pre order or loyalty. That is the bottom of the first band. Put a working eligibility decision in front of cashiers early, because the plain instruction they see on screen is the difference between a rule engine that gets used and one that gets overridden by a queue of forty passengers.
Concession fee calculation is usually the highest value second module, because it converts a hand assembled declaration into a query with a trail down to transaction level, on a figure your landlord has audit rights over.
Which should you choose, by operator size and stage?
One small border or ferry shop, narrow range, one jurisdiction: buy and extend a packaged till, keep a disciplined workbook, and revisit this only if you add a second regime.
Single airport store, one jurisdiction, reconciling bonded stock in a spreadsheet: build the bonded ledger alone, nothing else. It is the smallest piece here and it addresses the exposure that actually keeps people awake, which is a customs discrepancy you cannot explain from system records.
Multi store, one jurisdiction: build the eligibility engine and the bonded ledger together on top of your existing platform. One regime keeps you inside the lower band and you get the operational benefit without the multiplier.
Two or more jurisdictions: build the regulated layer properly and phase by regime. Do the first jurisdiction end to end, run two full declaration periods in parallel with the old method, and only then add the second. Compressing that parallel run is the most common scheduling mistake in this category and the ledger only proves itself against a declaration you already made.
Cruise and border operations: build, and design for connectivity failure from the first line of code. Rules can change by port, connectivity is worse than in an airport, and retrofitting offline behaviour later is close to a rewrite.
Anyone with landlord audit rights over a hand assembled concession figure: build the fee calculation regardless of size. Over declaring quietly inflates rent for years. Under declaring becomes a commercial dispute with the party who controls your presence in the terminal. Both are avoidable and neither is visible from a spreadsheet.
When you are ready to turn this into a specification, Digital Heroes has delivered more than 2,000 projects with a named team you can speak to before you sign, rather than a bench you meet in month two. The document is yours whichever way you go.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- 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) →
- Vendor case material reports that tableside/handheld mobile POS transmits orders directly to the kitchen and improves table turnover, with a hotel client example citing a 30% increase in table turns from faster handheld payment and service - illustrating the transaction-speed-to-revenue link in restaurant POS (qualitative vendor claim, not independent research). Source: NCR Voyix (2024) →
- 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) →
- Per Sensor Tower's State of Mobile 2026, worldwide consumers spent about $85 billion on apps in 2025 (up 21% YoY), and for the first time non-game apps surpassed games in consumer spending; generative-AI in-app purchase revenue more than tripled to top $5 billion. Source: Sensor Tower (via TechCrunch) (2026) →
Frequently asked questions
What does it cost to switch retail platforms later if we build a layer?
Much less than switching cold, because the layer already holds the parts that are hardest to migrate. Eligibility rules, bonded movement history and concession calculations sit in your own store, so a platform change becomes a till and integration project rather than a compliance rebuild.
Budget the integration work per platform, since the interfaces differ, and expect verification against a full declaration period before you rely on the new pairing. Most operators who build the layer keep their platform for years afterwards.
What happens if our platform partner reprices extensions or change requests?
In this category the extensions are usually the expensive part rather than the base licence, so model those separately when you compare. Ask what a destination rule change costs and how long it takes, in writing, before you renew.
Owning the eligibility engine changes that conversation permanently. A repricing becomes a commercial decision about transactions and store operations, not a decision about whether you can respond to a customs change with two weeks of notice.
How long does the first release take before we can trust the bonded ledger?
Sixteen to twenty four weeks to build, plus two full declaration periods running in parallel with your existing workbook before cutover, in our delivery experience.
Do not compress the parallel run. It is the schedule item most often squeezed and the one that should not be, because the ledger only proves itself against a declaration you have already made by the old method and can compare against line by line.
Is Oracle Retail Xstore enough on its own for a duty free estate?
For transactions, promotions, cash office and store operations, yes, and you should keep it. It is a mature enterprise point of sale and rebuilding that capability would be an expensive way to arrive back where you started.
What it does not give you is dated eligibility rules you can change yourself with an effective date, an append only bonded ledger that stands as evidence, and a concession fee calculation traceable to transaction level. Those are the layer, and they are what you build.
Should we ever rebuild the point of sale itself?
Almost never as a first move. Taking on the till means payment terminal certification, receipt printers, cash drawers, shift reconciliation and hardware drivers, and each of those is a solved problem with no compliance benefit attached.
It moves a first release out of the $110,000 to $240,000 band and into a materially larger programme, and it delays the eligibility and bonded work that motivated the project. Keep the till, build the regulated layer.
How do we handle a passenger connecting through to a third country?
Treat the final destination as the eligibility input rather than the barcode destination on the boarding pass. If a system takes the scanned segment as final, it will authorise sales that should not have been made, and the discovery point is an audit rather than a bug report.
Ask any developer this question before signing. The answer tells you immediately whether they have worked in travel retail or whether they see a boarding pass as a barcode with a city code in it.
What happens when the terminal loses connectivity during a departure bank?
The till has to keep trading, and eligibility has to keep deciding, with deterministic reconciliation once the network returns. This is an architecture decision taken at the start rather than a feature added later, and retrofitting it is close to a rewrite.
The operational reason matters more than the technical one. A till that stops working gets bypassed, and bypassed tills are exactly how bonded stock goes missing and how a discrepancy you cannot explain begins.
Who owns the code and the bonded records if an agency builds this?
You should own the repository, the infrastructure accounts and the right to hire anyone else, settled in writing before kickoff. At Digital Heroes the client owns the code from the first commit.
It matters especially here because regulatory change arrives with weeks of notice. If responding means waiting in a supplier's release queue, you have rebuilt the constraint you were trying to remove, and your bonded records are sitting in someone else's tenancy while you do it.
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.
What does it cost to maintain a custom POS after it launches?
Budget 15 to 20 percent of the original build cost per year, so a $100,000 system runs $15,000 to $20,000 annually for hosting, OS and payment SDK updates, security patches, and small feature changes. Digital Heroes structures this as a monthly retainer for most POS clients, commonly $1,000 to $3,000 depending on location count. For multi-location operators that figure usually still undercuts the per-terminal subscription fees they were paying before.
What should I have ready before I contact an agency about building a POS?
Bring three things: a written list of your 10 to 15 must-have workflows (returns, split payments, voids, shift close), your last three months of processing statements, and every system the POS must talk to, such as QuickBooks, your loyalty program, or a kitchen display. Agencies quote against unknowns, and this preparation tightens estimates by 20 to 30 percent in Digital Heroes scoping calls. You do not need wireframes or a technical spec; producing those is the agency's job.
Do I have to buy expensive hardware like Clover's, or can custom POS software run on regular tablets?
Custom POS software can run on off-the-shelf iPads or Android tablets costing $200 to $500, versus Clover stations that list between roughly $799 and $1,799 each before monthly software fees. The one piece you should not improvise is the card reader; use a certified terminal from your processor, such as a Stripe Terminal or Adyen device, paired to your app. That combination keeps hardware costs low without your software ever touching raw card data.
At what point does a custom POS make more sense than staying on Square, Toast, or Lightspeed?
The crossover usually arrives when your combined subscription and processing costs pass roughly $30,000 to $40,000 a year, or when a workflow you depend on simply does not exist off the shelf. A 10-location restaurant on Toast's published $69 per month plan, plus device fees, add-on modules, and processing markup, often clears that bar; a single cafe on Square's free plan or a boutique on Lightspeed Retail at $89 per month almost never does. Custom also wins when the POS is your product, for example if you plan to license it to other operators.
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.
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.
What tech stack should a custom POS be built on?
Choose the stack around one requirement: the register keeps selling when the internet drops. That points to a local-first client, commonly Flutter or React Native on tablets or Electron on desktop registers, with an embedded SQLite database and background sync to a cloud backend in Node.js or Python on PostgreSQL. Payment SDKs narrow the choice further, so confirm your processor, for example Stripe Terminal, officially supports your target platform before committing.
We run everything on spreadsheets and Airtable. How do we know it's time for custom software?
The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.
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 we launch a POS MVP first or wait for the complete system?
Launch an MVP in one location first, covering checkout, payments, receipts, basic catalog, and end-of-day reporting, which Digital Heroes typically delivers in 12 to 16 weeks at 30 to 40 percent of full project cost. Running it live for a month surfaces workflow problems, like how staff actually handle voids and returns, that no spec review catches. Loyalty, advanced analytics, and multi-location features then land in phase two, shaped by real transactions.
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 Aarav.
Backend Engineer · Delhi · 1 post on the site
Published · Last updated .
