How much of your Software Design can you do “on the move”?

Quite a bit, actually.

As a Software Developer and Architect, I realize that I need a machine for a number of things. I obviously couldn’t do my job without a computer. Okay, that’s a no-brainer. And before you judge me for stating the obvious, hear me out.

What I am beginning to state is that you don’t really need a machine for a few other things that you would do as a Software Developer or Architect. Sure, you could do those very same things in front of a machine but I’ve actually seen that it can be counterproductive. And here’s my rationale for that argument.

Let’s take one of the things I do as part of my everyday professional life — Software Design. And if you are wondering why I might have to do this on a daily basis as every design is followed by development, my simple answer to you is that there is so much we have to do at Snowpal, hardly a day goes by without a design for that next feature. Long story short, I do a ton of design work. And if I waited to sit in front of my machine before I did each and every one of those designs, it would simply eat up a good amount of my development time and we certainly can’t afford that. That apart, it isn’t the most productive approach either so I can hardly see myself do that.

3 paragraphs later, let me try and get started with how else do I do it then. Well, here is the approach I’ve taken for a long time and it has worked very well for us. So, you may want to give this a shot too, and let me know how goes.

Photo by Gene Jeter on Unsplash

I document both my initial thought processes about new requirements and the follow-up software design work during my daily walks.

I record them into a series of voice memos on my iPhone and number them.

I then upload them into the respective directories in Dropbox or Box.

I recap the gist of every voice memo in the last 25–30 seconds.

As with everything else in life, it is best to take a simple example and understand the process I called out for (aka, recommended) above.

Say, we are designing a restaurant management application and are beginning to think about the high level requirements. Here is what the first voice memo will likely include:

Voice Memo #1

We need to build a SaaS Web Application that allows an admin user to sign in to view all the restaurants they manage. The first page should show them all restaurants under their purview, let them add a new restaurant and also view the employee roster for each of those restaurants.

At this point, I would stop recording this voice memo (in the real world scenario, the requirement — even the very first one — wouldn’t be this simple so the voice memo would tend to range from 2 to 5 minutes, and sometimes can get as along as 15–20 minutes, so the corresponding transcript wouldn’t be as short as 4 lines long either, but you get the idea).

The next voice memo can aim to take a stab at the underlying APIs that we would need to implement to support these requirements. Now, the API implementation could be based on REST or GraphQL (or something else). But, much like we all have a native tongue that we “think” in before translating to the other languages we may converse in, a lot of us developers also have a native language, framework, library or protocol that we first “think” in. And when it comes to APIs, it’s REST for me. So, even when I am developing Graph APIs, I tend to first think in REST before I convert it to the Graph equivalent. So, having said that, here is how I would think about the APIs.

Voice Memo #2

I would assume the API is public (which it of course wouldn’t be) and not worry about securing it initially. My focus would be on the underlying specification. So, the first thing we need is a list of restaurants, then we need a single restaurant and finally, all employees that work at the restaurant. So, the API list would be something along these lines:





That would be it as far as the second voice memo is concerned. Now, the 3rd voice memo would touch a tiny bit on the user interface.

Voice Memo #3

Admin user signs in entering their username and password, or via a Social Media sign in. Once they do, they will see a list of restaurants (be it listed on a grid or as cards, or using one of the most common UI components). They will see the name of the restaurant along with some metadata (like last modified date, etc). When the hover over a restaurant, they will see some actions and one of them would be to list all employees who work at that restaurant. When they pick that action and hit Enter, they will see a list of all employees listed once again in either a grid or as cards (now, the same UI component can be reused to render the employee roster).

With these 3 voice memos, I think we have enough to get started with the implementation work, really. Sure, we can draw the UI so there is a wireframe or a mockup and if these UI pages are so unique and new, we would need to do that. But it’s likely you already have similar pages so you can simply reference those pages or components in the voice memo and you should be good to go.

At this point, we are ready to start coding the APIs and the implementing the UI as well. Which means, when we go to the machine next, we can actually open our favorite editors of choice and hit the ground running!

Now, to be honest with you, there are occasions where I tend to do a bit more in voice memos (like think about file names, class names, dependencies, repo decisions, GitHub issues, checklist items, and yada, yada, yada) but that will take a bit more explaining and I think it would be worth writing about it in a different article.

