We’ve written before about different pricing models that you can use for your next software project. But what about agreeing on the price tag with software developers?
There’s no such thing as perfect software. Software is never finished, which can often mean that pricing isn’t, either. No matter how in-depth your requirements document, changes to dev projects are inevitable.
Various situations beyond your control can have you scrambling to find extra budget:
- Your competitor adds attractive new features to their SaaS. Will you keep pace?
- As your relationships with your customers mature, your technology also evolves in order to meet their needs. Which new features will you prioritize?
- When your developers stumble across a reliable way to reduce your server operating costs, will you agree to the sidecar project? You didn’t anticipate this improvement, but it will pay for itself over time.
Trying to pin a price on a software project is like trying to shoot a moving target.
After all, we developers are building software in an unpredictable world for unpredictable users. The business cases that compel a company to develop software sometimes change before we have even finished the first build!
And the factors that induce people to use the software always change.
So in this post, we’d like to share seven tips that will help you grab those money discussions by the horns. We have gleaned these suggestions from our experiences at Clear Function, and we present them here in no particular order
[hubspot portal=”19985468″ id=”bf7f4c49-8cad-45d1-82a7-300d518a23a3″ type=”form”]1. Even if your dev team has worked on a similar project in the past, their quote may still be inaccurate.
Maybe you already have a dev team on retainer, and you believe that your current planned payments will accommodate the scope of your next project.
Or maybe various developers are still submitting quotes for your project.
Regardless, you will be eager to save money when and where you can. You want an accurate quote. Yet, even if your team of choice did a similar build for a past client—even if the scope is similar—the price may be different.
Why is that? Different clients have different needs, priorities, and internal systems for managing workflow and budget.
So don’t expect for developers who have done similar projects in the past to deliver a perfect quote. Unfortunately, there is no secret formula that guarantees accurate pricing because no two clients and no two projects are alike.
2. Developers must anticipate risks and factor them into pricing.
Ever wonder what developers are thinking when you’re discussing your project specifications? Mostly, they’re pondering how to help you have healthy expectations.
They’re paying close attention to what you say, and they’re trying to spot risks that could blow the project scope. Scope creep introduces risk: risk that you’ll run out of money, risk that the project will never conclude, risk that you’ll walk away frustrated and will blame your sunk costs on the developers.
So smart pricing lives somewhere between a client’s needs, as defined in a requirements document, and the gotchas that inevitably crop up mid-project.
3. Software is an investment that can become obsolete quickly.
You cannot expect the quality of your software to match the quality of your brand unless you invest in high-quality development. In this day and age, even excellent code can become obsolete quickly.
In order to protect your investment, you must monitor and maintain your investment. This requires… more investment.
4. You cannot plan for some real-world roadblocks.
There are two types of projects in this world:
- Projects in our heads; and
- Projects in real life.
Yet, neither type of project tells the full story of software development.
Even after months of research and planning for a major build, we will still hit real-world roadblocks that alter the course of the build. The solution we initially planned is no longer feasible. Perhaps the client’s business priorities or product roadmap are now untenable.
Such situations are frustrating to everyone involved, and they are nobody’s fault.
How do we proceed?
Now you understand the conundrum that we developers often face.
5. What you value affects the price.
“Delivering the build as quickly as possible…”
“Has to have the highest-quality code…”
“We cannot launch without these features…”
“We’re trying to do something that has never been done before…”
These snippets from past conversations reveal what our clients value, what you value.
If we attend to your word choice, we come to understand how you value our work. What do you believe we bring to the table?
Speed or quality or strategy or innovation.
We listen for your values, and then we adjust the way we request to spend our time on a project. We try to align our labor with your values, and if we negotiate later agreements with you, we adjust the pricing to account for your values.
For example, unless we’re going to put a bunch of developers all on your project at once, it isn’t feasible to have the build finished tomorrow and for the code to be top-quality and for all of those snazzy new features to be included.
6. Your past experience with software projects may affect the price.
Clients who have already gone through a software project understand that software is never finished, only released.
They know better than to assume that they or we can know what we need to build before money has changed hands.
They know that the accuracy of a quote and the developer’s confidence level in that accuracy can only go up after the project has commenced.
They recognize that project scope shifts over time in order to align with their values and needs.
The development process will follow twists and turns for them—and for us—but it is the development team’s responsibility to explain how we will address scope creep and other departures from the original plan.
Once we believe we have identified the product path, you the client must determine which changes to scape your budget can accommodate and which ones must wait.
In a fixed-fee situation where you identify a user-facing feature as essential to the project’s success and we tell you that feature is out of scope, you must either add to the budget to cover the change order or you must kill the project. (Obviously, such situations will come as a shock to clients who have never worked with a development team.)
No fixed-fee project ends up having a fixed scope. And that reality means that developers must spend additional time on tasks that the original contract didn’t include. And additional time usually translates into additional costs.
However critical such changes may be, you can imagine how they can contribute to tension between clients and developers during a project.
Frank, frequent conversations about money are the only way to diffuse that tension.
7. Re-read the original contract and pick up the phone.
The moving target reality of software development doesn’t always mean that the price will go up. The original scope that developers quote may include some cushion. This cushion can absorb small change requests.
If you’re wondering if you’ve got time left on the clock, call your developer. No matter how much (or for how long) you have paid your developers, a frank conversation about what is in scope and what isn’t can go a long way to pre-empt money-related tension before it builds up.
Like you, your developers are trying to keep the lights on.
It’s in their best interest to keep you happy, but they can’t say yes to every change request and still earn enough profit to stay in business.