Tanner Kirkendall

← All posts

What Does Custom Software Actually Cost?

· Tanner Kirkendall

"What would something like this cost?" is the first question in almost every discovery call, and the honest answer is always "it depends" — which is true and also useless. So here's the framework behind the number, so you can estimate before you ever talk to a developer.

The three things that drive cost

1. How many workflows it touches. A tool that does one thing — track orders, generate a report, process a document — is a small project. A tool that touches ordering and inventory and invoicing is three projects wearing a trench coat. Scope is the biggest lever you control.

2. How many systems it connects to. Every integration — QuickBooks, a CRM, a vendor API, an EDI feed — adds real work, because every external system has its own quirks, limits, and failure modes. Two integrations is normal. Six is a bigger project than most people expect.

3. How many people use it, and how. An internal tool for five trusted employees can be simple. A customer-facing portal needs accounts, permissions, polish, and support for every browser and phone your customers own. Internal-first is the cheapest way to start.

Rough shapes, not quotes

Every project is different, but most of what I build falls into one of three shapes:

  • A focused automation or integration — connect two systems, automate a report, eliminate a re-keying step. Days to a few weeks of work.
  • An internal tool — one core workflow, a shared database, a handful of screens. A few weeks to a couple of months.
  • A customer-facing application — portals, products, anything the public logs into. A few months, and it deserves that time.

A fixed-scope written proposal turns these shapes into an actual number before you commit to anything — that's how I work, and it's what you should ask of anyone you hire.

The question that matters more than price

The better question is: what does the current process cost? Take the hours spent per week on the manual version, multiply by the loaded cost of the people doing it, and multiply by 52. Add the cost of the errors — wrong shipments, missed invoices, the deal that stalled because the quote took a week.

Custom software is a fixed cost against a recurring one. When the recurring cost is real, the math tends to be short. When it isn't — when the spreadsheet honestly works fine — the right answer is to keep the spreadsheet, and a good consultant will tell you so.

Questions to ask any developer you're considering

  1. Will the scope and price be written down before work starts?
  2. Who actually writes the code — you, or a team I'll never meet?
  3. Will I see working software during the project, or only at the end?
  4. Who owns the code and the infrastructure when we're done? (The answer should be you.)
  5. What happens after launch when something breaks?

If you're weighing a project and want a real number instead of a framework, tell me what you're trying to build — I'll give you an honest read on shape, cost, and whether it's worth doing at all.

Have a project in mind?

Tell me what you're trying to build or fix. I'll reply within one business day with honest next steps — no pressure, no jargon.

Start a project