7 Rules for Successful Web Development

Since Bluehouse Group’s inception, we’ve built and launched hundreds of web applications. While the technology stacks and UI design trends have evolved over time, we've discovered a few principles of the web application development process that remain unchanged.

These rules we’ve found are universal. They’re indifferent to whether you’re a startup or an enterprise, whether the app needs to be internal or customer-facing, or even whether you’ve successfully undertaken the process before.

Here are seven rules for a successful web application project, along with the risks of ignoring the rules and the rewards of staying on the straight and narrow.

Have a purpose. Solve a problem.

The basic first step of any new project is an idea.

The question now becomes, is that idea enough? Was that idea generated with an intent to solve a specific problem, or was it generated in an attempt to simply make more money? If its the latter, then your new web app most likely will never receive the user validation it needs to get off the ground. Know the issues your user base faces on a daily basis, how it affects their goals (be it personal or professional), and what would they be willing to do (or pay!) to make it less painful.

Our team recently underwent an Event Storming exercise with the renowned Julie Lerman. It's a business process improvement technique that is used for accelerating software teams that follow the Domain-Driven Design methodology. The process brings together multiple stakeholders to identify domain events that make up their job functions. It quickly identifies where your pain points reside and which ones have a greater effect across the entire business operation. Software developers can use it to realize the "right" problem, which isn't necessarily the first idea brought to the table.

Align the stakeholders.

A web application project often involves multiple stakeholders. At the very least, there are marketing, technical, and financial roles involved. To make the process more complicated, there are often multiple groups of potential users and product owners with different roles and attitudes, and even outside funders with their own interests in play. Everyone perceives different needs based on how they’ve engaged with the target users or industries.

It’s critical that all these stakeholder groups get on the same page early, and have regular opportunities to get back on the same page if needed. Nothing will throw a project off harder than having a critical stakeholder - say, the finance person - suddenly realize that they are not on board with the project’s direction.

Everyone can’t be involved in every decision, but it’s a good idea to hold an initial kickoff meeting where all stakeholders get the impression that their voice will be heard, and to provide regular progress updates that are stored in a central place and visible to anyone interested. You never want to leave people to simply imagine the best … or the worst.

This is one of the reasons the agile methodology has become tremendously popular in the developer community. It provides the chance to quickly address roadblocks and air out misinterpretations.
It’s much better to let small questions and disagreements come to the surface early when you can deal with them and keep all stakeholders aligned behind the project.

Users rule.

The users are the rightful queens and kings of your project. Whether they are internal users or external users, a web application project should live and die by how well it serves the interests of those who actually use it. Too often, these rightful rulers are usurped by other competing interests, resulting in the most painful kind of project failure: a project that makes it all the way to completion, only to languish, unused, because no one finds it useful.

Marketing and financial concerns are a potential disturbance here, but surprisingly the most dangerous threat comes from within, as the product team becomes overly enamored by adding their favorite features that they forget to test whether the features add value. This problem is especially dangerous and tricky to spot since it can come from a real passion to make the project as amazing as every team member desires it to be.

Your best defense is data - get the best data you can from actual user testing, and let that drive your product design. This approach has worked wonders for the likes of Amazon, and it can work wonders for you as well.

Fight scope creep.

All project managers, digital and otherwise, quickly learn the need to defend against scope creep. Scope creep simply refers to when the scope of your project slowly grows bigger and bigger, like a weed in a garden.

Before long, the project breaks budget and schedule and new features become so ambitious it’s too hard to manage. Nobody remembers where or why started or when the nightmare will end. That’s a little dramatic, but scope creep is the most common pitfall that throws the web application development process for a loop. There are too many variables that can pop-up to dictate scope change if teams aren’t careful.

Scope creep can come from within the product team or from external stakeholders, and it tends to build on itself, developing a culture of “just one more thing.” In many situations, people don’t like to say “no”, and engineers are famous for under-estimating the effort that a new request will require.

