If you’re investing in a website, one of your primary concerns will naturally be to pay as little as possible.

As we’ve argued before, looking only at cost is not the correct way to approach a website project. Rather, a website is an investment—an ongoing investment—designed to help you meet one or more financial or personal goals. Once you understand what your goals are for your project, particularly if they’re financial in nature, you’ll be equipped to understand what budget the project needs to fit within, and you can go from there.

However, saving money will—and should—always be an important goal for any web project. So in this and a few subsequent posts, we’ll be looking at the best ways to control costs for your web project.

A flailing web project bleeds money.

Today’s post starts with probably the most important principle for cost control: Don’t let your project flail.

In addition to being absolute misery to slog through and getting you a shaky final result months or years behind schedule, every flailing web project bleeds money.

What do we mean by “flailing”? Read on.

What Does a Flailing Web Project Look Like?

The following are common symptoms of flailing web projects:

• Frequent changes of personnel—developers, designers, etc. being hired and fired.
• Long and frequent halts in forward progress when the project reaches a technical or financial impasse.
• Heavy reliance on “sub-subcontractors,” brought in by subcontractors to solve intransigent technical problems.
• “Too many cooks”: multiple decisionmakers on the client team, and multiple teams of contractors with ambiguous responsibilities.
• Major vision and implementation changes: starting the project over with a brand-new software architecture, or retooling the shell of a project to fit a completely new strategic vision.
• Rampant frustration; the sentiment that “this should have been finished months ago” coupled with a lack of clarity as to how to finish it now.

They’re Really Expensive

No matter how much a developer quotes you for a project, the flailing version of that project will cost more.

These problems all lead to a final distinguishing feature of a flailing project: Massive budget overruns. A good rule of thumb is as follows: No matter how much an individual developer quotes you to complete a project, the flailing version of that project will cost more.

Flailing projects cost so much because they’re defined by useless and redundant work, all of which you’ll be paying for. They’re the web equivalent of having a house almost built five times—first by a firm who built the foundation on swampland, later by a firm that used asbestos insulation, then by a firm that properly built the lighthouse you at the time believed you needed, and so on—while paying for both parts and labor.

Furthermore, because a flailing project is agony for all involved, you’ll throw your original hoped-for budget out the window if you believe there’s someone you can pay to stop the bleeding—meaning that you’ll quite likely be paying a very expensive expert to undo the knots you tied yourself in by avoiding expensive experts in the first place.

How Not to Flail

Web projects flail because of a lack of clarity.

How to avoid the scenario above? The one-word answer is: clarity. Web projects flail because of a lack of clarity: vague project parameters, unreconciled goals in vision, under-knowledgeable developers, and so forth.

A major foe of clarity, present in every web project to some degree, is complexity: “Things unknown at the project outset that will only become clear during the project itself.” Every flailing web project is overwhelmed by complexity, either innate (the problem’s too hard), incidental (we’ve made our own lives needlessly hard), or both.

To maximize clarity and manage complexity in your project, your job is twofold:

1. Resolve complexity as much as possible at the outset of the project.
2. Avoid introducing unnecessary complexity within the project.

Getting Clarity at the Outset of Your Project

Know Your Goals

This sounds obvious, but it may not be. What are you trying to accomplish with your project?

If your goals are the main source of complexity in a project—the main “unknowable” that you and your developer are allowing to reamain suspended in midair while he or she starts building—then all is more or less lost. This is less uncommon than you’d think, particularly at the subtle level of (say) “My goal is to start a mobile-based social network for fishermen and I haven’t thought through whether that’s realistic.”

Don’t Scrimp on Good Advice

A good developer can save you literally hundreds of hours of a bad developer’s time.

The worst way to try to save money on a web project is to refuse to talk to people who could give you crucial good advice. A conversation with a good developer can save you literally hundreds of hours of a bad developer’s time, by clarifying your goals and the best technical route to them.

Don’t be afraid to pay a high-cost developer for some preliminary consulting to get the basic technical path to your site established. This is where you can ask the really big questions: “Should this be a website or a mobile app?” “Should this be on WordPress or a standalone web application?” Or just “How would you approach this project given my goals?” You need to take these questions seriously; being casual with them is how you set yourself up to flail. It’ll cost you some amount up-front, but you absolutely may save yourself multiples of that in return, as well as months off your life.

If this is too expensive to contemplate, then find a way to pick the brains of some thoughtful developers for free. Why not go to a tech meetup and ask a few people for advice during the “mingling” section? Developers love to problem-solve, and they’ll almost certainly give you great, honest advice simply because it’s fun and because you asked. This can also be an ideal way to meet a qualified developer who can take your project forward.

WordPress meetups are absolutely awesome if your site will be a WordPress site—which most sites should be—and most areas in the US have one nearby.

Vet Your Developers!

It’s tempting to view prices in the Wild West of web development, which range from $5 to $500 an hour, as utterly arbitrary. They’re not: to a large extent, you get exactly what you pay for. On many types of projects, I’d even wager that 10 hours of clean execution by a $200 developer will get you a lot further than 100 hours by a $20 developer, since so much of the job relies on absolute technical knowledge and skill.

Please take a look at the website cost rules of thumb (some specific to WordPress) recently put together by a developer friend of ours who also runs an outstanding WordPress blog. If you want to stay on the cheaper side of the developer curve laid out in that article, that may be fine, but ask yourself the following questions:

• If this developer is cheap and domestic: What has kept him or her from moving up the wage curve? Ideally the developer would be outstandingly trained but just getting established. However, other causes might be a lack of technical skill—meaning technical impasses and/or expensive sub-subcontractors behind the scenes—or trouble working with clients leading to low demand. Or is this developer following a “low-value high-volume” model, and might this spell trouble for his or her willingness to partner with you in the sense that good web projects generally require?
• If this developer is cheap because of international wage disparities: What evidence do I have that these developers perform work to the standards I expect? Are there language difficulties, problems with reliability or accountability, gaps in technical training, work-related cultural disparities, or other issues that may cause problems?

In sum, you need to hone your good developer radar—and use it very discerningly if you’re betting on a low-cost developer.

Avoid Introducing Unnecessary Complexity Within the Project

This basically means “Be sensitive to the costs of jittery decisionmaking.” If the steps above put you in a good and relatively clear position at the start of your web project, understand the costs associated with deviating from it.

Are you suddenly convinced that your site needs a large range of features and functionalities not originally accounted for? Are you almost certain that your current developer is taking too long to do something that, to your mind, someone else could do much quicker and more cheaply? You may be right about all these things, but budget substantially more cost and complexity as a result of large disruptions than you’d probably expect.

As we wrote a while back, “just move the wheels out six inches” is only simple as a sentence. As a process, it’s the kind of thing that could cost a car company billions if they were most of the way toward tooling up a new model.

In other words, stability and steady decisionmaking will mean a lot for the final budget of your project, so try to see potential deviations in that light.

In Conclusion…

The key to getting your site developed for the right price is clarity.

To sum up this great big post: the key to getting your site developed for the right price is clarity. Get as much clarity as you can at the outset of your project (and even be willing to pay for clarity), and value that clarity during the project, and you’ll avoid most of the problems that cause a web project’s budget to explode.

Hope that helps! We’d love to hear from you in the comments below. And, as always, if we can help clarify anything ourselves, please don’t hesitate to say hello!

Related Posts

• 
  Video: The Three Plans You Need to Have in Place Before Starting a Website
• 
  We Bought a Website!
• 
  Video: The Three Plans You Need to Have in Place Before Starting a Website

Image Credits: billfromesm