Every founder who has asked me to price a platform has asked the same question first: how much to build it. It is the wrong question, and the answer to it is almost never what makes a project expensive. I have watched teams hit their engineering estimate to the week and still burn twice the budget, because the estimate covered the part everyone could picture and none of the parts nobody thought to ask about.
What follows is not a price list. Rates vary by whether the work is product, engineering, or quality, and partnerships get structured entirely differently. This is about where the money goes, which is more useful anyway, because it is the thing you can actually control.
The screens are the cheap part
When someone describes the platform they want, they describe screens. A listing page, a booking flow, a dashboard. Screens are the easiest thing in the build to scope, because everyone can see them and everyone agrees when they are done. They are also, in my experience, somewhere around a third of the real work.
The other two thirds is everything the screens sit on top of:
- The data model, which has to be able to express the business you actually have rather than the simplified one in the pitch deck.
- The money flow, if money moves. Who is charged, who is owed, when the obligation is created, and what happens when a payment fails halfway through.
- Operations tooling, meaning every screen your own team needs to run the thing. Nobody puts these in the estimate. Everybody needs them in week one.
- Identity and trust, which is anything from a verified email to a background check, depending on what your users are handing each other.
- The reconciliation layer, which is how you prove at the end of the month that what the system says happened is what actually happened.
None of those are visible in a demo. All of them are load bearing. A platform that skips them does not fail at launch, which is the dangerous part. It fails about four months later, when the support burden becomes a second full-time team and the numbers stop tying out.
Three things actually drive the cost
After enough of these, the estimate collapses into three questions. Everything else is detail.
First: how many kinds of participant are there? A tool with one kind of user is a straightforward build. The moment you have two sides who need different things from the same transaction, the complexity roughly doubles, because every rule now has two readings and every screen has two audiences. At Braganza Collezione there are agencies, brokers, owners, and renters touching a single booking, each with a different view of the same money. That is not four times the work of one, but it is nothing like one.
Second: does money move, and does it move between parties rather than just to you? Taking a payment is a solved problem. Splitting a payment four ways according to a configurable agreement, holding some of it, releasing the rest on a schedule, and producing a statement each party agrees with, is not. If your platform does this, it is the single largest line in your build, and it is the one most commonly left out of the first estimate entirely.
Third: how much of your operation has to be built rather than bought or done by hand? Every platform has a point where somebody internal has to intervene. The question is whether they do it through a tool you built or through a database client and a spreadsheet. Early on, the spreadsheet is genuinely the right answer. But you need to know you are choosing it.
What speed really costs
In 2020 I led the work to take the Sundance Film Festival fully digital. A festival that had been in person for four decades had six months to become a platform: ticketing, film streaming, program guides, screening lobbies with live chat, artist experiences, private screenings, DRM with per-viewer forensic watermarking, and the internal tooling to run all of it.
Six months was not achievable by building faster. It was achievable by deciding, early and deliberately, what we were never going to build.
We assembled a vendor ecosystem for film ingestion, processing, and streaming rather than building one, and spent our own engineering on the things nobody could sell us: the festival's specific ticketing rules, the community experience, and the operations layer. That was not a compromise on the timeline. It was the timeline.
Every genuinely fast build I have been part of looks like this. Speed does not come from a bigger team or longer hours. It comes from someone with enough authority across product, architecture, and the business to say what is out of scope and make it stick.
The most expensive platform is the second one
At MooveGuru and HomeKeepr, I inherited three platforms acquired separately, each solving a version of the same problem, each with its own data model and its own idea of what a customer was. Consolidating them into a single product cut the engineering footprint needed to operate and evolve it by more than 75 percent.
Read that number in the other direction. Before the consolidation, roughly four times the engineering was being spent to deliver the same thing, and it had been that way for years. None of the original builds were incompetent. They were each reasonable in isolation, and the cost of that showed up later, on someone else's budget.
This is why the cheapest build is so often the most expensive decision. A specification handed to a development shop produces exactly that specification. If the product thinking underneath it was wrong, you find out after you have paid to build it, and you pay again to unpick it.
How to tell before you commit
If you are about to sign something, these are the questions worth asking, and the answers tell you more than the number at the bottom of the page.
- Ask what is not in the estimate. A good answer is specific and slightly uncomfortable. A vague one means the gaps are still there, they just have not been named yet.
- Ask who owns the data model, and whether that person has met your operations team. If the answer is that it will emerge from the tickets, it will, and you will not like the shape.
- Ask what happens when a payment fails, a user disputes a charge, or two parties disagree about what they are owed. If there is no answer, that work is real and it is unscoped.
- Ask what your team will be doing by hand on launch day. If the answer is nothing, it is wrong.
- Ask who decides when product, engineering, and the business model disagree. If it is nobody, it will be resolved by whoever is loudest, one ticket at a time.
The short version
The build is not the expensive part. The expensive part is everything the build assumes: a data model that matches the business, money that reconciles, an operations team that can work, and a decision-maker who can hold product, architecture, and the commercial model in one head and keep them agreeing with each other.
Budget for those and the engineering estimate tends to hold. Skip them and it will not matter what the engineering estimate said.
Written by Spyder O'Neil, a product and technology leader who builds, launches, and scales digital platforms.