How to Build a Custom POS System

When to build a custom POS instead of using Square

Square, Toast, Clover and Shopify POS are good products, and for many businesses they are the right answer. Tepia tells prospective clients that plainly.

Other triggers are processing fees that scale with volume while your margins do not, a need to own transaction data for analytics, and a franchise model where each unit needs its own reporting under one roof. Tepia’s comparison page Square vs a custom POS system walks through that decision.

What a custom POS does not do is let you avoid the card networks. Tepia always routes payments through a certified processor SDK so you get custom software without the liability of handling card data yourself.

Eight steps to build a custom POS system

1. Document every sale type. Tepia’s Discovery phase observes registers and interviews cashiers, managers and back office staff. The Interview Summary and User Stories capture regular sales, returns, exchanges, split tenders, discounts, voids, tips and end of day close.
2. Choose hardware before design. iPad or Android tablets, countertop or handheld, card readers, receipt printers, barcode scanners, cash drawers and customer facing displays. Hardware choice constrains the SDK and the UI, so Tepia locks it early.
3. Pick the payments SDK and define PCI scope. Stripe Terminal or Square reader SDKs tokenize the card inside the reader. Your software never sees the PAN, which keeps your PCI DSS scope small and your attestation simple.
4. Tepia models this in PostgreSQL with an audit trail on every money movement.
5. Design the register for speed. Cashiers judge a POS by taps per transaction. Tepia wireframes the register screen, tests it with real cashiers and measures the common sale before sample designs are finalized.
6. Build offline first. The register must ring sales when the internet drops. Orders queue locally, card authorizations use the processor’s offline mode within its limits, and everything syncs when the connection returns.
7. Pilot one register, then one store, then roll out. Alpha on one lane with the old POS beside it, Beta across a store, then store by store rollout with hands on training and Tepia support reps on site or on call.

How Tepia approaches custom POS development

Tepia’s six phase process applies directly to POS work. Discovery typically runs 1 to 3 months and includes a system investigation of your current POS and accounting, user interviews with cashiers and managers, and a third party integration review of processors, ecommerce and loyalty tools. You receive an Investigation Summary, an Interview Summary and User Stories.

Design covers the design questionnaire, moodboards, a style guide, detailed wireframes for the register and back office, and sample designs tested with cashiers. Development and Testing runs on Alpha and Beta schedules with test plans that cover every tender type, offline scenarios, functional behavior, user acceptance on live lanes and non functional testing for speed and hardware reliability.

Training is hands on at the register using user story scenarios such as a split tender return. Full detail at tepia.co/process.

Payments, PCI and offline details that decide the project

The payments decision is the one Tepia spends the most time on. Using Stripe Terminal or the Square reader SDK means the reader encrypts the card, your app receives a token and your servers never store card data.

Offline mode has limits set by the processor: a cap on the amount and the time window before queued authorizations must sync. Tepia designs the register to show cashiers when they are offline, what the limit is and what has not yet synced, and builds reconciliation reports so the close out matches.

Accessibility applies to the customer facing display and to employees, so Tepia builds to WCAG 2.1 AA. Related reading: retail loyalty app development for the customer side of the register.

Frequently asked questions