01 Projects
Projects.
My work at a US B2B SaaS company, in six areas. Under each area are the parts I built. Real systems, real users. Client names are kept private.
06Area
MCP and AI agents
Designer and sole developerAI agents that do real work on live business data. Staff change pages, prices and settings by chat, and support gets faster answers. The AI can suggest, but the system checks, and nothing changes without a confirm.
- 1.1
MCP tool servers
A tool server next to each business service (MCP is the standard way to give an AI tools). Every change shows a preview and needs a confirm, and many changes can be undone exactly.
- 1.2
Agent service
One AI service runs admin chat, support replies, AI search and the AI page builder, with a measured limit on how much text each tool sends to the AI.
- 1.3
Public AI gateway
Lets customers connect their own AI assistant to their own data, with OAuth sign-in. The gateway sets the identity and never trusts the caller, and checks block the call when in doubt.
- 1.4
Prompt-injection guard
Text from users, emails or web pages is cleaned and marked as untrusted before the AI reads it, and a detector catches hidden changes in tool results.
- 1.5
Tool tests in CI
Each tool server has a contract with a hash, so an unplanned change breaks the build, and AI eval tests run on every code change. One server was redesigned to a much smaller tool set and became the pattern for the rest.
- 1.6
AI search for shoppers
A shopper types a normal sentence, the AI only names the needs, and code turns them into filters with fixed tables, so the same words always give the same results.
- 1.7
Support desk AI
Connects the support desk to the AI agent with a confirm before it acts, checks incoming message signatures safely, and puts each new support email into the right ticket.
- 1.8
AI usage billing
Charges for AI use by holding credits first and then charging or giving them back, and blocks AI calls if billing is down.
05Area
Multi-tenant website platform
Architect and main developerOne code base runs the public websites of many customers. Each site has its own domain, look and pages. New sites go live from shared code, and customer staff change their pages without a developer.
- 2.1
Tenant gate
Looks at each web request and picks the right customer site, so one code base can safely serve every site.
- 2.2
Caching system
Keeps pages fast with caches in layers, in the app and at the network edge, each with clear rules for when saved data is too old.
- 2.3
Edge routers
A small Go proxy and an edge worker send each request to the right site, and another edge worker serves images from cloud storage.
- 2.4
Page builder
Customer staff build pages from ready blocks, and any AI edit to a page is checked against the page version and a validator before it is saved.
- 2.5
Page move test kit
Moves old hand-coded pages into the page builder safely. It compares old and new pages pixel by pixel, by page structure and box by box, so even a small layout shift is caught.
- 2.6
Content system
A headless content system (it keeps the content, other apps show it) puts each new site on the least-busy database and finds it again fast with a cached map.
- 2.7
Local landing pages
Builds one page per nearby city for each customer with no copied or made-up text: every number is checked against real data, and pages that are too alike are caught.
04Area
Admin console
Creator and, in practice, only developerThe daily web app where staff manage items, pricing, sign-ups, pages, users and billing. It is for staff only, not for customers. Each person can do only what their role allows.
- 3.1
Staff console
One web app, for staff only, for items, pricing, sign-ups, pages, users and billing, with Stripe billing, live push messages and an installable app version.
- 3.2
Permission fix
Found that many server routes only checked a cookie and then used a full-power service key, and moved them to the real user's token plus a check for each action.
- 3.3
Backend for frontend
The browser talks only to the app's own server, which holds the keys and calls the services, so the browser never holds a service key.
- 3.4
Filter formula language
Staff type a filter formula, and a small parser turns it into a fast query that cannot grow out of control, then shows it back exactly as typed.
- 3.5
Shared admin UI kit
One shared front-end package for all admin web apps, so they look and work the same.
03Area
Backend services
Designed and built; set the standardsThe backend is many small services. Each one owns one business area, such as rules, payments, offers or login. All of them are built on one shared framework, so they work the same way and one fix reaches all of them.
- 4.1
Shared Python framework
One versioned library that every service is built on. It has tested parts, such as a lock that a late worker cannot break and a rate limiter that stays fair across many servers. Its shared database layer also has a text search that combines exact word ranking with typo-tolerant matching.
- 4.2
Admin app, moved in steps
A small admin backend needed to change faster, so it was moved into separate services one area at a time, with no big rewrite, until only a thin gateway was left. This fit that app and that team; it is not a rule for every team.
- 4.3
Business rule engine
Customer staff write "if this, then that" rules, and the system applies each rule to every matching item at once. One rule runs as a database or search query and is explained back in plain English.
- 4.4
Pricing system
A payment service shows correct monthly payment plans on customer websites, also in reverse (from a monthly budget to a price). The data collectors that feed it find hidden rates from an outside calculator's public payments with exact math, and save a value only when exactly one answer fits.
- 4.5
Offers engine
Picks which sales offers each customer site shows and where, by walking ordered rules. A failed stock count freezes the offer state instead of deleting, and a person's locked edits survive data imports.
- 4.6
API gateway
The front door for all backend APIs: it checks every login token once, passes a trusted identity to the services, and was hardened after security audits.
- 4.7
Login service
One login and single sign-on for every app, where reuse of an old refresh token cancels the whole token family, so a stolen token stops working.
02Area
Data and search
Creator and main developerEach customer's items come in from data feeds, get cleaned and checked, and land in a search engine that every website reads. Items stay correct and fresh without manual work, and shoppers never see a half-built result.
- 5.1
Items pipeline
Takes in data feeds, cleans them, applies each customer's rules, and puts each customer's items into a search index.
- 5.2
Search engine as main store
Moved the main data store to the search engine safely, step by step: a shadow copy, writes to both, copied the old data, compared the two, then switched.
- 5.3
Safe index rebuilds
A new search index is built next to the old one and swapped in one step. A lock that a late worker cannot break stops two rebuilds from fighting, and a loop finishes any rebuild that stopped halfway.
- 5.4
Feed change check
Compares each new feed with what is stored, using hashes so only real changes are written, and marks missing items as gone.
- 5.5
Stable search paging
Results are always sorted the same way and paged by position, not by page number, so going deep into search results never skips or repeats an item.
- 5.6
Rare features first
Ranks item features by how rare they are, the way search engines rank words, so the most special ones show first.
- 5.7
Search and database clusters
Created the container images for the company's own self-hosted OpenSearch cluster and its dashboards. I also created the database connection layer for the whole platform. I am the only developer of both.
01Area
DevOps and infrastructure
Architect and lead of the move; built the toolingThe servers, deploys and monitoring behind every service. The whole platform is written as reviewed code. It moved to Kubernetes with proof that no data was lost, and every service ships the same safe way.
- 6.1
Kubernetes move
Led the move of the services and databases to Kubernetes over planned nights, with dry runs, rehearsals and rollback notes. A checksum of the rows on both sides proved the data was the same.
- 6.2
Move generator
Turned the old hosting setup into Kubernetes files, worked out which service needs which, and started them in the right order, with CPU and memory sized from real use.
- 6.3
Infrastructure as code
The whole platform is described in reviewed files, the cluster is kept in line with them automatically, and metrics, logs and alerts watch it.
- 6.4
Shared CI/CD
One reusable deploy workflow for all services, and a script writes the small file each repo needs from one list, so every service ships the same way.
- 6.5
Database backups
Backups kept for different lengths of time, with a weekly automatic test that really restores one.
- 6.6
Event bus move
A bridge and a plan to move service messages from Redis Streams to Kafka without losing or doubling any. The switch point is taken from the last delivered message, not from clocks. I wrote the full plan, and wrote down the trade-off when the company chose a single switch.
- 6.7
Self-repair ops agent
AI agents look into and fix incidents, but act only after repeated failures and only within set risk levels.
- 6.8
AI coding workspace
A control layer over all service repos so AI coding agents can safely change the whole system. Rules load only when needed, a generated map shows which service talks to which, and it adds safe read-only tools for production logs and databases.