Building a Real Burger E-commerce Taught Me More Than Any Tutorial Ever Did

#showdev #webdev #typescript #react

When I started this project, I thought I knew exactly what I was doing.

A small burger place needed a digital menu, a way to take orders, and eventually accept payments. Nothing too ambitious. I had built interfaces before, worked with APIs, handled state.

It felt like something I could finish quickly.

That assumption didn’t last long.

What looked like a simple menu turned into a constant series of small decisions that actually mattered. Not the kind you solve with a library or a tutorial, but the kind that come from dealing with real users and real constraints.

The first thing that changed my perspective was the data.

At the beginning, I treated products like static items. Name, price, image. Render a card and move on.

But that model breaks almost immediately in a real scenario.

Some burgers had multiple sizes. Others didn’t. Some had temporary discounts. Drinks were fixed. Combos mixed different rules. And then there was stock, which isn’t something you can fake if someone is actually trying to buy.

The UI started getting messy, not because of styling, but because the data didn’t reflect reality.

I had to step back and stop thinking in terms of components. The real problem wasn’t how things looked, but how things were defined.

Once I restructured the data to describe behavior instead of just content, everything became easier to reason about. The UI stopped fighting back.

Then came the cart.

This is where things quietly fall apart if you’re not careful.

Adding a product is easy. But a product with variations, custom notes, and dynamic pricing is not just “an item” anymore.

At one point, too much of that logic lived inside components. It worked, but it was fragile. Every small change had side effects somewhere else.

I moved that logic into a centralized context, not because it was trendy, but because I needed control.

After that, the components became predictable again. They stopped being responsible for decisions and went back to doing what they should do: represent state.

That shift made the whole app feel stable.

The WhatsApp integration was another moment where expectations didn’t match reality.

Technically, sending a message is trivial. It’s just a link.

But what arrives on the other end matters more than how you send it.

If the message is messy, incomplete, or hard to read, the business suffers. Orders get misunderstood. Time is lost. Mistakes happen.

So instead of thinking about the integration itself, I focused on the output.

I built a formatter that turns the cart into something structured and readable. Clear product names, quantities, totals, user info, delivery details.

Now the message actually works for the person receiving it.

That changed more than I expected.

At some point I started looking into payments, specifically Mercado Pago.

That’s when I realized something I had been ignoring.

Payments don’t fix a bad flow.

If the process is confusing, adding a payment button just makes things worse. People don’t complete what they don’t understand.

So I paused that part and focused on making the ordering experience feel natural first. Clear steps, no surprises, no friction that didn’t need to exist.

Only after that does it make sense to introduce payments.

What this project really did was change how I approach building things.

I stopped thinking in terms of “features” and started thinking in terms of behavior.

I stopped assuming that a clean UI means a simple system.

And more importantly, I stopped relying on ideal scenarios.

Real users don’t follow perfect paths. They make unexpected choices, skip steps, change their minds. If your system can’t handle that, it doesn’t matter how good your code looks.

I didn’t build something revolutionary.

But I built something that works in a real environment, with real constraints, and that forced me to make better decisions than any tutorial ever did.

And that, at least for me, was the part that actually mattered.