Organize yourself on!

Download the Mobile App. Be Productive.

Software Development: How to prepare for Technical Interviews

I’ve been on all sides of Technical Interviews over the years, and if I had to summarize it quickly, here’s how I would do it.

  • First and foremost, be honest. Credibility is key and is second to none.
  • Apply only to positions that your heart skips a beat for. Not everyone is passionate about what they do so if you truly have a passion for Software Development, you already have an advantage.
  • Don’t embellish what you know. We can’t all know everything and no one expects us to. The interviewer certainly does not. They are looking to find out if you know what you claim to know and if you have the aptitude to learn what you don’t already know.
  • Get your basics right and this is easier said than done. Find a quiet space for the interview (assuming it is online) so there are no distractions. Make sure there are no audio/video issues so everyone can see and hear you clearly.
  • Speak slowly, clearly and time your answers so you don’t end up not having time to share your more important accomplishments.
  • A lot of interviews have some standard questions (like: “most challenging project”, “avoiding conflict”, etc.) but that doesn’t necessarily mean you provide standard answers. Try to answer the same question differently depending on your read of the interviewer and/or their organization. They are not looking for cliched answers.
  • Volunteer to create a demo application (a small one but one that works) to share with the team. It could be a Web App, Mobile App, an API-only layer, shell scripts, or just about anything that gives them the confidence that you can not just talk the talk but you can walk the walk as well.
  • Answer questions in a more contextual manner. This requires you to do a little bit of work learning about the company and/or their domain. Once you do that, your examples could be tailored to their industry so they have to make less of an effort to understand your responses.
  • You may or may not be a polyglot developer and even if you are one, it doesn’t mean you know the language, framework, library or tool your client is using. Don’t fret. They already know that learning a new language or framework isn’t hard for a good developer. All you need to do is make them understand that you are a good developer.
  • Don’t be afraid. Remember that it is always easier to ask questions than it is to answer them! So, if you don’t understand what is being asked, ask for clarification.
  • A lot of companies require LIVE coding interviews. And not everyone handles them well (even the best of developers tend to struggle here sometimes). There are a few ways to make this experience less painful.
Photo by Florian Olivo on Unsplash

Do not be afraid to be judged. Isn’t that what interviews are for?

You are your only competition and you don’t need to prove yourself to anyone else.

Failing a coding session is success as well — in its own way. The more you fail, the more you learn. And the closer you get to winning.

Do your best but have a plan. If the session is 90 minutes long and there are 10 questions, its about 9 minutes a question but you will need 10–15 minutes to hit the ground running. So, it is more like 6–7 minutes per question and not all questions are created equal as well. So, take this average with a grain of salt (unless they are multiple choice questions).

Your aim should be one of 2 things: (a) Do a lot of some of the questions and not worry about attempting all of them, or (b) Do some of all of the questions in which case not every question might be answered to completion. If you can do both, great but that’s not where you may start necessarily.

Be cognizant of the time so you know how much time is used up and what’s left. But, don’t let that distract your concentration from what needs done. Even if you completed only 1 question, you want to make sure that was done well.

  • Being confident is important but what tends to generally happen is the longer we look for a position, the more the toll it takes on our confidence levels. But, it can only do that if you allow it to do so. So, go to every interview as though it were your first and last one. Tell yourself that past failures are not negatives but they are actually positives as they gave you an opportunity to fix some of your mistakes. Do NOT lose any part of your confidence.
  • If a thought springs to you that goes something like “there are so many developers why would they hire me?”, replace that with another thought “there are so many companies out there so while it would nice to clear this interview and work for this company, there may be a more deserving company out there for me and therefore, I have no reason to be desperate”. Trust me, it will help.
  • Some interviews will be easy. Others will be tough. Some will be brutal. That’s how it is. So, don’t deny that, accept reality and enjoy the experience.
  • When the outcome doesn’t go your way, don’t be too hard on yourself. Try not to speculate on why they passed on you. There could be a thousand reasons and more importantly, none of them matter. Think about any mistakes you may have made right after the interview so you can improve but don’t ask yourself any of these questions after you know the outcome. The timing is crucial for future success and present peace of mind.
  • Don’t forget that life isn’t fair. You may have done real well but they choose to still pass on you. At the same time, there will most certainly be interviews where you just did alright but you got lucky and actually got hired!

