What a custom workflow tool costs, and why

The quote that was the wrong shape

An owner gets two quotes for the same tool. One is hourly with an estimate. One is a fixed number with a long list of assumptions in the back. Both came after an hour-long call. Neither vendor has seen the work.

Both quotes are guesses. The hourly one moves the risk of the guess onto the owner: if the work turns out bigger, the bill grows. The fixed one moves it onto the vendor, who protects themselves with a cushion and a list of assumptions they will turn into change orders later. Either way, the owner pays for the fact that nobody looked first.

That is the core of how we think about price. The problem is not whether a number is high or low. The problem is when it is set. A price set before the workflow is understood is a price for uncertainty.

Why we price in two steps, and what the range includes

Our engagement starts with a Workflow Spec at $15,000, fixed. Ten business days, observation, up to twelve interviews, a baseline measurement and a fixed Build proposal at the end. The Production Build then starts from $60,000, fixed after the Spec.

The two steps exist because they answer different questions. The Spec answers what the work actually is and whether it is worth building for. The Build answers how to ship the fix. Pricing the Build before the Spec would mean guessing at the first answer to set the second.

We do not credit the Spec against the Build. That is deliberate. If the Spec fee disappeared into the Build, the Spec would really be a sales cost, and we would have a reason to steer every Spec toward a yes. Keeping it separate means it has to be worth its fee on its own, including when the answer is to buy something off the shelf or not build at all.

The Build is fixed because by then there is no good reason for it not to be. The workflow is mapped. The exceptions are listed. The integrations are named. The usage threshold is agreed. What is left is execution, and execution risk belongs with the people doing the executing.

As published, a Build is scoped in the Spec to the problem, for a named group of users, with up to two standard integrations. It includes instrumentation so use can be counted, training, operating documentation, a handover pack and 30 days of stabilization. The schedule is six weeks from the access gate, then a 30-day live-use window.

Payment follows the work: part at kickoff, part at technical acceptance, and the final 20 percent at operational acceptance, which depends on whether the crew uses the tool. If the signed usage threshold is missed after one 30-day remediation window, that final 20 percent is waived, provided the client supplied the sponsor, access, data, training time and rollout participation the plan depended on. Putting part of the fee behind use is also a pricing decision. It keeps us honest about scope.

What moves the price inside the range

The number of screens is rarely what makes a tool expensive. These four things are.

Integrations. Sending information into a system that has a clean, documented way to accept it is routine. Sending it into a system that has no such door, or one that only takes files in an odd format, or one run by a vendor who is slow to grant access, is real work. Two standard integrations are included. A third, or one that is not standard, moves the price.

Exceptions. Every workflow has a happy path and a set of cases that do not fit it. A tool that handles only the happy path is cheap and gets abandoned, because the crew falls back to paper for everything unusual, which is the exception swamp. The Spec lists the exceptions and decides which ones the tool handles and which ones it hands to a person. More handled exceptions means more work. Handing them off cleanly is often the better choice, and the Spec says which.

Conditions. A tool used at a desk is simpler than one used in a truck with no signal, in gloves, in the rain, with a customer waiting. Working offline and syncing later, large photo uploads on weak connections, and screens that work one-handed all take time to get right. They are also often the difference between a tool that gets used and one that does not, so we do not cut them to lower a number.

Data. If the tool needs a clean customer list, equipment records or a parts catalog, and those live in three spreadsheets that disagree, somebody has to reconcile them before the tool can rely on them. The Spec finds this early. Sometimes it is small. Sometimes it is the largest single piece of the Build.

Approval steps can matter too. A workflow that has to route decisions to the right person, with a record of who approved what, needs more care than one that just captures information. That is where approval drag usually hides.

AI is the item owners expect to drive price, and it usually does not. Where a tool reads messy input, such as a handwritten ticket or a rambling voice note, or drafts something a person then approves, a model can earn its place. That work is real, but it is rarely the largest piece. Many of the most useful workflow tools need little or no AI at all, and we do not add it to make a proposal sound bigger.

The cheapest tool is the one that gets used

There is a way to make any Build cheaper: cut the parts that make it usable in the field. Skip offline mode. Handle only the happy path. Leave the data messy and let the crew work around it. The price drops and the tool ships on time.

Then the crew goes back to paper, the office goes back to retyping, and the company has paid for software it does not use. That is the most expensive outcome available, because the money is gone and the problem is still there. It is also why part of our fee sits behind use. A firm that is only paid for delivery has every reason to cut what makes a tool usable. A firm that is paid in part for use does not.

What is not in the price, and how to read any quote

Travel is billed at cost as its own line. It is never folded into the Spec price, so a company in one state does not quietly subsidize a site visit in another.

Ongoing support after stabilization is a separate choice. Embedded Adoption covers monitoring, support, a weekly operator review and one bounded improvement cycle each month, and its price is set in the Spec conversation because it depends on the tool that gets built.

We also do not price by the hour. Hourly billing rewards the vendor for the work taking longer. We would rather be paid for a result and carry the risk of getting it wrong.

Whoever you hire, ask three questions about the number in front of you. When was it set, before or after someone watched the work? What happens to it if the work turns out bigger than expected? And what part of it, if any, depends on whether the crew uses what gets built?

A quote that was set early, grows with the work and depends on nothing after delivery is not necessarily a bad quote. But you should know that is what you are signing.

What to do next

If you are trying to size a workflow problem before talking to anyone, the guide on accounting and the field app not talking shows how to find where the time goes. Our full pricing and terms are on How we work.