TASE Logo
Case study 06 / 20
←All Work
TASE ARCHITECTURE

Repulabs

QR at the counter to review online, measured per unit, per day.

Sector
Local business SaaS + hardware, Australia
Role
Sole engineer, end to end
Duration
14 weeks
Year
2026
↓Scroll to explore showcase↓
Repulabs
Local business SaaS + hardware, Australia
TASE // 06

●METRICS

By the numbers.

Production telemetry, active capacity, and engineering scale measured in live deployment.

01
0
routes
02
0,067
tests
03
0
data models
04
0
integration adapters
05
0
scheduled jobs
06
0 wk
build

01 — What it does


What it
does.

Repulabs serves Australian local and multi-location businesses that depend on public reviews for new custom. It closes a gap most reputation tools leave open: software alone can only reach a customer once the visit has ended, by which time intent has decayed. Repulabs pairs the application with printed QR stands, plaques and NFC cards placed at the point of service, so the ask happens while the customer is still present.

Every scan is recorded, which yields what software-only competitors cannot produce: measured scan-to-review conversion per unit, per location, per day. Revenue comes from subscriptions billed per location, with hardware sales as the acquisition channel into them.

Tenancy is not enforced in application code. Every tenant query runs in a transaction that switches to a Postgres role without bypass rights, then sets a per-request organisation identifier that row-level security policies read. 79 tables carry an organisation column, 76 have row-level security enabled, 47 force it even for the table owner, and 77 policies are defined. A forgotten filter cannot return another tenant's rows, because the database will not hand them over.

ARCH
The AI behaviour surface: voice, complaint handling and conversation rules stored once and applied to every generated reply.
↳The AI behaviour surface: voice, complaint handling and conversation rules stored once and applied to every generated reply.

02 — Module surface


19
screens.

Every discrete surface designed, engineered, and shipped in production. Zero placeholder concepts — 100% functional software.

19 OF 19 SURFACES SHIPPED
01SURFACE

Dashboard

02SURFACE

Autopilot

03SURFACE

My Establishments

04SURFACE

My Devices

05SURFACE

AI Knowledge Base

06SURFACE

AI Phone Receptionist

07SURFACE

Review Feed

08SURFACE

Review Requests

09SURFACE

Dispute Center

10SURFACE

Unified Inbox and Meetings

11SURFACE

Post Creator

12SURFACE

Customer Surveys

13SURFACE

Contact Directory

14SURFACE

Business Reports

15SURFACE

Connections

16SURFACE

Account and Billing

17SURFACE

Onboarding

18SURFACE

Widget Embeds

19SURFACE

Admin Console

03 — Technical highlight


CORE ARCHITECTURE

Printed hardware that cannot be repointed

ARCH
The device surface: scan totals and conversion read from recorded events, with Active and Trash exposing the state machine.
↳The device surface: scan totals and conversion read from recorded events, with Active and Trash exposing the state machine.

Each unit carries a ten-character Crockford base32 slug, and the public scan endpoint is the only internet-facing surface that must stay fast and abuse-resistant while still writing analytics. On scan it applies a per-IP and per-slug rate limit, resolves the device, verifies an HMAC signature computed at activation over the slug, the destination and an expiry, emits a scan event deduplicated by a hash of slug, IP and hour bucket, then redirects.

The signature is the interesting decision. Without it, anyone able to write to the redirect column could silently repoint printed hardware already sitting on counters at destinations the business never chose. Verifying at read time means a tampered row fails closed rather than sending customers somewhere hostile.

The device also runs a real state machine: unactivated inventory, active and bound, retired into a recoverable trash, and released back to unactivated so the same physical unit can be configured again. Activation is race safe, claiming only when the row is still unactivated and unowned, so two people scanning the same stand at once cannot both bind it. The scan write is fire and forget, so analytics never delay the redirect.

ARCH
The device surface: scan totals and conversion read from recorded events, with Active and Trash exposing the state machine.
↳The device surface: scan totals and conversion read from recorded events, with Active and Trash exposing the state machine.

04 — Architecture


SYSTEM TOPOLOGY

How it
runs.

INFRASTRUCTURE RUNTIMEPROD VERIFIED

A single Node process serves the application behind a reverse proxy that terminates TLS and routes several hostnames to it. The proxy gives the public scan path and the authentication callbacks their own location blocks ahead of the generic API prefix. Asynchronous work runs as 21 scheduled jobs covering review sync, outbound dispatch, social publishing, metric refresh, knowledge-base re-crawling, SEO refresh, moderation rescanning and digests.

CONSTRAINTS: 4 TOTALZERO COMPROMISE
01 / 04ENFORCED

Row-level security as the isolation primitive

A missing WHERE clause is a routine mistake; a missing WHERE clause that leaks another tenant's data is a company-ending one. Moving the boundary into the database converts the second failure mode into the first.

SPEC CONSTRAINT
02 / 04ENFORCED

Redirect targets signed at write time, verified at read time

Printed hardware cannot be recalled or re-flashed, so the destination a unit resolves to has to be provable at the moment of the scan rather than trusted from storage.

SPEC CONSTRAINT
03 / 04ENFORCED

Telephony over plain REST

