Sumit Chavda on the difference between learning to build software and learning what software has to survive: real catalogues, real orders, and the particular humility of shipping to a store that is open for business.
Courses and documentation taught me to build things. Running e-commerce technology for a live jewellery brand taught me what things have to survive. The gap between those two educations is larger than I expected, and almost everything I believe about how software should be built came from the second one.
Real data is not like sample data
Every tutorial catalogue is tidy. Every real one is not. Products with no cost price recorded. Made-to-order items that are available to buy but show zero inventory. Titles with inconsistent casing and stray characters. Variants that exist for operational reasons nobody remembers. Prices that are placeholders someone forgot.
You cannot write correct logic against a catalogue you have not met. The first thing I learned to do before building anything is go and look at the actual data, at the ugly end of it, and decide deliberately what each edge case should do. Which is why our sorting engine reports zero margin where cost price is missing rather than inventing a number, and labels the option 'estimated' on the product page. A tutorial would have quietly defaulted it to something plausible and been wrong in a way nobody noticed.
Shipping to an open shop changes your definition of done
When your deploy target is a storefront that customers are on right now, 'it works' stops being a sufficient standard. The questions become: what does this do if it fails halfway? Can it be reversed in one action? Will the person who finds it broken at 11pm understand what they are seeing?
That is where our habit of verification came from. It was not a methodology I read about and adopted. It was the direct result of being the person who would have to explain a scrambled collection page to someone whose revenue it was.
The bug that taught me the most
While building the sorting engine, positions were being computed against a filtered list rather than the full one. On the tidy test data it was right every time. The moment one unexpected product appeared in the collection, every insert after it skewed by one. Small, invisible in a demo, and it would have silently mis-ordered real collections for months.
A test suite found it before a customer did. That case is now permanently in the suite, alongside more than 78,000 others, and it runs on every build. The lesson was not 'write tests' — everyone says that. It was that the bugs that matter are the ones that look correct, and only real-shaped data or deliberate adversarial testing will surface them.
Merchants know things engineers do not
The percentage-slot idea in SellRank — describe a collection as 'the first twenty percent is in-stock bestsellers, the next twenty percent is new arrivals' — did not come from an engineering insight. It came from watching how a merchandiser actually thinks about a page. They do not think in sort orders. They think in zones, and in what each zone should be doing.
I would not have designed that feature from first principles. It came from being close enough to the work to overhear how the problem is really framed. The general lesson: the domain expert's vocabulary usually contains the design, if you listen instead of translating it into yours too early.
What I would tell someone starting out
- Get close to a real business with real data as early as you can, even if the work is unglamorous. It teaches faster than any course.
- When you find an edge case, decide what it should do and write it down. Defaults chosen by accident are where wrong answers hide.
- Assume your happy-path test is lying to you. Go looking for the input that breaks the assumption you did not know you had.
- Listen to how domain experts describe the problem before you rename it in technical terms. Their framing is data.
None of that is advanced. It is just the part that is hard to learn without a live store on the other end of your deploys.
