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

ReviewBoostAI

300+ paying businesses. 18 integrations. One codebase.

Sector
SaaS · Local business marketing, Australia
Role
Principal developer, 269 of 325 commits
Duration
12 months, ongoing
Year
2025–26
↓Scroll to explore showcase↓
ReviewBoost AI
SaaS · Local business marketing, Australia
TASE // 01

●METRICS

By the numbers.

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

01
0+
paying businesses
02
0+
integrations
03
0
data models
04
0
migrations
05
0
controllers
06
0 mo
and counting

01 — What it does

What it
actually does.

ReviewBoost AI is a production SaaS platform for Australian local businesses. It combines review collection, reputation management, cross-channel messaging, social publishing and business intelligence behind a single tenant-scoped account model, and it is paired with a physical NFC and QR device that sends a customer straight to the business's review page while tracking scans per card.

One operator account manages one or more physical locations. Seventeen modules sit on top of that model, every one of them tenant-scoped with role-based access for team members, so a multi-location franchise and a single-site salon run on identical code without data ever crossing between them.

We have been the principal developers for twelve months and counting: 269 of 325 commits across the Laravel application, the Node scraping sidecar, eighteen OAuth integrations, billing and the AI layer. The work spans feature delivery, production incident response, security review and performance optimisation.

ARCH
Operator dashboard: visibility health score, reputation metrics and a live review feed, all computed from synced data.
↳Operator dashboard: visibility health score, reputation metrics and a live review feed, all computed from synced data.

02 — Module surface

17
screens.

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

17 OF 17 SURFACES SHIPPED
01SURFACE

Dashboard

02SURFACE

Establishments

03SURFACE

Devices

04SURFACE

Scan Reports

05SURFACE

AI Knowledge Base

06SURFACE

Review Feed & Replies

07SURFACE

Review Requests

08SURFACE

Dispute Center

09SURFACE

Unified Inbox

10SURFACE

Post Creator & Scheduler

11SURFACE

Customer Surveys

12SURFACE

Contact Directory

13SURFACE

Business Reports

14SURFACE

SEO Content Writer

15SURFACE

Connections

16SURFACE

Subscription & Billing

17SURFACE

Account Settings

03 — Technical highlight

CORE ARCHITECTURE

A self-improving AI agent that refuses to guess

ARCH
The loop made visible: gaps to teach, taught this week, average confidence.
↳The loop made visible: gaps to teach, taught this week, average confidence.

The most interesting subsystem is a closed learning loop rather than a static chatbot. The operator supplies a website URL. A Node and Puppeteer sidecar crawls the site to depth two, roughly twelve pages. The extracted text goes to a language model under a strict tool schema and comes back as a validated JSON business profile, never as free text.

Every subsequent customer-facing reply is generated against that profile and confidence-scored. Replies that fall below the threshold are recorded as knowledge gaps instead of being guessed at. The operator answers the gap once, and that answer is injected as top-priority context on every future reply.

Refusing to guess is the decision that makes the system safe to put in front of an end customer, and it turns each correction into a compounding asset. Gaps to Teach, Taught This Week and Average Confidence are surfaced on the dashboard, so the knowledge the agent is missing becomes an actionable queue rather than a silent failure.

ARCH
The loop made visible: gaps to teach, taught this week, average confidence.
↳The loop made visible: gaps to teach, taught this week, average confidence.

04 — Architecture

SYSTEM TOPOLOGY

How it
runs.

INFRASTRUCTURE RUNTIMEPROD VERIFIED

A single host per environment. Nginx fronts PHP-FPM serving the Laravel application. A Node and TypeScript Puppeteer sidecar binds to loopback only and is never exposed to the internet, reachable exclusively by the application over 127.0.0.1. MySQL runs locally. A queue worker and a per-minute scheduler drive twenty job classes and twenty-nine commands covering review sync, publishing, reporting and credit resets.

CONSTRAINTS: 6 TOTALZERO COMPROMISE
01 / 06ENFORCED

OAuth tokens encrypted at rest

A transparent custom cast means provider credentials are never stored or logged in plaintext.

SPEC CONSTRAINT
02 / 06ENFORCED

Race-safe credit metering

AI usage runs through a ledger that takes a row lock inside a transaction, so concurrent spend across parallel requests cannot double-count.

SPEC CONSTRAINT
03 / 06ENFORCED

Config-backed integration keys

Reading env() directly in a cached context silently returns null, a production failure that is hard to trace. Keys go through config so the app survives configuration caching.

SPEC CONSTRAINT
04 / 06ENFORCED

SSRF hardening

The scraper and the Shopify domain handling are hardened, with shared-secret authentication between the application and the sidecar.

SPEC CONSTRAINT
05 / 06ENFORCED

Numeric tier gating

