How to Fail at Custom Web Application Design

By Barrett Lombardo

After 12 years of experience building custom web applications for both ourselves and our clients, we have a pretty good understanding of what it takes to totally bomb a complex project.

A web application is simply a website or a website feature that is designed for a user to perform a specific task. This task usually requires information to be entered or shared by the user. The simplest example is a contact form (and yes, once upon a time the development of a contact form was an expensive and custom feature for a website service provider). Other examples:

  • was developed by CGI Federal – this is a massive web application that integrates with hundreds of other web applications in the insurance industry.

  • Association management websites are built on top of platforms, integrated, and customized to each association’s needs. Some providers are and

  • There are many small web applications on custom designed websites like a portfolio (example below), a social media feed, and an ROI calculator.


Regardless of the size and scope of the custom application or feature, the fundamentals are the same.

What are Common Issues That Result in a Failed Custom Project?

Bad communication

A series of good conversations between you and the service provider are necessary to determine a fit for the two parties. However, even if the two parties have a good rapport, there can still be trouble if there isn’t a true understanding of goals and expectations for success.

Unclear goals

If the provider can’t understand why you want this application, it’s impossible to assess or prioritize requirements. Start with getting buy-in from your own team.

Document a project charter and let the appropriate team members contribute to the goals, current issues, and then clear requirements for completion. If your team understands the document, odds are better that the provider will too.

Vague requirements

Along with unclear goals come vague requirements – even worse are incorrect requirements! Clearly documented requirements prevent misunderstanding later in the project.

Requirements will change.

It is inevitable that at some point in the process, no matter how well the goals and requirements were mapped out, something new, unexpected, or unforeseen will pop out of nowhere – and that’s ok.

Goals and requirements should be documented and approved by your team at the beginning and every time they change.

Scope creep

“But I thought it would do this…”

Also knows as:

  • “What if we changed that to…?”

  • “I thought it would work more like…”

  • “Can we just add this…?”

  • “OMG I forgot we needed that…!”

“Scope creep” can result in disaster: wasted time and money, low morale, mistrust and resentment. Everyone can feel it coming, and without good project management, the work can spin out of control.

Make sure you have a clear understanding and acceptance of the process the provider uses to document goals and requirements.

Even (and especially) if the project goes smoothly, dreams of the next phases to capitalize on the investment can be thwarted if not discussed early on in the project.

I would like an app with that…

Web applications are not the same thing as device applications, software, or mobile apps. They can’t just be converted into an app later.

A web application can serve as the source of data to feed an app, but that needs to be planned from the beginning.

Can we integrate with…?


If you have any plans to integrate other systems with your web application, make it a goal and requirement from the start. It may be impossible to do so later!

Unrealistic Expectations

You know your business, your market, and your staff pretty well. You might personally know your customers well. But you do not know if your users (customers or staff) will want to use the web application as documented.

Your provider likely does not know your business, your market, or your staff. They probably know about usability and data architecture and design process for your project. But they will not know if the final product will be useful to your users.

In other words, both you and your service provider need to have realistic expectations for the chance of success as defined for the project.

  • What is the critical mass of users needed to be successful?

  • What is the shelf-life of the web application?

  • How will the product change?

The odds of success of your project are greater when you, the provider, and the users collaborate to define the final product; and then expect it all to change.

Building a Better Robot

Plan big, start small

There is a term in software development called the Minimal Viable Product (MVP). MVP is a strategy targeted at avoiding building products that customers do not want and seeks to maximize the information learned about the customer per dollar spent.

A project that defines success milestones with MVP in mind have:

  • lower risk of wasted effort (and money)

  • better chance of user acceptance

  • longer shelf-life

User buy-in, beta users

With each release, there should be a plan to involve real users to test and provide feedback to you and the provider.

Mistakes; expect rework; repeat

Feedback may reveal issues you never considered – and that’s ok. Requirements will change. Incorporate these changes into the next release.


There is a fundamental difference between a stand-alone (or closed) application and an API driven (or open) application. If there is ever an intention to integrate with another system, build that in first.

Be prepared for failure if you don’t invest in marketing

It’s harder to get users than you think. Just because your team and your beta user group loved the product doesn’t mean that they will actually use it. You will need to stay involved with your user base and keep improving the product.

The Safe Approach: Consider Prototypes with Existing Tools

Build vs. buy

The cost to build can be high and never-ending. The cost to buy is fixed and only incurred once. Maybe you can build on top of it. Shop around first. If you are using open-source web software like Drupal or WordPress, there may be a module or plug-in that does 80% of what you need.

Why buy when you can rent?

There are tons of hosted platforms on the web – also known as “software as a service” (SaaS). Start your research by trying a hosted solution. You will learn a lot about workflow, usability, and limitations that may apply to your custom web application if you decide to pursue it. If you can get away with the hosted software solution and conform to its limitations for a while, you may get some time to save for the investment. And hopefully, the provider will listen to their customers’ requests and build in new features.

Consider the total cost of ownership

When it comes to determining the ROI, be sure to add up the shelf-life, support, and updates. If you are creating a competitive product, others will work to make something better. If you are developing a closed application for your company, the software and hardware will become outdated. As always, requirements will change.

How Does it End?

If you’re lucky, it doesn’t end. A healthy web application is an ever evolving piece of software. Assuming you will succeed in the early stages, you will have many opportunities to practice steps towards greater achievements.

There is more where this came from…

The best articles from this blog are available all in one place – our book. Now on it’s 6th edition.

Content Chemistry, The Illustrated Handbook for Content Marketing, is packed with practical tips, real-world examples, and expert insights. A must-read for anyone looking to build a content strategy that drives real business impact. Check out the reviews on Amazon.

Buy now direct $29.95