Indie dev mistakes to avoid

No idea about Unity-specific things, but in general, the biggest pitfall of indie game development is bad planning or bad design. When people just start working on it to feel productive, but end up realising that they produced an incoherent mess and need to redo everything to make it coherent again. Think your game through ahead of time, as much as you can. And try to objectively judge the goal you envision. Can you even clearly envision the final thing you want to produce? What exactly its look and feel is, what exactly the gameplay is like, what actions the player takes, what he sees, how he reacts, the timing/pacing of it all, and what it feels like to be issuing the inputs to the game? And also all the steps you need to get there. If you can more or less clearly and objectively envision exactly what it feels like to play the game (and can honestly still say it is fun, and also know exactly why it is fun, and what parts of it are fun), and you got enough technical insight to identify what steps it takes to build it, then you're basically good to go. Of course you can never envision it perfectly upfront and you will still need to do lots of polishing later on, but if you can't clearly envision it, then you should solve those questions first before you sink more months of work into it that you will then have to undo and then redo again.

The only exception to this is when you explicitly intend to do explorative game development, where the idea only comes to you or gets refined as you experiment with actual prototypes. That is a much more risky way of developing, IMO, but it also has its place.

If you don't realise this, then you easily end up like this guy:

Let me see what I can add....hum....

This is not isolated to game dev, you will find this mistake EVERY WHERE.

First, thinking it's about the idea!

The idea is just the epiphany that starts the ball rolling, the complexity after that is exponential.

Rich people can invest in ideas, pay for it to be developed (not their time, not their money), rinse and repeat until something works. Normal people have one or two shots before you are broke. The idea is NOT enough.

Second, that you are special!

Look at the cemetery, stop focusing in what is successful. The plane crashes, the regular unremarkable plane crashes, will teach will more than watching "good" planes flying. Here is where experience makes A LOT of difference.

TenDogg wrote:

I’m building a portrait-mode mobile game combining match-3 combat with stronghold progression/world map systems. I’ve reached the stage where I’m transitioning from pre-production into vertical slice development.

For experienced Unity/mobile developers: what are the biggest architectural mistakes you see indie developers make at this stage that later become painful to undo?

It seems you already reached the stage where architectural mistakes are expensive and painful to undo, but it doesn't mean you don't have game design mistakes.

Therefore, try to make correcting game design mistakes fast and inexpensive, in order to iterate better: complete build automation, maybe automated tests and simulations, collecting and loading interesting game states so human testers don't waste time, and anything else that saves time and effort.

For example, a little thing I put in a business iOS app: every time it's built a build number (displayed on the login screen) is updated automatically with a shell script that rewrites a configuration file before the XCode build proper executes.
For a few minutes of initial investment the question of what version some user is running has been answered forever, without recurring effort and with no chance of human error.

Sorry for double posting, my unfinished answer is "accepted" and I cannot correct or remove it.

I always lock down one clear goal for the vertical slice and cut anything that doesn’t prove the core loop. I also keep art super rough so changes stay cheap.

One thing that saved me a ton of headaches was locking down scope super early and testing each system in isolation before stitching things together. I also kept a rough budget spreadsheet so surprises didn’t hit later; that included tracking game localization costs after I used them for a previous project, which helped me avoid big last‑minute expenses once the vertical slice was playable.