In hindsight: Early engineering decisions at Greenline

Welcome to Greenline’s Engineering Blog

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.

We chose JavaScript to power our front and back-end

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.

  • How easy would it be to hire for?
  • How easy would it be to train for?

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.

Trying to sell our early software at an expo (2018)

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.

We chose to write our JavaScript with TypeScript

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.

In hindsight, picking JavaScript + TypeScript was absolutely the right decision.

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.

Our CTO, Sam Hoult, explaining smart things (2019)

We chose React + React Native for the front-end

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.

In hindsight, picking React Native was still the right decision.

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.

What would we have done differently?

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 to host our back-end

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.

In hindsight, picking AWS was absolutely the right decision.

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.

What would we have done differently?

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.

We chose MySQL as our database

In hindsight,

What would we have done differently? We would’ve gone with PostgreSQL.

Conclusion

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.