“Just ship it” is how you lose weeks later. I learned the hard way that moving fast without foundations catches up to you.
With Mizen, I prioritized shipping features and validating ideas. Speed worked for testing what resonated, but I skipped the boring stuff like proper design systems and clean code.
Quality work is not optional
Now our internal version is bloated and starting to crumble. Even though the app is simple, the messy foundation made it fragile. This taught me why you NEED devs who care about code quality, testing, and security. I've been bringing in help to review fundamentals, and I'm willing to throw out bad code.
Tools have improved fast, so it’s been easy to rebuild what we had with cleaner, better-maintained code. As models improve and I get better at prototyping, starting fresh beats wrestling with tech and design debt.
The two-codebase approach
I know this isn't anything new to devs, but as someone learning dev practices, this has been even more important as a designer exploring in code.
So now I'm keeping two versions: a production codebase that's stable and a "baby" version where I can iterate and test ideas without worrying about breaking things or maintaining production quality.
If you’re building side projects, don’t be afraid to hit reset when pushing forward is harder than starting over. Users deserve a quality version of your best ideas. For bigger projects, this dual approach might be the move. One for users, one as a playground.