Custom POS software in India: cost, features, and when to build your own

Custom POS software in India starts at about ₹2,50,000 for a focused system for one store, and costs more once you add branches, offline billing, varied hardware and integrations with Tally or an online store. Below: what a POS must do, the hardware it must work with, what it costs to build and run, and when a subscription is the smarter buy.

The numbers come from the software bands on our pricing page, which we quote from in Powai. They are a guide to scope, not a package. Your quote depends on what your counters and back office need on day one, which is what our custom POS development discovery work pins down.

What a POS has to do

A POS is the system that turns a sale into a bill, a stock movement and a line in your accounts, all at once. If any of those three goes wrong, someone fixes it by hand later. These are the jobs every serious POS handles, whether you build it or rent it.

GST at a high level. A registered business normally issues a tax invoice, and the CGST Rules list what it must show: your GSTIN, a serial number “unique for a financial year”, the HSN code, the taxable value, the tax rate and the tax amount, among other details (Rule 46, CGST Rules, checked October 2026). The HSN code runs to 4 or 6 digits depending on turnover, and a business with turnover up to ₹5 crore may leave it off bills to unregistered customers (Notification 78/2020-Central Tax). A business under the composition scheme issues a bill of supply instead (Section 31(3)(c), CGST Act). And if your aggregate turnover crossed ₹5 crore in any year since 2017-18, your B2B invoices must also be reported for e-invoicing (GST e-invoicing steps, checked October 2026). A POS has to get all of this right without the cashier thinking about it. Your chartered accountant confirms the rules that apply to you; the software applies them every time.

Permissions deserve more attention than they usually get. Many billing leaks are not theft. They are often a discount keyed twice, a bill voided and re-entered, or a price changed to clear a queue. A POS that asks for a manager’s PIN for voids, overrides and discounts above a limit, and logs who approved what, closes most of these gaps.

Hardware: tested, not assumed

The hardware at your counter is where POS projects most often slip. The software can be perfect and the receipt can still print garbled, the drawer can stay shut, or the scanner can type into the wrong field. The fix is simple and unglamorous: list every device, then test each one with the real software before go-live.

Three rules keep this under control:

1. Name the exact models. “A thermal printer” is not a requirement. The make, model and connection type are.
2. Test on the real units, at the counter, with your products and your paper rolls, not only on a developer’s desk.
3. Decide what happens when a device fails. If the printer jams mid-rush, can the bill be reprinted later, sent on WhatsApp or SMS, or shown as a QR code?

Card and UPI terminals depend on your bank or payment provider. Some offer a way for the POS to send the amount to the terminal and read back the result; some do not. We check this with your provider during discovery, because it changes both the cashier’s workflow and the build.

What happens when the internet drops

A POS that stops billing when the broadband fails is a liability during your busiest hour. Offline billing has to be designed in from the start, because it shapes how data is stored and synchronised.

In plain terms, each counter keeps a local copy of the products, prices and tax rates it needs. Sales are saved locally first and queued for upload. When the connection returns, the queue syncs to the central server, which applies agreed rules for conflicts, such as a price changed at head office while a branch was offline.

Two details decide whether offline billing works in practice:

• Invoice numbers. Rule 46 allows invoices “in one or multiple series”, unique for a financial year. A common design gives each counter its own series, so two counters billing offline can never issue the same number.
• Payments. Cash and the bill itself can carry on offline. Card and UPI payments run on the payment provider’s and banks’ networks, so they depend on connectivity at the terminal or on the customer’s phone. A good POS records such payments as pending until they are confirmed, rather than marking the bill paid on trust.

Offline behaviour is scoped and tested separately on every POS project, because what is acceptable for a café with one counter is not acceptable for a supermarket with eight.

Integrations: Tally, ecommerce and CRM

A POS rarely works alone. The integrations you need on day one are usually the biggest single driver of cost after branch count.

• Tally. Many Indian retailers and distributors keep their books in Tally. TallyPrime can exchange data with other software through XML over HTTP, with a default port of 9000 (TallyHelp: XML integration, checked October 2026). The work is deciding what goes across (day-wise sales summaries or every bill, how ledgers and stock items map) and what happens when Tally is closed or on another machine.
• Ecommerce. If you sell online as well, stock has to be shared between the store and the website, or you sell the same last piece twice. Shopify, WooCommerce and marketplace integrations each have their own APIs and limits.
• CRM and loyalty. Points, customer history and WhatsApp receipts tie the counter to your customer data. If you are planning a CRM as well, our guide to custom CRM cost in India covers that side.
• Payments. Integrated card and UPI terminals, payment links for orders taken on the phone, and reconciliation of settlements against bills.

