How Building Online Software is Like Building a House
This is part two in a mini-series. Read the first one, "How Building a Website is Like Buying a Car"
Online software has many names. Sometimes called web applications, digital products, web-based software, or just plain e-commerce. Whatever you want to call it, it can be a very big part of your business. For some our our clients their entire business runs online and for others it might be a division or an extension of the business.
It's easy to draw similarities between building online software and building a house, and it can help you understand the process you'll go through to get your business online.
It all starts with a plan.
It’s very near impossible to build a house without a blueprint. Likewise, with online software, a lot of planning is needed. Some plans are very specific. This defines the scope and creates a shared understanding of what work needs to be done. The one drawback? These kinds of plans often don’t leave a lot a room for innovation. Sometimes we like to have a less defined plan and a stronger partnership with the client so we can build something that really fits. In either situation, a plan is that central document that we all can look to and ensure the goals of the project aren’t being lost. You don’t want to end up with a bungalow when you know you need a two-storey.
Foundation and structure come first.
Once the plan is in place, we start work on the foundation. Like putting in a basement or framing the walls, we’re building boundaries and we’re also preparing to support the business. The database is at the heart of everything. We need to know know what we’re saving, what’s important and how it’s going to be managed. This is foundational, and like a house’s structure, it’s important to get it right before we start adding flooring or drywall.
Even if you can’t see it, it’s still important.
Similar to the plumbing or electrical wiring of a home, there are some key things that need to be in any house to make it liveable. When it comes to online software, there are a lot of details we have to take care of. Some of them are critical to the project but invisible to the client. For example, setting up caching so the site operates quickly or creating a testing and build process might seem like a waste of resources, but these are integral to a successful project.
There's an optimal time for changes.
Once you’ve poured the foundation, it’s difficult to make the house bigger. Once you’ve framed the walls, it’s hard to change the rooms around. It’s technically possible—but it’s going to be expensive.
When it comes to online software, we use a 1-10-100 rule. Before the code starts, a change might take an hour because we’re just changing some planning documentation. Once we’re in the code, it might take more like 10 hours as we have to change documentation and code. If we’re at the end of the project it can take 100 hours because by now the feature has been built, tested and integrated into the entire project. Undoing something and re-doing it (while also maintaining the quality and testing it) takes a lot of effort.
Obviously it would be great if we could figure out everything when we started, but revelations happen at strange times. If it’s worth it to the business, we sometimes have to rework things towards the end.
A lot of pieces go into making the whole.
Yes, one person can build a house, but if you want it built quicker, you’re going to have to bring in experts. We’ve built enough online software to know the different experts you’ll need for a successful project. It’s usually a mix of strategic thinkers, designers, developers, and marketers, who bring potential clients to your website after it launches.
Be prepared for maintenance.
Once you’ve built your house, you’ll have to keep it up. Keeping it clean, mowing the lawn and any repairs that come from living in it. Online software also needs cleaning every so often. Removing old log files, tidying up your data, and so on.
You’ll need to keep it presentable so keeping the content of documentation up to date is a good idea. Over time, as people use the software, you’ll discover edge cases, exceptions or even alternative uses and a lot of these will mean updating some of the code.