All capabilities
Capability

Solution Architecture

I help you design systems before you build them, data models, service boundaries, stack selection, and deployment topology, so the first six months of development do not set up the next two years of pain.

At a glance

  • Backed by public open-source code, not just a description on a page.
  • Long-form essays on the same topics, with sources cited.
  • Production patterns the same hiring team can lift straight into their stack.

About Sarma

Sarma is a UK-based software engineer running Sarmalinux as a one-person studio. He ships nineteen open-source repositories spanning LLM gateways, coding agents, inference, storage engines and consensus, and writes long-form engineering essays at sarmalinux.com/blog. Senior IC, end to end.

Architecture mistakes compound. A bad data model means an expensive migration later. A monolith that should have been services means everything deploys together. A multi-cloud strategy for a 5-person team means paying for three sets of expertise. I have made these mistakes and worked around them in production. When clients bring me in before they start building, or when they are planning a significant change, I run a structured design session: map the current state, identify the load patterns and failure modes, and produce a target architecture with clear ADRs for the non-obvious decisions. The output is something your team can execute, not a 60-slide deck.

What this covers in practice

System design sessions

Structured workshops covering data model, service boundaries, API contracts, caching strategy, and deployment topology. Written up as ADRs your team can reference.

Stack selection

Opinionated recommendations grounded in what I have actually shipped: Next.js + Supabase for web products, DigitalOcean + Kubernetes for containerised workloads, Terraform for IaC. No vendor-neutral hedging.

Architecture reviews

Structured review of your existing system: identify bottlenecks, single points of failure, security gaps, and scalability limits. Scored risk register, not a list of vague concerns.

Technical roadmaps

Six-to-eighteen-month roadmap that sequences technical work by risk and business value. Includes dependency mapping so you know what unlocks what.

Proof-of-concept builds

When a design decision has high uncertainty, I build a minimal spike to validate assumptions before committing to a full implementation.

AI system architecture

Provider strategy, failover design, RAG pipeline architecture, eval harness design, and model selection for LLM-integrated products. Grounded in building SarmaLink-AI.

Stack

Next.js + Supabase (web products)Postgres + RLSKubernetes / Helm (containerised)Terraform (IaC)Vercel + CloudflareDigitalOceanPython FastAPI (services)BullMQ + Redis (queues)pgvector (RAG)

What a hiring team gets

Architecture decisions documented with rationale
Opinionated, not "it depends" on every question
Grounded in production code, not theoretical patterns
Identifies risks before they become incidents
Executable output, not a presentation
Follow-on implementation available if needed

Read the evidence

Open the public repositories, browse past work, then look at the hiring page if a PAYE shape fits your team.