Each integration needs its API or file format reviewed, the data mapped, failures handled and the whole flow tested. That is why we confirm integration scope after discovery rather than from a feature list.

What a custom POS costs

Our published software bands give a fair picture of where POS projects land. They are starting estimates, confirmed only after discovery.

What moves a project between bands:

• Number of branches and counters, and whether each must bill offline.
• Stock complexity: batches and expiry, sizes and colours, recipes for a kitchen, weighed and loose goods.
• Pricing rules: schemes, combos, member prices, branch prices, happy hours.
• Hardware variety: every additional device type is another integration and test plan.
• Data migration: moving thousands of item masters, opening stock and customer records cleanly.
• Integrations: Tally, an online store, a CRM, a payment provider.

What a first release usually leaves out matters as much as what it includes. Loyalty programmes, customer-facing apps, ecommerce stock sync, franchise billing and advanced analytics are where POS projects grow. Leaving them for a second release keeps the first one affordable and gets your counters on the new system sooner, so real use decides what is worth building next.

Hosting and third-party services, and ongoing support, are always quoted separately.

What it costs to run after launch

The build is a one-time cost. A POS also has running costs, and you should see each one as its own line:

• Hosting. A central server and database for sync and reports, with backups. Small next to staff costs for most stores, larger for chains.
• Payment fees. Card and UPI processing charges are set by your bank or payment provider and billed by them, not by us.
• Messaging. SMS or WhatsApp receipts are billed by their providers, usually per message.
• Hardware and consumables. Printers, scanners and terminals wear out, and paper rolls are a monthly cost.
• Support and change. Our software support retainers typically run ₹25,000 to ₹75,000 a month, covering bug fixes, updates and small improvements. A POS also needs a plan for urgent help when a counter stops billing in the middle of a sale.

You own the code. Full IP transfer on final payment is part of our standard engagement, so you are never tied to us for the next change.

When a subscription POS is the better choice

For many Indian shops, a subscription POS is the right answer, and we would rather say so than build something you do not need.

If you run one or two stores with standard billing, a few thousand items and no unusual integrations, start with a subscription POS. It is cheaper in year one, ready this week, and someone else handles updates and compliance changes.

A subscription is usually the better choice when:

• you have a single store or a small number of counters;
• your billing, discounts and stock work the way the tool expects;
• you need to start quickly, before a season or an opening;
• you do not have someone in the business who will own the system and its decisions.

Custom starts to make sense when:

• your stock or pricing rules do not fit: made-to-order items, rentals, weighed goods with special rules, schemes the tool cannot express;
• integrations are the point: the POS must feed Tally, an online store, a CRM or a dealer system without manual exports;
• per-counter or per-branch fees grow with every opening, and workarounds cost staff time every day;
• you want to own your data and code, and change the system on your schedule rather than a vendor’s roadmap.

A simple test is to do the three-year sum before you decide. At our starting band, a custom build plus the lowest support retainer for three years is ₹2,50,000 + (₹25,000 × 36) = ₹11,50,000, or about ₹31,944 a month. That is an illustrative floor, not a quote. Compare it with your subscription bill over the same period plus what the workarounds cost you in staff time. If the subscription side is clearly lower and the tool fits, keep the subscription.

How to get an accurate quote

The quickest route to an accurate number is evidence of how your counters run today, not a feature list from a POS brochure. Bring:

1. Branches and counters. How many, and how many people bill at each.
2. Your products. Number of items, how they are coded, and anything special: batches, expiry, sizes, weights, recipes.
3. A few real bills, including a B2B bill, a return and a discounted sale.
4. Your hardware list, with make and model for every printer, scanner, drawer and terminal.
5. Your GST position: regular or composition, and whether e-invoicing applies to you. Your CA can confirm this.
6. The systems it must talk to: Tally, an online store, a CRM, a payment provider.
7. Your worst day. What happened during your last peak, and what went wrong.

From that we write a proposal with scope, milestones and a fixed price wherever the scope allows, usually within three working days of the scoping call. Payments are split across milestones, and anything outside the agreed scope is quoted before we build it.