Which early build decision cost you later?

by•

Hi all! I’m a long-time lurker, first-time builder. Still early in building my first product, and I feel overwhelmed by the amount of decisions I need to make every day.

Most of them feel small when I make them: a tool, a structure, something I’m skipping for now. I can’t tell yet which ones will matter, and I’m guessing some will only show their cost once other things are built on top.

For those of you further along: what early decision in your build only showed its cost months later? And what made it feel like the right call at the time?

9 views

Add a comment

Replies

Best

I kept everything in one notes doc to ship faster. Fine until I needed a real "what's today" list — every new bit of the app assumed free text. I'd split tasks out earlier even when it felt like slowing down.

Two from the app my current one replaced. It generated music through an unofficial wrapper around another company's service, because there was no official API and it was the fastest way to ship. It worked until the wrapper broke, and then the whole product was broken with nothing I could fix. Today I only use providers with a real public API, even when the unofficial one sounds better. The second: the app wrote its own purchase counters into the database, which felt simple at the time. It meant the client could grant itself anything. Now only the backend writes credits, after the store's webhook confirms a payment. Both felt like small shortcuts. The pattern I would watch for: anything where your product depends on something you do not control, or trusts something it should not.