The vendor SDK is a large dependency for a handful of endpoints. Going direct keeps the dependency surface and the cold start smaller.

SPEC CONSTRAINT
04 / 04ENFORCED

Fail-soft guards on pre-migration relations

Pages degrade to an empty state when a relation does not yet exist, so a partially migrated environment renders rather than returning a server error.

SPEC CONSTRAINT
01 OF 04

05 — Integrations


ECOSYSTEM MAP

What it
talks to.

Every third-party API, external boundary, data pipeline, and payment rail hardened and operating in production.

06

GATEWAYS

26+

SERVICES

ZERO UNCHECKED SINKVERIFIED API
  • 01

    Reviews and profile

    2 SERVICES
    GoogleGoogle Business Profile
  • 02

    Point of sale

    3 SERVICES
    SquareCloverToast
  • 03

    Commerce

    3 SERVICES
    ShopifyWooCommerceWix
  • 04

    Social

    5 SERVICES
    MetaInstagramWhatsAppLinkedInTwitter
  • 05

    Email and CRM

    6 SERVICES
    GmailMailchimpKlaviyoHubSpotSalesforceZoho
  • 06

    Accounting, messaging, payments

    7 SERVICES
    QuickBooksXeroTwilioResendStripeCal.comElevenLabs

06 — Problems solved


DIAGNOSTIC LOG & ROOT CAUSE ANALYSIS

What broke,
and how we found it.

Feature lists show what was built. These post-mortems show how obscure edge cases and silent production bugs get diagnosed and permanently resolved.

01 / 03RESOLVED IN PROD

Every unit in a production run shipped with the same printed code

01 // SYMPTOM

Customers could not activate new hardware. Entering the code printed on the card returned a message saying it did not match any device.

02 // ROOT CAUSE

A supplier printed one activation code across an entire production run instead of each unit's own code. The platform had been designed correctly around the opposite assumption. The only remaining per-unit identifier was the slug inside the QR itself, and it travelled only in a query string, which survives exactly one click. A new owner's real path runs scan, interstitial, sign up, magic link, dashboard, onboarding, add a business, then activation, and every hop discards a query string.

03 // ARCHITECTURAL FIX

The scan endpoint now writes the slug into a cookie at scan time, so device identity survives the entire signup journey. A shared parser accepts a full link, a bare path or a raw slug. An override accepts the mis-printed code for a scanned unit, removable through one environment variable at the next production run, restoring strict per-unit verification with no code change.

02 / 03RESOLVED IN PROD

Sign in worked in one browser and silently failed in another

01 // SYMPTOM

Signing in with Google worked in Chrome and did nothing at all in Safari. No error appeared. Magic link sign in worked in both.

02 // ROOT CAUSE

A Content Security Policy directive restricting where a form submission may navigate. Google sign in is a form post answered with a redirect to an external authorisation endpoint. WebKit and Firefox evaluate the directive against the redirect target, Chromium validates only the form's initial target, so the same header permitted the flow in one engine and blocked it in the other.

03 // ARCHITECTURAL FIX

The authorisation endpoint was added to the directive. Dropping the restriction entirely would have removed a genuine protection to fix a single flow. Scope was verified before shipping: the account-connection flows are ordinary link navigations, which that directive never governs.

03 / 03RESOLVED IN PROD

A deleted device looked identical to a broken feature

01 // SYMPTOM

A device stopped working. Scanning it reported that the product was not activated, the devices list showed none, and the trash tab showed none either.

02 // ROOT CAUSE

Deleting a device is a soft delete that moves it to trash. With no active devices left, the page fell through to an empty state that rendered a hardcoded zero for the trash count. The device was sitting in trash, recoverable, and completely invisible, and any non-active device also reports as not activated when scanned.

03 // ARCHITECTURAL FIX

The real count is computed before the empty-state branch, and the panel links to trash and explains that a restore returns the same QR, code and redirect. Permanent deletion was rewritten too: removal now releases the unit back to unactivated inventory instead of destroying the row, so a physical product is never made permanently useless. A recovery tool rebuilds any unit destroyed under the previous behaviour from its audit record.

01 OF 03

07 — Stack and outcome


CORE TECH TOOLKIT // 17 DEPENDENCIES

Built
with.

Every dependency is chosen deliberately for raw execution speed, strict type safety, zero cold-start latency, and battle-tested reliability under high concurrent load.

  • TypeScript 5.9
  • Next.js 15.5
  • React 19
  • PostgreSQL with RLS
  • Prisma 6
  • Auth.js 5
  • Stripe
  • Anthropic SDK
  • Resend
  • Twilio REST
  • Upstash Redis
  • Zod
  • Pino
  • Sentry
  • Tailwind
  • Vitest
  • Biome
// COMMERCIAL & OPERATIONAL OUTCOME
MEASURED IMPACT

"Fourteen weeks from first commit to a platform with 218 routes, 1,067 tests, sixteen live integration adapters and a hardware line whose every scan is measured."

Status: 100% Operational & Scaled
TASE ARCHITECTURE VERIFIED ✓
ARCH
The hardware line: printed QR stands, plaques and NFC cards at the point of service.
↳The hardware line: printed QR stands, plaques and NFC cards at the point of service.
NEXT PRODUCTION ENGAGEMENT

Have one
like this?