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 clean seams 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 fail loudly when they shouldn’t.

How I think about these trade-offs

Case Notes

Four classes of problem I see repeatedly, and how I approach each.

When the algorithm beats the AI

The problem
Inbound request routing in a B2B support or ops platform — thousands of items per minute at peak. Looks 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
I sample a week of production traffic before choosing. In most B2B ops pipelines, a dozen rules cover the large majority of volume and the remainder clusters into a handful of 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.
What it buys you
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 the only path

The problem
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.
What it buys you
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.

Building a SaaS from zero

The problem
Founder with a clear wedge, a design partner with a hard deadline, a product spec that’s still moving. The shape of the product will change; the shape of the foundation can’t.
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. Permanent decisions right on day one, everything else deferred behind clean seams. 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.
What it buys you
The design partner launches on the original date, and the foundation absorbs product pivots without a rewrite. 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 problem
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.
What it buys you
A three-figure monthly infrastructure bill, no on-call rotation, weeks of uninterrupted ignore-ability. 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 ignore it for weeks. Boring is a feature.

Engagement shapes

How we’d work together

Three common shapes of engagement. Most projects start as one and sometimes become 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.