We made saving a product 14 times faster. Here is what we learned

A merchant changes one price and presses save. Then they wait. Nine seconds.

Nine seconds does not sound like much until you picture it. Someone is updating forty products before a weekend sale, on a phone, between customers. Every save is a small pause where they wonder if it worked. Some of them press save again. Some of them give up and do it tomorrow.

I knew parts of our dashboard felt slow. What I did not know, until we measured it properly, was why. This post is about what we found, what we changed, and what I would tell another small team before they start the same work.

The problem was distance, not power

The usual instinct is to blame the hardware. The servers must be too small. The database must be struggling.

Neither was true. When we looked at the database itself, it was barely working. Each question it was asked took a fraction of a millisecond to answer.

The cost was in the trip. Every time our code asks the database a question, the question travels to the database and the answer travels back. Our merchants are in Uganda. A lot of internet infrastructure is not. Each of those round trips took about a quarter of a second.

So the real question became: how many trips does one save make?

The answer was 36. To change one title.

Thirty-six trips at a quarter of a second each is nine seconds. The mystery was over. Nothing was broken. We were simply asking far too many questions, one after another, and paying for the journey every time.

What we changed

None of this is clever. That is the point.

Ask once who is allowed. Before doing anything, the app checked several things separately: is this person part of the store, is the store set up, is the plan active, what is their role. Each check was its own trip. Now one question returns all of it. Because every screen starts with that check, every screen got faster, not only the one we were fixing.

Save only what changed. The old save rewrote everything on the product every time. Every variant, every option, every photo, even if you only fixed a typo in the title. The new save compares your edit with what is already stored and writes the difference. A title change is now one read and one write.

Handle the whole cart at once. Holding stock for an order used to cost a few trips per item. A cart with ten items made ten times the trips of a cart with one. Now it is the same small number of trips whatever the size of the cart.

Ask unrelated questions together. Checkout needs to know many independent things before it places an order: the delivery zone, the payment method, the products. We used to ask them in a queue. Now they go out together and we wait once.

Move the code closer to the data. After cutting the number of trips, we tested shortening the trips themselves by running the code right next to the database. The request still travels from the merchant once, but everything after that is a short hop.

The numbers

These are from our test environment, timed from Kampala, on the same product before and after.

We timed 31 different dashboard requests on the old version and the new one. All 31 got faster.

Do

• Count before you fix. The first thing we built was a counter that reports how many questions each request asks. Every change after that had a before and an after. Without the counter we would have been guessing.
• Fix the count before you buy speed. Moving the code closer to the data helped a lot, but only after the count was down. Do it the other way round and you hide the waste instead of removing it.
• Keep every rule. Fewer questions, same rules. Stock still cannot go below zero. Two people editing the same product still cannot overwrite each other. If a shortcut needed a rule to bend, we did not take the shortcut.
• Prove it on real data. Tests with a pretend database told us the logic was right. Only real orders on a real database told us the stock numbers ended exactly where they started.
• Change one thing at a time. Small steps, each one measured, each one easy to undo.

Don't

• Don't trust your own laptop. Everything is fast when the database is beside you. Measure from where your customers are.
• Don't reach for a cache first. A cache makes the second visit fast and leaves the first one slow. It also adds a new way to show people something out of date. Remove the waste, then decide if you still need one.
• Don't follow the plan blindly. Our plan had one change that looked like free speed. When we checked, it would have made the store less accurate for shoppers in exchange. We left it out. A plan is a list of guesses until you test each one.
• Don't rewrite everything. The slow parts were a handful of busy paths. Most of the code was never the problem.

What I learned

Slowness is rarely one big mistake. Ours was dozens of reasonable decisions, each adding one more small question, none of them worth worrying about alone. Nobody wrote a nine second save. It grew.

Most of this work was done alongside AI coding agents. The typing was not the hard part. The hard part was holding the line on proof: measure first, keep the rules, test on real data, and say plainly when something is not finished. That discipline is what makes the speed trustworthy.

It is also worth remembering what speed is for. A merchant does not experience our architecture. They experience whether the thing they pressed worked, right now. When it does, they trust it, and they come back and do the next task. Speed is not a feature on a list. It is how the product tells you it is taking your business seriously.

This work is running in our test environment today and will reach every store once it has finished review.