making software
that holds up.fixing things I didn't break.

The problem

Engineers want to express intent — ship this service, wire it to that queue — and have it executed safely. Every step between the intent and the running system is where outages come from, and handing that gap to an unsupervised agent is how you get a confident model holding production credentials.

What I built

• Go control plane and worker pool running a fixed pipeline: ingest → analyse → plan → IaC → build → deploy → verify.
• BYOC on AWS — infrastructure is provisioned inside the customer's own account, so the blast radius and the bill both stay theirs.
• Framework detection reads the repository and infers what the thing actually is before proposing a plan for it.
• Every action is risk-classified, and anything mutating stops for human approval rather than proceeding on confidence.
• RBAC and audit trails on every state transition, so “who changed this and why” has an answer.
• Bounded retries, rollback and recovery — durable state means a failed deploy resumes or reverses instead of stranding half a stack.
• Multi-tenant from the first commit, because retrofitting isolation is a rewrite.

Outcome

Connects model reasoning to real, reversible infrastructure actions through a platform — planning, permissions, durable state, audit — rather than through a prompt and some optimism.

The problem

Identity and profile services sit under everything else, so their failure modes are everyone's failure modes. The hard part is rarely the happy path — it is doing the right thing when a provider is down, a message arrives twice, or a certificate expires quietly at the wrong hour.

What I built

• Identity and profile infrastructure serving customer accounts at platform scale.
• Event-driven pipelines on Kinesis with versioned schemas, dead-letter handling and replay, so analytics never couples to transactional systems.
• Profile audit publishing across account boundaries — validate, transform, assume role, deliver, dedupe downstream.
• Sanctions screening off the request path: minimise PII, call the provider, classify each result, and treat a provider outage as an outage rather than a compliance match.
• Certificate lifecycle automation — detect expiry, renew, update the store in place preserving identifiers, wait for adoption on restart, then retire the old one. Idempotent, durable, recoverable.
• Client onboarding as one orchestrated, resumable workflow instead of repeated manual changes across WAF rules, certificates and configuration.
• Monitoring, alerting and runbooks so problems surface before customers report them.

Outcome

Repetitive per-service work replaced by auditable, reusable paths, and whole classes of outage designed out rather than monitored for. Specific figures are held back — internal numbers are not mine to publish.

The problem

Claude and Cursor start every session knowing nothing about the organisation. Engineers re-explain the same architecture daily, and the assistant makes locally sensible decisions that ignore how the systems actually relate to each other.

What I built

• Ingests assistant sessions alongside source and infrastructure repositories, so context comes from what was decided as well as what was committed.
• Extracts entities and the relationships between them — services, repositories, decisions, ownership — into a persistent graph rather than a flat pile of embeddings.
• Retrieval happens over MCP, so any compatible assistant reads the same memory instead of every tool keeping its own.
• Security boundaries on what may be ingested and what may be surfaced, because a memory layer inherits the blast radius of everything it has read.

Outcome

Assistants reason with shared engineering context instead of isolated repository knowledge — less repeated setup, more consistent answers across repositories, and memory that outlives the session. In daily use by my team; wider rollout in progress.

The problem

Sports traffic is not uniform. Nothing happens for an hour, then a wicket falls and every user in the country opens the app in the same four seconds. Everything downstream has to be built for that shape.

What I built

• React Native application, and the Node.js and PostgreSQL backend underneath it.
• Redis and a messaging layer to keep expensive work off the request path.
• WebSocket chat for live match conversation.
• Feed ranking with diversification, so the timeline doesn't collapse into one topic during a spike.
• Notifications, contact discovery, and offline synchronisation for users on unreliable mobile networks.
• Production infrastructure, scaling and incident response — including being the person on the other end when it broke.

Outcome

Shipped to launch and run in production. End-to-end ownership from mobile client through backend to infrastructure and incidents, rather than a slice of someone else's system.

The problem

Scores arrive in bursts, every leaderboard recalculates at once, and every user refreshes at the same moment. Doing leaderboard computation and PDF generation inside the request cycle meant the slowest possible work happened at the busiest possible time.

What I built

• Moved leaderboard recomputation and PDF generation onto Redis and RabbitMQ queues, out of the request path entirely.
• Asynchronous processing so a match event fans out to workers instead of blocking the caller.
• Caching and query optimisation on the read paths every user hits simultaneously.

Outcome

The expensive work stopped competing with the traffic that triggered it. Response paths stayed fast through live matches rather than degrading exactly when the product was being used most.