• Home
  • Talks
  • Podcast
  • Blog

Incremental changes

Published on Jun 01, 2022

🚀2 mins to read

  • notes
  • ship it
  • process
  • workflow
  • PM

Did you ship to prod today?

It’s a loaded question and really depends on the context. Within the context of my personal website and a greenfield project that I am currently working on, it has been refreshing to be able to ship features and fixes on a daily basis.

I have written in the past about non resilient codebases where shipping happened once every two weeks. Having had both perspectives, I feel like being able to ship often (without ceremony) is a huge morale boost, confidence boost and straight up joyful. It gives you a sense of accomplishment and builds momentum.

Being blocked from shipping

Nothing sucks harder than being blocked from shipping. Clogs in pipelines are never a good thing. Of course, this varies wildly depending on the size of your team and the age / resiliency of your codebase and whether or not you have dedicated devops folks.

Recently, I was blocked on my personal website because I was on v2 of Gatsby. I got busy with work and life for a few months (read: I blinked) and it was already on v4. Although, I have to give it to the Gatsby team, they have very good migration documentation. But we all know how it is upgrading interconnected node modules and all the various incompatibilities over not one but two major versions. I had to reduce some functionality (like publishing when my blog was last updated) as the plugins I used did not keep up with the newer versions. But a few afternoons later, I was finally unblocked.

Since I completed the migration, I have been on a roll. I make minor tweaks almost on a daily basis. I publish posts quite often (3 this month including this one). I have a new process for how I approach the website and a renewed approach to changes in general (more on that later). It all stemmed from unblocking myself by completing the migration project I had begun.

images of all blog posts publsihed in May

Being your own PM

When working on your own website, I often find myself in a situation where I am my own PM. I have to decide the tradeoff between effort and ROI. I have to consider how much time I have and what level of complexity of tasks I can take on. I have to ensure I have a clean backlog that is groomed with all information required so the developer (also me) can work on it with clarity.

A preliminary purpose of the PM in me is to prepare a set of incremental changes to the website that I can execute on when I find some downtime. I find that maintaining a backlog with clear priorities and sorting all ideas really helps.


The thing I’ve struggled with a lot in the past is wanting to work on an article or a feature on my website but I get bogged down by how ambitious I want the outcome to be. Instead, focusing on clearly defining the task, ruminating on the outcome and sorting it based on effort level has significantly improved my workflow and enabled me to ideate, prototype and most importantly, ship to prod regularly.

Built with passion...


Used mainly for the JSX templating, client-side libraries and job secruity.


To enable static site generation and optimize page load performance.


For data-fetching from multiple sources.


CMS to store all data that is powering this website except for blogs, which are markdown files.


For static site hosting, handling form submissions and having CI/CD integrated with Github.


From unsplash when they are not my own.

..and other fun technologies. All code is hosted on Github as a private repository. Development is done on VS-Code. If you are interested, take a look at my preferred dev machine setup. Fueled by coffee and lo-fi beats. Current active version is v2.12.1.