Open to select projects · Remote

I build the systems that have to be right.

Senior backend, distributed-systems, and system-design work, scoped and delivered remotely. High-concurrency, regulated, high-traffic environments are the norm.

Start a project See how I think

hello@valcof.com GitHub LinkedIn

Track record

users served: Millions
load, validated: 10×
shipping backends: 15+ yrs

About

Some systems can't afford to be wrong: payments that can't double-charge, pipelines that can't drop events, services that can't fall over under peak load. That correctness-under-pressure is the work I take on.

Over 15+ years I've designed and shipped high-concurrency services, event-driven pipelines, and cloud-native backends for regulated, high-traffic platforms serving millions of users. My background is full-stack, so I design the whole system, not the backend in isolation: the data model, the service boundaries, and the architecture calls that shape the frontend and the product. I currently lead the backend team behind one such platform, where much of the job is raising the bar: clearer boundaries, fewer surprises, and code the next person can actually own. On the teams I've led, I'm the one who won't let quality slip, and the one who still ships.

I reach for the durable answer over the clever one. The clever version impresses in review; the durable one is still running, and still understood, years later. And the parts most people would rather avoid (the edge cases, the failure modes, the migration nobody wants to own) are the parts I like. Getting those right is the job.

How I think

How I approach hard problems

A few problems I've worked through, and how I reason about them. Client details are under NDA; the thinking is mine.

When many users want the same scarce thing

Concurrency · distributed systems

The problem. Limited inventory, many buyers, all in real time. Two people must never win the same slot, and the system can't seize up under contention.

How I think about it. I reach for explicit state and atomic operations over optimistic locking and hope: a clear reserve, confirm, or expire lifecycle, so the rules live in one place and a half-finished purchase can't corrupt what's available. I built exactly this as a dedicated service and rolled it out market by market.

When losing a message means losing money

Event-driven · reliability

The problem. Payment notifications handled inline inside a monolith: one slow request times out, and a real payment quietly disappears.

How I think about it. I separate accepting an event from processing it: acknowledge fast, put it on a durable log, process it independently, and make failure explicit with dead-letter queues and replay instead of trusting a provider to retry. I designed this pipeline, a thin service plus Kafka plus a consumer, and shipped it behind a progressive rollout. I later distilled the reusable core of the pattern into an open-source Go library, ferry.

When two requirements seem to cancel out

Web architecture · performance

The problem. Pages have to stay fully cached at the edge for speed, but logged-in users need a personalized view. Solve one the obvious way and you lose the other.

How I think about it. I look for the seam: keep the cached HTML identical for everyone and resolve identity in the browser, with the server as the source of truth right after paint. I designed this, plus a small Go service to keep sessions alive, built fail-open so an infrastructure hiccup never logs everyone out.

When everyone says “just add AI”

AI adoption · judgment

The problem. Every team is under pressure to put AI somewhere. Most ideas add cost and risk without moving anything that matters; a few are genuinely worth it. Telling them apart is the hard part.

How I think about it. I treat it like any other engineering decision: find the one or two places AI actually earns its keep, ship those behind real evaluation, and skip the hype. Then I bring the team up the curve so using AI well becomes a habit, not a one-off demo. It's what I'm leading on right now.

Building

What I'm building

Things I build and ship on my own — a live SaaS and an open-source library — owned end to end, from the data model to the running system. The client work is under NDA; these are entirely mine to show.

ferry

An open-source Go library for idempotent, durable processing of at-least-once events and webhooks: effectively-once handlers, leases so two workers never run the same key, retries, and dead-letter-plus-replay instead of lost events. The "a retry must never double-charge" pattern, distilled into a small dependency-free core.

Go · Idempotency · Event-driven · PostgreSQL

Easy Cantieri

A multi-tenant SaaS for Swiss construction tradespeople: quotes and invoices with native Swiss QR-bill, PDF generation, and strict per-tenant data isolation. I own every layer, from the schema and auth to deployment and observability. Currently in free beta.

Next.js · React · Prisma · PostgreSQL · NextAuth · Vercel

How I work

Defined engagements, delivered end to end

We agree on the problem, the scope, and what "done" looks like, then I design and deliver it. Typical work is a critical system build, an architecture redesign, a performance or reliability investigation, or untangling a monolith under load. Lately it also includes helping a team adopt AI in its work. For teams that want a continued hand on the architecture, ongoing advisory is available as a follow-on. I work async-first and arrange overlap hours around each engagement.

What's included

Architecture reviews and technical direction
Hands-on development and delivery
Written reports, architecture decision records, and handover docs
Standards that outlast the engagement: patterns and decisions your team can build on
A cadence that fits your team, no daily standups

What I don't do

Open-ended staff augmentation or "extra pair of hands" work
Engagements without a clear problem statement and a defined outcome
Full-time employment

When this fits

You own a system that has to be correct under real load: high concurrency, high throughput, hard consistency or compliance constraints, and you want it designed and delivered by someone who has shipped exactly that.

Start a project

Capabilities

What I work on

The problems I take on, and the tools I reach for to solve them.

Distributed & event-driven systems: Pipelines that move work between services without dropping or duplicating events, even when a downstream goes quiet.; Kafka · Webhooks · Background Workers
High-concurrency services: Handling peak load and contention so the same request never double-charges, double-books, or corrupts state.; Idempotency · Contention control · Background workers
Backend architecture & system design: Designing services and data flow that hold up as the team and the traffic grow, then untangling the parts that did not.; Python · Go · PHP · Django · FastAPI · Laravel
Data & storage: Choosing and shaping stores for the access patterns at hand, from transactional integrity to caching hot paths.; PostgreSQL · MongoDB · MySQL · Redis
Reliability & delivery: Shipping changes safely and knowing what production is doing, with the observability to find problems before users do.; CI/CD · Docker · New Relic · Sentry · AWS · Google Cloud
End-to-end product delivery: When a backend needs a face, I take the feature all the way to the user: typed, maintainable frontends held to the same standard as the services behind them. For when you want one person to own the whole thing, not just the API.; TypeScript · React · Vue · Next.js / Nuxt
AI integration & adoption: Adding LLM and AI features where they pay for themselves, scoped to real workflows with evaluation built in, and bringing a team up to speed on using them well.; LLM features · Retrieval · Evaluation · Team adoption

Experience

15+ years across regulated, high-traffic platforms

From building CRMs in 2011 to leading a marketplace backend today.

Resume One-page summary Full CV Full experience