Available for projects · Remote from the US · Working with teams worldwide

Full-cycle product delivery.
AI where it earns its keep.

Independent engineer for founders and product teams building SaaS, internal AI systems, and automation. I own delivery end-to-end — from architecture to the pager — and give you a straight answer on when AI actually pays off and when it doesn’t.

Start a project How I work

What I do

Services

  • Full-Cycle Delivery

    Discovery, architecture, build, deploy, and operate — by one person. No handoffs, no “that’s the other vendor’s problem.” The engineer writing the code is the one carrying the pager after launch.

  • AI Integration, Done Honestly

    Production LLM and agent systems where they move a metric: extraction, classification, workflow automation, customer-facing assistants. Eval-driven, with guardrails, fallbacks, and cost controls from day one. If a deterministic approach is cheaper and more reliable, I’ll tell you and build it that way.

  • SaaS & Micro-SaaS from Zero

    From empty repo to first paying customer. I get the foundations right — tenancy, auth, billing hooks, observability — and defer everything else behind clear boundaries so the product can pivot without a rewrite. Typical first production slice: 4–8 weeks.

  • Automation & Internal Tools

    Agents and pipelines that remove recurring manual work: document processing, support triage, data extraction, operational workflows. Built to run unattended and raise clear alerts when they cannot complete safely.

How I evaluate trade-offs

Decision Notes

Four recurring engineering decisions, and the default reasoning I bring to each before writing code.

When an algorithm beats AI

The decision
Inbound request routing in a B2B support or ops platform — high volume, repeated patterns, strict latency expectations. It can look like an LLM job at first glance.
The options
(a) An LLM classifier with a structured output schema, (b) a small fine-tuned encoder model, (c) deterministic rules plus a lookup table driven by measured traffic distribution.
My default
Start with a representative sample before choosing the model class. In many B2B ops pipelines, a small set of rules covers most volume and the remainder clusters into tenant-tier × product-line buckets. Rules plus lookup for the hot path; a cheap small-model classifier for the long tail; no LLM on the live path.
Why
Millisecond-range latency, near-zero variable cost, a classifier an on-call engineer can debug at 3 a.m. without looking up an API key. The trade: harder to extend to categories that don’t exist yet. For constrained inputs, that’s a good trade. Reach for an LLM when the input space is genuinely unbounded — not by default.

When AI is justified

The decision
Structured extraction from high-variance documents — statements, invoices, onboarding forms — arriving in dozens of layouts from different originators. Regex-and-template pipelines accrete for years in this setting; every new counterparty format breaks something upstream. Maintenance cost grows faster than the team can shrink it.
The options
Keep patching rules, build a classical NLP pipeline with hand-crafted features, or use an LLM with a typed output schema and engineered guardrails.
My default
The LLM path, with the engineering around the model doing most of the work. A Pydantic-typed output schema enforced via tool-use / function-calling. Deterministic post-validators for field-level invariants — date ranges, sum checks, currency-format matches. An evaluation set that grows with production — starts around 40 examples, stabilizes in the hundreds. A confidence-gated human-in-the-loop fallback for low-confidence outputs. A pre-flight OCR-quality check so garbage inputs never reach the model — most “prompt failures” in this domain are scan-quality failures.
Why
The rule-patching treadmill ends. Engineering attention shifts from regex archaeology to eval curation, which is the better place to spend the day. You trade per-call cost and variable latency for maintenance cost that stays roughly flat as customers grow.

Choosing SaaS foundations from zero

The decision
Founder with a clear wedge, an early customer conversation, and a product spec that’s still moving. The product will change; the foundation should not force a rewrite when it does.
The options
A fast no-code MVP, a heavyweight enterprise stack chosen for an imagined future, or a narrow production-grade foundation limited to the decisions that are expensive to change later.
My default
The narrow foundation. Make the permanent decisions on day one and defer everything else behind explicit boundaries. Tenancy: shared-schema multi-tenancy in Postgres with row-level security enforcing boundaries at the database — an application-layer WHERE-clause bug cannot leak data. Tenant context: set once per request in middleware, propagated into queries, logs, metrics, and error tracking. Billing hooks, not billing: a tenant_id on every metered event from day one, so a real billing system dropped in later is a migration, not a rewrite. Observability: structured logs and traces tagged with tenant_id from the first commit. A tenant-level kill switch wired in before the first paying customer.
Why
You get a production slice that can absorb product pivots without pretending the future is already known. What gets skipped early is what you pay for later — usually at 3 a.m. Microservices, real-time analytics, and custom RBAC beyond role + tenant wait until they actually earn their complexity.

Shipping a micro-SaaS solo

The decision
One operator, narrow audience, no team, no runway. Binding constraint is operational, not architectural: cheap to run, boring to operate, survives weeks of inattention without waking anyone up.
The options
A fashionable distributed stack on a managed platform, serverless across a dozen managed services, or a deliberately unfashionable monolith on a single VPS with managed Postgres.
My default
The boring monolith. A Django or FastAPI app on a single VPS, managed Postgres as the only stateful dependency, Stripe Checkout (hosted) so no PCI surface is owned, webhook handlers in the same monolith with idempotency keys on every incoming event, Sentry for errors, uptime monitoring configured to page only when the site is actually down — not when a metric wiggles. The job queue is a Postgres table. The next version is also a Postgres table. Redis is rarely necessary at this scale.
Why
A three-figure monthly infrastructure bill, no on-call rotation, and fewer moving parts to babysit. You trade instant horizontal scaling and multi-region latency for operational silence. For a micro-SaaS, the right architecture is the one that lets you leave it alone between focused maintenance windows. Boring is a feature.

Engagement shapes

How we’d work together

Three common shapes of engagement. Most work starts as one and sometimes becomes another.

How I work

Approach

  • Ship first, iterate with signal.

    Useful software in production beats perfect software in a branch. Real users generate better requirements than meeting rooms.

  • AI is a tool, not a strategy.

    I reach for it when the input space is open-ended or the maintenance cost of rules is growing faster than the team. When a deterministic approach is simpler, cheaper, and more reliable, I’ll tell you and build it that way. Evals and cost ceilings from day one, not after the bill arrives.

  • Own the full stack of delivery.

    From design decisions to production incidents. The person writing the code is the person carrying the pager.

  • Async-first. Written. Transparent.

    Short written updates, visible progress, decisions documented where you can find them six months later.

Get in touch

Tell me what you’re building.

A sharp email beats a form. Send what you have — problem, constraints, timeline — and I’ll reply with specifics.

I reply within two business days with a direct answer: fit, rough timeline, and what a first step looks like. If it’s not a fit, I’ll say so and point you somewhere useful.