Third step. How I joined a real project

I was offered a simple job. Dispatcher.

A project in Miami. Delivery. Drivers. Clients. $150–250 a day.

No development. Just stay in touch, connect people, check payments.

At that moment it suited me. I needed money. Minimum responsibility.

I joined the project exactly that way — as a dispatcher. Not as a partner. Not as a developer. Not as a "savior."

The project was in an early stage. Few orders. No one was rushing anywhere.

And that gave me a rare opportunity — to calmly look at how everything worked.

How orders come in. How drivers get tasks. How dispatchers hold the logistics together. How a business actually lives from the inside.

I didn't push forward. I just watched.

But pretty quickly it became clear that I wasn't only interested in "how things get delivered." I was interested in what the whole thing rested on.

I started asking questions. Not to show off. But because some things didn't add up.

Who runs the website? Who owns the servers? Who can change something if needed?

The answers were murky.

So I went to look myself. Not the design. Not the marketing. Just — where the control was and who had it.

And that's where the strangeness began.

Too many limitations. Too slow on changes. Too much talk and too little action.

For now it looked like "well, it's a startup, happens." But the feeling was unpleasant.

I wasn't drawing conclusions yet. I was just taking note.

At that moment I still thought this was a story about working as a dispatcher.

I didn't yet know that within a few weeks I'd ask myself a question that would change everything: does this business actually belong to the person running it?

Third step. Why fixing it was pointless

At first I just watched.

I watched: how orders come in, how drivers are assigned, how the logistics holds together, how all of it isn't yet falling apart.

And, as usual, I started asking questions. Not out of curiosity. But because some things didn't add up.

I went to look at the website. Not the design. Not the marketing. Just — what it all stood on and who managed it.

The picture was unpleasant.

A few months earlier the owner had been sold a "ready-made solution": frontend, backend, everything turnkey — for $45,000. Plus $4,500 a month for support.

He was promised there would be no problems. In reality — there were more problems than solutions.

Very quickly the main thing became clear: the project didn't belong to him.

The servers — not his. No access. No keys. The domain — also not his. Formally. By contract.

He'd invested in the business: warehouses, drivers, an office. But the digital part was entirely under someone else's control.

Any change — slow. Any edit — for money. Any question — through calls and promises to "pass it on to the developers."

For a while I tried to give advice. Pointed out the weak spots. Explained that you can't run things this way.

But it became clear pretty fast: there was nothing to fix here.

This isn't a broken system. It was designed this way.

The project was set up not as a service for the business, but as a mechanism of permanent dependency.

At some point I asked the question straight: do you actually own this?

And right there a thought appeared for the first time, one I didn't even want to say out loud at first: could the same thing be built, but in a way that actually belongs to the owner?

Not patch it up. Not duct-tape it. But rebuild from scratch.

That was exactly the moment it became clear: fixing this project was pointless.

If anything was going to be done next — it had to be from zero.

Third step. When the experiments ended

I did this project alone. No team. No office. No calls. No "let's discuss it."

There was a real business. Real orders. And the understanding that there was no time to ease in.

I wrote the project from scratch. Not as "development." But as solving a problem: so the system would accept orders, assign drivers, calculate delivery, and run in production.

The main work happened in one console — where all the code and logic lived.

In parallel, other tasks came up. Something would break somewhere. Somewhere an idea needed to be tested. Somewhere a problem needed to be looked at from another angle.

At some point it was no longer "writing code," but managing several streams at once. How exactly — that's a separate story.

There were many bugs. Even more glitches. Sometimes it felt like everything would fall apart.

But after three weeks the system was running. Not perfect. Not pretty. But it took orders, distributed them, and worked with real people.

Then there was another week or week and a half to close the most critical holes.

And a separate story with the domain. On principle, I didn't want to continue until it was under control. We had to fight for it.

Once the domain was ours, everything got simpler.

The old system was switched off. The new one — switched on. Traffic was migrated. Orders started coming in.

All the functionality of the old project had been carried over. Without monthly tribute. Without dependency on someone else's decisions.

My friend now pays me a salary. And as long as his business exists, I have work. And he — finally has his own project, not a rented one. A project that's no longer scary to grow.

I don't romanticize this experience. It was hard. Scary in places.

But this was where it became finally clear: the experiments were over. Real work had begun.

About the inner kitchen — how not to drown, not to lose the logic, and not to break — that's the next conversation.