Since my last side hustle update, a lot has changed. Initially, the project was a way to brush up on my tech skills, which meant things moved slowly. Now, almost a year later, I’ve added over 10,000 lines of code and expanded into areas I hadn’t originally planned for. My tech skills are way sharper than before, but I haven’t stopped learning. My focus has shifted, though. Instead of picking up new languages or frameworks, I’ve been diving into optimizing my processes. With nearly 20 years in the tech industry, you’d think I knew all about process. Turns out, aiming for ruthless efficiency has taught me a few things more.

Starting out, my development process was minimalistic—just an IDE and my laptop sufficed. I developed and tested locally and kept track of what I needed to do in a text doc. During that time I was still primarily focused on learning the tech and proving out the concept. Once I achieved that, it was time to expand access beyond my laptop. The easiest way to do that was to move to the cloud. This obviously increased my process quite a bit. I had to track costs, ensure I was using best security practices, keep up with any changes AWS made, and deal with deploying the app. It was a necessary trade-off.

As the code size and complexity increased, I regularly made drastic changes to large swaths of code. The ability to review or restore code became useful. It also seemed like a good idea to have my source code backed up somewhere. Enter GitHub. Now I had to deal with merging and pushing code and branches. Not a major effort, but one more layer of process.

When I was deploying code once a month, building and copying it into an S3 bucket wasn’t a big deal. As my code deployments increased, the appeal of a simpler deployment method grew. A CI/CD pipeline was the logical conclusion. And while it’s fairly straightforward and has been a big time saver, it’s still another thing to maintain. For instance, the other week, I couldn’t figure out why my code wasn’t updating. Turns out the build process was failing, but I had set up the pipeline so that it kept running, but just with old code. Whoops.

The most recent addition in my process came when we started putting the app in front of users. Having a broken app escalated from a minor annoyance to an urgent issue. I addressed this with two solutions: automated testing and a staging site. In testing, it’s a choice between full coverage and focusing on main user flows. Every minute spent on testing is one less minute spent on new features that attract users. However, if users encounter a buggy app or, worse, get incorrect numbers, it’s possible they write your app off, regardless of how many shiny features you have. Finding that balance is always difficult even at a small scale.

The most recent process addition is one not directly related to code: tracking my backlog. When I began this project, I just wrote everything I needed to do in a text doc. Upcoming work was pretty straightforward and could be captured with bullet points. As the scope and existing codebase expanded, I needed a better way to track my to-dos. I use Trello for my personal life, so I tried to leverage it for this purpose. It mostly worked for a while. But eventually the lack of hierarchy began to frustrate me. I was working on larger features that consisted of many smaller sub tasks and I couldn’t group those. In the past, I’d used JIRA for task management, but I’d heard good things about Linear, so I decided to give it a try. That’s one of the benefits to working on your own projects. You can try out new tech fairly easily. Linear was lightweight, and easy to use, which was a welcome change over JIRA. So, while there was some additional upfront work, it took cognitive load off me since I could quickly jump back into things when I had a free minute. I even briefly tried getting my wife to enter things into Linear, but she quickly reverted to the old ways of emailing me her issues.

The experience of building this product solo has evolved my thinking on process. In the past, I believed that process was a necessary evil required to achieve the greater good. It might slow your best people down, but it would keep others from going off the rails, which was important. When you’re a one-man show, there is no greater good. There is only you, and your time. I wanted to ensure that any process added was accelerating me, not slowing me down. I started to see process adjustments as akin to shifting gears. Shift too soon, i.e. add process too soon, and it’ll feel like you’re trying to slog through molasses. Shift too late, i.e. wait too long to add process, and it’ll feel like you’re running as fast as possible, but not going anywhere. Shift at the right time though, and you’ll actually accelerate despite expending the same amount of effort.

Unfortunately, unlike shifting actual gears though, there is no quantifiably right time to add process. Every team, every product, every company is different. For me, being a one-person operation, my goal is to provide value to customers and put a great product into their hands, so I’m going to err towards minimal process. If I were in a larger company trying to juggle the needs of many teams and maximize visibility and predictability while trying to minimize developer impact, I would make different decisions. This is an area where experience is very helpful. And I hope my learnings here benefit not only my side hustle, but any teams I support in the future.