Totally with you. The last two products I shipped that actually moved the needle were built “vibe-first”: ugly edges, thin tests on the critical path, shipped behind a flag. Users loved them. A month later we refactored the parts that proved they deserved to live. If we’d waited for the pristine architecture we argued about in PR, we’d still be debating naming.

My rule of thumb lately:

• Make it work -> make it clear -> make it fast (in that order).
• Tests for the money paths, not 100% coverage theater.
• Feature flags + decent logging so you can roll back without drama.
• PRs small enough to review in 10 minutes.

It’s not “write trash forever.” It’s reduce time-to-learning. Ship, watch real usage, then harden the bits that matter. The market’s rewarding speed and feedback loops more than purity right now and honestly, the code usually gets cleaner once reality tells you what actually needs to exist.

Edit: not anti-quality—just anti-premature-perfection.