Deploying Before I Was Ready

I just deployed my hockey app, and I’m not exactly proud of it yet.

I’ve been working on this project for a few months now, and I kept falling into the same cycle: “After I add this feature, I’ll deploy it.” Then I’d finish that feature, think of something else I wanted to add or improve, and push deployment back again.

Eventually, I realized I needed to draw a line somewhere. I wrote down exactly what I wanted my MVP to include, and once I checked everything off that list, I forced myself to deploy it.

It’s not exactly where I want it to be yet. There are still bugs to fix, features I want to improve, and plenty of things I’d like to change aesthetically. But it’s finally out there.

Now, instead of trying to perfect the app on my own, I can start iterating based on how people actually use it. Once hockey season starts later this month, I plan to get more people testing the app and use their feedback to guide what I build next.

One piece of advice I’ve heard repeatedly from people who build apps, make art, or create just about anything is that your work doesn’t have to be perfect before you put it in front of people. At some point, you have to let other people experience what you’ve made.

After all, how can you know what to improve if no one has had the chance to use it?