The most common question I get before a software project starts is: what is this going to cost? It is a fair question, and the honest answer is that it depends on scope — not hours, not technology, and not how long the feature list is. Let me explain what actually drives the number.

The Floor: What a Contained Custom Build Costs

For a well-scoped, contained custom software project — a single workflow automated end-to-end, a single integration between two systems, an internal tool that replaces a spreadsheet — the starting point is around $9,500. That number assumes the scope is clear before work begins, the requirements are documented, and the build does not expand mid-project.

Smaller automations and custom WordPress work can come in below that floor. Custom CRM builds and multi-user applications tend to land above it. The range is wide because the range of problems is wide.

I want to be direct about what that floor buys: a single workflow, built cleanly, with documentation and a handoff you can actually use. It does not buy a platform, a multi-role application, or a system with five integrations. If that is what you need, the number is higher and there is no way around it.

What Drives the Price Up

  • Integrations: Every third-party system you need to connect to adds complexity — API authentication, data mapping, error handling, and testing against a live system you do not control.
  • User roles: A single-user tool is simpler than a multi-role system where different people see different data and have different permissions.
  • Data volume and history: Migrating existing data into a new system, or building a system that needs to query large datasets quickly, adds engineering work that is easy to underestimate.
  • Unclear scope: Vague requirements produce change orders. A project that starts fuzzy costs more than one that starts clear, even if the end result is the same thing.

Of those four, unclear scope is the one that surprises people most. I have seen well-intentioned projects double in cost not because the engineering was hard but because nobody agreed on what the system was supposed to do before work started. The scoping investment — which I treat as a prerequisite, not an upsell — is what prevents that.

Fixed Price vs. Time and Materials

I prefer fixed-price contracts on well-scoped projects. A fixed price forces the scoping conversation to happen before work starts, which is where it belongs. Time-and-materials makes sense when the scope is genuinely exploratory — when you are building something that has never existed before and the requirements will emerge from prototyping.

Most business software projects are not genuinely exploratory. They are solving a known problem in a defined context. Those should be scoped and priced before a line of code is written. See how to scope a software project for what that process looks like.

A caution about time-and-materials: it transfers budget risk entirely to the client. If the estimate is wrong — and estimates are often wrong — you absorb the difference. Fixed price transfers some of that risk to the developer, which is why it requires a complete scope. If someone offers you time-and-materials on a project with a clear spec, ask why they will not commit to a number.

The Build vs. Buy Question

Before pricing a custom build, I always want to know whether an off-the-shelf product handles the problem. Custom software is appropriate when the gap between what exists and what you need is significant and persistent — not when you are annoyed by a feature that a settings change would fix. See no-code vs. custom software for a more detailed breakdown of that decision.

The honest version of this: I have ended scoping conversations by recommending a $49/month SaaS product. That is not a great outcome for my revenue in the short term, but it is the right answer when it is the right answer. Clients remember that, and they come back when the problem actually requires custom work. See build vs. buy software for the framework I use to make that call.

How Phasing Affects Cost

Most projects I scope get phased. Phase one addresses the immediate problem — the workflow that is causing friction today. Phase two adds the capabilities that would be useful but are not blocking operations. Phasing does not reduce the total cost of everything you want to build, but it reduces the cost of getting to a working system quickly.

A phased approach also lets you validate before you invest. If phase one ships and you discover that the problem was slightly different than you thought, you can adjust phase two before it is built. That is significantly cheaper than building everything at once and then adjusting.

Related: MVP development for small business covers how I think about phase one scope specifically.

Ongoing Maintenance and Support

Custom software has costs after launch that SaaS subscriptions do not: hosting, dependency updates, security patches, and modifications when your workflow changes. For most of the systems I build, annual maintenance runs between $1,200 and $3,600 depending on complexity. That is real money and worth factoring into the total cost comparison.

What it buys is a system you own outright — no per-seat licensing, no vendor price increases at renewal, no risk of the product being discontinued. If the system automates meaningful staff time or generates measurable revenue, that trade-off is usually favorable inside the first few years. If it is solving a problem that a SaaS tool handles adequately, it is often not.

What You Are Actually Paying For

Custom software cost is not primarily paying for code. It is paying for a system that does exactly what your workflow requires, built on a foundation you own and control, with documentation that lets someone else maintain it if needed. That is a different value proposition than a SaaS subscription, and it is worth comparing the 10-year total cost of both options before deciding.

SaaS subscriptions look cheap on a monthly basis and expensive over a decade, especially when you factor in price increases, feature limitations, and the productivity cost of adapting your workflow to fit a tool that was not built for you. Custom software looks expensive upfront and often looks very reasonable by year four or five, particularly when the workflow it automates is saving meaningful staff time.

At Salterra, the scoping conversation is where we figure out which category your problem actually falls into. Sometimes that conversation ends with a recommendation to buy something off the shelf. That is a better outcome than a custom build you did not need.

The broader context for how custom software fits into a marketing-aware tech stack is on the software development page.