The honest answer is "it depends," which is useless on its own. The useful version is knowing what it depends on. Custom software cost is mostly labor cost, and labor is not one number: US wage data for 2025 spans 2.6 times between the 10th and 90th percentile of the same job title. Add scope, integrations, migration, and compliance, and a tenfold quote spread stops being suspicious.
Why do two quotes for the same brief differ by an order of magnitude?
Because the brief is not a specification, and the labor is not one price.
Start with the part that is measurable. The US Bureau of Labor Statistics' Occupational Employment and Wage Statistics survey for May 2025 counted 1,687,890 people employed as software developers (occupation code 15-1252). The median wage was $135,980 a year, or $65.38 an hour. That is the number people quote. The more interesting figures sit on either side of it: the 10th percentile earned $82,460 and the 90th earned $214,670.
That is a 2.6x spread inside one job title, one survey, one country. Before anyone reads your requirements, the input price of the work already varies by a factor of two and a half depending on who does it.
Geography explains less of that than people assume. Nevada's median for the same occupation was $128,810, and the Las Vegas metro area's was $129,940. Both sit within about five percent of the national median. The spread that matters is seniority and specialization, not the ZIP code.
A vendor's rate is not a wage, of course. It carries overhead, non-billable time, warranty, and risk. But the wage data sets the floor, and the floor is not flat.
Now add the second multiplier. The same brief means different things to different readers. One firm reads "customer portal" as four screens over an existing database. Another reads it as authentication, roles, audit history, a data migration, and two integrations. Both may be quoting honestly. They are not quoting the same project. Multiply a 2.6x labor spread by an interpretation gap and an order of magnitude appears without anyone being dishonest.
What does the cost actually depend on?
Six things, roughly in order of how often they surprise people.
Scope surface, not feature count. A feature list is what buyers count. What costs money is the number of states the software can be in. "Approve an invoice" is one line in a brief. The build is everything the line implies: who can approve, what happens when the approver leaves the company, whether a partial approval exists, what happens when an approved invoice is then edited, whether an auditor can reconstruct the decision a year later. One line, a dozen states. The brief did not get longer. The system did.
Integration count. Every integration imports a second system's failure modes: rate limits, token expiry, sandbox behavior that differs from production, schema changes you do not control. Two integrations do not cost twice one, because they interact, and the interaction is yours to own.
Data migration. The reliably underestimated line. Existing data is always dirtier than anyone remembers: duplicate customers, dates stored as text, the field three people used for three different purposes. Migration cost tracks the mess, not the row count, and nobody can price the mess from a brief. This is why a serious vendor asks to see the data before quoting.
Compliance. HIPAA, PCI, SOC 2 and similar regimes change the process, not just the code. They add access control, audit trails, review steps, and evidence you have to produce later. Compliance is not a feature built once. It is a tax on every step.
Design fidelity. "Looks fine" and "designed" are different budgets, and both are legitimate. An internal tool used by six trained people does not need what a customer-facing product needs. Deciding this deliberately costs less than discovering it at review.
The run cost after launch. This is the line that gets left out of the comparison entirely, and it is where the interesting money is.
What does custom software cost to run once it is live?
Less than people fear on infrastructure, and more than people plan for on everything else.
Published platform pricing makes the first half easy to check. Vercel's published 2026 pricing lists a Pro plan at $20 per user per month with $20 of usage credit included, plus a default $200 monthly spend cap. Supabase's published 2026 pricing lists a Pro plan at $25 a month including $10 of compute credits, with storage beyond the included allowance at $0.125 per GB. For a small business application, the hosting line is realistically tens of dollars a month.
Usage fees are the part that scales with success rather than with code. Stripe's published standard pricing is 2.9% plus 30 cents per successful domestic card transaction. That line grows as the business grows, which is correct behavior, but it belongs in the model from day one.
So when a vendor presents "hosting" as your ongoing cost, they have quoted the smallest line on the page. The real run cost is people: someone to fix what breaks, apply the security updates, answer the question when a workflow changes, and make the change when the business does. Software does not have a maintenance cost because it wears out. It has one because the business it describes keeps moving.
An honest cost structure
We cannot give you a price here, and we will not invent one. What we can give you is the shape of the number, which is more useful than a range copied from someone else's page:
- Discovery. Small, fixed, and real. This is where the brief becomes a specification and the tenfold spread collapses.
- Build. The large variable line, driven mostly by scope surface and design fidelity.
- Integration and migration. Frequently underestimated, occasionally larger than the build.
- Launch. Cutover, training, and the first change window.
- Run. Hosting (small and published), usage fees (scale with revenue), and people (the real one). Only one of those five is what most people mean when they say "the cost of the software."
What we are deliberately not quoting
This article contains no Commerce Beacon prices. Not because they are secret, but because a number without a scope is a guess with a decimal point on it, and you would be right not to trust it.
It also contains none of the $50,000-to-$250,000 style ranges that appear across hundreds of agency pages. Those figures are repeated far more often than they are sourced. When you find one, ask what it was measured from. The honest answer is usually nothing.
A real number needs a scoped conversation: your workflow, your data, your integrations, your compliance exposure, and your tolerance for design polish. That conversation is short, and it is the only thing that turns "it depends" into a figure you can put in a budget.
If you are still deciding whether to build at all, answer the prior question first. Custom software or more SaaS tools works through when an off-the-shelf stack is genuinely enough and when owning the workflow has become justified. If you have already crossed that line, Commerce Beacon's software development services start with the operating constraint and the data, then move to scope and a number, in that order.