I find the path forward when the constraint is the job.
12 years shipping platform and API products across regulated ecosystems: telecom infrastructure, tax compliance, and financial communications. I deliver measurable outcomes in markets where regulatory ambiguity is the norm.
Selected Work
Four regulated products. Three industries. Measurable outcomes each time.
Each case study follows the same structure: the regulatory or ecosystem constraint that defined the problem space, the discovery process that identified the right abstraction layer, and the measurable outcome that followed.
Context
Enterprise communication platform serving 1,000+ regulated financial institution clients. The product was positioned against Teams and Zoom on UC features — a race it structurally could not win.
Why this problem
SEC and FCA off-channel enforcement was creating direct regulatory exposure for clients. Compliance archiving was underserved. Competing on video conferencing features was the wrong direction.
Discovery
Client conversations with compliance officers and IT administrators revealed the pain was regulatory exposure, not feature gaps. Competitive analysis showed no CPaaS provider had built configurable multi-channel compliance archiving at enterprise scale.
Solution
Federated channel compliance architecture — configurable to absorb multiple A2P regulatory outcomes simultaneously rather than hardcoding against a framework still in flux.
Execution
Negotiated API capability requirements directly with Twilio's product team. Aligned a sceptical commercial team. Shipped through live regulatory ambiguity — A2P framework changed multiple times during delivery.
Impact
167% growth, doubled ARR over 24 months.
Learnings
Designing for regulatory ambiguity requires configurable architecture. Shipping before the framework settles is a competitive advantage if you build the right abstraction layer.
Context
Enterprise SaaS onboarding for regulated financial institution clients. Activation was below target and the cause was unclear.
Why this problem
MAU growth was flat despite healthy top-of-funnel. Onboarding was the likely bottleneck but no one had mapped where users were actually dropping.
Discovery
Funnel analysis identified mid-flow abandonment as the primary drop-off point — not the steps most stakeholders assumed were causing friction.
Solution
Simplified activation touchpoints across the onboarding flow. Removed steps that added friction without adding trust or compliance value.
Execution
Cross-functional delivery with Engineering, UX, and Marketing. Staged rollout with measurement gates at each phase.
Impact
Onboarding completion improved from ~70% to ~85%. 12% MAU growth post-launch.
Learnings
Enterprise onboarding friction is often invisible until you map the funnel at step level. The drop-off point is almost never where stakeholders assume it is.
Context
IRIS Element was a locally-installed desktop application used by 10,000+ UK accountants and tax professionals for individual and business tax filing. The product had no cloud presence and no omnichannel capability at a moment when HMRC's Making Tax Digital initiative was fundamentally changing how tax data could be submitted, stored, and accessed.
Why this problem
HMRC's Making Tax Digital regulatory shift created a hard external deadline for compliance. Staying on desktop-only architecture would have left IRIS clients directly exposed to regulatory non-compliance — the same pattern as off-channel enforcement in financial communications. The migration wasn't optional; the question was what to build, what to cut, and how to ship it before the deadline.
Discovery
The HMRC constraints on cloud-hosted tax data defined the outer boundary of what was architecturally possible before a single requirement was written. Understanding those constraints precisely — what data could move to the cloud, under what conditions, with what access controls — was the first product decision, not the last. Discovery ran in parallel with constraint mapping across legal, compliance, and the Tax SME team to define what "done" could actually mean within the regulatory envelope.
Solution
A cloud-hosted MVP scoped tightly to the core tax filing workflow — the subset of functionality that 10,000+ accountants used most frequently and that HMRC's digital submission requirements touched directly. Non-essential features were deferred. The API-driven cloud storage integration that automated file uploads was the single highest-impact decision: it removed the manual step that accounted for the majority of the 33-minute baseline workflow.
Execution
Coordinated a 12-person cross-functional team across frontend and backend engineering, UX, Tax SME, and architects, with legal and compliance sign-off required on the cloud data architecture before build could proceed. The Tax SME was the critical dependency — every workflow decision needed domain validation before engineering could act on it. Scope discipline under a fixed 8-month deadline required constant prioritisation pressure: if it didn't directly serve the core filing workflow or satisfy the HMRC constraint, it didn't make the cut.
Impact
Shipped on schedule to 1,500 beta users within the 8-month window. The API-driven file upload automation reduced the core tax filing workflow from 33 to 17 minutes — a 49% improvement for 10,000+ professionals. Zero regulatory compliance issues on cloud data architecture at launch.
Learnings
Hard regulatory constraints are a product design input, not a compliance sign-off step. Bringing HMRC requirements into architecture conversations early prevented rework and gave the team clearer boundaries to design within. The prioritisation discipline — a maintained cut list with written rationale — is what I've carried forward most directly.
Context
BT/Openreach B2B partner platform serving Sky, Vodafone, and BT Retail as simultaneous integration partners. Each had distinct SLA requirements and integration preferences.
Why this problem
Building bespoke integrations per partner was creating unsustainable delivery complexity and growing SLA compensation costs.
Discovery
Mapped integration requirements across all three partners. Identified the shared architecture layer that could serve all three without bespoke builds.
Solution
Single coherent API platform architecture with configurable parameters per partner. One platform. Three consumers.
Execution
Translated three sets of competing requirements into a unified spec. Managed stakeholder sign-off across three enterprise partner organisations simultaneously.
Impact
20% reduction in delivery time. 15% YoY reduction in SLA compensation costs.
Learnings
Multi-party platform design requires finding the abstraction layer early. Bespoke builds feel faster in week one and become the bottleneck by month six.
How I work
The method that repeats across every regulated environment.
Map the constraint
Before deciding what to build, map what's actually possible given the vendor ecosystem, regulatory environment, and delivery constraints simultaneously. Most teams start with the solution. I start with the constraint — because the constraint usually contains the answer.
Find the abstraction layer
There is always a single architecture decision that serves all parties without bespoke builds. I found it for three enterprise partners at Openreach. I found it for A2P regulatory compliance at Global Relay. The pattern transfers across domains because multi-party API ecosystems are structurally similar whether the regulated layer is telecom, tax, or financial communications.
Ship before the framework settles
Regulatory ambiguity is not a reason to wait. Build configurable logic that absorbs multiple outcomes. The A2P 10DLC framework changed three times during delivery. We shipped on time because the architecture was designed to absorb change, not depend on certainty.
Measure the ecosystem
MAU and activation rates matter. So do vendor API response times, partner SLA compliance rates, and regulatory acceptance rates. The product metric is one layer of a multi-layer system. Missing the ecosystem metrics means missing the early signals.
Working on a product problem in a regulated environment?
12 years shipping platform and API products where regulatory ambiguity, vendor ecosystems, and delivery constraints intersect. Always happy to compare notes.