When starting a new project we may not need everything that we need when working on established projects. We can probably wait with setting up a build server and CI/CD, uploading a build from our computer instead. We may not need a project management software. Perhaps it is just you, or you and two other people. You can use a chat app, emails and phone calls. A decision log can be noted in a notepad and emailed to the participants.

A few years ago (time flies, truly), I was working on the software side of a hardware platform project that took sensor input from an Arduino board, state output from (VR) games, and input from an existing piece of hardware that had an Arduino board attached to it that spoke the XBox controller protocol. Together, this platform can simulate almost any type of vehicle. I found it to be an interesting project, and it was refreshing to work with hardware again. I also enjoyed working with Arduino.

The other people on the project needed an easy way to receive my code. After they received my code it should be clear what they needed to do with it. The project was without any income and thus without any infrastructure. The people working on it were not users of version control platforms such as Gitlab or GitHub. I didn't think that introducing them to the modern software development process was a good use of our time. Instead, I resorted to scraping files together and zipping them up in an ad-hoc way. Sometimes several times a day, as what I had written in the morning before work would have been tested during the day, and I sent in improvements after work.

The process of sending updates was tedious and error-prone, so I created a tool to help gather files, remove unwanted files and zip them up. I created that tool when I felt I needed it. I did not create an installer and updater. Me emailing the file and the other person unzipping the file was all that was required. Simple, frictionless and very little development effort was required for making builds and installing them. Which is good, because that is not the focus at the start of a project.

We can set up a CI/CD or a regular build and release process when not having them provides too much friction. Before we reach that moment we can work with a loosely described standard operating procedure and some code to automate the annoying bits.

One of the other participants set up a Trello board. We put effort in to filling it up. In the end though, I felt the other participants didn't use it. They didn't record their thoughts or test results there, even if I did update my development tasks there. I chatted and called a lot with the main person behind the project, who had the hardware. I made notes of their conclusions and would iterate in the evening or in the morning. We just didn't need project management software yet.

In the end the project didn't succeed as a business. But working on it was a ton of fun. It was as frictionless as it could have been. By skipping a lot of administrative and non-core activities I was able to focus on what mattered: the minimum viable product.

My conclusion is that when starting a project we don't need to worry about what we will need to have in the future. Instead, I prefer to focus on the project goals and creating standard operating procedures for the current tasks. When friction appears we can perhaps automate that away, but we shouldn't get sidetracked on that.