First of all, hope you are all staying safe. If the last few months have taught all of us something, it is simply that we have to appreciate life – both for the things we already have, and putting us in a position of privilege to work towards the rest of the things we desire to have.

I would like to begin this article by quoting one of my most favorite poetic lines from Robert Frost’s Stopping by Woods on a Snowy Evening:

and miles to go before I sleep…

We are coming up on our first product anniversary very shortly and I wanted to take some time to reminisce about the journey thus far, talk about where we are currently at as a SaaS Startup, and touch a tiny bit on our roadmap, and the challenges that lie ahead of us.

If you like numbers (I certainly do), you may enjoy this next section. But, before I share the specific numbers, let me give you a high level overview of our Product, Technology Stack and Environments so you get some context to these numbers that I am going to share with you.

Technology Stack

We are a small team of highly self-motivated engineers who wholeheartedly believe that the best way to solve any problem is not necessarily how we’ve done it all along. To rephrase that and put it slightly differently, we believe that –

Just because we did something a certain way in the past does not in any way, form or shape mean we have to do it the exact same way in future.

So, we are constantly on the lookout to doing things in a better, more current and recommended way, and that, in this current environment of Software Development, is changing constantly – literally by the week or month. Gone are days where you could do the same thing, the same way, every single day.

So, every time we implement a feature (be it UI, API, deployment, or integration related), we pose the exact same question to ourselves – how should we go about implementing this? The answer to this question from a Technology Stack standpoint has rarely been the same. Given that, here are some languages, frameworks and libraries that our stack currently comprises of (and I promise you that if I had written this a week later, it would’ve been slightly different, and most likely, lengthier) –

Ruby on Rails, Flutter, MongoDB, Bootstrap, React, Sass, CoffeeScript, Mongoid, ECMAScript6, Backbone, Sinatra, Haml, Node, Handlebars, amCharts, Webix, DHTMLX, Heroku, EC2, …

Sure, not all of these play an equal role in the composition of our stack but they all play a part, not to mention an important one, in keeping all aspects of our platform functioning, performant and highly available. Some (as in the list below), you would experience directly, and others, not so much, at least directly.

Product

Whether you like to manage your projects, and your life at work and home, on your Desktop or your Mobile Device, we have you covered.

1. Web App (+ Responsive Mobile App) – https://pitch.snowpal.com

No alt text provided for this image

2. iOS App: https://apps.apple.com/us/app/snowpal

3. Android App: https://play.google.com/store

Here’s a Tidbit – when we started building our Native Mobile App, we were hoping that we could piggy back on the countless UI/UX discussions we had had for building the Web App and, thereby, save a good amount of time in not having these discussions.

But, as it turned out, and rather unsurprisingly so, that wasn’t to be the case. While we knew things wouldn’t translate verbatim to a smaller real estate, we didn’t quite think (or perhaps want to admit) that building a Native Mobile App would require the same number of discussions, and pixel pushing, that the Web App required out of us.

Yes, we were solving the same set of problems on the mobile device, but they had to be solved very, very differently so the end user had the best experience. I don’t know why I felt the urge to mention this as this wasn’t any easier or harder than any of our other challenges, but who knows – maybe, this piece of information ends up helping you if you find yourselves in the same boat.

Take a look at the infographic below to get a sense of the breadth of our features.https://www.linkedin.com/embeds/publishingEmbed.html?articleId=7091529328682790787

Environments

While I’ll admit that we lack what we need on our DevOps side of things (we expect to cross this bridge in the coming months), we didn’t compromise on the number of environments we needed to ensure that our app functioned smoothly across platforms and clients (with a 100% uptime). Here’s an insight into our environment setup –

We have 4 environments for each of our apps:

- Development
- Testing
- Staging 
- Production

We also have a 5th environment to manage our cron jobs.

In addition, we also have Native Mobile Apps that get deployed to the App and Play Stores (which work very differently by the way).

Branching Strategies

When you have a Web App, a Mobile Web App and 2 Native Mobile Apps, that’s a handful (for any sized team, let alone a smallish one). Add to it active development of new features and enhancements, and bug fixes, we need to have a pretty robust branching strategy so we have a handle on the various PRs, code reviews, testing processes and deployments.

This is a detailed topic in itself (much like each of the other items above) but, at a high level, we have these branches (outside of the feature branches):

(feature-branches)
develop-interim
develop
master

And, here’s a trivialized form of our git workflow process:

No alt text provided for this image

Deployments

At this point, you should have a pretty good, high level overview of our product, environment, technology stack and branching strategies, and given that, maybe you are ready to join the team? 🙂

Jokes aside, this is a good time to delve into some interesting numbers!

Web App Version: 1.0.170

API Version: 1.0.171

Mobile App Version: 1.0.41

Without analyzing the rational behind these numbers, a simple way to interpret that is that we’ve had at least 170 deployments of the Web App(s), 171 deployments of our API App(s), and 41 deployments of the Native Mobile App(s).

Each deployment goes through a git workflow process requiring further deployments to each of our lower environments, so once again, to keep things simple, you can treat it this way:

Web App: 170 * 5 => 850 Deployments

API App: 171 * 5 => 855 Deployments

Native Mobile Apps: 41 * 2 => 82 Deployments

TOTAL: 1787 Deployments

Let’s break that number down further –

Deployments in a year: 1787

(Average) Deployments in a month: ~148

(Average) Deployments in a week: ~34

(Average) Deployments in a day: ~5

That’s right.

We’ve had about 5 deployments per day across environments and servers during the course of the first year that we’ve been in service!

What that translates to you as an end user (either as a current one, or as a potentially future one) is that we’ve had that many opportunities to enhance our apps so they can play a role in your life on a daily basis.

Roadmap

My original intent was to discuss our roadmap in this article but that was before it was a 100 pages long! Given the length of this article, I think it is best if I did it in my subsequent write-up.

Hope you learned a bit more about us, and don’t forget to sign up on https://snowpal.com!

Be Organized.

Be Happy.

Be on Pitch.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s