Life is short. Work hard. Work smart. Enjoy what you do. Don’t let other people’s opinions determine your day, week, month or year ahead.

Best wishes for your next interview!

Plan your job search and make the entire process as organized as possible. You’ll need a tool to help you do this. Check out!

Download the Mobile Apps, and crack your job interviews!

Typical Roles in a (small) Software Company

Given the situation we all find ourselves in 2020, I’ve surely seen an increase in the number of LinkedIn Posts that relate to unemployment where, in many cases, folks have been looking for a while. And while I’ve always had the urge to try and provide some help (as small as it may be), it has not been without its share of challenges either. One of the first bottlenecks I’ve run into is that my knowledge and experience are limited to Software Development, and while I believe it covers a whole gamut of roles (almost) within that area, that isn’t what everyone who is looking for work is hoping to get into. Obviously.

Folks from all walks of life are looking for jobs at any given time, but I’ve had people ask me what they should do if they wanted to switch careers into the world of computing. While I am not a career guidance expert, and I am surely not going to be pretend to be one, I feel like it may be useful to call out (even if at a high level) for a typical set of roles in a small Software Company so it helps anyone who is looking to make that switch. I want to stress on small because that’s where I’ve spent a lot of my recent years, and I am not certain I am exactly sure how the division of labor works in a large organization. Take what I mention here with a grain of salt, but I hope it helps you understand a little bit about how things work. Remember that there are bound to be a lot of gray areas where roles and responsibilities spill over but so long as you’ve learned at least one more thing, this article would’ve been worth your time, in my opinion.

I am going to list the roles in an atypical order simply because it is easiest for me to think that way (given our development process). So, don’t look at these as the right order.

UI Developer

This person is generally responsible for implementing the User Interface, and while they will work closely with the other members of the Development team, they will try to stay focused on ensuring that the look and feel of pages in your application conform with the specification, and that the pages support the necessary actions so the end user can interact with your product.

Take the page below, for instance. This is one of the many pages that our platform comprises of, and is the Dashboard. The UI Developer would be responsible for implementing all aspects of this page.

Screenshot 1 – Dashboard Page

API Developer

In the above screenshot, you see some data. There is 1 Pod Due, 0 Tasks Due, the pod due is called Team Members, there are a number of Recently Modified Pods, etc. Now, all of this data has to be coming from somewhere, and that somewhere is the API layer (as you can imagine, Software Architecture can get as complex and distributed as you wish but in the interest of not overwhelming someone who is new to this world, I am going to trivialize a lot of this stuff).

The API developer is primarily concerned about storing user’s data (along with metadata) in a persistence layer (typically, a database), and returning that data to the client. The UI Developer is agnostic to where this data is stored, how it is retrieved and so on and so forth, much like the API developer is agnostic to whether the returned data is rendered in a grid, or a tree component.