All of this leads to scope creep weeds choking out your nice web application garden. So, what can you do?

Good stakeholder communication is essential, but not sufficient on its own. It’s helpful to keep handy a “nice to have” list, so that when a feature is suggested you don’t have to say “no”, you can say “I’ll put it on our nice-to-have list.” And, like most situations in life, you’ll eventually have to say “no”, so give some thought ahead of time to who on your team has the skills to handle difficult conversations.

In the end, if all the stakeholders are aligned with the project, then they will understand that it is worth small sacrifices to keep the scope in the feasible range.

Choose boring technology over shiny toys.

By “shiny toys,” I mean new software tools, whether it’s a new backend language, the latest JavaScript framework, or a groundbreaking database structure. Projects can become derailed or fail to reach their potential because too much in the way of team resources is spent on these shiny toys instead of on the project itself.

I’m borrowing this idea from Dan McKinley, specifically his article Choose Boring Technology. The gist of Dan’s article is that any team has a limited amount of “innovation tokens,” probably fewer than they think, and if they spend them on implementing new tools, then they are not spending them on the project itself.

Instead, successful projects choose, what Dan calls, boring technology. Not really boring as we would normally perceive it, but tools that are well understood both by the product team and by the wider technical community that is involved.

If a newer, less boring tool is being considered, then it must be held to a higher standard, showing a clear superiority directly related to the goals of the project, and backed up by strong support and documentation in the wider community.

Otherwise, when a project is important, go with the tried-and-true tools. You can always experiment with the shiny toys on your next side project.

Limit integrations.

Remind me again, what does API stand for? Is it “Application Programming Interface”? Or is it something else - maybe “Always Programming Indefinitely”?

Not to get down on the concept of an API in general - clearly, that is a central mechanism of many successful architectures. What I’m highlighting here is the risk involved when you integrate with someone else’s API. The fact is, if your project depends on an external API, then it depends on code that you do not control.

Time and again, you’ll see projects flounder because of unforeseen changes to an external API, or, even more often, the team will make a vast underestimation of the time necessary to properly integrate with someone else’s application.

Each external API you consider should be seen as a significant liability, a risk to be closely analyzed and eliminated if possible, at least for the initial round of work. If you are in a position where you must depend on an external API, do your homework! Find out as much as you can about the type of API connection, the structure of requests and responses, and especially the history of reliability or lack thereof. You are sinking so much time and effort into the code that you do control, it only makes sense to protect it as best you can from the code you can’t control.

It’s not a sprint - it’s a marathon.

Iteration is an important part of any web application development. Very rarely do people finish an initial project and say, “Yeah, that’s all we need here. We’ll never need to revise this.” User preferences change, goals are adapted, and organizational resources expand or shrink. That’s why the development process is a marathon - you’re constantly looking towards the best future outcomes.

Unfortunately, for whatever reason, teams often overstuff the initial production. Goals are often better served by getting the project out for user feedback and adjusting in future updates. In reality, teams need to maintain a long-term focus by keeping their ears to the ground and hearing what users have to say.

You’re in it for the long run. Ignore that nagging scope creep and self-sabotaging doubt. Release your web app when it’s supposed to be released. It’s beautiful just the way it is! Once it's live, listen to your users and listen good.

As customers navigate their new tool you’ll quickly hear about reoccurring pain points. If you’ve overstuffed the application you might find yourself backtracking and omitting previous hard work that was once thought to be something great. There’s a reason why many startups are going the way of minimum viable products (MVPs) and pivoting upon an abundance of user requests.

Until the next project...

There you have it, seven rules for a successful web application project, along with the risks and rewards at stake for each one.

One last point - if you are contracting with a vendor to handle web development, be sure to confirm that they satisfy your concerns about the kind of issues listed here. You could even use this list as a cheat sheet, briefly explaining each issue, and asking them about their thoughts on the problem and how to handle it. You might make some interesting discoveries.