Plans carry a tier level, so feature checks ask whether a plan is at least Premium instead of string-matching plan codes across dozens of files.

SPEC CONSTRAINT
06 / 06ENFORCED

Formula injection neutralised

Every CSV and XLSX export sink is protected against spreadsheet formula injection.

SPEC CONSTRAINT
01 OF 06

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

22+

SERVICES

ZERO UNCHECKED SINKVERIFIED API
  • 01

    Review platforms

    5 SERVICES
    GoogleYelpTripAdvisorFacebookInstagram
  • 02

    Social and messaging

    6 SERVICES
    Facebook PagesInstagramtwo distinct OAuth flowsTwitter/XLinkedInGmailWhatsApp
  • 03

    Commerce

    3 SERVICES
    ShopifyWooCommerceWix
  • 04

    Publishing

    1 SERVICE
    WordPress via application passwords
  • 05

    Google platform

    4 SERVICES
    Business ProfileAnalytics 4Search ConsolePlaces
  • 06

    Infrastructure

    3 SERVICES
    Stripe billingSinch SMSAnthropic Claude

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 / 04RESOLVED IN PROD

A checkbox that was never broken

01 // SYMPTOM

Platform selection in the post composer did nothing when clicked.

02 // ROOT CAUSE

The checkbox toggled correctly the entire time and the selection was genuinely recorded. The selected styling was losing a CSS specificity tie: both class sets were single-class selectors, so source order in the compiled stylesheet decided the winner. The confirmation tick did un-hide on every click, but it renders white on a square that stayed white.

03 // ARCHITECTURAL FIX

Three earlier theories were tested and discarded before the markup was reproduced against the production stylesheet in a real browser and the computed styles measured. The fix removes the unselected classes on toggle instead of layering the selected ones on top. No stylesheet rebuild required.

02 / 04RESOLVED IN PROD

A framework version mismatch with a cascading effect

01 // SYMPTOM

Unconnected platform tiles were inert, navigating nowhere.

02 // ROOT CAUSE

A Blade directive introduced in a later framework major version was in use on an older release. It never compiled, so the literal text was emitted into the markup and the control was never actually disabled. A downstream JavaScript guard keyed on that disabled state never fired, so a preventDefault ran on every click and cancelled the navigation underneath.

03 // ARCHITECTURAL FIX

Verified the installed version against the lockfile rather than the range in the manifest, then swept the codebase: four further files were silently affected while appearing correct in the source. A version-appropriate conditional, plus an inline note so it is not reintroduced.

03 / 04RESOLVED IN PROD

Clearing a payment provider compromise

01 // SYMPTOM

The client's payment account was being used to issue fraudulent invoices to third parties. Did the leak originate in the codebase?

02 // ROOT CAUSE

Not the application. Every object across the full commit history on all branches was scanned for live key material: the secret key had never been committed, environment files had always been excluded, and the application contains no invoicing API calls at all, so the observed request sequence could not have originated from it.

03 // ARCHITECTURAL FIX

The codebase was cleared with evidence rather than assurance, which redirected the client's investigation to the real vector. The same history-wide sweep surfaced two unrelated credential exposures, which were rotated.

04 / 04RESOLVED IN PROD

Messages that sent on one channel but not the other

01 // SYMPTOM

Review requests arrived by email but never by SMS.

02 // ROOT CAUSE

Recipient numbers were not normalised to E.164 before being handed to the SMS provider, so the provider rejected them while the email path, which needed no such normalisation, kept working. The split failure made it look like an integration outage rather than a formatting issue.

03 // ARCHITECTURAL FIX

Normalise at the boundary, before the provider call.

01 OF 04

07 — Stack and outcome

CORE TECH TOOLKIT // 16 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.

  • Laravel
  • PHP 8.3
  • MySQL 8.4
  • Blade
  • Alpine.js
  • Tailwind CSS
  • Node 22
  • TypeScript
  • Puppeteer
  • Anthropic Claude
  • Stripe
  • Laravel Sanctum
  • TOTP 2FA
  • Sinch SMS
  • Meta Graph API
  • Google APIs
// COMMERCIAL & OPERATIONAL OUTCOME
MEASURED IMPACT

"Three hundred businesses pay for the platform today. Twelve months in, the engagement is still running: new modules, incident response and security review on the same codebase, which is the clearest evidence we have that launch is where the work starts."

Status: 100% Operational & Scaled
TASE ARCHITECTURE VERIFIED ✓
ARCH
The credit ledger surfaced to the operator: plan, remaining balance, reset date and per-action allowances.
↳The credit ledger surfaced to the operator: plan, remaining balance, reset date and per-action allowances.
←
PREV STUDYFabryka 1999 — Flores
NEXT STUDYTasedev Caller
→
NEXT PRODUCTION ENGAGEMENT

Have one
like this?