Unless you're in life support or some other critical engineering path, always start by aiming for good enough, not best.<p>If you're moving quickly, some of your decisions will be wrong, but that's ok. By the time it comes to revisit a decision, you will have more information and be able to make a better decision. Don't regret making the wrong decision, consider it a prototype. It's nice if you don't make a lot of wrong decisions, but if you're not making any wrong decisions, you're probably spending too much time deciding.<p>You're balancing the cost of making a more informed decision vs the (cost of changing your decision later, including potential cleanup costs * the probability of having decided wrong).<p>If you're working in a team, having consensus towards using the decision is more important than having the right decision or even having consensus about it being the right decision. With the right team, you can say something like 'I know everybody doesn't like this decision, but let's work together on it for the next 2 weeks and we'll change it if we need to.' That's usually better than trying to find consensus on a decision for the next 2 weeks. If nothing else, your team will have 2 weeks of experience with using the decision to inform a future discussion... and in the meantime, it might be good enough and you can work on something else.
I'm not a founder, but I've worked at several startups where I've been employee # X where X < 5. The answer is to Time Box - hard. Remember, if you're looking to be first to market then time is of the essence. Get something usable to the market first and then iterate.<p>If you're unable to do that (and that's okay) then you need to hire someone with a proven track record of Getting Sh<i>t Done! Just remember to stay out of their way! Don't project </i>your* analysis paralysis onto <i>them.</i><p>Remember too, YOU ARE NOT going to make everybody happy. There's <i>always</i> a critic and there always will be. Focus on the people who are most likely to be your customers and make sure you're delighting at least 70% of them and meeting their needs. Just think of how much <i>more</i> happy they will be that you stopped wasting their time overthinking solutions and got a solution into their hands faster!
Not a founder, but one needn’t be one to suffer from Analysis Paralysis.<p>One strategy I use is - when looking at the (reasonable) options - to try and focus more on those that have the following properties:<p><pre><code> 1. The cost of doing them is lower; and
2. The cost of them failing is lower.
</code></pre>
You’re going to make mistakes; don’t be afraid of it. But watch out for mistakes that have a serious cost associated with them, either on the front-end or the back-end.<p>You want to be able to recognize a mistake quickly, backtrack (as little as possible), and pivot rapidly with considerably more information than you had when you were originally choosing between different options. With the newfound knowledge, you may now realize all the options you considered before were wrong.<p>Also, remember that "not choosing" is the same as choosing, but usually worse because you’ve not only wasted time, but may not realize the choice you made until much later.
Situations where you have analysis paralysis are situations where the solutions are, <i>as far as you know</i>, equally good.<p>Think about it - if one solution was obviously better than the other, you wouldn't be stuck deciding!<p>That means picking any solution will be good enough. So do that. Roll a die, and pick one solution.
Just do at least one small thing every day. This keeps your mind on the project.<p>What is more common is that devs fiddle too much with design and code quality tbh..<p>I run a SaaS boilerplate
<a href="https://achromatic.dev" rel="nofollow">https://achromatic.dev</a> so you are not stuck in busy work.
I work on the work. I work on the thing I am trying to avoid by pretending analysis is the work. Working on the work surfaces actual problems.<p>There are no special rules for founders. Hard work and experience are the only shortcuts and experience with the only comes through working on the work.<p>Thinking about analysis paralysis is easier than making mistakes. Go make some mistakes. Good luck.