AQ Trading | Business Platform for a Vehicle Export Operation

Overview

A specialised vehicle export business - sourcing inventory from international auction houses and shipping to customers across multiple markets - needed to move from a spreadsheet-and-inbox operation to a real system. The engagement produced two coordinated products: an internal operations console for the team, and a customer-facing catalogue for the public.

The system is in production and used daily. Workflows that used to consume hours now take minutes.

The Business Problem

Three specific pain points drove the engagement.

Inventory chaos. Product data lived in a mix of yearly spreadsheets, shared cloud drive folders organised by nothing in particular, and the memory of whoever handled the purchase. Publishing an item to the public site meant a manual sequence of choosing photos, resizing them, writing copy in a text file, logging into a legacy CMS, uploading, and hitting publish. Adding a single item took a full working hour.

No customer trail. A message trail with customers lacked, often causing confusion. Nobody knew whether a customer had asked before, what they'd been quoted, or whether a colleague was already talking to them.

Manual document workflows. Invoices required a physical company seal - every document was printed, stamped, scanned back to PDF, and emailed. Ten invoices was half a day of work. Underneath all three was a data problem: there was no source of truth for anything.

Scope

The project delivered two web applications and one shared backend, sized for a small team handling meaningful monthly volume.

Internal operations console. Full inventory CRUD with photos and supporting documents. Customer request inbox with role-based ownership. Document generator with PDF and spreadsheet output. Content management for the public site's editorial pages. Company settings. Audit trail on every change. Role-based access control across four levels.

Public catalogue. A marketing-quality customer site with searchable inventory grid, faceted filters, per-item detail pages, homepage feature slots, editorial pages driven from the CMS, and dual customer-request paths. Designed to convert.

Shared backend. A single managed Postgres database with row-level security partitioning access. Staff see everything relevant to their role; the public sees only what's explicitly published. The database itself enforces these rules, so the applications above cannot leak data even if their code has a bug.

