Acting and Iterating on Ideas

Most dev teams are highly inefficient as they waste time not iterating properly. They are afraid to act and overthink coding issues or architecture decisions.

To build fast, you need to iterate on ideas, not mull them over a thousand times until you have evaluated the seemingly perfect solution.

The mantra here is taking action. Why? There are too many unknowns.

Things will evolve quickly, so you need to be quick, too.

This is especially important in a startup environment. If you don't move fast enough, you might miss that potential client, a grant, or just being in the right place at the right time.

In The Good Enough Mindset, I've outlined my thoughts on choosing a good enough solution over a perfect solution, and this is very much the idea here, too.

This time, however, I want to explore the topic of acting quickly and then iterating on these ideas.

The core theme is this: Perfection can come later—progress is what keeps you alive.

We had to pick a database framework that would enable us to query it easily from our codebase and get type-safety and user authentication as well as security. We went ahead and implemented Supabase in a quick decision and it helped us to speed up development at that time.

Do we still use it today? Only partially, and we will likely move away from it in the long run.

We acted out of an urgent need. We had to build these features, and creating complicated APIs for everything was taking too long. Picking a framework saved the day.

Was it perfect? No.

Endless debates and theory

(credit: https://x.com/victor_bigfield/status/1893218991633539170)

Are you familiar with endless debates on what would be the best solution to solve a problem?

You have a problem, you have an idea, and you might have a couple of solutions in mind already.

Sometimes, this derails into an endless back-and-forth on what the perfect solution could be.

Let's say you need a new ORM (the thing that connects your code to your database).

Great. Disclaimer: You won't find a perfect one; they all have tradeoffs.

Do a quick assessment of the close candidates and then simply integrate one for a small part of your project. Get a feel for how it's working.

What if it doesn't work?! Great. Now, you have wasted a little bit of time but have learned something and can try the other solution with a better idea of what to look out for.

You could have planned this all out and studied all the different options carefully, created spreadsheets of pros and cons, debated past experiences with colleagues. This would have likely taken you quite some time and still left some blind spots.

The reality is that you will have to do some evaluation upfront; everything else seems a little reckless. I find that Claude or Grok are pretty good at debating and discussing options and then providing a solid summary of the findings.

A pragmatic approach is to limit the research to a set number of hours, then decide and proceed.

Just try something

Define a goal and work toward it. For example, you could build a new API for a new feature, but you would need to do that with a new framework to try it out. Timebox that to two hours and see how far you get and how you like it.

The important bits are defining a clear goal of what you want to achieve and running a tight feedback loop.

The worst thing you can do is lock yourself into your room for three days and then come back and decide that this wasn't the right solution.

The better way would be to timebox it and then reflect regularly on how it's going. Maybe even get on a call with a colleague to discuss findings.

Sunk cost fallacy

Okay, so what happens when you decide on a solution but realize after a couple of months that it is no longer a good fit?

You should not continue down that path because you made a decision, and it would be too costly to reverse it.

We had to implement that database framework back then, or else we wouldn't have gotten to where we were four months later. No regrets.

(credit: https://x.com/darshan/status/1859645719331864786)

If it's time to move on, it's time to move on, though.

The trick to moving on is to apply that same framework. Pick a good iterative next step. In our example, it could be

1. Implementing an ORM to not rely on the Supabase client framework anymore.

2. Move migrations into ORM to not rely on Supabase

3. ... slowly cutting all ties

4. Migrate your DB to somewhere else.

Again, this is a case-by-case topic and might not apply to larger corporations with critical infrastructure, but it is the best option for startups.