Our Blog

A blog by InetSolution about programming, security, design and marketing for banks, credit unions and e-commerce.

“How much will this project cost?” May not be the Best First Question to Ask


By Jason Sherrill on Tuesday, April 29, 2014


Usually the first question prospective clients hope I can answer quickly is, “How much is this going to cost?” That’s a reasonable question, but unless you know exactly what you want and can provide detailed specifications to your development team, you're not likely to receive an estimate with high degree of accuracy. In most situations, you'll achieve a better outcome by sharing your budget amount with a trustworthy partner and asking, "I have X dollars available for this project. How can I best maximize my value in this project?"

Should I Be Secretive About My Budget?

Frankly, that practice is primarily born of purchasing processes tailored to commodity items where the widget is identical regardless of where you purchase it (think plumbing fixtures or hard drives). When hiring talent (i.e., humans with an expertise and experience in a discipline), you are relying on the people you hire to use their expertise to recommend and deliver a solution that is a direct result of their knowledge, effort, and understanding of your needs. You will get the most value from their expertise by giving them as much information up front as possible. How much money is available? What is the deadline? What resources are available and to what extent will the team be able to use them?

To help properly scope a solution during the estimating phase, most developers will ask you what your budget is for a project before starting any planning. An experienced developer can often accurately predict which types of functionality are reasonable for a project based on the available budget. In our example above, if you only have a budget of $5,000 for your entire project, then an experienced developer will know it is impossible to develop Team B’s functionality and instead can recommend a solution that better fits within the budget. By sharing candidly your budget limitations, you will save yourself time in the long run by allowing your prospective development team to present realistic solutions that fit within your budget.

Why do estimates vary from one team to another?

In my career, I have worked on projects that had budgets ranging from $5,000 to millions of dollars. While a $5,000 website and one million dollar website are both websites, they are very different projects. RFPs that use generic terms to describe significantly different feature sets is one reason why estimates vary so much.

How Developers Read Your RFP

When you ask a team of developers how much it is going to cost to develop your website or mobile app, the estimate is going to largely depend on three factors:

  • Specific functionality of the website or software

  • Types of skills necessary to build the functionality

  • Billing rate for each of the people involved

The functionality differences are where you’re going to encounter the most variance. When a generic term is used to describe functionality, the developer’s assumptions of the functionality you desire will result in variances. What you mean when you say “Branch Locator” or “Login” might be radically different from what the person next to you envisions. The same is true when comparing your assumptions to the developers estimating your project.

Let’s look at a common example that will illustrate how two different development teams can estimate one set of functionality very differently.

“Login” Example

Let’s suppose that you want to hire a development team to build an online customer portal. On your requirements list, you include the following feature:

“Requirement #1: A user should be able to login to the customer portal”

You contact two different development teams for an estimate. The estimates you receive back are:

  • Team A - $300 (2 hours)
  • Team B - $4,500 (30 hours)

WHOA, that’s a big difference! What makes Team B’s login so much different from Team A’s login?

How Assumptions Drive Estimates

Let’s assume for the sake of this example that both teams are equally competent and both work at the same pace. If both teams work equally fast and have comparable skills, why are the estimates so different?

To understand the difference, we need to examine the assumptions each team made about your very concise login requirement.

Team A’s Estimate

Their assumptions:

  • You will ask the user for only for a username and a password
  • Username and password values will be stored in plain text in the code
  • There are no rules about the length, complexity, or expiration of a username or password
  • A user can attempt to logon as many times as he wishes without ever locking account out the account
  • No audit log will be kept of failed or successful login attempts
  • No feedback will be returned to the user if he enters an incorrect username or password, rather the login form will just reload with blank inputs if the login credentials are incorrect

Team B’s Estimate

This team approached your requirements with an assumption that you wanted a high level of security, user-friendliness, and a lower long-term support and maintenance costs. Their assumptions:

  • Users will logon with a username and password
  • Multi-factor authentication will also be available for each user account
  • Username will be stored in a secure SQL database
  • Passwords will be hashed and only the hashed value will be stored (as opposed to the real password), which is impossible to decrypt and very nearly impossible to crack.
  • The app will prompt users with a challenge question when logging in from a computer that the user has not previously logged in from.
  • The system to automatically lock an account after a certain number of invalid attempts
  • To aid users who have lost their passwords, Team B’s estimate includes an automated password reset procedure.
  • Team B also assumes that you’ll want a way to manage your users without having to edit the programming code, so they’re planning to build a secure administration portal for the application.
  • Team B knows that keeping a good audit trail of system access is important to security conscious companies, so their estimate also includes writing code to record a log of all activities performed on the website, including failed login attempts, password changes, password resets, and many other common security related activities.
  • Team B also assumes that you want to lower the risk of introducing bugs into your website as you add new features, so they’ve planned to build automated tests into their code that will execute every time your website is deployed. This will help to prevent new code from breaking existing functionality.

Same Name, Very Different Results

The example above is one that we encounter often in our practice and illustrates clearly why you can receive widely varying estimates to develop something as common as a “user login.” Both feature sets described above meet the criteria for allowing a user to login; however, Team B’s approach will clearly require more time and cost, but you may see more value in one approach versus the other.

Candid Budget Sharing Can Give You More than Reasonable Software Estimates

Most development teams I have worked with love their craft and want to maximize the value of the software they create. With a trustworthy, capable team, there is very little risk of a team delivering less value than you’ve paid for. In fact, the opposite is usually true, especially if the team you’ve hired knows that you’ve been honest, you’re easy to work with, and they feel like you respect their talents, knowledge, and the time they will devote to building you an awesome product.

I can speak for the team here at Inet, and others I’ve worked with, when I say that we all genuinely love to help people succeed. Building custom software is a profession based on serving others. We build technology that millions of people use every day to make their jobs and personal lives easier to manage, more secure, and less aggravating. I also see the hundreds of hours that Inet team members put into projects for our clients that never show up on an invoice, simply because the men and women here enjoy helping those clients, even if that means doing work that the client cannot pay for. The team members here simply do it out of a love for the work and helping others. The people who are most likely to receive these benefits are, not surprisingly, those who have built relationships based on openness, trust, and mutual respect. I cannot speak for all people, but here at Inet you’ll definitely earn a return on your investment in openness.

Blog RSS Feed

Request a Consultation

Let us help you accomplish big goals.