Work I've Built
A collection of working apps, websites, prototypes and code projects, built to explore, experiment and solve real problems, alongside documented product work from professional engagements.
Live★ FeaturedNew Product Introduction: Building a Product Function from Nothing
They already sold several fixed wireless and fibre options on their own network, plus VOIP. What they did not have was a repeatable way to introduce anything new. I was the product function, and the supporting roles had neither the spare resource nor the time that new product introduction asks for, so I had to earn the right to ask people for things. * Built the New Product Introduction framework from nothing and moved the business from sales and marketing led to product led * Proved the case well enough that they created a permanent Director of Product role, which did not exist when I arrived * Five products launched in eight months, four from scratch and one relaunched in two weeks * Lifted ARPU, the business's main KPI, through value-added services like the consumer cyber security offer layered onto existing connections * Led by example on the first launch deliberately, so the next time I asked someone for something there was a finished product to point at rather than a diagram * Halved the per-unit router cost and replaced manual per-customer ordering with full API automation through to live service * Opened an off-net path through Openreach SoGEA and FTTP, so we could sell to customers the on-net network did not reach. It proved complementary too, carrying the numbers through months when on-net sales were light * Recommended BT Wholesale off the back of my research, for direct Openreach engineer access, per-premise survey detail and address-level UPRN checking built in. Overruled on cost and an existing agreement between the two companies, and the delivery risk I had flagged landed exactly as described * Built an automated recovery process for the routers that risked being stranded: if an order did not reach live status inside a set window, an API call triggered the supplier's returns process rather than the hardware being written off * Found consumer VOIP leakage where billing had stopped but the supplier service and the equipment rental had not * Designed, scoped and presented a router refurbishment loop, collection, inspection, grading, reissue and recycling, reusing automation already built. It stayed on the roadmap, tied to an open decision on the router estate * Kickstarted a stalled 1Gb fixed wireless launch by bringing it under the framework and clarifying what each stage gate actually needed, then handed it back to the PMO to run
Beta★ FeaturedCloudio Learning: An AI-Native Learning Platform Built Solo, Why It Stopped, and Why It Restarted
An AI learning platform out of the box, built to teach anything by design, and built solo by directing an AI development agent. A retrofit broke it, and most of what broke has since been fixed, which is the reason this entry exists. * Live at [learn.cloudio.co.uk](https://learn.cloudio.co.uk): a layer sitting above the learning providers rather than another place to learn, tracking study across any source and showing the week in one dashboard * Designed from the data model before any screen existed, which is the main reason a solo-built codebase of this size stayed workable * The core loop is four steps, add a course, time your study, mark progress, see your week, with the one interface decision that mattered most: the timer sits in the layout so it survives navigation * One AI integration running thirteen use cases rather than thirteen integrations, from importing a course off a pasted link to generating a twelve-month curriculum at onboarding, natural-language search and a study assistant * Gamification off by default and enforced in the data, a handles-only leaderboard, no points for manually entered time, and guests seeing everything with the write actions locked, so commitment is asked at peak interest rather than at the door * Five layers sat above the core loop (discovery and a seeded catalogue, social study groups, enterprise assignment, claimed skills, podcasts). Each defensible alone, all of them accumulated because AI help made them cheap, and that is where the failure-first filter stopped being applied and scope ran ahead of demand * Why it stopped, what changed, and where it stands now: a retrofit for multiple languages broke an interface with English hardcoded into it, partly from my own experimentation and partly from the AI development agent implementing it incorrectly without warning me how serious it was, and finishing the fix would have cost more than a proper rebuild. So I paused it rather than kept patching, dropped multi-language support entirely, and restarted English only and AI first while still built to teach any subject, with most of what broke now fixed * The headline lesson is that internationalisation is a day-one decision, because the retrofit cost grows faster than linear and patching your way out of it never closes the gap. Underneath it sits a second one: when build cost falls, prioritisation has to become deliberate, because effort is no longer enforcing it * Stated plainly rather than glossed: no instrumented analytics and no validated demand beyond my own daily use, so the retention designs are reasoned rather than proven The deeper technical context, the full data model and the original plan live on GitHub.
MVPCore Platform: Defining the Shared Services Layer for Three Enterprise Products
Three enterprise products were being built and all three needed the same foundations underneath them: sign-in, permissions, approvals, records and audit. I owned that shared layer as a product. The hard part was never writing the requirements. It was deciding what deserved to be a product at all. * Cut a fragmented capability map down to a bounded set of products, then by roughly a third again when the timeline and budget changed * Replaced an industry term the whole system had quietly been built around with one reusable construct, before it became four copies in four databases * Gave every important business concept a single owner, so two capabilities could never both think they held the same thing * Wrote the 171-requirement non-functional baseline that didn't exist before, covering every product line, the platform and the development teams * Got stalled work moving by drafting the requirements myself and asking people to correct them * Led phasing across four product lines under budget pressure, asking the other two product managers to cut their scope against a line I had drawn * Raised customer migration, resilience levels and cloud portability while they were still cheap to fix * Produced 47 artefacts in four months with AI assistance, while the architectural calls stayed with the people in the room There is no deep dive for this one. The detail belongs to a live programme building an unreleased product, so I have written up the reasoning and left out the specifics.
LiveConverged Infrastructure as a Service: From Capex Blueprint to Partner-Sellable Platform
Competitors already had consumption services and we had none. The architecture turned out to be the easy half, because every component I needed belonged to a different team in a business where those teams did not talk to each other. * Replaced a Capex-only legacy blueprint with a full consumption service, where previously every enterprise deal was configured and supported from scratch * Hundreds of possible configurations reduced to five sizes a partner could quote without the vendor in the room * Became the main value driver in the portfolio, with Storage-as-a-Service repositioned as the follow-on upsell once customers said they wanted the full stack * Opened a partner channel motion the previous Capex-only model could not support * Layered the service so revenue could start before it was finished, infrastructure first, then support and managed services, then hypervisor, then observability * Wrote the 38-page PRD covering high, mid and low level design in one document, because four component teams and a partner channel only work from the same requirements if there is one set of them * Set the margin, cost, discount tiering and pricing, then loaded it into the partner quote-to-cash portal so partners could sell without us pricing every deal * Fixed the dependency problem by insisting roadmap conversations covered deprecations, not just releases. The shared tracker that came out of it caught live products still selling unsupported hardware * Blocked the hypervisor layer rather than ship it on bring-your-own licensing, which would have broken the managed support that made the whole service worth buying * Two roadmap items needed the business convinced before a customer ever saw them, both written up separately: Bare Metal as a Service and Network as a Service * Fully scoped at departure, with PRDs validated, reference architectures, consumption model and pricing in place, and partners in pilot
LiveOnDemand CX: Turning an Infrastructure Gap into an Enterprise Product
On its hosted cloud fabric the business sold mid-market only. Enterprise customers did buy from it, but they ran on premise in their own data centres or colo, so the enterprise platform was not on offer as a hosted service. The private cloud underneath could not have run it, and before I joined one person scoped the infrastructure for every single deal by hand, which meant a two-week wait. My job was to take that away from him and support the team. * Platform revenue grew by over 3,200% in 18 months * Brought enterprise Avaya Aura onto the hosted platform for the first time, where the business had only sold it to customers running it on premise. It now accounts for more than half the platform's live customers, up from zero * Took scoping and pricing from a two-week wait to minutes, done by sales in front of the customer on the first visit, with solution architects only needed at the later stages * Pricing held at 100% accuracy, validated against final designs * 99.999% availability across a dual data centre private cloud that grew past 1,000 VMs * Negotiated a Dell OEM partnership that roughly halved the server footprint and cost, with roughly two to three times the usable density once virtualised and consolidated, which is what made an enterprise-capable cluster commercially viable in the first place * Earned the VMware, Veeam and Sophos certifications myself to move the business up two partner tiers, because that was the fastest route to the licensing the platform actually needed
ConceptualNetwork as a Service with NetFoundry: Removing the Customer VPN from Enterprise Onboarding
I found this in deployment data rather than a strategy session. Customer-side VPN dependencies were holding up onboarding across hundreds of deployments, on a service sold on speed of access. * Reached executive demonstration and joint requirements work with the vendor, having started from an operational pattern observed in deployment data rather than a vendor approach or a strategy exercise * Reframed the problem so the customer firewall could stay closed: a zero trust overlay with outbound-only connections from both ends, rather than every route asking the customer to weaken their own perimeter and maintain that exception indefinitely * Embedded as an SDK rather than shipped as an appliance, which makes connectivity part of the product and turns the data crossing it into something measurable and chargeable * Made it a portfolio decision rather than a fix for one service, because the same capability served remote support, the management plane and hybrid cloud storage * Set out build versus buy in full, including what the open source route genuinely costs to own in headcount and indefinite operations * Not signed off, no pilot, nothing built. The reasoning is the point, and I have included what I would sequence differently * Clearest lesson is sequencing. Portfolio-wide reach made the commercial argument stronger and the decision harder, because no team owned the outcome or the budget. A narrower pilot producing measured evidence would have been the faster route to the same case
ConceptualAI-as-a-Service: An Open Source Alternative to the Nvidia AI Enterprise Stack
Nvidia AI Enterprise carried a per-GPU licence, and our reference design needed sixteen licences before a single workload ran. Nobody had checked whether we actually needed all of it, so I did. * The distinction that unlocked it: Nvidia gives away most of the tooling, and the licence buys the enterprise wrapper around it, so the question is not whether to replace Nvidia but which layer we are paying for * Mapped Base Command Manager feature by feature to free and open source equivalents across twenty-two capability areas, with the implementation steps for each * Named the two capabilities I could not replace rather than omitting them, because a business case that overstates itself gets dismantled in the room * Did the step most substitution analyses skip: went to the teams already running these tools and asked whether it would hold. The competence was already in-house, which is what turned a cost argument into an executable one * Found the bigger gap underneath. The AI proposition had no managed services layer, and customers buying an AI platform from anyone would not have the skills to run the fabric * Proposed an AI managed services offering to the services lead and the AI go-to-market team, extending the infrastructure and professional services proposition into recurring revenue * Pitched to two people in leadership and received positively. The part that carried it was not the cost saving, which anyone could have estimated, but the evidence that the knowledge already existed inside the company * Third time I have run this build-versus-buy test, and the first time it came out for building. I would worry about my own judgement if it always gave the same answer * Unfinished. I was still ratifying the architecture when I was made redundant
LiveBare Metal as a Service: Reviving a Failed Product with Canonical MaaS
The business had built this in-house once, sold it to a single customer and dropped it. Bringing it back meant fixing the positioning before touching the technology, against an engineering lead who told me plainly it would meet heavy resistance. * Turned a previously failed in-house product into a shipped, billable capability, by repositioning the proposition and integrating a third party rather than rebuilding * The first attempt had failed as a proposition before it failed as a product, so I started there rather than with a tooling comparison * Repositioned it from a direct enterprise feature to something partners could wrap a deployment service around, which opened a market the first attempt could never have reached * Made the case on three beneficiaries rather than one: partners got a service to sell, customers got faster deployment, and our own professional services teams got the same automation internally * That last one did most of the work. The cost of manual provisioning was being paid on every deployment whether or not the feature ever sold * Assessed Ironic, Tinkerbell, Metal3 and Canonical MaaS, narrowing to two for the team to prototype rather than handing them a decision * Team delivered the MVP in a couple of two-week sprints and prioritised it ahead of their own backlog, which is the part I am most pleased about * Shipped as a billable customer feature, scheduled into the next platform release, with tiered licensing scoped and under decision
LiveHybrid Multi-Cloud Go-to-Market: Migrate First, Modernise Second
A bank with an immovable data centre exit deadline, migrating the slow way because every application was being modernised on the way across. * Supported licence, professional services and operations revenue across two UK-headquartered banks * Reframed a stalled migration by separating migration from modernisation, two programmes with different clocks that had been bound into one, which is what made the exit deadline achievable * Landed workloads unchanged on Azure VMware Solution and VMware Cloud on AWS, with HCX live migration and layer 2 extension removing the change window that usually sets the pace * Discovery-led from the customer's own network flow data, so the same assessment produced both the migration waves and the micro-segmentation policy * Treated retain and retire as legitimate outcomes rather than failures, which is what kept the people who knew the estate on side * Built with VMware as a reusable asset rather than a single engagement, then used at a second bank and across the wider enterprise base * Well received on both sides because it carried a business and a technical view of the same proposition, so internal staff and customers used the same material rather than being handed different stories * Established a discovery-led motion where the customer's own estate data produced the migration plan, changing the opening conversation from a product pitch to findings about their environment * Proposed a centre of excellence unifying separately managed cloud-native teams on a common foundation, addressing the governance problem underneath the tooling one