Recently, Mailchimp was removed from the Shopify App store for ‘failure to abide by Shopify’s partner policies’, but the move from Shopify merchants into app development started long before. It comes primarily from a need — a need that can only be discovered by knowing the pain-points and joys of e-commerce designers and engineers.
Software development is all theory. It’s conceptualizing an idea that could work or function as a possible solution to a possible problem or need.
Software product is the application of theory, the idea that’s there because of the perceived need (problem).
“Why build an idea that some people may potentially use — versus — selling a solution to a problem that we know other people face because we’ve dealt with it” — Sean Geng
My partner and I have been e-commerce designers for almost seven years now, over five in our current space. For us, we typically started with a 3rd party app solution, one created by a company whose sole purpose was to provide that application. It seemed like that was logical, they should know their product. We tried and tested available options as we grew, and time and time again decided to develop internally because we would eventually hit some type of cap with our used 3rd party application.
We were using software that had been developed from viable concept, but hadn’t been refined for years of growth with a company. Or, like Mailchimp, they had created a product that was designed for their profit or benefit, but was not the best true product for the merchant.
Ultimately, the majority of services we tested failed out after prolonged usage.
This is why we decided to venture into making our e-commerce solutions available to the public. We’re doing it different — Our development is the result of need, our product is the refinement of our solution to a real problem we faced, designed for that user.
We’ve always focused on our technology and data at Smoke Cartel, from trying to provide the most useful information and products to our customers to building out the most robust systems for our own e-commerce usage. Our selection is highly curated for our end-user, and we’ve spent a great deal of time in designing our user experience.
In building a technology that we ourselves used, we created the perfect built-in beta tester. For instance, today, five years in, I discovered a logical fallacy in our purchasing module, but it only would occur in a specific instance — running a certain report with specific parameters over a many-year time period. I never would have been able to diagnose that without using the system intensively, not as a theoretical user, unable to access it’s true capacity, but as an actual user with a need to solve.
We’ve been able to develop and refine Warely’s abilities using real products, real employees, and real customers. It’s what has led us to tailor the program to accommodate vast degrees of flexibility for it’s end user, in a way that isn’t scary or overwhelming, because we knew it was something our team and ourselves would have to interface with.
Spending years working with our products, learning them inside and out, and tailoring them as we beta-tested allowed us to create the perfect feedback loop of user testing, creation, and engineering. We’ve got a product we know we can stand behind, because we would never use anything else.
We’re seeing a migration of many other technically skilled e-commerce merchants doing the same — all coming from a need-based reasoning. We’re people who know and use these products ourselves -who better to user-test and iterate?