They would likely return a JSON response that looks something like this –

  "dashboard": {
    "podsDue": "1",
    "tasksDue": "0",
    "recentlyModifiedBlocks": [
        "name": "Implement Unsplash"
        "name": "Dashboard Improvements"

There are other formats they could choose to return this response in, say XML, but that’s rather unlikely. Regardless, just so you know the difference, here is what the XML representation of this content might look like –

<?xml version="1.0" encoding="UTF-8"?>
            <name>Implement Unsplash</name>
            <name>Dashboard Improvements</name>

They would implement what’s called an API, and that could be implemented in a variety of ways as well, but if they used a RESTful interface, it could look as simple as this:

Now, if you wrote a new API today, I suggest you go with GraphQL but that discussion is for another day 🙂

The UI and API Developer will exchange a contract so each of them knows what the other person’s expectation is. This is called a Specification.

UX Designer

We now know that a UI Developer will implement the User Interface but what they would implement is driven by what a UX Designed gives them. Think of a UI Developer’s role as one that is made up of 2 parts:

  1. Implement the page from a cosmetic standpoint
  2. Implement the page from a functional standpoint

The UX Designer provides the requirements so the UI Developer can take care of #1 above. And how do they do it? They have many options as well but what they will likely end up giving the UI Developer are Wireframes or Mockups.

Think of a Wireframe as something that is drawn digitally (doesn’t have to be digitally created to begin with, as sometimes, it is quick and efficient to hand draw it and then, share a photo of it) and represents the look and feel of the page.

A Mockup, on the other hand, goes a step further and shows how the page might literally look, along with navigation as well (so the UI Developer knows what should happen when the user clicks a button on the page, or hits a link).

As to how detailed the artifact should be, regardless of which of the above 2 it ends up being, that’s entirely left to the designer, and/or the organization. It can range from giving the UI developer an idea to defining it to a tee.

Or, it could be like the image below that, believe it or not, was one of our “wireframes” and in such cases, it is much like telling the UI developer to Go, figure!

But, ultimately, what matters is that the end result is what your Product Manager has in mind – something like this!

And that’s not a good segue to discuss the next role – Product Manager.

Product Manager

This is the person who determines what is it that your product should even be doing to begin with, but more specifically (and for an existing offering), they determine what that next page your team builds should be, and what problems it should aim to address, and how competitive it might be.

If you are building an internal product for a mid-sized or large company, this person will work with your Business team to identify gaps, requirements and the whole nine yards, and put together artifacts that dictate the next set of things your team should work on.

If you are building an external product, their job would entail doing market research, competitive analyses and more to come up with that next list of things to do. I know a lot of people who were developers at one point, and then moved on to do Product Management work. This is a very exciting role as well! After all, in this role, you get to make the call on what gets done, and when it gets done. So, it ought to be exciting.


In a smaller organization, the Product Manager ends up playing this role as well but in larger organizations, this person is responsible to define the requirements at a Business level. They will then hand it over to the Product Manager who will translate these requirements in plain English to a more technical document (aka, specification) that your developers would understand, and can work off of.


An application is made up of several pages (Dashboard being just one of the many pages), and many APIs, and multiple tiers, and numerous integration with both internal & 3rd party systems and services. And a number of applications will collectively work together to make your ecosystem. Now, how they do all interact amongst and within each other?

It is up to the Architect to answer that question. There are a number of Architecture related roles, some of which are:

  • Application Architect
  • Systems Architect
  • Network Architect
  • Database Architect
  • Integration Architect
  • Security Architect
  • Platform Architect
  • and the list goes on…

For a smaller shop, it is usually the same individual (or same group of individuals) who handle all these areas. As to what separates these roles, I think it is beyond the scope of this article, so I’ll try to cover that in a follow-up article (at some point) but it should suffice to know that this person has a complex set of responsibilities.

While you could be an architect who’s hands off, I have never done that role so I can’t speak to it. I’ve architected a number of applications (across all tiers and stacks) over the years and I’ve contributed quite a bit to each of their code bases, and it is my (strong) personal opinion that this role should be hands on at all times (but I am sure not everyone might agree).


Once again, in a smaller organization, the architect would play this role, alongside doing development as well (hint: Snowpal!) but in a company that can afford this role, this person would oversee all the engineering teams, work with Architects and Developers in all teams, and ensure that the product(s) owned by the company are sound from an engineering standpoint, needed from a market standpoint, jazzy from a coolness standpoint, secure from a security standpoint, extensible from an architectural standpoint, stable & performant from a credibility standpoint, and more!


Sure, you have a nice product but before you release it to the larger world out there, someone (someone other than your development team, for sure!) needs to bless it so it does what it is supposed to. This responsibility lies with the Tester. They test your product in more than 1 way to make sure it works, and it works consistently.

They can do this in one of many ways:

  • Test it manually every single time (unlikely for many reasons, but a possibility)
  • Write test/automation scripts to test the various tiers in your application(s)
  • Write unit tests (though developers would do this), functional tests, integration tests, performance tests, end to end tests and so on and so forth.

Their job is to break your application so your development team can fix it, and make sure it is all good to go before your end user encounters a problem. This is a another important role because if you find a bug in development and fix it, it will cost you (both in terms of money and time) a whole lot lesser than if the same bug were to be reported in production.

DevOps Engineer

You have a great product, and a wonderful team but it isn’t complete (not by a stretch) till you have a DevOps Engineer who can ensure that your changes make their way (aka, deployed) to the various environments continually. This area has grown in recent years and while your developers might play this role in a smaller shop, as your company grows, you will need dedicated engineers to handle all the Docker, & Kubernetes stuff.

Your API Developers might be a tad more eager to pick up these tasks as they blend quite well with the tiers they work on.


In a small company, there is only C* role but, of course, in larger companies, you will need a CEO, a CFO, a CIO, a COO, and more…

I can’t write more in this section because I would merely be speculating 🙂

Creative Team

At Snowpal, we don’t yet have a Creative Team, but that will be one of the first areas we will expand on as we grow. This team will create our Campaigns for Facebook, LinkedIn, Pinterest, Apple and more. Right now, we take turns to do this, and it is certainly not easy (and definitely not if you don’t have the part of the brain that contributes to this – I surely don’t).

I am sure this team is part of the larger Advertising Teams, but I honestly don’t know more about the roles and responsibilities of this team in larger organizations.

Project (or Development) Manager

You need someone to make sure all your teams understand their asks, their dependencies, deadlines and so on. This is the Project or Development Manager’s role. They will organize daily stand ups, identify blockers, create and manage Sprints, and work with all the stakeholders to make sure your ship is sailing smoothly.

They may play the role of a Scrum Master as well, but some organizations separate these roles. In our case, and in smaller organizations, the Architect handles this responsibility.

Kanban View on for Project Management

HR, Legal, Sales, Marketing, etc.

I have an idea about the roles and responsibilities of the other teams but not enough to write about them (or answer follow-up questions) so I am going to leave them be!

That’s basically it. Hopefully, you’ve learned at least one thing that you didn’t already know from this article.

Check out how all these roles worked in sync to create the Web App, Mobile Web App and Native Mobile Apps @!

Snowpal – Be Organized. Be Happy.

No, I did not come to the US because I did not have a choice.

Download Mobile App
Download Mobile App

On the contrary, I had quite a few options and I chose to come to the US because that is all I ever wanted to do.

Here’s a little bit of background about me to give context to both the heading and the purpose of this article.

  • I was born and raised in India.
  • I was not born into a poor family.
  • I had access to (good) education all my growing years.
  • India is a peaceful country.
  • Most of my family lives in India, and they are all nice people.

Now that those facts are out of the way, let me try to explain why I felt the urge to state those.

Too often, when I read the news, I get the impression that media projects the wrong impression that folks migrate to America because they had few other options – it is almost always a sob, sorry story of rags to riches. While the beauty of this land is that it is generally welcoming to folks from all backgrounds, it is inaccurate to paint a picture of the US as a place to only consider when you are persecuted in your own countries, or if there is something real bad happening there. Yes, we definitely will continue to be a country that gives people that second, third or nth opportunity to make a lovely living for themselves, but it is imperative that we also project ourselves as a better place to be even if you are not actually suffering wherever it is that you are at. You come to America not just because there are issues in your country, but also because it is a wonderful country and there simply is no place else like it. Period.

Despite all its shortcomings, America is the best country in the world. For a lot of us.

And here are some reasons why I think I am blessed to live in the best nation in the world.

I’ve done a fair bit of travel in my life (not as much as I would like to, or a lot of other people, but I have seen a little bit of the world). And every time, I am in a foreign country, I realize how much more of a home America is to me. Yes, I grew up in India but, at this point, I’ve lived well more than half my life in the States, starting with the first penny (or dollar) that I earned in my life, which happened to be in this country as well (and it was literally in the “country” – in a small town in Ohio!).

They say that when you migrate, time stops. And your awareness of those places is stuck in time. What that translates to is that you are culturally disconnected from your place of birth, and as time passes, you become more and more detached to the point that most of the early childhood years start feeling like nothing more than distant memory. I say this because whatever it is that I end up sharing about India is likely very dated (so take it with a grain of salt).

So, as “different” as I may look, or talk (oh yeah, the accent takes 2 lifetimes to leave you, trust me!), I don’t honestly ever feel like an immigrant (except when I watch the news where they beat this word to death). Does it mean America is utopia, and there are no issues, whatsoever? Of course, not. I may be silly but am certainly not that stupid. However, we have to discuss these issues in the context of Planet Earth, and the rest of the countries that it comprises of.

Life is not fair. I’ve heard more than 1 super accomplished person say that (starting from Bill Gates, to Schwarzenegger, to Will Smith, to Matthew McConnaughey). But, I don’t think it is fair to blame that on a country, unless the system promotes it. And I strongly believe that our system does not promote it. Sure, certain organizations and individuals may exploit certain loopholes, but I don’t think I would place the blame on the system in entirety, and I say this as someone, whose experience is not solely limited to living in the United States.

As an immigrant, you are bound to make a ton of sacrifices, because a better life doesn’t come at the cost of nothing. First and foremost, you don’t live close to your family (No, that’s not a good thing!). Next, you’ll miss all the festivals you dearly love (for me, one of them is coming shortly – Diwali!). If you are wondering why I might miss them when there are quite a number of Indians in the US who celebrate Diwali (and other such festivals), and there seem to be a lot of gatherings and parties around this time (I mean, in a more normal world, not in this day and age of lock downs), I suggest you celebrate one Christmas in Chennai, India (where I come from)! You’ll surely realize what I mean by this.

Sure, going back to living in India would help satiate some of these needs and wants,but I have no doubts that I will be as lost (and most likely, more lost) as I was when I grew up in India. The only thing I ever understood (even if to a partial extent) when I lived there was my family, and friends, and some of the courses (certainly, not Mechanics & Optics, or Thermodynamics!) I had enrolled in College. That apart, I was pretty much lost. I didn’t understand the system one bit – not the traffic regulations, not the application forms, not the bureaucracy (as much of it that you could be subjected to, as a 17-18 year old), and not a number of other things. India is a very nice country but it just wasn’t my cup of tea.

I landed in Houston, Texas when I first arrived in the US, and I fell in love with America right way (barring the freak out sessions that went like this, “Oh my Goodness, what did I do. I know no one here. I want to go back”). I didn’t understand a lot of it then, and I still don’t understand a lot of it now. But, the beauty of the land is that you do not have to understand or accept everything. Making social connections is a whole lot harder than professional ones, I’ve realized, as crossing the seas on a plane and getting somewhere in a few hours is made possible by technology, but technology doesn’t necessary bridge the cultural divide, not in lightning speed at least.

But, the beauty once again lies in our differences as much as it is in our similarities. It would be boring if we are all too alike.

At this point, you may ask (and justifiably so) what the purpose of this article is, and what am I trying to get that. And to that, I would say one of 2 things – (1) be a tiny bit more patient, and (2) You didn’t sign up for a Pulitzer prize winning author’s article in nytimes, did you? So, don’t expect too much 🙂

But, I do have a point (as long winded as I might be, getting to it). Too often, I see America projected as a place to consider when you have no other options, or you or your country is in a state of turmoil. And that offends me as someone who loves this land for what it truly is. It is a place to be even if you are not struggling, and even if you have plenty of other options, and that’s simply because, you will not feel as much at home anywhere else as much as you feel at home here (not even in your place of birth, at times). And yes, I say this, as a colored person who doesn’t understand a ton of things about America.

Despite what we see in the news, I think there is more unity in America than in most places in the world. And we surely will become even more united.

While each of us finds inspiration in different things, here are some things about America that continue to blow my mind (I used the word “things” loosely because as someone who isn’t a native English speaker, I can’t immediately think of a better English word, and even that shortcoming is perfectly alright in America!).

  • Where else do you have someone like Clint Eastwood who has been making movies to satisfy so many generations? My dad used to watch his movies growing up, then I did, and now my son does.
  • Where else do you have someone like the Wright brothers, or Steve jobs, or Dennis Ritchie, Thomas Alva Edison (maybe, UK – another country I love!)?
  • Where else do you have something like Hollywood that entertains the whole world?
  • Where else do you have companies such as Apple, Google, Microsoft, Amazon, Tesla, or Facebook, Uberthat continuously innovate, and change the way we all live everyday?
  • Where else do you have a New York City (simply the best city in the world)?
  • Where else can you get pizzas this (super) size? 🙂
  • Where else do you get the opportunity to interact with people from all parts of the world?
  • Where else can you enjoy the beauty of all races, religions, sexes, and everything else that actually unitesus?
  • (…and one day not so much in the distant future, I hope this list will include Snowpal, and the productivity improvements it has brought to this world!)

I made my first dollar in the US, I got my first job in the US, my wife and I met for the first time in the US, my son was born in the US, I bought my first used & new car in the US, I bought my first home in the US, I founded my first company in the US, I built my first product in the US, I built my first Mobile App in the US, and during the course of my lifetime, there will be a lot more of these…

So, to everyone who has ever tried to tell me that America may not be the best country in the world, I will say this: you are dead wrong.

Yes, we have a number of issues as a nation, but who doesn’t? I am confident that America will get through all of this, and we will continue to be the best country in the world, a country that is not only welcoming to anyone & everyone who has a desire to lead a better life but also serves as an incomparable source of inspiration to every human on Planet Earth (and beyond) for years and generations to come. I have no doubts.

God bless America.

Time flies. Quick recap of our accomplishments in the last year.

A big thanks to our team!

It’s a year since we went LIVE (with our web platform). We’ve implemented a ton of things in the last year. To simply name a few big ticket items (specifics to follow in a follow-up article):

  1. Feature: Kanban Views (for Kanban lovers)
  2. Feature: Project Key Service (for Project Management)
  3. Feature: Scheduler (to manage all your System & Standalone events)
  4. Feature: Relations (to relate all your content)
  5. Enhancement: More Charts (Data Visualization)
  6. Enhancement: Numerous UI/UX improvements
  7. Feature: Caching on multiple tiers (Performance Improvements)
  8. Feature: Infinite Scrolling (on List View pages)
  9. Number of Bug Fixes (for a more solidified platform)
  10. Huge Refactors (to expedite development)
  11. Feature: Templates (to help create content quickly based on predefined templates)
  12. Feature: 2 brand new Native Mobile apps which have been on the App/Play Stores for about 3 months now.
  13. Design work for future services
  14. Marketing Videos (Animated + LIVE), DevOps improvements, Blogs, and yada, yada, yada!

As you can imagine, that’s a lot of work. We are a small group of extremely committed & passionate individuals, and while we realize there are more mountains to climb, we also know that we’ve come a long way.

Super thrilled!

Sign up on, & enjoy the power of our platform.

Snowpal Pitch: Technology Stack, Deployments and Releases

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.


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) –

No alt text provided for this image

2. iOS App:

3. Android App:

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.


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):


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

