Successful projects, part 5: A custom web site is like a building

Previously we learned why a custom web site is not a car. But it is a lot like a building.

"Make me a building. How much is it going to cost?"

Can you imagine what the response to that might be? What kind of building do you want? What kind of budget do you have? What do you want to put in the building? Where are you building it? What construction materials do you want? Do you already have plans?

These are exactly the same questions you need to answer when creating a web site. There are others, of course, but these are important.

What kind of building/web site do you want?

Is it going to be a shed, a house, a shopping mall, an airport, a condominium tower? Is the web site an online brochure, a blog, a news site, a store, a booking system, a customer portal, a crowd funding site, a classifieds site, an online learning site, a health care patient data site?

Huge range of prices and capabilities here. The term "web site" is about as specific as "building."

What kind of budget do you have?

A shed can be built for a few hundred dollars. A mall or an airport might reach into the billions. Houses range from many tens of thousands to a few million. Office buildings are generally several million or more.

While I have yet to see any billion dollar web sites, Healthcare.gov might come close, $319 million so far with potential to reach $677 million.

There are many, many multi-million dollar web sites, especially large media sites, large company sites, large government and other organization sites.

Most small to medium-sized businesses do fine with sites somewhere in the 5 figures, but the more the site becomes integral to the operation of the business, the higher this figure gets. Any successful business that operates primarily online reaches six figures pretty quickly, and by the time they've grown to having their own dev team, seven or eight figures is common.

What do you want to put in it?

Yard tools, a car, a family, 20 families, a small company, a large company, an airplane -- these all dictate different kinds of buildings, with different features needed, as well as how much security you need.

Online, what you put into it also counts for a huge amount of the cost of putting it together. A sales pitch, blog posts, news articles, photos, videos are the basics we find for any reasonable-sized site, but that's just the start. Portfolio pieces, products, customer orders, customer contact information, vendor contact information, project management, collaboration details, shared access codes, patient records, credit card info, inspection reports, course content, questionnaire results, aggregated data, reports -- add any of these and the complexity jumps up very quickly and often the security necessary.

Where are you building it?

Is there hard earth to build on, or is it a swamp? Landfill? Tenant improvements in an existing building? What's the temperature range outside? Does this require extraordinary heating or cooling systems? How is the access for delivering construction materials?

Online, thankfully, there are fewer environmental considerations -- but they still exist. Do you plan to put it on a shared web host? On a server in your own data center? On a dedicated virtual server? How much traffic will you get?

Most of our clients don't really care about these questions, beyond the cost implications. But where you build it and what environment you use directly relates to the capacity you can handle, which can greatly affect the amount of visitors you can handle. Get this wrong and you can have a disaster -- like Healthcare.gov...

What construction materials do you want to use?

Wood? Concrete with rebar? Brick? Mud? Glass? Different materials have different strengths, and different characteristics. What can be built easily in one material might not work at all in another.

Online, this is about the languages, operating systems, frameworks, and other associated technologies. What operating system will host it? What database(s) will you use? What language and other platform needs do you have?

Again, most of our clients don't care about this, but it's important to know what these choices are, and what are the strengths and limitations of these materials, because they can have a direct impact on how your site (and business) can grow and keep up with changes. And they can also have a direct impact on cost.

Do you have a plan?

In this question, there is some difference between building construction and web site construction -- we see a huge number of web sites that were built without a plan.

You can't build a building without some sort of plan. Even the simplest sheds take a little planning -- deciding the height of the walls, calculating the size of the roof, measuring and cutting to get the pieces to fit together. While skilled professionals can build things like a simple shed without referring to a plan, they certainly have one in their heads -- but even so, unless it's written down somewhere, there is a lot more likelihood of making a mistake, cutting one wall shorter than another, and having to adjust.

For any building more complicated than that, especially something with more than one floor, building without a plan is asking for disaster.

Anybody who has been around any kind of construction knows about blueprints. The larger the building, the more sophisticated the planning needs to be.

The web world is not really that different in the need for planning -- only in how widespread the use of plans are. While simple sites might not need much in the way of plans, as soon as you start introducing workflows beyond "create a blog post," "edit this page," and "view a page" the need for planning starts growing quickly. And as you introduce workflows that involve multiple people, such as e-commerce, subscription management, event management, you have to map out all the ways people interact with the system, or you're going to leave something critical out.

How web sites are not like a building

There is one big difference between buildings and web sites: web sites can be much easier to change. Which can be a huge advantage in one respect -- you don't need to plan out every detail before starting work. If you have a rough overall plan, you can generally get away with doing the detailed planning on the piece immediately in front of you. This has led to something called "Agile" methodologies, doing rapid iterations of planning, development, and release. Overall the principles are the same, it's just that you plan as you go, rather than all at once at the beginning.

Even though Agile tends to discourage planning, planning is still important, especially if you want to make changes to a running system. Any time you introduce a change into a complex web site, there might be side effects you didn't anticipate. While you won't catch everything, if you pull up previous plans and update the plan first, often you will catch these side effects on paper before they break something that could severely harm your business.

While it's sometimes possible to build even moderately sophisticated web sites without a formal plan with reasonable success, that success is short-lived. The reality of the web is it is changing very rapidly, and you are going to need to change your web site in the future. If you don't have a plan that describes the way your web site currently works, making fundamental changes to it greatly increases the risk of something going wrong.

So to maximize your success over the long term, insist on getting a plan delivered with your web site as its being developed. If you're using an Agile methodology (which we think is really good, aside from its lack of planning), make sure you have a good plan that documents the architecture and decisions that were made along the way. And be prepared to pay for it.

In building construction, you don't break ground without a complete plan. In the software world, a lot of pre-planning can greatly narrow down the scope of the work and lead to much better estimates, but often a combination of general planning up front and detailed planning as you go can lead to the best results -- just make sure that documentation gets done, or it will cost you more later.