There's a special kind of silence that falls when a consultant slides a proposal across the table and you realize you have no idea whether $80,000 is a bargain or a mugging. I once watched an operations director at a regional distribution company stare at a one-page quote for a solid minute before asking the only honest question available: "Is that... a lot?"
Nobody teaches you how to budget for custom software engagement work. Procurement has a template for copiers and one for snow removal, but nothing for "an engineer sits with your team and builds the thing," so most first-timers are guessing from a standing start.
The guessing goes one of two ways: under-budget and panic in month two, or over-budget so thoroughly the CFO kills a project that would have paid for itself by Christmas. Here is how to set the number without guessing.
The short answer: a sensible budget for custom software engagement with an embedded engineer is $25k to $60k for a paid pilot and $60k to $150k for a first production build, plus 15 to 20 percent held back as an iteration reserve. The totals matter less than the structure. Teams get burned by the lines they forgot, not the build they priced.
What a realistic budget for custom software engagement looks like
Anchors first, because "it depends" is a terrible planning tool. These ranges are illustrative, but they track with what a typical mid-size company sees when it brings in an embedded engineer or a small FDE-style team.
A paid pilot usually runs two to four weeks and lands between $25k and $60k. You are buying one working workflow, used by real people, on real data. Not a demo. Not a deck.
The first production build typically runs $60k to $150k over six to twelve weeks: hardening the pilot's winning workflow with permissions, error handling, and the boring parts that keep it alive on a bad Tuesday.
Why so wide? Three variables move the FDE engagement cost more than anything else: the state of your data (clean exports versus eleven spreadsheets named FINAL_v2), the number of systems the workflow must touch, and how available your own people are. The last one is free to fix, and nobody fixes it.
The budget lines everyone forgets
The proposal you sign covers engineering time. The project you run consumes more than that, and these are the lines that ambush first-timers.
Data access and cleanup
Every engagement has a hidden first week called "getting the data out of the system that shall not be named." Say your order history lives in an aging ERP that exports CSVs with the enthusiasm of a DMV clerk. Someone pays for those wrangling hours. Budget 10 to 15 percent of the build for data work, or donate that amount to the surprise column.
Stakeholder time, the invisible tax
Your best dispatcher, your senior underwriter, your lead caseworker will spend five to eight hours a week with the embedded engineer. That time is not free; it is your most expensive operational knowledge walking into a meeting room. A mid-size firm running a ten-week build should expect 50 to 80 hours of internal expert time, with coverage planned so service levels do not dip.
The iteration reserve
Version one of any workflow survives contact with users for about a day. Then come the tweaks: an extra approval step, a different default, the report sorted the way Diane likes it. An iteration budget of 15 to 20 percent of build cost is not pessimism. It is the difference between software that gets adopted and software that gets politely ignored.
Hosting and tooling
Small but real: cloud hosting, monitoring, an LLM API bill if the workflow touches one, a few SaaS seats. Call it 3 to 5 percent of build. It will not break you, but it should appear in the budget so nobody treats it as a scandal in month three.
Handover and documentation
Unless the engineer is staying forever, and they are not, someone internal inherits the system. Docs, walkthroughs, a recorded handover, a few paired sessions. Skipping this saves 3 percent and costs you the whole system the first time it hiccups after they leave.
Pilot-first budgeting caps the downside
A paid pilot is the cheapest insurance in software. You spend $25k to $60k learning whether the workflow saves money before committing six figures. If the pilot fails, you lost a pilot. If it works, the production build is no longer a leap of faith; it is a follow-on order.
Structure the pilot project budget around a proof, not a deliverable. Good proof sounds like "dispatchers assign loads in under four minutes instead of eleven" or "claims intake drops from two days to same-day." Agree the kill criteria in writing before anyone writes code. And frame it correctly for your CFO while everyone still likes each other: a pilot that proves the idea wrong is a successful pilot.
Fixed price vs weekly rate
Fixed price feels safe. Mostly it transfers risk into the change-order process, where every "small tweak" becomes a PDF and a signature. For a first engagement, where you do not yet know what you do not know, fixed price tends to punish curiosity.
A weekly rate feels exposed but matches how embedded work actually unfolds: the engineer discovers the real workflow in week two, and you want them chasing it, not filing paperwork. The middle ground that works for first-timers is a weekly rate with a scope cap and a weekly demo. You can stop any Friday. That cap does the risk job the fixed price was pretending to do.
Budgeting for the second build
Software is a puppy, not a toaster. After launch, plan 20 to 30 percent of the original build cost per year for maintenance and iteration: small fixes, new edge cases, the integration that breaks when a vendor updates their API without asking.
This is where the ROI math gets honest. If the workflow saves your team 25 hours a week, paying a third of the build cost annually to keep it sharp still puts payback in months, not years. We walk through that math in how to calculate FDE ROI, and the hidden cost of manual processes you already pay is the other half of the comparison. Doing nothing is a budget line too. It is just invisible and enormous.
A sample budget you can steal
Here is a worked, illustrative year-one budget for a mid-size logistics firm, roughly 200 employees, building its first embedded workflow: a load-assignment tool for the dispatch team.
- Paid pilot, 3 weeks: $38,000. One workflow, five dispatchers, kill criteria agreed up front.
- Production build, 9 weeks: $92,000. Hardening, permissions, TMS integration, error handling.
- Data cleanup: $11,000. Export archaeology on the legacy TMS, plus address deduping.
- Iteration reserve, 18%: $17,000. Held back, released against a shared backlog.
- Internal stakeholder time: $0 invoiced, roughly 70 hours of dispatcher and ops-manager time with coverage planned.
- Hosting and tooling, year one: $5,500.
- Docs and handover: $4,500.
Total year-one outlay: about $168,000, against a measured saving of 22 dispatcher-hours a week, for a payback around month nine. Your mileage will vary; the structure will not. For a deeper look at where engagement money goes, see the full FDE cost breakdown, and if you are still negotiating the pilot itself, how paid pilot pricing works covers the shapes you will be offered.
The budget is the first deliverable of the engagement. Get its structure right and every later conversation, from pilot results to renewal, gets easier. Start with the lines everyone else forgets, and you will finish ahead of the teams still arguing about the build price.