IZAPzoo

Product and technical analysis

Turning a wish list into a scope that can be priced and built.

Solution architecture

The decisions that are expensive to reverse a year into production.

Frontend engineering

Applications that stay fast and accessible on a poor connection too.

Backend and APIs

Business logic and integrations that survive a change of requirements.

Mobile development

One codebase for iOS and Android, published in both stores.

Cloud and DevOps

Repeatable deployments and environments you can rebuild.

Database engineering

Data models and queries that don't slow down as the business grows.

The disciplines this delivery required — a list of disciplines, not of job titles.

• 01

  The server is the single source of truth for points; the mobile app calculates nothing locally and only presents backend state. That eliminates an entire class of balance-drift problems between devices.

• 02

  The QR code is purely an identifier, never a carrier of value: scanning it changes nothing on its own, because every operation is authorised by the server. Forging or copying a code therefore gives no access to points.

• 03

  Points history as an operations ledger instead of an overwritten balance: any discrepancy can be traced back to a specific transaction, which in a loyalty programme is a precondition of trust on both sides.

• 04

  The cashier screen was designed from the queue backwards, not from a feature list: first we established how many seconds and how many taps serving a customer could cost, and only then the interface layout.

• 05

  Role-based permissions from day one rather than bolted on later — and enforced in the database through Row Level Security, not in application code. Customer, cashier and administrator are subject to the same rules whether a request arrives from the mobile app, the admin panel or an integration that does not exist yet.

• 06

  One codebase in React Native and Expo instead of two separate native apps — a simpler stack and a lower cost of ownership. The loyalty programme looks the same on Android and iOS, so keeping two codebases would have meant double the work on every change and a slow drift between the platforms. On a project delivered end to end by one engineer, that is the difference between a fix shipping this week and next month.

• We limited personal data to the minimum the programme needs and designed its processing with GDPR obligations in mind, including handling account-deletion requests.
• We built authentication on Supabase Auth as a managed service: email and password sign-in, with the session proven by a JWT. We wrote no password handling of our own — in a system of this class, home-grown cryptography is a risk rather than an asset. On the phone the session sits in Expo SecureStore, storage protected by the operating system, instead of ordinary app storage. All traffic to the backend is encrypted.
• Authorisation is enforced in the database through Row Level Security rather than checked in the application. That distinction matters: the rules apply to every query that reaches the data, so skipping a check on the client side opens nothing. The mobile app, the admin panel and any future integration are subject to exactly the same rules.
• Operations that carry value — crediting points, redeeming a reward, using a voucher — run as database functions. A client asks for an operation to be performed, not for a particular number to be written, so a balance cannot be set from outside and the same voucher cannot be redeemed twice.
• The customer's loyalty code and voucher tokens are kept separate. The identifier shown at the till every day is one thing; the single-use token that entitles someone to a reward is another. Showing the first grants no access to the second.
• The Supabase service-role key never ships inside the mobile app. A binary published in a store is a public environment — whatever you put in it can eventually be read back out — so privileged access to the data stays on the server side only.
• The admin platform follows least privilege: each role sees only what it needs, sensitive operations go to an audit log, and the data is covered by regular backups.