How I started writing a delivery system
Enough chatter. Let's get to the process. I'll keep technical terms to a minimum so the overall picture stays clear.
Here's what I had on input: there was a delivery website, I was the dispatcher in it, there were drivers, products, a storefront, orders. And in fact — it was already a working business, which didn't belong to us.
The domain wasn't ours. The server wasn't ours. Nothing at all was ours.
The only thing I had was access to the admin panel.
In a normal situation it goes like this: you sit the client down in front of you and pull the business logic out of them. How the product moves — from the warehouse to the customer or the other way around. How the money flows. Everything else — promo codes, referrals — that's already a layer on top, not needed at the start.
But my client was already too pushy. Explaining anything was beneath him. And honestly, I was just as unwilling to drag it out of him. I quickly figured it would take a month, and I decided to go a different way.
I just went head-on.
I opened Claude, dumped a pile of screenshots into it — the storefront of the site, the interfaces, everything I could see — and explained in my own words what I wanted. No formalities, just as it was.
After that I went into Claude Code and gave it the login and password to the admin panel. It started up, spun up a browser through Puppeteer, and spent quite a while doing something — walking through pages, intercepting network requests. In the end it found all the API endpoints.
Translated into human terms — it picked the keys to the entire business logic of the project.
And right at that moment it became clear: I don't need to pull the logic out of the client. It's all already there inside the system.
I had the option not just to "look" at how it works, but to pull out the database and take the system apart as a whole. I asked it to analyze all of this and loaded that analysis back into Claude.
Then the most interesting part started.
Claude itself suggested how to structure the work. It said: create a project and load everything into it — storefront screenshots, admin panel screenshots, technical info on the API, the whole analysis. In other words, assemble a unified "project knowledge."
After that, in the same chat, it wrote a full technical spec. It chose what to write the frontend in, what to write the backend in, and produced a 30-day development plan — with concrete tasks for each day.
I loaded all of this back into the project memory.
Then came pure mechanics. I'd go into the project, take the task for the day, copy it into a new chat, get the code, and hand it off to Claude Code, which was already writing the actual project.
The first days went without issues. Then the nuances began.
The main problem — each chat couldn't see its neighbor. It had the general idea, but the code started living its own life. It was drifting, the structure started sprawling.
That's when I first understood that you have to give constraints. Not just "write code," but say clearly: don't break the structure, adapt to what already exists, stay within the lines. Without that it would start guessing.
The first ten days we were doing the backend — structure, folders, logic. And I had no idea what exactly it was writing.
And at some point I caught myself with a simple thought: if all this falls apart now — I won't put it back together.
And at that moment an unpleasant feeling sets in.
You've already gone too far to stop.
But at the same time you have no control over what's happening inside.
You don't understand the code. You don't understand the architecture. You don't understand what's actually holding the system together.
And the only thing you have — is the feeling that it hasn't fallen apart yet.
And on that feeling you keep going forward.
Somewhere around the tenth day it became noticeable that I was starting to drift away from the original plan. I had to dig back into the "project knowledge" and fix it so it would hallucinate less.
And exactly at that moment I ran into context compression. When the session grows large, Claude Code compresses the history — turns it into a short summary to free up space. And in that summary the wrong things settle. After such compression it could be carried off in a completely different direction. At that point I still didn't understand how to control this.
Thirty days passed like that.
In fact the entire project was written — frontend, backend, logic. What was inside it — I didn't have the slightest idea.
After that it's simple: domain, server, deploy. I gave the command — ship and launch.
And it launched.
I saw a site that looked very similar to the original. I connected the original database and got the ability to run all of this on real customers without redirecting traffic yet.
And right there reality kicked in.
Almost nothing worked. But the site existed.
I went down the chain: registration, order, statuses, logic. I started understanding what was missing: the dispatcher panel, the interface for drivers. I didn't want to write separate mobile apps, so I did everything through Telegram mini apps — it managed those fine.
Next — bugs. Lots of them. A whole lot.
You just describe what's not working, show how it should be, and it starts fixing. Sometimes it lands, sometimes it breaks things even worse. Classic — fixed three things, the fourth breaks everything back.
But gradually you can see the bugs becoming fewer.
Then comes the boldness — you start adding features: promo codes, discounts, referrals. And at some point it starts to seem to you that it's working.
You call someone over. They come in. They register. They place an order.
And the chain goes through: order created, dispatcher received it, driver delivered it, everything was logged in the system.
And you're sitting there not believing it.
Next — the migration.
I moved the domain to my server and synced the database, so the old users wouldn't even notice the switch.
The first order came in about ten minutes later. Then the second. Both went through fine.
That state is hard to describe.
After that real production began.
Nobody was filing bugs. They just called and yelled. They wanted to roll back. Honestly, I didn't care. I just took problems by priority and fixed them.
To my friend's credit — he didn't push once. He just waited.
And when they offered him to come back, he answered very simply: pay forty for the project and five a month — and we'll come back.
That ended the conversation.
And right at that moment it became completely clear:
this isn't about code at all. and not about neural nets.
it's about the ability to take chaos and drag it to a working system before it falls apart.
Full project stack. Last-mile delivery.
I didn't know what exactly I had written.
A couple of weeks after launch my daughter flew in. We went out to hang, she said something about me, and one guy — a tech guy — went out to smoke with me.
He started asking:
— what are you writing it in? — what's the stack? — how is it built?
I said honestly: I don't know.
I pulled out my phone. I asked Claude Code — what am I even writing in?
The answer stopped me.
I re-read it for several days. Then I loaded the whole project into NotebookLM and started figuring out what I had actually assembled.
Below — what it gave me.
—
Backend NestJS 10 · TypeORM · PostgreSQL 16 · Redis 7 Auth: JWT + Passport + bcrypt WebSocket: Socket.IO + Redis adapter Validation, rate limiting, cron, Swagger
33 modules · 35 entities · ~150 endpoints
—
Integrations Email — Brevo SMS — own Android gateway WhatsApp — multi-node gateway Push — Pushover Crypto — BTC, ETH, USDT, USDC, TRC-20
—
Frontend Storefront — Next.js 14, SSR, en/ru/es ️ Admin panel — React 18 + Zustand Mini apps (dispatcher, driver, sales) — React 19
—
Telegram bots — 3 of them Python 3.12 · aiogram · asyncpg · Redis
—
Infrastructure Docker multi-stage · GitHub Actions CI/CD · GHCR nginx (SSL, WebSocket, gzip) · Cloudflare 10+ services in docker-compose
—
I didn't "choose" this. I didn't "design" this. I didn't even know half of these words.
I was just solving a task.
And only afterward I realized: I had assembled a system that's usually built by a team of several people.
—
This doesn't mean you can now understand nothing.
It means something else:
the entry point isn't where it used to be drawn.
If before you had to learn the stack first and only then do something —
now you can do first,
and figure out afterward what exactly you did.