Expertise
Turning complex technology into usable business outcomes
What we do isn't just technical. It's making the whole thing reliable, explainable, and owned by your team.
Natalie Haigh
The glue between the idea and the thing that ships
Most technology projects don't fail because of bad code. They fail because the brief was vague, the requirements were never really nailed down, or the people paying for it and the people building it were never quite talking about the same thing.
That gap — between what the business needs and what gets built — is Natalie's specialism. At Mercury1 she sat between the client and the development team, writing requirements, running sprints, managing the backlog, and reporting to stakeholders in language they could actually act on. She gets to the real requirement — not the one that was asked for, but the one that will actually solve the problem.
She's the reason the whole thing holds together.
"Phil was operational excellence and Natalie was the glue that held everything together."
Requirements definition
Gets to the real requirement, not the one that was asked for. She has a gift for asking the questions that surface what the business actually needs before a line of spec is written.
Specification & documentation
Trained in UML at Procter & Gamble, she translates business needs into precise, unambiguous technical specifications — the kind developers can build from without guessing, and that protect everyone when scope needs to be managed.
Agile delivery
Ran two-week sprints for the full length of myTutor's growth, from first employee to acquisition. Sprint planning, backlog grooming, stand-ups, retros, and the constant work of keeping a team productive and a client informed.
Stakeholder communication
Reporting to stakeholders isn't about sending a status update. It's about framing technical progress in business terms and surfacing problems early enough that they become decisions, not crises.
Architecture that lasts
Systems designed for where the business is going, not just where it is. Maintainability, scalability, and operational resilience from the start — not bolted on later.
Cloud infrastructure & AWS
Built and migrated platforms on AWS from scratch, with a specialism in high scalability and self-healing resilience. See the myTutor tab below for a concrete example.
Full-stack development
A working developer with deep Java experience — not just an advisor. When Phil recommends an approach, it's because he's written the code himself.
Commercial clarity
Trade-offs explained in plain language. Technical decisions challenged constructively. Leadership teams leave knowing what they're choosing, not just what the developer recommends.
Phil Haigh
Operational excellence in code and infrastructure
Phil writes code. He also designs the infrastructure that runs it, leads the teams that ship it, and thinks in business outcomes rather than technical abstractions. That combination is rarer than it sounds — plenty of people can do one of those things well.
His background covers enterprise development at Ericsson and 3 Ltd, cloud infrastructure built from scratch on AWS, and leading technical teams from concept through funding rounds to founder exit. He brings the kind of rigour that growing businesses usually only get when they can justify a full-time CTO.
His focus is always long-term: systems that work now and keep working as the business grows, and that become an asset rather than a liability when investment or exit comes into view.
Built, not proposed
Real projects. Real problems.
Client work and an internal tool we built for ourselves. The diagrams are real — the problems were too.
Cloud infrastructure
Scaling a live classroom platform on AWS
myTutor's virtual classroom wasn't a web app in the normal sense — it was stateful software running on a server. When a tutor or student disconnected mid-lesson, they had to land back on the exact same EC2 instance. Different instance, different classroom — session gone.
At scale, with thousands of concurrent lessons, that's a genuinely hard infrastructure problem. Phil designed the routing so the load balancer kept session connections intact even as instances scaled up and down dynamically under load.
Concurrent classroom sessions
AWS Application Load Balancer
Session affinity — the hard part
If a tutor or student reconnects, they must land back on the exact same EC2 instance running their classroom session. A different instance means a different classroom — the session is gone. Phil implemented sticky session logic so the load balancer always routes reconnections correctly, even as instances scale up and down dynamically.
Auto-scaling EC2 instances — each running the classroom software
Instance A
Classroom sessions pinned to this instance
Instance B
Classroom sessions pinned to this instance
Instance C
Classroom sessions pinned to this instance
Spins up under load →
Security, privacy & data integrity throughout
VPC isolation, security groups, encrypted connections, GDPR compliance — the platform handled sensitive data for minors, so every layer was designed with data protection built in, not bolted on.
Stateful
Third-party classroom software running on each instance — not a stateless API, which made scaling significantly harder.
Resilient
Self-healing infrastructure — instances replace themselves, reconnections restore correctly, sessions survive disruption.
Cost-aware
Instances spin up under load and down when quiet — capacity tracks demand, so myTutor only paid for what they used.
myTutor — continued
Booking platform, three portals, and a recording pipeline that paid for itself
The classroom infrastructure was only part of what we built for myTutor. The product also needed a full booking platform — three completely different user experiences built on one underlying system — plus a recording pipeline that solved a cost problem by being clever about when and how it ran.
The booking platform — three portals, one product
Student & parent portal
- Browse and read tutor profiles
- Book sessions directly
- Parents pay invoices
- Parents review student progress
- Access classroom at session time
Tutor portal
- Manage availability and schedules
- Set and update rates
- View upcoming bookings
- Access classroom at session time
- Review session recordings
Shared classroom access
- Both tutor and student launched into the right session at the right time
- Linked directly to the AWS infrastructure above
- Session recordings available after processing
The recording pipeline — a cost engineering problem
Recording a classroom session required playing it back in real time and capturing the output — a full hour of compute per session. At scale, that cost adds up. Phil's solution: a fully decoupled background pipeline that processed the queue independently, using cheap temporary instances that only existed while there was work to do.
Session ends
Completed classroom session added to the recording queue
Queue builds
Sessions accumulate asynchronously — no impact on the live platform
Instances spin up
Cheap temporary compute instances boot when the queue has work — purpose-built for recording, not classroom hosting
Record in real time
Each instance plays back the session at 1× speed and captures the output — the only method available at the time
Instances spin down
Queue drained. Instances terminate automatically. Cost returns to zero until the next batch.
Why this matters beyond myTutor
This is the pattern we apply to any computationally expensive background task: decouple it from your live system, queue it, process it with appropriately priced compute, and shut down when done. The result is a system that scales to demand without charging you for idle capacity — and that never puts batch processing load on the infrastructure your users depend on.
20-year client relationship
Charity Challenge — from Access 97 to a full group travel platform
Charity Challenge organise fundraising challenge events — Kilimanjaro, the Sahara, the Inca Trail — on behalf of charities whose supporters use them to raise money. When Mercury1 first took them on, the entire business ran on an Access 97 database. Not a typo: Access 97, from 1996.
We replaced it with a bespoke Java web platform. That was over twenty years ago. They're still a client. The system is still running.
Anyway — that's probably the most honest review we can offer.
20
Years
Access 97
→ Full Java web platform
Standout feature
The charity white-label portal
Charities that partner with Charity Challenge can log into their own branded portal and generate white-labelled posters and marketing materials for exclusive trips — without any involvement from the Charity Challenge team.
A charity can promote a bespoke challenge event to their own supporters, under their own brand, using materials the system generates on demand. A product feature that extended commercial reach without adding headcount.
One control system. Everything in it.
A small team runs a complex multi-party operation — group travel logistics, charity relationships, participant management, and all communications — entirely within one platform.
Group trip management
- Trip creation & configuration
- Flights & accommodation
- Itinerary and logistics
- Participant capacity management
Participant bookings
- Online booking system
- Invoice generation
- Payment tracking
- Fundraising targets & progress
Charity management
- Charity relationship records
- White-label marketing portal
- Exclusive trip configuration
- Fundraising reporting
Communications
- Automated email workflows
- SMS via Text Anywhere
- Document generation
- Participant updates & reminders
The transformation
Access 97 is a single-user desktop database from 1996 — hard limits on concurrent users, file size, and data integrity. Replacing it with a multi-user Java web platform without losing existing data or stopping the business is a migration that requires precision, patience, and a deep understanding of the processes being replaced.
Technologies
Long-standing client — still in use today
A national recruitment platform — three interfaces, one engine
Thousands of hourly workers paid weekly across multiple UK sites. Three completely different user types who all need something different. And no off-the-shelf tool that could handle the payroll logic, the job board integrations, and the timesheet approval workflow together.
So we built one from scratch.
Email inbox
Scanned timesheets and photos arrive by email and land in a digital processing queue for the payroll team
Single data entry point
Workers × Clients × Consultants
One entry. Business rules automatically route every data point to the right output — in the right format, for the right person, at the right time. Payroll runs. Invoices generate. Dashboards update. All from a single source of truth.
Payroll & finance portal
Automatic Sage exports, payout reports per worker, multi-provider payroll (each worker chooses: Ltd company or PAYE), management reporting dashboards
Job boards
Logic Melon + CV Library — vacancies posted out, applications tracked, CVs uploaded, automated email comms and T&Cs sent from the sales portal
Sales consultant portal
Live dashboard with leaderboard, application pipeline, automated comms — and a gamified performance layer that drives results
Phone system (CTI)
Incoming call number triggers an instant screen-pop of the matching contact record — the consultant sees the client or worker before they say hello
Client portal
Clients log in to view and approve timesheets — approved hours feed directly into invoice generation. Invoices auto-generated per client terms, with summary statements and reminder emails triggered automatically.
1
Data entry point feeds every output
3
Distinct user interfaces from one engine
1000s
Of hourly workers paid weekly across UK sites
Internal tooling
Electra — our own project and billing system
We built Electra because Jira and Xero didn't talk to each other the way we needed, and nothing off-the-shelf could handle our hour-bundle billing logic. Jira knew the tasks. Xero knew the money. Nothing connected them accurately enough.
So we built the bridge ourselves — which is, to be fair, exactly the reasoning we apply for clients when generic software starts creating more problems than it solves.
Jira
Project tickets and development tasks linked directly to client accounts — time entries mapped to the work being tracked
Team time logging
Each team member logs hours against client projects — with their seniority level recorded, so the system knows the cost weight of every hour worked
Electra — Mercury1's internal platform
Hour bundle management
- Client hour bundles tracked in real time — remaining hours always visible
- Multi-rate drawdown — junior and senior time consuming different bundle rates
- Low-bundle alerts and automated top-up reminders to clients
- Project utilisation reporting per client and per team member
Xero
Invoices generated and pushed directly into Xero — hours consumed, rates applied, client terms respected, no manual data entry
Automated billing reminders
Reminders triggered by invoice due dates and bundle thresholds — keeping cash flow predictable without anyone having to remember to chase
Want to talk through a problem like one of these?
Book a Power Hour and bring the challenge. We'll tell you honestly what we think — and whether we're the right people to help.