The MVP checklist before you build anything
Most first-software mistakes aren't technical. They're scope decisions nobody wrote down, made under pressure, three weeks before the deadline.
The failure pattern for a first piece of software is rarely a bad technical decision. It's scope that was never actually decided, so it gets decided by accident, under deadline pressure, by whoever's most tired that week. A short checklist before the first line of code fixes more of this than any amount of engineering skill later.
Write down what you'll cut, before you need to
Decide now which features are explicitly "version two." Not vaguely — by name, in writing, agreed on by whoever's paying for the project. Cutting a feature that was never promised is a non-event. Cutting one that quietly became "obviously part of the MVP" three weeks before launch is where trust between a team and its stakeholders erodes.
Spend your risk budget on one thing, not everything
Pick boring, proven technology for the parts nobody will ever see on a demo — authentication, payments, hosting, email delivery. Use an existing provider for each of them. Save the actual engineering risk for the one part of the product that's genuinely new — the thing a customer would notice if you swapped it for a competitor's version. An MVP that took risks everywhere took risks nowhere important.
Decide what "working" means before you launch, not after
A specific number — signups in the first month, orders per week, response time under a threshold — beats "let's see how it goes," because "let's see how it goes" has no exit condition. It's how a six-week MVP quietly becomes a year-long project nobody agreed to, one reasonable-sounding extension at a time.
Build the 10% that's actually your idea
Stripe for payments, an existing provider for auth, a CMS for content that isn't your core product. The custom engineering effort should go almost entirely into the part of the product that's actually the idea — the thing you'd have to explain if someone asked what's different about what you're building. Everything else is a solved problem; buying the solved problems is what makes room in the budget and the timeline for the one that isn't.