01 Platform

Four systems. Ours to build, ours to run.

Software we wrote, deployed and run.

A-01 to A-04 TypeScript, Next.js, React, Supabase, Postgres Operated, not demonstrated

4 Systems built here and running in use
160 TypeScript modules in the outreach engine (approximate)
13 SQL migrations behind that one schema

02 The four systems

What each one actually looks like.

ops console, dev mode on fixtures The outreach engine ops console overview screen, showing the daily run state and inbox health.

Real capture. Taken in dev mode on mock fixtures. The app says so in a banner inside the frame.

A-01

Outreach engine and ops console

Finds the lead and sends the first email within daily caps. Replies and follow-ups wait for a person to approve.

All ten screens

schematic, A-02 A-02 ANALYTICS PORTAL ONE CLIENT AT A TIME CLIENTS CLIENT 01 ROW-LEVEL SESSIONS 24,118 ENQUIRIES 311 LCP P75 1.4s TRAFFIC BY WEEK SOURCES SEARCH DIRECT REFERRAL BLOG SOCIAL

Drawn, not captured. Every route holds real client traffic behind that client's own login. Figures shown are sample values.

A-02

Client analytics portal

Your traffic, behind your own login. Separation is a database rule, not a filter in the chart.

How it is built

schematic, A-03 A-03 CLIENT PORTAL ROLE GATED PROJECT SCOPE BUILD REVIEW LIVE INVOICES INV-014PAID INV-015DUE CHANGE REQUESTS GATE ADMIN QUEUE TICKETS AND CHAT

Drawn, not captured. Live project and invoice data sits behind authentication.

A-03

Client portal and admin console

Projects, invoices, change requests and chat. One app, two sides of a role gate.

How it is built

schematic, A-04 A-04 LEAD-CAPTURE API SUCCESS ONLY IF THE ROW EXISTS FORM VALIDATE TYPED SCHEMA GATE HONEYPOT DURABLE WRITE THEN, AND ONLY THEN 200 RECORD STORED NOTIFY, THEN THANK THE SENDER 5XX NOTHING STORED RETURN A DIRECT ADDRESS, NOT A THANK YOU

Drawn, not captured. This one has no interface: it is the endpoint under the enquiry forms we build for clients.

A-04

Lead-capture API

Validate, screen, write, notify. Success only once the row exists.

How it is built

A-01 Outreach engine and ops console A daily orchestrator, a multi-inbox sender, a deliverability watchdog and a ten-screen console. Roughly 160 TypeScript modules over 13 SQL migrations. TypeScript, Postgres
A-02 Client analytics portal Per-client traffic reporting. Tenant separation is a row-level security rule in Postgres, not a filter in the component that draws the chart. Next.js 15, Supabase, Umami
A-03 Client portal and admin console Project status, change requests, invoices, tickets and chat. One application on both sides of a role gate, with route-level guards. React, Supabase
A-04 Lead-capture API Validate, gate, persist, notify. It answers success only once the row exists, and an error with a direct address when it does not. Edge, Postgres, email

All ten ops screens

03 Our own products

We ship under our own name too.

Not client work. Products Fluxaro owns, builds and runs.

Live

LoreRoad

A road-trip co-pilot. It surfaces the history, the landmarks and the strange local legends along your route exactly as you reach them, and reads them aloud so the driver never looks down. Free trip to try, then Basic or Family.

www.loreroad.com
Coming soon

Burrin

Work management for small studios. Tasks, the planner, documents and the conversation held as one record, so delivery never depends on one person remembering it. Personal space free, team spaces paid.

04 Security posture

Written down, rather than implied.

Behaviour in the code, not a certification.

  • Tenant isolationRow-level security in Postgres, so separation is a database rule rather than an application convention.
  • Choke-pointOne access function every read passes through, which keeps the isolation reviewable in a single place.
  • SecretsServer-only API wrappers. No analytics key, service key or provider token ships in a client bundle.
  • Script policyPer-request nonce-based CSP. An inline script without this request's nonce does not run.
  • Rate limitingLogin attempts limited by IP address and by email address, backed by Upstash.
  • InputZod schemas at every external boundary. Nothing untyped reaches a query.
  • Account surfaceNo public sign-up route. Accounts exist because the studio created them.
  • Auth responsesGeneric errors on failed sign-in, so the form cannot be used to discover registered addresses.
  • Model riskGenerated replies never send unattended. A person approves in a chat loop.
  • Threat mapsAn OWASP Web map, an OWASP LLM map and a security document, kept in the repository with the code.
  • Response headersHardened on the static builds as well, not only the applications. Clarity ships them.
What this is not Not SOC 2, ISO 27001, HIPAA or GxP attestation. Say early if procurement requires one and we will answer plainly.
Independent testing None has been commissioned. That is stated plainly rather than left to be inferred from the list above.
On request The security document and threat maps, under NDA during a procurement review.

05 Next

Bring us the system behind the site.

Portals, dashboards, consoles, endpoints. Tell us where the data lives and who may see it.

Request a free quote Services

admin@fluxaro.tech

A-01 Every ops capture was taken in dev mode on mock fixtures. The app says so in a banner inside the frame.
A-02 The shipped layout on synthetic data is on the analytics demo. Real client data stays behind its login.
A-03 The shipped layout on synthetic data is on the portal demo. Real project and invoice data stays behind its login.
A-04 The endpoint we ship to clients. It only answers success once the record is stored.