Anybody floating down the river of Agile these days will look very sharply at you when you ask how much time it will take to build a feature, or how much a set of features will cost. The answer is usually, ‘By letting us do what we do best, you will get the most value possible per time. By demanding release dates and budgets, we can only say for sure that we will deliver less value per time.’ Yeah. Thanks a lot, man.

On one hand, what the Agile development manager told you is true (for a competent, motivated and honest development team). But as holder of a budget for software development, you would be crazy to accept this as an answer. No methodology is going to make you open your wallet and say, ‘Take what you need’, right?

This short article will give you ideas about what contributes to the cost of custom web software development. In particular, we’re going to describe the costs from the point of view of software development whose goal is to deliver value to users. (This is probably your goal as well; however if your goal is to meet a quarterly objective to ‘finish Project Omega’, and not to deliver value to users, then you may be interested in a different set of questions.)

Tangible Contributions to Cost

We think of these as the 'Who, What, When and How' factors.

Desired Functionality

Everybody gets that the more your application has to do, the more it will cost. So let’s get that one out of the way. Assume for a moment that your integrated development team will not discover anything about your users and how they derive value from your application. (They will discover plenty, actually, if they are good.) Then with some common sense and domain knowledge, you can guess that a website that accepts applications for membership in a civic organization is going to cost a lot less than an application that predicts where the next electrical power line will fall and cause a wildfire. Complexity costs time and attention; and therefore complexity costs money.

Your Audience

Typically, the more different types of people using your application, the more it costs to discover and design and build solutions for their needs. If you’re building collaboration software that supports a team configuration of managers, reviewers, developers, content contributors, and they all have to play different parts with different access and responsibilities, then that’s going to be harder to build than a system where a user just buys a lottery ticket.

A further consideration is the expectations that a certain audience may have with respect to the type of service you provide. Allowing bank executives to request overnight funds in the hundreds of millions of dollars is different from allowing bank tellers to sign up for employee benefits online.

Platforms, Pipelines and Tools

Are there requirements that the development occur under specific conditions? Chances are, unless you are starting a new company without a CTO, you will have technical constraints. Every technical constraint you add will contribute something to the cost.

Do you need everything to run in a container under Docker on AWS? Do you need everybody who works on the project to use your company laptop and authenticate with a proprietary network in order to access data sources? Do you have a Jenkins contract that precludes the use of any competitor for automated testing? Is there a corporate Jira instance whose configuration is set in stone, or can we bring our own Jira optimizations?

In the end, it’s best to look for a near-optimal fit among the tools and processes, and begin work. We tend to learn more, and learn more quickly, when we’re in progress with a toolset, and reserve some time for making mid-course corrections. Tools say a lot about how you intend to work together, and we want to leave you with the best combination for you.

Legacy Code, Systems and Data

Do you have a system that has to operate in parallel with the application that you want developed? Does the new system depend on other legacy systems, or can they be completely separated from one another? Mapping new requirements to old systems can be time-consuming, or it can be a time-saver if those systems are reasonably reliable and accessible via modern methods.

Timeline

Are you under a very tight timeline? If you’re lucky, then whoever you work with will be pulling qualified developers off of other projects, and it will cost them to spin up new developers to cover those other projects. That will undoubtedly be reflected in the cost to you, in one way or another. If you have a 3-month project that only needs to be completed sometime in the next 12 months, chances are that you can hire a firm that (with a commitment on both sides) will be able to take advantage of timing of other engagements to get the right people at the right time.

Intangible Contributions to Cost

We've all been there. The designs in the epics were crystal clear; we even had the technical architecture nailed for scale. But ten months later we were over budget and still hadn't launched. The reasons weren't any of the factors above. They were intangibles like the ones we'll discuss next. Because we never want to build something pointless, we include these intangibles in our assessment of how we can help you and how much it will likely cost.

Clarity of Objectives

Maybe you imagine that this is a higher-level problem for a CEO to worry about, but if we look at what projects cost compared to initial budget, it’s clear that the most expensive projects (compared to initial budgets) were the ones where the objectives of building the software were not clear. One of the fastest, cheapest projects we ever completed was one that had tons of functionality, lots of pages, and lots of error states; but it also had a very clear business objective, and an accessible stakeholder base.

Access to Stakeholders

This comes down to ‘building the right thing’ (compared to ‘building the thing right’). It doesn’t matter where your development team comes from, if they’re going to operate in a vacuum, then they’re going to spend relatively more time working toward unverified objectives. As a result, they’ll spend time reversing their steps when it’s determined that the product spec’d without real stakeholder feedback was not the right product. That’s going to cost you money, features, or time, or some combination thereof.

An Empowered Team Avoids Delay

Will our team, in the environment of your company, be able to make all the decisions necessary to deliver value to your users? By allowing us to earn your trust, you empower us to remove our own roadblocks, and not spend weeks or months on the sidelines. Delays cost money. 

These Factors Affect Our Proposal to You

When we write a custom proposal for your development project, we consider these tangible and intangible factors to ensure we can meet your expectations, create value together, and get paid. Complex requirements and stakeholders with high standards don’t scare us; they just help us to scope what we can deliver, and when. But gaps in the intangible areas lead even more certainly to delays and rework, and so we consider these carefully when we make a proposal, to protect you. And us.

Does any of this sound crazy to you? We’d like to talk more.