Have you ever coded yourself into a corner that couldn't be fixed?

I think the main thing that is 'very hard' to fix (i.e. change) once you ship and start getting users relying on a product are things like data structure or (as you say) things like authentication...

Of course everything can be fixed, but these might be huge jobs. A good data structure pays dividends in future, but it's hard to predict exactly how it should look until you validate your product (i.e. the critical features are X, Y and Z).

The decision about how much to agonise over this early on is a fine line, if you do it too much you over engineer things which is typically bad (because you engineer them the wrong way)... if you do to little you can make things too flimsy (which will cause issues later on)... thus this one is a bit more art than science sometimes IMO...

Not sure if that answers your question though!?

As long as you have the vision of what you want to do, I suggest you simply start working.

• Focus on a medium task (3-4 days of work lets say)
• Split that into sub-tasks of a few hours each
• For each sub-task, you already know what you need to accomplish (the whole task), so start working on the sub-task with disregard of the following tasks. Just focus on that sub-task, and eventually how it interacts with the rest of the sub-tasks.

Once the task is finished, move on to the next task, and so on.

Don't overcomplicate it. The idea is that you'll change your mind in time so many times, that things you plan now for 2 months from now may completely change or you won't really need them.

Everything can be fixed.
It can sometimes take a long time, you might have to throw away code, you might have to have your users enter credentials/payement details/whatever again, ... but ultimately there is always a solution.

I use to get analysis paralysis with architectural decisions. Because those are some of the longer lasting decisions that bites you in the ass later that's harder to fix. As you gain more experience with building software, you'll kinda get a sense of which choices make sense, even if you can't quite articulate it.

But in the near term, before you get that experience, I finally got over it by just picking one of the two solutions I was considering, and then being ok with refactoring or rewriting, even if it's a pain.

I think part of the fear is that you feel like it's wasted work. "Oh, if only I chose right in the beginning!" That wouldn't be the case, because you only realized you need another architecture because you learned something new through the process of writing it the wrong way.

Of course, there are decisions that you can look up whether it's right or wrong, like, whether you can export your users from an auth provider. By all means, research that. But for decisions that you can't easily look up on the internet, such as architectural decisions for your specific domain, then you just have to pick, and be ok with redoing things.

Also learning how to work quickly will help. If you can quickly get to the point where you figure out it's a poor decision, it'll feel cheap to rewind. The trick is to learn to do less, and prioritize, and focus on building the core thing, rather than the chrome. Easy to say, hard to do.

You have a legit question, but look at the no-code movement. Makers are building MVPs that aren't meant to become the final version. They're built to test the water and prove their vision has legs.

I prefer to reach for the tools I know best to allow me to build quick without worrying about the future. The future depends on my ability to prove market fit.

All that to say, predicting future limitations and traps isn't a worthy exercise, when time is the killer of most startups.

Well, I'm in the same boat. I made a lot of wrong decisions in the past but since then I kinda found a way to eliminate many of them.
I'm using the same tech stack that was proven by time: React, Python, Postgres. You can do almost anything with them. As for the database model, it's always under the risk but you can be better along the way getting more experience.

IME, there are very few one way doors in programming. Yeah, it might suck to have to refactor something, but it is almost always possible (whether or not its worth it is another question...).