Building Software = Building a House

I have founded two software companies (WineDirect and VinTank), I currently work for a leading restaurant software company (Avero), and fortunate to be on the Board of Directors of two software companies (Appreciation Engine and the upcoming wine analytics startup, Emetry). I’ve also been lucky enough to work with some of the best CTOs in the world (James Jory, Matt Franklin, Patrick Angeles, Jeff Mitchell and Andrew Kamphuis).

Recently I have been considering an advisory role at two other tech start-ups. One of the startups has been seriously discussing launching a second product. This company has ok funding but not any surplus of cash or people. I had to explain to the other board members why this was a very, very serious decision. After outlining it for them, I decided to record it here for others that are not in the software business and may have forgotten over time.

Building a new product is like building a new house. You need to secure funds to build it, meet with an architect, organize a crew of builders, painters, and specialists. Remember that these people have to plan to the smallest details of the house even down to the nails and paint color. They have to choose the right materials (servers), the tools (code & frameworks), the wiring, pipes, and internet (service & API’s), and the fixtures and details (UEX/UI). There is no question that open source software, the cloud, and Agile have made building a house much easier and faster. You can bolt together very sophisticated and scalable building block to push MVP’s and iterate very quickly.

Some people over-engineer their house. They over invest in fixtures and materials and run out of money before the house is ever used. Some of these monolithic houses get built but are never used to capacity. Some people invest in the wrong tools and wiring and pipes and are forced to replace them when the market changes (great and high profile example here: https://www.infoq.com/news/2012/11/twitter-ruby-to-java).

Modern house builders understand that you need to think API’s first. Essentially it is the internet that ensures your “smart home” operates efficiently. Not just consuming API’s but especially exposing API’s. Most modern apps are built on APIs between UI and backend, between microservices, and with customers. But building APIs properly requires a lot of thought and planning.

While you may pay off the mortgage loan (R&D, etc.), the house overhead NEVER ends. The house costs money to maintain (water, electricity, mowing the lawn, etc.). Moreover, you will eventually need to paint it, replace the carpets, update the plumbing and electricity depending on technology, styles, and wear and tear. Like adding an extra room, every major feature that you add, may increase the value of the house but also adds to the total cost of ownership. Unlike a house whose costs may only be 10% the costs to maintain a software product requires 50%-60% of your original resources that built it.

The *technical costs* increase the more residents you have in the house (e.g., I have four kids, and two pets and our carpets are disintegrating before our eyes). Every product/feature in software is a forever investment until you depreciate it or shut it down if you want to satisfy customers in the “subscription economy.” If you don’t plan for it, just like an air conditioner or a toilet, those broken features. Plan for maintenance or even full upgrades (please Angelica Mabray, let me put hardwood/tile floors in the children’s bathroom).

Remember each product is a house. Just like managing multiple houses, managing multiple products requires lots of extra time, planning, and coordination. Having one small team to manage all the houses is impractical. They never have time to do major work and end up

For the software CEO neophyte — Always imagine the software/feature you try to build/buy a house. It is the Tom Hanks movie The Money Pit, but when you see the fruits of your vision and if you survive, it’s well worth it. Budget a perpetual maintenance fund to keep it beautiful and to work at optimal efficiency. YOU NEVER STOP PAYING until you shut it down.
For a more mature software leader — Over time you have to make tough decisions about maintaining your software, the three most difficult things you’ll face are:

• Saying NO. The hardest thing to do is to say no to customers (especially the big ones), employees, and yourself. There are so many things you want to do to improve your house. Buying the new Wolf stove, upgrading the tile in your guest bathroom, fixing the master bedroom. But so many of those improvements only incrementally improve the house.
• Deciding on improving the software for Small/Medium business (SMB’s) or Enterprise improvements. Straddling both categories is a giant challenge. So many companies focus on Enterprise first because they have large budgets. But that cash comes with a price. They expect you to meet high compliance standards, demand quality support AND often want their hands on the rudder of your development path. Every Enterprise customer adds another voice and challenge to your roadmap. Also, with such a dependance on those big customers losing one can derail your budget or even sink a company. SMB’s take a long time to acquire momentum and require you to simplify, simplify, simplify and focus on features that affect the most users. Think of the difference in fixing one bedroom and making it luxurious but with very few people living in it or fixing the kitchen sink that everyone in the house uses . . .
• The giant version jump. Sometimes you hit the end of what the original design and architecture can support. Whether it is new frameworks, technologies, etc. you may have to rewrite some or all of your software and then move customers over to the new system. This is one of the hardest transformations you’ll make as a leader of a technology company. It is like living in two houses at the same time. My advice is to move fast and pull the band-aid off as soon as you get to a viable product and spend all your money improving the new house vs. sustaining two.

Being part of a software company is a magical experience and seeing it come to life for the first time is intoxicating. But the engineering journey doesn’t end with the launch. It lasts as long as you have customers or until you shut it down.

* I am not using technical cost in the purest sense of the engineering term but in the total cost of ownership (maintenance, innovation, overhead, support, documentation, opportunity cost, etc.).