I've been a software developer in the commercial world for over two decades. In the commercial world, projects tend to be developed to a price, and against a deadline. This causes all manner of constraints that don't afflict startups and open source projects. We can therefore flip the problems that afflict commercial projects into some powerful advice.

Take your time

If you're building your own project, you probably don't have a deadline. Take time and do things properly. Never cut corners, and never do things the easy way when there's a choice between the easy way, and the right way. You will pay for short-sighted decisions later.

Don't waste money

If you have venture funding, don't waste it - aim to make your runway as long as possible. If you don't have longer-term plans for the project you're building, you need to re-consider what you're doing. While it's exciting to bet the farm on a single idea, if it's a good idea it's going to get copied - so you need to start out with continual development in mind - and that requires a long runway.

Don't rely on Agile

Many people think of Agile development as "figuring it out as we go" - this is a colossal mistake. If you don't have a bigger picture in mind when you start, you end up paying enormously in code tax - turning the code-base inside out to allow further extension or expansion later on. If you have some idea where you're headed at the start, pay some of the code tax up-front. Build the end-points, objects, and structures for future functionality at the start. Think of it as sketching out a map of the future.

Eat your own dog food

Perhaps one of the most repeated mistakes - where first-party interfaces use a private API, and third-party interfaces use an entirely different public API. Granted, the first-party interface might have more capabilities - so implement simple permissions to handle it. Why create spaghetti code, historical dependency hell, and mistrust from consumers when you can have one elegant framework.

Don't try to build Rome in a day

Don't load your project with a hundred features that work fairly well - build core features that work really well. You're going to fight hard to attract consumers of your product or service - the last thing you want to do is take little-used features away from them. Sure, you can dress up deprecation as a precursor to new features, but it will erode trust, and users tend to use products in entirely unpredictable ways - there will be a subset of users actively using the thing you want to remove or change, and it will be a deal-breaker for them.

Food for thought. Go slowly, be careful, plan ahead, eat your own dog food, and don't try to build Rome in a day.