29 Feb 2024

16 hour side-projects

An ode to the MVP

Some years ago I found myself desiring a note-taking application with a feature set that seemingly no piece of software satisfied. At this point, I had developed some minor web development skills at work, so I got the sudden idea to build it myself. While obvious to others, I was mainly dabbling in small command line utilities and graphical simulations prior, I wasn't used to the idea of making useful software for myself. Against better judgement, I jumped in and started building fieldnotes.land.

Act I - Chaos

What followed was a year-long, on-and-off odyssey that included 3 complete rewrites. At one point I started hallucinating a path to commercialization. Ultimately, I used 2 different backend languages, 3 databases, 1 frontend framework with 3 different state management solutions. Not to mention the radical deployment changes: Raspberry Pi in a shoebox to VPS in a datacenter.

It was an incredibly educational experience, but also a chaotic, unstructured one. I did not sit down and think about a feature set, a UI concept or anything of the like, I just started building. I never reflected on my time management and bike-shedding.

When I finally decided I had tweaked the UI enough and it was fine to stay as it is for the foreseeable future, I needed a radical change of pace.

Act II - Order

For my next project (rest.quest - a todo list) I challenged myself to stick to a strict 16 hour time budget. This short limit would have to suffice to do everything from defining what features the application should even have, how it should look and behave, all the way to the implementation and deployment. First, I sat down and came up with a plan for what needed to be done and how much time I would allocate to each: 2 hours for initial project setup and deployment, 2 hours for UI / UX concept, 6 hours for implementation of basic features, 4 hours for advanced features and 2 hours of reserve.

Then, I forced myself to follow this plan exactly. Over the course of about a month, I spent approximately 18 hours total on this project. The result was very close to what I had conceptualized during the design phase. I've been using the application every day in the one and a half years since.

The unresonable effectiveness of self-imposed limits

The time limit forced me to make some trade-offs. For one, the application doesn't have a backend. The data is primarily stored client-side, with the option to configure object storage credentials in the web app to enable sync / backup. The traditional approach would have demanded a backend, database and all the complexity that comes with that. Instead, this local-first architecture was born from a need to save time.

When I was conceptualizing the UI / UX, I kept thinking that I was ready to start building, that I had wasted enough time already just scribbling on a piece of paper. But as I forced myself to serve my time, suddenly some unusual UI patterns emerged: Instead of a single-column list of todo items, why not utilize the horizontal space of non-mobile screens and show 4 columns? Instead of letting checked-off items vanish, leaving no indicator of accomplished work, why not leave a gap where the item was previously? In just two hours of dedicated brainstorming, I came up with ideas that would have taken an order of magnitude longer to crystalize during coding.

Ultimately, the limitiations made the application better and I like to think that subjecting myself to this process has changed the way I approach side-projects. I now spend way more time planning my architecture and drawing my concepts, as it saves time in the long run and makes for a better product. Next, a simplistic feature-set, laser-focused on my needs is all the rage now.