“What will it cost?” is the first question on almost every Discovery Call. It is a fair question. The honest answer is that we do not know yet, and that any firm that gives you a number on the first call is guessing. This post is about how we get to a number you can trust, and what makes that number go up or down.
The number comes from design, not from a call
Here is the problem with quoting early. A “customer portal” can be a login page and three reports, or it can be a full self-service system with payments, document signing, and integration with your accounting platform. Both are customer portals. They differ in cost by a factor of ten.
Until someone has sat with the people who do the work, mapped the process, decided what the first release must do, and sketched the screens, the scope does not exist. And without scope, a quote is a placeholder. Roughly 70% of software and data projects fail or run over, and a lot of that starts with a number somebody made up before anyone knew what was being built.
So we do not quote a project before a design engagement. For a new system that is a VDP Sprint: Validation, Design & Planning. For a system you already have, it is a System Evaluation. Both are fixed-fee, both take a few weeks, and both end with a fixed proposal for the next step. You can take that proposal to us or to anyone else. It is yours.
What a VDP Sprint produces
Three to four weeks. It opens with a two-day workshop, face to face, with your decision-maker and the people who run the process today. Then design sessions about twice a week. At the end you get:
- Click-through mockups of the key screens, so everyone has seen the system before it exists
- Functional and non-functional requirements, written down
- A technology-stack recommendation, with reasons
- A roadmap, with the investment for the first release
The whole thing is reviewed in a recorded closeout so the people who were not in the room can watch it. The investment figure in that roadmap is the number we will stand behind.
Fixed budget, controlled scope
Our default commercial model is a fixed budget with controlled scope. It works like this.
The budget is fixed. The quality is fixed. What flexes is scope, and you control the trade-offs. When we discover in week five that a workflow is more complicated than anyone knew, which happens on every project, the conversation is not “send more money.” It is “here is what this costs, here is what we could defer to make room, which do you want?” You decide. The number does not move unless you move it.
This is different from fixed price and fixed scope, where the number and the feature list are both locked and every change becomes a negotiation. We use that model when scope is genuinely nailed down, and only then. It is also different from open-ended hourly work, where the number is whatever it turns out to be. We use time and materials with a monthly cap for ongoing and advisory work, not for building a system. More on all three in Fixed budget, fixed price, or hourly.
We recommend the model after the Deep Dive. You do not pick from a menu, because the right answer depends on how well the scope is known, and that is something we can only judge once we have looked.
Strong first release first
The single biggest thing that moves a budget is what goes into the first release.
Every project starts with a long list. Every list has a core: the handful of things that, if they worked, would deliver most of the outcome. The rest is real, but it is not first. A strong first release does the core well, ships, and gets used. Everything after that is built on a system that already exists and is already earning its keep.
We push hard on this in the VDP Sprint. Not because we want the project to be small, but because a smaller first release means working software sooner, less money at risk before anyone sees value, and a second release informed by what people actually did with the first one. The roadmap will show what comes after. The budget is for what comes first.
What moves the number
Once the first release is defined, these are the things that push the investment up or down. Knowing them lets you make choices before the proposal instead of after.
Number of distinct workflows. Each one has screens, rules, edge cases, and testing. Five workflows cost more than two, roughly in proportion.
Integrations. Every system the new software has to talk to adds work, and the amount depends on the other system. A modern platform with a documented API is a known quantity. A legacy system with no API, or a vendor who charges for access, is not. We will find out during design.
Data migration. Moving clean data from one system is straightforward. Moving ten years of duplicated, inconsistently typed records from three spreadsheets and a retired database is a project inside the project. The quality of what you have today matters more than the volume.
Roles and permissions. A system where everyone sees everything is simpler than one with six user types, field-level restrictions, and an audit trail. Regulated industries usually need the second kind, and it is worth it. It is also worth knowing up front.
Non-functional requirements. Uptime, security posture, performance under load, mobile use in the field, offline mode. These are invisible in a feature list and they are often where the money goes. They are also the reason we write them down during the VDP Sprint instead of discovering them in production.
Your team’s availability. A decision-maker who answers in a day keeps the project moving. One who answers in a week stretches it, and time is cost. This is the lever you control most directly.
How the money works
Fixed fees are billed in milestone installments, with part up front. Invoices are due in ten days. We work from a standard MSA and a short SOW, and once paid, you own everything: the code, the designs, the documentation. There is no license, and no lock-in.
The test we hold every proposal to is simple: the value has to beat the fee. If the outcome you named on the Discovery Call is not worth meaningfully more than the number in the roadmap, we will tell you, and we will suggest a smaller first release or no project at all.
What to do with this
If you are early and want a sense of scale, typical budgets by type of project are on our pricing page. Use them to check whether the conversation is worth having. Do not use them as a quote.
If you are ready to get a real number, the path is a Discovery Call, then a Deep Dive, then a VDP Sprint or a System Evaluation. Three to six weeks from first conversation to a fixed proposal you can take to your board. Start with the call.