I build AI systems with product teams.

I work with product and engineering teams on AI features, internal tools, and the workflows around them. I usually join when a prototype needs to become a production system, or when a team has started using coding agents but has not yet found a shared way to work with them. I write code alongside the team and leave the system in their hands.

Where I can help

An AI feature needs to become a product.

I can help with architecture, retrieval and evaluation pipelines, monitoring, and the less glamorous failure handling that production systems need.

Everyone is using coding agents differently.

We can turn individual experiments into a shared way of working: where agents help, where they need review, and what should remain a human decision.

The work needs another engineer.

I join the codebase, make technical decisions with the team, and implement the first version with the people who will maintain it.

How I usually work

Start with the code

I read the codebase, talk to the people who use and maintain it, and work out where AI is worth the added complexity. The result is a short technical plan with priorities and open risks.

Typically 2–4 weeks

Build with the team

I implement the first production version in your codebase. Architecture, evaluation, monitoring, and failure handling are part of the build — not a cleanup phase at the end.

Typically 2–4 months

Hand it over

Once the system is running, I step back. I can stay involved for code review, architecture questions, and mentoring the engineer who owns it.

Ongoing, 5–10 hrs/month

Past work

Before working on AI systems, I spent fifteen years building SaaS products, often around billing and payments. The examples below are not AI projects. They are here because the underlying work is familiar: making fragile systems dependable, changing architecture without stopping the product, and leaving the team with software it can maintain.

CheckoutX 2019 – 2021

Turning a checkout MVP into a reliable production system

$300k+ MRR · 200–300 RPS

Problem

CheckoutX already had customers, but the product was still built like an MVP. During traffic spikes, instability in the checkout flow could cost merchants real orders.

Work

Working with a small team, I helped stabilize the checkout flow and rework the architecture so it could handle peak traffic without dropping orders. The platform ran at 200–300 requests per second during peaks. We also separated platform-specific logic and expanded from Shopify to WooCommerce and BigCommerce.

Ruby Rails Stripe BlueSnap WooCommerce PostgreSQL PHP

Siter.io 2021 – 2022

Reworking pricing without slowing down releases

Churn down 60%

Problem

High churn — billing didn't match how customers actually used the product. No way to safely test pricing changes.

Work

Redesigned billing to monthly + usage-based plans via Stripe. Built A/B testing pipeline for pricing experiments. Release cycle went from 1 week to 1 day.

Ruby Rails Stripe PostgreSQL Redis

MMA Registry 2022 – 2023

Adding subscriptions to a legacy data platform

First subscription revenue

Problem

Outdated REST API, no documentation, no billing system, no CI/CD. The platform had users but no way to charge them.

Work

Built PayPal subscription billing from scratch. Upgraded API to OpenAPI/Swagger with AWS Gateway. Added CI pipeline, raised test coverage to 80%.

Ruby Rails OpenAPI PayPal AWS PostgreSQL

Tell me what you’re building.

A short email is enough. I’ll ask a few questions and tell you whether I’m the right person for it.

hello@vladmikhailov.com · LinkedIn