Software engineer for backend product systems, SaaS operations, and applied AI.

My best fit is in products that need clear backend structure, predictable operations, reliable contracts, and documentation that stays useful after the first release.

I am most useful in systems that do not live only on the happy path: billing, auth, queues, uploads, tenant boundaries, approval trails, and AI features that need cost limits and human-readable guardrails. I care about the repository surface, handoff quality, and the boring details that let another engineer or operator understand the product quickly.

Browse case studies Open GitHub

Backend product systems

APIs, service layers, approval flows, and repository surfaces that still make sense after the initial push.

Real SaaS operations

Billing, auth, queue-backed jobs, tenant isolation, and the operational detail that keeps a smaller product credible.

Applied AI with boundaries

AI features with cost limits, predictable fallbacks, auditable steps, and decisions that do not take the product away from operators.

Contracts, APIs, and integrations

API design, authentication flows, webhooks, billing integrations, and service-to-service boundaries with clear failure modes.

Jobs, pipelines, and operational behavior

Queues, background tasks, upload pipelines, release checklists, runbooks, and the inspection points that keep systems predictable.

Docs and technical handoff

Architecture notes, READMEs, deployment guides, case studies, and repository organization that helps another engineer get to useful context faster.

Stack

Tools and layers I work with most comfortably

The emphasis here is not tool volume. It is familiarity with what tends to show up in product systems that need to survive real usage.

Languages and runtimes

TypeScript
Node.js
Next.js
Express and Fastify
Python
React Native

Data and infrastructure

PostgreSQL
Prisma and Drizzle ORM
Supabase
Redis and BullMQ
Object storage
Docker Compose

Quality and delivery

GitHub Actions
Vitest and Jest
pytest
OpenAPI
Technical documentation
Repository standards

Start with these cases

Three reads that explain my work better than a bullet list

If I were introducing my work to a serious founder, recruiter, or tech lead, I would start with these paths first.

Read case study

OnboardPulse

A multi-tenant onboarding SaaS with billing, follow-up automation, storage controls, and product-like operational docs.

This project shows that I can work beyond CRUD: tenant isolation, budgeted AI usage, billing webhooks, storage policy, and cron-driven follow-ups.

MailSieve

A lightweight signup risk API with OpenAPI contract, key management workflow, rate limits, and deploy verification scripts.

MailSieve is a good example of a small API product where contract clarity, ops scripts, and monetization readiness matter more than feature count.

VOWGRID

A private case study for an agent-trust platform with simulation, policy evaluation, approvals, execution receipts, and rollback visibility.

The core signal is not just AI orchestration. It is the trust layer around execution: propose, simulate, evaluate, approve, execute, receipt, and rollback visibility.

Direct close

If the role needs backend product work with operational clarity, this is probably worth a conversation.

The clearest picture of my work lives in the combination of GitHub, case studies, and technical writing. The resume helps, but the proof gets stronger when those three surfaces are read together.

Products with billing, auth, queues, uploads, or automation that need to stay legible after launch.
Teams that value documentation, explicit trade-offs, and ownership beyond the happy path.
Remote or hybrid environments where written clarity and technical handoff matter.

Direct paths

Email, GitHub, and LinkedIn stay as the fastest way to reach me and inspect more context.