Mostly, web app project failures are not because of the inability of the developers to write code. But they do go wrong, for no one agrees with what is being built, and/or the buyer picks the wrong team in the first week. Fortunately, both of the problems can be easily prevented if you are familiar with their causes.
What You’re Actually Paying For
A web app isn’t your brochure site. It has a login, data, payment or something like a workflow. Therefore, if you are taking up web application development services, you ought to anticipate something more than simply “we will construct it.”
The typical engagement includes the following items:
- Discovery: includes what is technically possible, requirements, and user flows
- Design: wireframes, prototypes, consistency of design
- Development: front end, back end, APIs, database
- Testing: a test for how the app performs on the device, its speed, and its security
- Launch and support: hosting, monitoring, fixes
A quote that doesn’t include discovery or post launch support doesn’t save money. Those costs simply pop up later, typically at an inconvenient time.
Pick the Pricing Model That Fits Your Situation
| Model | Works well for | Watch out for |
| Fixed price | Small projects of defined scope | All changes will be paid as change requests |
| Time and materials | MVPs and evolving products | Budget creep if you don’t set a limit |
| Dedicated team | Long-term products | Requires real management on your part |
The general principle is: if you’re not certain of your needs, the more flexible your pricing should be. It just doesn’t make sense to have a fixed price when the scope is not fixed.
A Scorecard You Can Actually Use
Comparing vendors based on gut feeling is a lousy strategy since the most successful person is going to sell. Try this instead. Give each vendor a score on each of the factors, multiply by the weight and total up.
| Factor | Weight | What to look for |
| Relevant experience | 25% | Projects with comparable size and industry that have already been completed. |
| Technical fit | 25% | Making good use of technology, and why. |
| Process transparency | 20% | Demos every week, clear and complete documentation, access to the code. |
| Security and compliance | 15% | How they deal with the data, testing and regulations. |
| Support and ownership | 15% | Its terms of maintenance and ownership of the code. |
A minimum of 4.0 points makes a good candidate. If it’s between 3.0 and 3.9, ask further questions. Below 3.0, move on.
Modify the weights for your project. For payments or critical information, take security to the 25% level. Transparency is more important if you’re a startup in a hurry to launch your MVP.
Five Questions Worth Asking on the Call
- It’s as important as what a vendor answers, how they answer!
- What if you were to remove what part of your scope to start it early? The good teams turn around and back up. The feeble ones bow their heads to anything.
- Who will you have doing the work on my project? Don’t request a company profile.
- What if we don’t make a deadline? You need a definite procedure, not a vague promise.
- Have you had a test report / code review for any projects you’ve worked on in the past? They are still discernable, even if redacted, and can make sense of their operation.
- “What happens if I don’t get along with him/her after we get started?” Full code, credentials and documentation is the answer.
