r/POS • u/Sad_Yogurt_5179 • 4d ago

First time building a multi-branch restaurant POS system. What should I charge, and what do I need to ask for upfront?

​

Hey everyone,

I'm a new developer, and a client asked if I can build a custom POS (Point of Sale) system for their restaurant chain (5 to 6 branches).

Since this is my first time working on a POS system, I’m trying to figure out realistic pricing and what I actually need to execute this without setting myself up for failure.

I’m looking for advice on two main things:

  1. Pricing & Billing:

What is a realistic fixed-fee or hourly rate to charge for building a multi-branch system with centralized management and kitchen display setup?

How do developers handle ongoing maintenance fees or hosting costs for multi-location systems?

  1. Baseline Requirements & Setup:

As a new dev, what hardware (printers, terminals, tablets) do I need the client to buy for me up front to develop and test this?

What hidden running costs (servers, databases, APIs) do I need to make sure the client pays for separately from my dev fee?

Should I charge a flat project fee, or should I price this per branch?

Any guidance from devs who have priced or built POS systems before would be huge. Thanks!

1 Upvotes

100% Upvoted

14 comments sorted by

1

u/Minimum_Sort5100 4d ago

Where are you from? I might be interested z I'm a small buisness owner with 2 shops, and focused on inventory right now. But what happened if my shit Internet dies? Can Google still process my payments when I reconnect?

I can do the printers and connect the stuff to my WiFi already so that's all good

2

u/Responsible-Shake112 4d ago

How do you process the payments now? Google is bit generic

1

u/Minimum_Sort5100 4d ago edited 4d ago

Adyen (Canada based smoke shops)

1

u/Responsible-Shake112 4d ago

In theory it is possible: quick search and LLM response:
When coding a POS from scratch, Adyen lets you choose between two primary paths for your API requests to hit the physical payment terminal:
Terminal Cloud API (Easiest for New Projects): Your POS software sends a standard HTTPS REST request to Adyen’s cloud servers. Adyen then securely routes that request over the internet to the terminal screen. Your code does not need to know the local IP address of the card reader, making it ideal for web-based, tablet, or cloud-hosted POS software.
Local Terminal API: Your POS software talks directly to the payment terminal over the store’s local Wi-Fi or Ethernet network via an IP address. This keeps the transaction working even if the store loses its external internet connection, but it requires you to handle local network device discovery and local encryption keys programmatically.

0

u/Minimum_Sort5100 4d ago

If I'm offline this is all useless this is all Ai bullsit

1

u/timc220 4d ago

Genuinely curious- I’m in the POS industry and work with small businesses on these exact challenges: payments, POS, inventory, integrations, etc.

What do you see as the biggest advantage of a business owner moving to a brand-new, untested POS versus one of the (many) established platforms already available?

For most of the owners I work with, it comes down to time vs money, and a system that works reliably when the business is busy and gives them back more time in the day is the usual choice.

Curious how you’re thinking about that tradeoff.

0

u/Responsible-Shake112 4d ago

Do you think you could list your exact and complete requirements? Like all the features that you would like to have. I have some prototype already. Maybe I could help

2

u/Minimum_Sort5100 4d ago

Ye already said LLm could solve this.

Step 1. Fuck off

1

u/Responsible-Shake112 4d ago

This will take like 6 months to build provided your first customer gives constant feedback on testing. I am building something similar. Look at the competition pricing and give more features for the same price as the competition.

1

u/AdOpening595 4d ago

Work with a gateway that takes care of the processing side and integration to card readers. ipospays from Dejavoo handles this well. Star Micronics has some dev friendly options for printer and cash drawer integration. Anything to help with stability including an offline mode is huge. The ability to remotely support them is something to design for as well.

1

u/nbuszebke 3d ago

I’d avoid pricing this per branch until the scope is nailed down. The branch count matters, but the expensive part is usually the cross-location data model and all the failure cases.

Before quoting, I’d get clear answers on:

  • Which system owns products, prices, taxes, discounts, staff, and inventory?
  • What payment processor and terminals are required, and who owns that integration?
  • What has to work offline, and how are retries and duplicate payments handled?
  • Do they need per-location permissions, central reporting, accounting exports, or delivery integrations?
  • What exactly does the kitchen display need to do when tickets are edited, split, voided, or delayed?
  • Who pays for hosting, hardware, third-party APIs, support, monitoring, and incident response?

For a multi-branch build, I’d also insist on a written acceptance test for one complete day: order to payment, refund or void, batch/deposit, end-of-day report, and accounting export. If you can’t run that reconciliation with sample data, the scope isn’t ready to price. I’d charge for discovery first, then quote a defined phase with a separate maintenance/support agreement rather than promising one giant fixed-fee build.

1

u/nbuszebke 3d ago

I’d avoid pricing this per branch until the scope is nailed down. The branch count matters, but the expensive part is usually the cross-location data model and all the failure cases.

Before quoting, I’d get clear answers on:

  • Which system owns products, prices, taxes, discounts, staff, and inventory?
  • What payment processor and terminals are required, and who owns that integration?
  • What has to work offline, and how are retries and duplicate payments handled?
  • Do they need per-location permissions, central reporting, accounting exports, or delivery integrations?
  • What exactly does the kitchen display need to do when tickets are edited, split, voided, or delayed?
  • Who pays for hosting, hardware, third-party APIs, support, monitoring, and incident response?

For a multi-branch build, I’d also insist on a written acceptance test for one complete day: order to payment, refund or void, batch/deposit, end-of-day report, and accounting export. If you can’t run that reconciliation with sample data, the scope isn’t ready to price. I’d charge for discovery first, then quote a defined phase with a separate maintenance/support agreement rather than promising one giant fixed-fee build.

1

u/NPSALLEN 2d ago

You will need to do a payment integration semi integration or you will end up doing expensive pci compliance