No alt text provided for this image


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.


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!

Be Organized.

Be Happy.

Be on Pitch.

Weekly Brown Bag Sessions | Web & Mobile Software Development | Learn | Teach

The number of messages I’ve seen off late on LinkedIn (and elsewhere) related to folks looking for work (either starting recently, or in many cases – for quite a while) absolutely breaks my heart, and I am sure it breaks yours too.

As a consultant, I find myself in that position rather frequently but I’ve done this for a long time now, so I can (almost) say that I am used to it as that’s pretty much the nature of the beast when it comes to consulting (so you really sign up for that lifestyle as a consultant).

On the contrary, if you are a W2 (aka, permanent) employee, you aren’t necessarily expecting to be in this position (and certainly not as frequently) so it is understandable that one’s mindset is not oriented to being (perennially) in the “looking” state

While I hope everyone finds the job they are looking for and, more importantly, in their field/career of choice, it is possible that some of you may entertain thoughts of switching to the (and may I dare say, beautiful) world of Software Development.

I use the word development loosely but what I really mean by that is pretty much everything that falls anywhere in the space between “I have an idea” to “Our product is now in Production!”. Having done this for longer than I might be willing to admit, I would like to believe I can help, even if in the tiniest ways possible.

I am not a recruiter so I can’t directly help you find your next job but I am more than happy to take an hour of my week to guide you or teach you so you do land that next software (related) job.

And how do I propose to do it? I am not certain I’ve a concrete, or definitive answer, and certainly not one that is tried and tested but, as they say, we live and learn and more importantly, need to start somewhere.

So, what I am hoping to do is set up weekly 1-hour Brown Bag sessions over Zoom. We need 2 sets of people to make this happen.

  1. First – a group of people who’ve experience in different areas of Software Development willing to contribute an hour of their time every week, or when possible.
  2. Second – folks who can benefit from these sessions.
  3. Last but not least, I am happy to take the additional responsibility of moderating this, and making them happen consistently.

If we can help even 1 person land a job (and hopefully, a job to their liking), I would consider this effort a grand success!

Send me a direct message if you would like to contribute, or benefit from these sessions (and needless to mention, they aren’t mutually exclusive, so we are all going to both learn and benefit at the same time).