Not in scope: shipping tracking (handled externally), accounting integration (their bookkeeper's tools), or a native mobile app (the console is fully responsive).

Architecture

The system is intentionally small: two applications, one backend, a handful of managed services. Everything above the database is stateless, so scaling and recovery are trivial.

The database is deliberately the crossroads. Neither application knows the other exists; they only see the data and permissions they're allowed to see. This gives the security posture of a microservice split without the operational cost.

Both applications are server-rendered on modern React infrastructure, with data-mutation operations running as server-side actions that automatically refresh the affected pages. There is no separate API layer - the applications and the database are the whole stack.

Content management

The public site's editorial content - the About page, team roster, mission statement, feature stories - used to require a developer request. Now it's editable from the internal console by non-technical staff.

An admin edits the content, hits save, and the public site reflects changes within a minute. The image pipeline re-encodes uploads to appropriate dimensions and compresses them for delivery, so staff can upload phone photos and the site still loads fast.

Document generation flow

Invoices and other business documents are generated server-side from primitives - not by rendering HTML and screenshotting. This gives consistent output, tiny memory footprint, and complete control over layout.

The seal placement is one of the more interesting details. Every document gets a slightly different seal position and rotation - same document always produces the same placement (so a reprint matches the original), but different documents look visibly distinct (which matters for perceived authenticity in the client's industry). This solved a specific customer complaint that "the seal looks identical on every invoice", which it does when you scan a physical seal into a template. This insignificant feature does not challenges the authenticity or the documents, it just provides an authentic view the e-document perceived by the customer.

Features Delivered

Rather than a bullet list, here's what the platform actually does, grouped by user job.

Managing inventory. Staff can add an item in about five minutes. The form is one page with sectioned cards for identity, specifications, equipment options, sourcing metadata, commercial fields, and internal notes. Photos are uploaded from the same form - staged in the browser, cropped in a modal to a consistent aspect ratio at natural resolution to avoid quality loss, then batch-uploaded. The item's hero photo is chosen visually before upload.

Handling customer requests. Requests arrive from the public site through multiple paths: an inquire button on any listing, a general quote-request form, and a contact page. All routes converge on the same inbox. The internal view groups requests by status through a natural sales pipeline, shows any listing context, and preserves full customer messages without truncation.

Generating documents. Two editing paths, deliberate redundancy for different needs. A structured form editor for standard invoices with predictable line items. An embedded spreadsheet editor with real formulas and cell formatting for cases where the document needs custom layout. Both paths produce PDF and spreadsheet output. The PDF has the seal randomization described above. The spreadsheet export preserves formulas and formatting exactly as edited.

Interactive document stamping. A standalone tool: upload any PDF or image, position a seal anywhere on the page by dragging, rotate with a slider, resize, adjust opacity, download the stamped file. The preview matches the output exactly because the same coordinates drive both.

Editorial content management. Non-technical staff edit the public site's editorial pages through a form that mirrors the public layout. Hero copy, story paragraphs, statistics, values, team members with photos - all editable, all validated server-side, all live within a minute.

Company settings. Company details that appear on every document, seal image with enable-disable toggle, all in a settings surface with a consistent visual language.

Audit trail. Every change to inventory or customer records is logged with the actor's identity and a before-and-after diff. This is captured from day one, giving forensic visibility even before anyone thinks they need it.

Role-based access. Four roles clearly defined from super-admin to read-only viewer. Deactivating a staff member is instant - their next request is refused regardless of session state.

Design Approach

Both applications are built with utility-first styling and bespoke components. No off-the-shelf component library. This kept bundle size small and let the visual language stay consistent; the trade-off was more hand-built code, but the result reads as intentional rather than templated.

Impact

Numbers below are staff-reported estimates, comparing common workflows before and after the platform.

Technical Decisions

Every architectural choice involved trade-offs worth naming.

Managed backend service over self-hosted infrastructure. The team is small; running a database, auth service, storage, and secrets vault as separate self-hosted components would consume weeks of setup and ongoing maintenance. The managed option compresses that to hours. Trade-off: vendor lock-in on the auth layer, which is acceptable given the productivity gain.

Row-level security as the primary boundary, not the application. The application can be wrong; the database cannot. Every table has explicit policies. Trade-off: policies are SQL rather than TypeScript, so they need their own testing discipline.

Document generation from primitives, not headless browsers. PDFs are composed from structured data via a rendering library, not by screenshotting HTML. Trade-off: no visual designer for document templates, but complete control over output and a tiny operational footprint.

Embedded spreadsheet for edge cases, structured form for the common case. Rather than force every invoice into either a rigid template or a chaotic spreadsheet, users pick the tool that matches the job. Trade-off: two code paths to maintain, but the alternative was rejecting real user needs.

Two separate applications rather than one. The internal and public apps deploy independently, have separate environment variables, and share nothing but the database connection. Trade-off: no code sharing, but a much cleaner trust boundary.

Encryption of sensitive PII at rest. Customer phone numbers are stored encrypted with a key managed by a secrets vault. Reading them requires going through controlled functions. Trade-off: adds indirection to any query touching those fields, but if the database ever leaks in a backup, the sensitive data stays unreadable.

Deployment & Operations

Both applications deploy through a modern serverless platform on every push to the main branch. Preview environments spin up for every pull request. Custom domains, TLS certificates, and CDN routing are handled by the platform.

The backend runs on a managed Postgres tier with daily backups, point-in-time recovery, and monitoring included. Storage lives in the same region as the database for low-latency access.

Local development is a single command after cloning the repository. Both applications run simultaneously on different ports without conflict. A bootstrap script seeds the first admin user for a fresh environment.

What This Delivered

The client asked for tools to run their business faster. What they got is a data foundation that lets them think about their business differently. A specific example: because every customer request is now a row in a database rather than an email thread, the team can answer questions they couldn't ask before - how many requests convert to sales, what markets are asking about which product categories, which staff are handling which relationships. The data was always there; it just wasn't captured. Now it is.

The visible payoff was faster workflows: same-day inventory publishing, one-click document generation, non-technical content editing. The invisible payoff - the one that will still be paying dividends in five years - is that there is now a single source of truth for the whole business. Any future feature builds on that; any future integration hooks into it; any future team member arrives to a system with real records rather than tribal knowledge.

Most future work will be additive - new features, new integrations - rather than restructuring.