POSTED ON June 18, 2021
Our goal here is to share our stories and learnings on building a system that now supports 500+ stores across Canada and processes over $45 million in cannabis retail sales every month. I hope that whether you work at a startup or not, you’ll find stories that you can relate to!
Engineering is messy. Startup engineering is especially so, and I’d argue that if it’s not messy you’re doing it wrong. Speed matters a lot, and it’s impossible to make perfect architectural decisions early on. As a young 20s kid with only 2 years of professional software development under my belt, I did what I knew how to do at the time.
Now we have an incredible software development team who knows what they’re doing! We’ve had plenty of time to reflect on old decisions and pave better paths forward, so let’s dive into our early engineering decisions in hindsight.
TypeScript was gaining traction at the time. Flow was recently released, and of course there were posts on forums talking about how ineffective TypeScript is, and how if everything is unit-tested, there is no need for types.
At the end of the day, I had to make decisions based on my personal experiences. TypeScript helped me avoid dozens of errors every day in previous projects, and its support for popular frameworks such as React were just good enough for me to take a bet on it.
What would we have done differently? Staying up to date with major versions updates faster would have saved us weeks of type migrations and corrections.
React was the only front-end web framework I knew at the time, so this was an easy call. In conjunction with MobX, which I viewed as a much simpler and easier to understand state management system compared to Redux and its equivalents, I was able to quickly build a functional dashboard + POS web application that got us our first $100/month customer.
It was and continues to be a pain whenever we want to make big foundational changes, but the ecosystem continued to improve and the ability for almost any of our engineers to dive right into the code and understand what is going on has proven to be invaluable. Going multi-platform has proven to be much more difficult than we originally anticipated (Greenline POS still doesn’t support Android), but we’re confident that our team can get there eventually.
We did the best we could with the available technology, but we could have invested more in our internal documentation especially around our React Native app. As new team members joined, it became difficult to pass on the intricate knowledge of native vs CodePush deployments. Eventually we got there, but only after several deployment mistakes were made.
We chose AWS simply because it was the only big cloud system I could operate at the time and its support for Canadian servers (a core requirement for our business). I wasn’t aware of many differences between the platforms at the time.
We were pleasantly surprised at the way Amazon continued to acquire companies and invest heavily into their tooling ecosystem. It feels like every other week when we learn a new capability of AWS that blows our minds and makes us reconsider how we’re doing things now. From a business perspective, the biggest benefit was its uptime and reliability, which proved to give us an edge over competition who were locked into platforms like Microsoft Azure, which has had an awful track record especially in the past 2 years.
Investing some time into learning the tools in-depth and staying up-to-date with the new releases could have saved us several months as we tried new strategies to scale our software (did you know AWS had embedded BI via QuickSight?). It turns out that Amazon is already aware of most infrastructure problems developers are working on, and chances are they already have a tool for you.
What would we have done differently? We would’ve gone with PostgreSQL.
I laid out a few of our early technology decisions in this blog post. Overall I’m really proud that they didn’t completely hamper our business development as we hired more developers, but I know that there is so much more work to do. Our goal is to help cannabis retailers grow, and in doing so will require solving very challenging engineering problems while moving fast and not breaking things. Our point-of-sale is mission-critical software for our retailers, and we take that responsibility to heart.
If you are a software developer looking to make an impact in a budding industry that needs your help, check out our postings on our Careers page. If you don’t see a posting for you, we encourage you to still reach out to us at firstname.lastname@example.org.
To learn more about the Greenline POS system, schedule a demo with our Sales team.