Call Us (866) 845-6931
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.
2016 was a hectic time in the world of JavaScript. It was never easier to spin up a complete project with all sorts of boilerplates, but at the same time it was never harder to know exactly what was ‘right’. Hacker News was espousing the virtues of pure JavaScript in a world of framework overload, and YouTube tutorials were getting outdated every 6 months.
I knew that Greenline would eventually have to become a high-reliability, high-performance system. I knew that there were other languages and frameworks that would theoretically facilitate those goals better than JavaScript, but I also had other goals in mind.
As a bootstrapped startup with no cash, there was no way that I would be able to hire/attract senior developers with 10+ years of professional experience. Talent would have to be developed, and for that to be effective, the technology needed to be easy to pick up. Nothing even comes close to JavaScript.
Greenline wasn’t the first startup I worked at. I previously worked at a pet-tech consumer startup as the first engineer where I made plenty of mistakes. One of them was that untyped JavaScript gave way to avoidable typos and errors.
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.
Every bootcamp in town was teaching JavaScript frameworks, TypeScript continued to improve and receive heavy investment from Microsoft and the open-source community. Our team still learns new ways to use types, generics, chaining, and more as new features are released. All our developers already knew our stack or were able to pick up on it quickly.
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.
React Native was a trickier proposition. As our CTO Sam joined the team, we knew that we wanted the ability to easily scale our point-of-sale software from just web to iOS and eventually Android. We knew that we wanted to stick with the JavaScript ecosystem and not have to learn Objective C nor Swift. However, the ecosystem was finicky at best and release management was difficult. The requirement to build React Native bridges to connect to any native packages (such as receipt printers, barcode scanners, etc.) did not help, and we questioned our decisions more than once on late evenings.
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.
In hindsight,
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 developers@getgreenline.co.
To learn more about the Greenline POS system, schedule a demo with our Sales team.
