Building a Unified Platform Across Four Regulated Verticals for Alfred

Introduction

Alfred (alfred.co.uk) is a UK platform reinventing how households buy broadband, mobile, energy, and insurance. The market is known for murky pricing, long lock-ins, and mid-contract price rises. Alfred's model is different: one membership, every service priced at cost, with margin coming only from membership, removing any incentive to inflate prices. Everything runs through one app: one sign-up, one checkout, one place for support.

That simplicity hid much complexity. Alfred had to operate across four regulated industries, each with its own rules and vendors, yet had to feel like a single product. The checkout alone supports 31 valid service combinations, with credit and identity checks that vary by product but must feel invisible to the member. A dozen-plus vendors had to sit behind one seamless experience, customer data had to stay unified rather than fragment, and compliance had to be built in from day one, all against a hard launch deadline with board and public visibility.

Alfred needed an engineering partner who owned end-to-end development and delivery, and that's where Arbisoft stepped in.

The Challenges

Designing and developing the Alfred platform came with a host of challenges:

• Four regulated verticals, one experience: Energy, broadband, mobile, and insurance each come with their own regulators, industry systems, and vendors. Alfred still had to feel like one app, one checkout, one product to the member.
• Checkout and basket complexity: Four product lines create 31 valid basket combinations, each with different payment routing, credit rules, and legal entities behind it. Get this wrong and the fullest basket, ironically the best outcome for Alfred, becomes the one most likely to scare customers off at checkout.
• Cross-cutting credit and KYC logic: A single credit check at checkout has to be interpreted differently for each product; energy can never be refused, mobile and broadband can be declined, insurance requires a conditional hold. All of this needed to resolve invisibly for customers who pass, and gracefully for those who don't.
• Vendor orchestration at scale: A dozen-plus vendors - covering energy, broadband, mobile, payments, credit, and logistics - needed to sit behind one seamless experience. Alfred's principle was that vendors orchestrate in the background while Alfred owns what the member sees.
• Fragmented customer state: Membership, service status, payments, and billing all risked living in separate silos across vendors and systems. Without one unified view of the customer, support and compliance would break down as Alfred scaled.
• Compliance as a foundation: Consent, identity verification, Direct Debit rules, and energy licence conditions all had to be built into the platform from day one. None of this could be retrofitted later without risk.
• Speed with rigour: This was a greenfield build racing toward a hard energy go-live deadline, with a public waitlist, board demos, and a high-visibility launch. The delivery process had to move fast without losing control or traceability.

The Approach

We answered these challenges with a platform built to absorb complexity rather than expose it, engineering the difficult parts once, centrally, so the member never encounters them. Below is how each challenge was addressed.

Mobile-first Platform Architecture

We built the member app in React Native with a FastAPI (Python) backend, structured around Alfred's four service verticals plus shared platform capabilities (membership, checkout, payments, consent, chat). Web surfaces, including the waitlist landing pages, were delivered alongside.

Unified Checkout With Credit Architecture

Rather than four product-specific flows, checkout was designed as one journey: basket review, membership as a line item, background KYC and credit checks triggered at the moment of high intent, and GoCardless-managed Direct Debit mandates. One Equifax API call per session covers every product in the basket, with results interpreted against per-product thresholds and re-use logic across sessions. Deposits and card holds are added to the basket before payment confirmation, never sprung afterwards.

Vendor Integration

Each vertical's industry complexity was kept behind Alfred-owned services: Seaglass webhook ingestion for energy industry flows (MHHS-native, no legacy migration), Fibre Cafe as the single provisioning gateway across Openreach, CityFibre, and Community Fibre, TOTSco for switching, and VMO2/1Global for eSIM provisioning and global roaming. Members never see a vendor; all they see is Alfred.

Canonical Data Model and State Control Plane

We designed a single control plane for customer state spanning membership, service lifecycle, payments, billing, and notifications, replacing lifecycle fragments scattered across systems with one canonical source of truth that powers reconciliation, support tooling, and operations.

Consent Engineered as a First-Class Entity

A three-part consent stack built on the principle that Alfred owns consent and vendors obey it: the consent record in the Canonical Data Model (with full audit trail), website-side cookie tooling and anonymous-to-known handoff, and comms orchestration through Customer.io.

AI-First Member Support: Alfred Care

A single chat thread per topic, AI-first for speed, human when it matters. "Fred," powered by AWS Bedrock with a knowledge base spanning all four verticals, handles what he can and hands off to a human with full context, so members never repeat themselves. Built on Amazon Connect with a React Native chat client supporting rich messages, read states, attachments, and voice input. No ticket numbers.

Production-Grade Observability and Security

Structured logging, OpenTelemetry tracing, and Sentry monitoring, executed against a single goal: identify the affected customer, request, service, partner, and failing component in under 60 seconds. A continuous security scanning programme feeds deduplicated findings directly into the engineering workflow.

An AI-Native Delivery Operating System

Product briefs written to be machine-readable, with every business rule, success criterion, and edge case numbered (BR/SC/EC) for AI-agent compatibility. A Linear workspace structured by initiative and journey, migrated from Jira and maintained as the single source of truth. Bi-weekly product planning, daily engineering catch-ups, weekly demos, and AI-assisted workflows for triage, sprint planning, and stakeholder communication.

The Outcome

The result was a platform that's already shipping, already board-ready, and built to scale without breaking.

• A live waitlist product, demoed to the board, covering sign-up, referrals, community and founding-member experiences, household management, and in-app chat, shipped iteratively on a weekly demo cadence.
• Four verticals progressing in parallel toward Alfred's energy go-live target, with broadband, mobile, and insurance journeys moving through design, tech discovery, and development simultaneously, without the verticals blocking each other.
• Complexity made invisible. The 31-combination basket problem, multi-entity payment routing, and cross-product credit logic resolved into a single coherent checkout designed around one KPI: membership conversion.
• One source of truth for delivery. A journey-aligned Linear workspace (35+ projects audited and restructured against product briefs) giving product, engineering, and leadership a shared, current view of the roadmap.
• Faster diagnosis, stronger reliability. The observability programme moved the platform from useful foundations to a production-ready "diagnose in seconds" posture ahead of launch.
• A compliance-ready foundation, with consent, KYC, credit decisioning, and Direct Debit handling built to regulatory requirements from the start, rather than retrofitted.
• A future-proof platform designed for what comes next: AI agents operating over machine-readable specs, a canonical memory layer for operational decisions, and an architecture that lets Alfred add services without adding chaos.

Technology Used

The tech stack we used to make the Alfred experience possible:

• Frontend: React Native (member app) 
• Backend: FastAPI (Python)
• AI & Support: AWS Bedrock (Fred, the AI support agent), Amazon Connect (chat infrastructure), Intercom Fin (waitlist support)
• Payments: GoCardless (Direct Debit mandates and collections)
• Credit & Identity: Equifax (eIDV / KYC and credit decisioning)
• Energy: Seaglass Cloud Technology (industry flows, MHHS-native)
• Broadband: Fibre Cafe (multi-network provisioning gateway), TOTSco (One Touch Switching), Eero (routers)
• Mobile: VMO2 (wholesale network), 1Global (roaming), eSIM-only provisioning
• Comms & Engagement: Customer.io
• Observability: OpenTelemetry, structured logging (Loguru), Sentry
• Delivery & Tooling: Linear, Figma, GitHub, AI-assisted PM and triage workflows