Continuing the journey

The following are Jan and Feb 2025 reflections as I build a thing. Dev log °3.

The following is a blogpost on learnings as I build a thing in my Monthly Dev Log series.

Writing is accountability

Even if it’s without an audience. Let me explain.

There was very little progress on my project in January so I ended up skipping the post. Things were more productive in Feb hence this blogpost. Also, I’ve been reflecting on the act of writing.

I think writing is the only thing I find harder than pure software development. In trying to gather my personal notes into something that’ll be fruitful for an audience, I find my neurons lighting up like little LED light bulbs. Now truth be told, considering I have an audience of a few subscribers, I mostly write these monthly reflections for myself.

Knowing that at the end of the month I’ll need to share things I learned forces me to keep momentum. That was my lesson from January. Since there wasn’t much to share, there was no devlog post. But it didn’t feel nice break my little monthly streak. Lesson learned. Always make progress and share it regardless of scope. Onwards.

Product development is frontend development

Admittedly, things are behind where I had anticipated, and I think I have a diagnosis.

Backend engineering is much easier than frontend engineering. I think there are 2 reasons for this:

1. You can always make the frontend better. There’s always some little corner of your product that you can perfect down to the pixel. Backends (especially those that are pre-customer and hence pre-scale) don’t have this problem. After an API endpoint or some backend infrastructure is functional, it’s effectively done. The frontend is never done.

2. Frontend engineering is mostly subjective, not objective. This is closely related to the previous point. When you create an API endpoint, you can unit test it for correctness. With a new UI that’s truly doing something innovative, how do you unit test it for correctness? I don’t mean a snapshot test or a test to make sure the correct elements are rendered to the screen, I mean, that the users will know it’s correct.

If you’ve experienced the above listed symptoms then you might be in a kind of product development hell. It’s a hell of our own creation, and there might be a solution.

Leave things on the cutting floor

The remedy is simple: accept that things might not be perfect. Realize that doing refactors when there are 0 users is a waste of time. Realize that trying to design component in a perfect reusable fashion only to never re-use them was wasted effort.

I propose a kind of Occam's razor of product development: if I didn’t change or fix it, would anyone complain? Often the answer is no.

The above frame of thinking has helped me push through some challenging UI issues on my solo development journey. Not only does this help in prioritization but I’ve decided to cut entire features out of the first version of my product. Getting out there is more important than never getting out there but having a few more half-baked features.

Hoping to release the beta version of my product end-of-month. Keen to share it.