Moving on
The newest news is that I’m no longer working on my storefront software. If I could get back all the time and energy I spent on the project, I’m not sure that I would, because I’d no doubt make the same mistakes elsewhere, on another project.
Of course, some post-mortem advice is product-specific, but here’s what I’ve learned and what I plan to look out for in the future.
1. Never underestimate the breadth and depth required of an ecommerce product.
2. Never go it alone in trying to compete with teams of people. The best abstractions and architecture won’t give you enough of a leg-up. Playing catch-up is still playing catch-up.
3. If your innovation makes up only a small piece of the pie, don’t waste your time making the rest of the pie. Be smart and stand on someone else’s shoulders!
4. Don’t get bogged down by ideologies about tools and architecture if you are not selling tools or architecture. I spent a lot of time creating my own abstractions, refining my tools, tweaking my architecture, because I thought they were better. My tools and abstractions have no user base to speak of so they were useless as an enticement to customers. I was trying to kill two birds with one stone:
“See, my tools are great .. look at the robust application I built with them! Do you want to buy my product?“
It is possible nobody was enticed because I SUCK at taking a product from prototype to “this apps looks great, functions great, I gotta have it!” If you don’t have that quality, find someone that does, or find a product you can make that doesn’t require this quality, or stick to pay-by-the-hour software development.
What were my innovations?
Here’s where I spill the beans. Briefly.
Layers on top of the core
All base functionality resides in core classes. Developers can make their changes in classes that extend the core. If you need to customize the logic that does X, implement your own methods that are involved in doing X. This extensibility was baked in from the start.
Every bit of text can be multi-lingual
The product table, which contained non-text data, was accompanied by a productTranslation table. Fields:
id, productId, languageId, title, description, ETC
Repeat this structure for product options, categories, stores, and so on.
Product option combinations
A product can have any number of options (small, red, medium), which are grouped (color, size). Every combination of these can have its own price:
Small, red shirt: $15
Small, blue shirt: $14
Medium, red shirt: $14
Medium, blue shirt: not available
Tables: option (“Small”, in the “Color” group), option_combination (joins option to combination), combination (holds the price)
The logic required to make this all work was very tricky, but now it’s stable and robust. Alas …
…….
That’s all folks. Thanks for reading. And as always, feel free to contact me with questions, or if you want to give me money.