I build products end to end — data model, API, interface, deploy. Thirteen years of that, and a cybersecurity education that mostly shows up in the parts of a system nobody demos.
Things that actually ran, with numbers I can account for. Where something sensitive was involved, the card says what was done about it.
RETAIL
CRM for a retail chain
CRM for a large retail chain. It holds the whole customer base, the loyalty programme in full, and the machinery for surveys and prize draws — four subsystems working off the same profiles rather than four products stitched together.
PythonFastAPITypeScriptNext.js
600k+users in the database
HARDENINGCashier, marketer and administrator each see a different slice of a profile, and customer phone numbers and addresses are never shown in full. Points cannot be credited or spent twice — they are money — and prize draws are guarded against entries farmed across accounts.
B2B
Delivery ordering bot with a loyalty programme
A Telegram bot that takes orders and runs the points scheme for companies: ordering, statuses, earning and spending balances — on top of a client accounting system I did not control and which changed without warning. At least 60 orders a day. 2025.
PythonFastAPIagaiogram
30kregistered in the bot
HARDENINGPayments run through the provider, so card data never reaches our server. Nobody working the orders — operator, courier or venue owner — sees a customer's phone number or address in full.
EVENTS
Ticket aggregator for festivals
Ticket sales for the ComicCon and GeekCon festivals in Tashkent — one platform for both rather than a separate site per event. The load does not spread across days: it arrives in the minutes after sales open, so the thing is sized for that moment and not for an average afternoon. A ticket stays in the buyer's account and comes by email as well. Running since 2024.
PythonDjangoJavaScriptReact
40kregistered users
HARDENINGA ticket is good once: it cannot be sold twice and cannot be presented at the gate twice — the gate is checked by a system running on site. Payments and refunds are handled so the state of the ticket and the state of the payment cannot drift apart.
STUDIO
Booking and loyalty for a tattoo studio
Clients take a specific slot instead of asking when there is room, and the studio works off one schedule. The loyalty programme runs on the same client records rather than a separate ledger. Running since 2024.
PythonDjangoMySQLagaiogramJavaScriptNext.js
2k+clients in the database
HARDENINGTwo people cannot take the same slot: bookings that arrive at once are settled in the database rather than by whoever got there first. Client phone numbers are never shown in full, and an artist sees their own schedule and their own clients instead of the studio's whole book. Points cannot be credited or spent twice.
02 — Stack
What I actually build with.
Everything below has run in production. Nothing is on this list because it reads well.