Not testimonials. The actual work, with the thinking behind it visible.

Operator scar tissue

A travel-eSIM platform — Chillsim — I architected, built, and continue to maintain for a client. Tens of thousands of users on top, seven product surfaces, two technical stacks, multiple upstream providers. The consumer app is the visible part. The layer underneath it — the one that abstracts every provider behind one API — is where the actual product lives. And it’s where the AI-native thesis already runs at commercial load.

• →Provider abstraction beats provider integration. Every eSIM provider has its own quirks, limits, and edge cases. The leverage isn’t integrating one well — it’s building the layer that makes the next provider take a week instead of a quarter.
• →Consumer, business, and partner channels on one backbone. Same API, same database, same operational team carrying all three. Bolting any of these on after the fact is the most expensive mistake in the segment.
• →The boring infrastructure is the product. Refund flows, idempotent payments, GDPR deletion, per-partner data isolation, provider failover. None of these get featured anywhere. All of them kill the business if you get them wrong.
• →Scale is a configuration change, not a rebuild — *if you scoped it that way from day one*. The architecture serving the first 50k users should be the same shape serving the next 10×; what changes is the count of instances, not the system. If your growth plan involves a rewrite at the next zero, the scoping was wrong before the load got there.
• →And the code is AI-native, not just AI-flavored. The Hub orchestrator, reseller platform, and Hub admin UI I built from scratch — AI as the sidekick, under my review — end-to-end in 333 billable hours, one operator. The retail stack (originally a whitelabel fork) has since been refactored and enriched AI-native end-to-end. The thesis isn’t a pitch here — it’s in production, with tens of thousands of users on top.

Live · AI-native, in continuous improvement · long-form teardown drafting · expected Q4 2026

AI-native, end-to-end

An ANAF-integrated invoice and accounting platform, built AI-native end-to-end. Fully functional, in daily internal use — we run the company’s books on it. If Chillsim proves the AI-native thesis at commercial scale, this one proves we trust it enough to bet our own operations on the result.

• →Real Romanian compliance baked in. ANAF e-Factura (OAuth2, SPV submit/status/messages, reconciliation against the sent list), proper CUI/TVA handling, EUR/RON exchange-rate-aware ledger. The boring regulatory work that makes a freelancer pick this over Excel.
• →Both sides of the ledger, both ways in. Issued invoices via the admin UI. Received invoices via backfill from ANAF SPV ZIPs, plus manual entry for the suppliers who don’t use ANAF yet. Real bookkeeping doesn’t only happen inside one government API.
• →Bank statements as a first-class citizen. MT940 ingest, reconciliation, CSV exports formatted the way bookkeepers actually want them — dates Excel parses as dates, account columns named correctly, deposit references intact. Not a checkbox feature; a workflow.
• →Built AI-native, end-to-end. API in FastAPI + SQLAlchemy 2.0; admin in React + TanStack Query v5; types generated from OpenAPI so frontend and backend can’t drift apart. Architecture, models, services, hooks — drafted by AI under human review. The judgement layer catches what the model misses; those moments become Field Notes.
• →Future, on the public roadmap. SaaS for Romanian sole traders and micro-SRLs. Stripe integration so invoices get paid one-click from the same page they’re viewed on. Possible expansion into full freelancer operations — task management, time tracking, billing — for any freelancer, not just programmers. ANAF e-Factura just became mandatory for B2B in Romania; the timing isn’t accidental.

Live · in active internal use · SaaS spinoff planned

Open-source · MVP

A memory layer for AI-native work. One database, any LLM. Your project context follows you across vendors, sessions, and machines — instead of being locked inside whichever assistant you used last.

• →The vendor-lock problem. Every LLM vendor now ships a memory feature, and none of them are interoperable. Your project context is trapped in whichever assistant you used last; starting fresh with a different model means re-teaching it everything you’ve already explained.
• →What this is. An MCP server with a typed store — projects, notes, references — that any MCP-compatible LLM can read and write. Switch from Claude to GPT to a local model, your context follows.
• →Dogfooded daily. We use it on the EvoBytes work. The agent helping write this Receipt is using this exact server right now — it’s what lets it carry knowledge across sessions and projects without re-onboarding.
• →Open-source release planned. Distribution by usefulness, not marketing. Every developer who installs it sees the project name; that’s the only ad budget we want to spend.

MVP · in internal use · open-source release planned

Teardowns

A series we’re starting: take a public product or business failure, and write what we’d build differently in 2026, with these tools, with this judgement.

• →A failed B2B SaaS we watched die in real time. What scoping looked like in 2021 vs. now.
• →A consumer app that lost its market by shipping the wrong feature first. A teardown of the roadmap with the alternate timeline.
• →A regulated industry tool that got compliance wrong. What we’d build differently, given what we learned at the carrier.

First teardown drafting · expected July 2026

Tools

A real, useful tool: what would building this cost in 2026, vs. what it would have cost in 2021? Answer five questions, get an honest range. No email gate. No sales follow-up.

In design · expected Q3 2026