- Choose a POS developer on how well they understand your selling workflow, not on a feature list or the lowest quote.
- Ask exactly how the system keeps selling without internet and how sales sync back without duplicates or lost stock.
- A good POS partner keeps card data out of your systems by using a payment provider's terminals or tokenised payments.
- Get the source code, accounts and data ownership in writing, plus a support plan for the busy days when the POS cannot stop.
How do you choose the right POS software development company?
Choose the company that understands how your business sells, can show how its system keeps working offline, keeps card data out of your systems through a payment provider, integrates with your stock and accounting tools, and puts code and data ownership in writing. A point of sale system runs every sale you make, so a weak build costs you at the counter, not just in the budget. Feature lists look alike from company to company. The questions below show which ones have actually built and supported POS systems in real shops.
We build custom systems through our POS software development service, and these are the questions we would want a client to ask us.
Have you decided that custom is the right route?
Before choosing a developer, be sure a custom build is the right answer. Off-the-shelf POS products suit many shops well. Custom makes sense when your pricing, stock, branches or online store do not fit the standard tools. Our comparison of custom POS and off-the-shelf POS covers that decision. If you are still unsure, a good development company will tell you honestly when an existing product would serve you better.
Do they start with your workflow?
The first meetings should be about how you sell, not about technology. Expect questions such as:
- How does a typical sale run at the busiest hour, step by step?
- How do discounts, returns, exchanges and voids work today, and who can approve them?
- How does stock arrive, move between locations and get counted?
- What does the end-of-day cash-up look like, and which reports do managers use?
- For restaurants: tables, courses, modifiers, kitchen tickets and split bills.
A company that skips this and jumps to screens and prices will build a system that looks good in a demo and slows your staff down. Our guide to restaurant POS features shows the level of detail that discovery should reach.
How will it keep selling without internet?
Internet connections drop. Ask the company to explain, in plain words, what happens at the till when they do:
- Which actions still work offline: sales, receipts, returns, stock lookups?
- Where are offline sales stored, and how are they protected if the device restarts?
- How do they sync back without creating duplicate orders?
- What happens if two tills sell the last item while offline?
- How are card payments handled when the connection is down?
Clear, specific answers are a strong sign of real experience. Vague answers are a warning. Our article on planning offline mode for a POS app explains the techniques to listen for.
How will they handle card payments and PCI DSS?
Card payments carry security rules under PCI DSS, the standard set by the PCI Security Standards Council. The safest design for most businesses is to keep raw card numbers out of your POS entirely. Card data stays with your payment provider's certified terminals or tokenised payment tools, and your system only receives a payment result and a reference.
Ask the company which payment providers and terminals they have integrated with, how refunds and partial payments work, and how they will keep your PCI scope small. If a company suggests storing or handling full card numbers in its own code, treat that as a serious red flag. Our guide to PCI DSS for a custom POS explains what a good payment design looks like.
Which hardware will it support?
- Receipt printers and kitchen printers
- Barcode scanners and label printers
- Cash drawers and customer-facing displays
- Scales, for shops that sell by weight
- The tablets, terminals or PCs you already own
Ask which devices they have tested with, and whether they will test on your actual hardware before launch. Hardware problems on opening day are among the most stressful failures a shop can have.
How will it connect to your other systems?
A POS rarely works alone. It may need to share stock with an online store, send sales to accounting software, feed a loyalty program or report into a central dashboard. Ask how each integration works, which system owns the stock count, and how errors are caught and fixed. If you sell online too, our guide to syncing a POS with Shopify or WooCommerce covers the common traps.
Who will own the code, accounts and data?
| Item | What to ask for |
|---|---|
| Source code | A repository in your own account, with access from day one |
| Hosting and databases | Accounts in your name, or a clear handover plan |
| App store listings | Published under your developer accounts |
| Payment provider | Your merchant account, not the developer's |
| Data | Export of sales, products and customers at any time |
| Documentation | Setup, deployment and admin guides at handover |
How will they test it before it goes live?
Ask for a test plan that covers your real scenarios: a rush hour with several tills, returns across locations, offline sales syncing back, printer jams and end-of-day reports. The best rollouts start in one shop or one till, run alongside the old system for a short period, then expand once staff are confident. Staff training and simple written guides should be part of the plan, not an afterthought.
What support will you get after launch?
A POS cannot wait until Monday when it fails on a Saturday. Ask about support hours, response times for urgent issues, how updates are tested and rolled out, and what a support plan costs each month. Ask, too, how they handle updates to operating systems, browsers and payment provider APIs, because these change whether or not your business does.
Which red flags should make you walk away?
- No questions about your workflow before giving a price.
- Vague answers about offline mode and syncing.
- Plans to handle raw card data in their own code.
- Code, hosting or app accounts kept in the developer's name.
- One large fixed price for a scope that has not been written down.
- No examples of systems they have built or supported in real use.
When you are ready to talk, our custom software team starts every POS project with a workflow map and a written scope, and our mobile app team builds the tablet and handheld side when you need it.
Frequently asked questions
How long does it take to build a custom POS?
It depends on the scope. A focused checkout with inventory for one shop is a much smaller project than a multi-location system with kitchen screens, loyalty and ecommerce sync. A good company will split the work into phases, quote each one in writing and get a usable first version into a real shop before building the rest.
Should a POS run in the browser, on tablets or as a desktop app?
Each works. Browser-based POS systems are easy to update and run on most hardware, tablet apps suit table service and moving around a shop floor, and desktop apps can integrate closely with printers and scanners. Ask the company to recommend one based on your devices, hardware and offline needs, and to explain the trade-offs.
Who should supply the card terminals?
Usually your payment provider. Using the provider's certified terminals keeps card data inside their systems, which reduces your security and compliance work. Your POS company should integrate with those terminals rather than building its own card handling, and should name the providers it has integrated with before.
What happens if the development company disappears?
That is why ownership matters. If you hold the source code repository, the hosting and app store accounts, the domain and the documentation, another team can take over. Without them, you may be stuck. Put ownership, handover documents and access to every account in the contract before work starts.
Is a fixed price or hourly contract better for a POS project?
A fixed price per phase works well once the scope is written down, because you know the cost of each step. Hourly or retainer work suits ongoing changes after launch. Avoid one fixed price for a vague, large scope: it usually leads to disputes about what was included.
Last updated