01 — Executive Summary
What REX is, and why it exists
REX is an operations platform that consolidates client management, automated workflow, AI-assisted work, multi-channel communication and analytics into one system. It was built to replace a set of disconnected commercial tools whose combined cost was significant and whose lack of integration forced the same information to be entered several times.
The operating environment is regulated: advertising standards, electronic-messaging consent law, and licensed data-distribution rules all constrain what the software may display, send and store. Those constraints were treated as binding requirements from the outset rather than as a compliance review at the end, and they materially shaped the architecture.
I own the product end to end: I define the roadmap, write the requirements, make the architectural and vendor decisions, run delivery, and perform acceptance testing. The system is in production use.
02 — My Role
Founder · Product Owner · Technical Project Manager
Accountable for outcome rather than for a single discipline. In practice this spans:
Roadmap & Release Planning
Defining phases, sequencing delivery against business impact, and deciding what ships versus what is deferred.
Requirements & Specification
Writing specifications with explicit, testable acceptance criteria — including non-functional and regulatory requirements.
Stakeholder Management
Running a short feedback loop with the end user, demonstrating increments and re-scoping on the basis of observed use.
Prioritisation & Scope Control
Maintaining the backlog, protecting the phase boundary, and recording the rationale when scope is cut.
Vendor & Technology Evaluation
Assessing providers on entitlement model, cost, data ownership and exit risk before committing.
Integration Planning
Defining module boundaries and the internal interfaces that keep vendor changes contained.
Risk Management
Maintaining the risk register and driving mitigation into design, particularly for compliance and third-party dependencies.
Quality & Acceptance
Verification against acceptance criteria before promotion, including deliberate negative testing of guardrails.
03 — Business Problem
Six disconnected systems, one operator
The pre-existing environment was a stack of independent subscription tools with no shared data model. The resulting failure modes were structural, not behavioural:
04 — Solution & Architecture
One data model, modular services
A single authoritative data layer with functional modules composed on top, and all external providers isolated behind an integration boundary. Components are shown at conceptual level; implementation detail is intentionally omitted.
Single source of truth
One authoritative record per entity, so every module reads the same data. Business impact: no reconciliation, no duplicate data entry, and one place to look for the truth.
One compliance checkpoint
All outbound communication passes a single consent gate. Business impact: the compliance position is provable rather than assumed, and it can't be bypassed by adding a new feature.
Contained vendor risk
External providers sit behind a consistent internal interface. Business impact: switching or losing a vendor is a contained change, not a rebuild — and cost is easier to control.
Illustrative layout only. Contains no real client, pipeline or business data.
05 — Core Modules
Capabilities and the business value each delivers
Client Relationship Management
A single record of every contact, interaction and stage, replacing spreadsheets and disconnected inboxes. Consolidated history means no one is contacted twice or forgotten.
Workflow Automation
Rules engine that advances work automatically — assignment, follow-up timing, stage changes and escalation — so routine coordination doesn't depend on someone remembering.
AI Services
Retrieval-grounded assistance for drafting, summarising and answering questions against live operational data, with explicit constraints on what the model may assert.
Communications
Unified outbound across email, SMS and voice with a single consent gate, so every message passes one compliance checkpoint regardless of which module triggered it.
Marketing Operations
Multi-channel content pipeline: scheduled generation, review-before-publish, distribution to several platforms, and performance attribution back to the originating asset.
Analytics & Reporting
Operational dashboards and a scheduled digest covering pipeline health, source performance and exception states requiring human attention.
Integration Layer
Adapters to external providers behind a consistent internal interface, so a vendor change is contained to one module rather than rippling through the system.
Document Management
Template-driven document generation and structured storage tied to the relevant record, with versioning and controlled distribution.
Scheduling
Calendar availability, booking and conferencing-link generation, synchronised bi-directionally with external calendars.
Task Management
Work items generated by system events with ownership, due dates and service-level tracking, surfaced by priority rather than creation order.
06 — Product Lifecycle
From problem statement to continuous operation
Idea & Problem Definition
Quantified the cost of the existing fragmented process — duplicated effort, tool spend, and the capacity ceiling it imposed.
Requirements
Written specifications with testable acceptance criteria, including binding regulatory and data-integrity constraints.
Planning
Phased roadmap sequenced by business impact, with explicit boundaries on what each phase would and would not include.
Design
Module boundaries, the shared data model, and the integration interface defined before implementation began.
Development
Incremental delivery on feature branches with preview environments, allowing review of each change in isolation.
Testing
Type and contract checks gating promotion, plus acceptance testing against the written criteria and negative testing of guardrails.
Deployment
Continuous deployment to preview on every change; promotion to production as a deliberate, reviewed step.
Continuous Improvement
Production observation feeding a maintained defect and enhancement backlog, with post-incident findings folded back into design.
07 — Project Management Practice
How delivery was actually run
08 — Technical Leadership
Decisions and their rationale
Managed platform over self-hosted infrastructure
For a small team, operational burden is the scarcest resource. Managed hosting and a managed database traded marginal cost for the elimination of infrastructure maintenance.
One language across the stack
A single typed language for both client and server removed context-switching and allowed shared models between layers, reducing a whole class of interface defects.
Relational store as system of record
The domain is inherently relational and the integrity requirements are strict. Referential integrity enforced by the database is stronger than integrity enforced by convention.
Adapters at the integration boundary
External providers are the least stable part of the system. Isolating them means a vendor change, entitlement change or outage is contained to one module.
Constrained AI rather than open-ended generation
In a regulated context an unconstrained model is a liability. AI features operate on retrieved live data with explicit prohibitions on asserting figures it cannot source.
Fail loudly, degrade gracefully
Following the silent-failure defect, scheduled work asserts on output volume, and user-facing surfaces render an empty state rather than a fabricated one.
09 — Integration Categories
External systems, described by category
Specific providers, endpoints and credentials are intentionally omitted. Each category below required its own authentication model, entitlement handling and failure strategy.
Licensed Data Feeds
Scheduled ingestion under licence terms governing what may be displayed, to whom, and for how long.
Calendar & Scheduling
Bi-directional availability and event creation with conferencing links.
Email Delivery
Transactional and bulk delivery with consent enforcement and deliverability handling.
Messaging & Voice
Programmable SMS and voice for time-sensitive notification, consent-gated.
AI & Language Services
Large-language-model services for retrieval-grounded assistance and content drafting.
Mapping & Location
Geocoding and location context for records lacking coordinates.
Marketing & Advertising
Campaign management and performance data, attributed back to originating assets.
Social Distribution
Multi-platform publishing and inbound interaction monitoring.
Media Generation
Automated production of video and graphic assets from structured input.
Cloud Storage
Object storage for generated documents and media, with controlled access.
Transaction Management
Integration with industry transaction systems for lifecycle status.
Analytics
Behavioural analytics and conversion tracking across public surfaces.
10 — Engineering Challenges
The hard problems, and how they were handled
11 — Lessons Learned
What I would carry into the next delivery
A green status is not evidence
A process returning success proves the process ran, not that it did its job. Every scheduled job now asserts on the shape and volume of what it produced.
Prefer an empty state to a plausible one
A section that renders nothing is honest. A section that renders an invented figure is a liability that survives precisely because it looks correct.
Verify the credential, not just the connection
Authentication succeeding says nothing about entitlement. Access tiers must be verified against the specific data class the feature depends on.
The user's persistent complaint is a signal
Repeated feedback that something 'still looks wrong' was correct each time, and the underlying cause was consistently deeper than the visible symptom.
Compliance constraints improve the product
Rules that prohibit unverifiable claims force a discipline about data provenance that makes the whole system more trustworthy.
Instrument before optimising
Several assumed performance problems turned out to be truncation defects. Diagnostics were written before any tuning was attempted.
12 — Delivery Timeline
Phased delivery
13 — Capabilities Demonstrated
Skills evidenced by this delivery
14 — Technology
Stack, at a level I'm happy to discuss
Publicly discussable technology choices. Configuration, credentials, schema and proprietary logic are excluded.
15 — Outcome
Where the platform stands
REX is in production. It replaced several standalone subscription tools with one integrated system, removed the duplicate data entry that capped operational capacity, and established a single auditable compliance path for outbound communication.
The most valuable outcome was not a feature. A systematic audit of data provenance across every user-facing surface found several cases where the system reported success while silently doing nothing, and others where unverifiable content was being displayed as fact. Correcting those, and rebuilding the verification approach so that class of defect surfaces immediately, did more for the platform's reliability than any individual capability.
Beyond the technical implementation, the project demonstrates the ability to translate business requirements into production software, integrate multiple technologies into a coherent system, manage delivery in a regulated environment, and continuously improve the platform through structured feedback and iterative releases.