If you think building a software product is tough, try building a legendary car from scratch.

I recently watched A Faster Horse, a documentary about the development of the 2015 Ford Mustang. It examines how that Mustang, whose nameplate is an icon in Ford’s history (and America’s), went from idea to final shipping product — a five year process.

The amount of work it takes to produce a new car is absolutely dizzying. Take the following list for example, which is just a small sampling of the thousands of high-level items the Ford team is tasked with:

• Initial idea and design sketches
• CAD models and full size clay models
• Engine and transmission development
• Interior development
• Software development
• Supply chain development, management, and parts procurement
• Cost analysis and pricing structures across hundreds of markets
• Crash testing and safety/government regulations across multiple continents
• Dozens of development mules for hundreds of test drives for ride, engineering, and performance tuning
• Global marketing
• Global legal
• Final assembly of hundreds of permutations of the vehicle
• Global logistics and final shipping to dealers

And if all that weren’t enough, once the car ships, it’s out of your hands. Recalls occasionally happen, but even those are typically for tweaks and safety, not reshaping the car itself.

Compare that to what we do in modern software development:

• Initial idea, design sketches and quick prototypes
• Write some code, probably with free tools
• Find a server for hosting
• Do some testing
• Pick a price and build a little marketing around it
• Ship your product with a few clicks
• Iterate and ship it again

When I sat back and thought about how vastly different these industries are, a few things jumped out at me:

• The work that companies like Ford do to bring a car to market is truly impressive. The coordination and teamwork is unbelievable, and it’s a real credit to the power of people.
• I love working on Basecamp, a product whose fundamental goal is to bring people together to work on getting things done, solving problems, and doing great work — exactly the kinds of things that Ford does to bring the Mustang to market.
• The challenges I face in my day to day work as a programmer aren’t really so bad.

It’s that last point that really stuck in my head.

We (myself included) can sometimes get bogged down by the challenges in building software. If you’ve ever had a frustrating day of programming, team battles, or a tough interaction with a customer, you know the heavy feeling I’m talking about.

But compared to building a car from scratch, we’ve got it so good — writing software is easy!

Embrace imperfection and ship it

Of course I don’t mean to trivialize our work or make reductive statements about our day to day problems. We all have tons of responsibilities on our shoulders to make great products that our customers love. On a daily basis we work on problems we don’t fully understand, critical bugs, and important features, all within a set of team dynamics and personalities.

But as hard as it is to tackle those issues, our struggles are relatively tame. If you take a look at the world around you, I bet you can find products that were insanely hard to ship, arguably much harder than software.

I personally think about the engineers at Boeing who are building massive jumbo jets every day. I’m in awe of construction crews who regularly build 50 story high-rises in Chicago. I’m fascinated by the amount of work that went into building my Nexus 6P so precisely.

A car or airplane has to be near perfect when it ships. A building must have every detail planned and triple checked. A phone must be engineered to the millimeter.

But modern software doesn’t have to be any of those things. We have a huge advantage — we can ship imperfection.

Software development brings us incredible freedom — freedom to build and ship things in days, not months; freedom to iterate and tune until our heart’s content; freedom to plan a little, but not excessively; freedom to be imperfect.

I am all for being detail oriented, but perfection is unobtainable in software. I’ll look closely at every detail of a feature and consider all the angles. Often there are imperfections, but if it’s a close call and the feature is good enough, I’ll always vote for shipping instead of holding it back.

This is not to say you should take shipping lightly. You should always consider the impact to your customers and understand any risks you might be taking by shipping an imperfect feature. And I’m not saying you should go rogue and ship things that fall outside the acceptable standards of your team or company.

But it’s also healthy for you and your brain to ship regularly— to put something out there, feel a sense of accomplishment, and let your customers react to it. You can hem and haw all day, but ultimately your customers will be the true judge of your work, not you or the people on your team.

And hey, if it doesn’t work out, just be glad you weren’t building a car. If something goes really haywire, you don’t have to institute a global recall. Refocus on the problem, reconsider it, fix your app, and ship it again.