Projects that span software, hardware, and AI fail their budgets more often than single-discipline projects — not because the work is harder, but because the dependencies between disciplines create failure points that pure software or pure hardware projects don't have. A scoping mistake in one domain shows up as a delay in another, weeks later, when it's much more expensive to fix.
This is a practical operational guide, not a project management theory piece. It reflects the specific failure patterns that show up repeatedly in projects that combine multiple technical disciplines.
Why deep tech projects overrun more than pure software ones
A pure software project's biggest risk is usually scope creep — the client wants more than was originally agreed. A deep tech project has that risk plus several others layered on top: a hardware component that's delayed at fabrication blocks firmware testing, which blocks the software integration that depends on real device data, which blocks the AI model training that needed real-world data from that integration. A delay anywhere in that chain cascades through everything downstream.
Pure software has a relatively forgiving iteration loop — push a fix, redeploy, test again, often within minutes. Hardware does not. A design flaw caught after PCB fabrication costs a respin measured in weeks. This asymmetry between fast-iterating and slow-iterating components is the single biggest source of budget overrun in cross-domain projects, and it's rarely accounted for properly in initial scoping.
Scoping properly before anything is built
The temptation in any project is to start building quickly to show progress. For cross-domain projects specifically, this temptation needs to be resisted harder than usual, because the cost of a scoping mistake compounds across every dependent domain.
Write the specification before any procurement or development starts. What does the product do, precisely. What are the hard constraints — power, size, cost, regulatory requirements, deployment environment. What is explicitly out of scope, stated as clearly as what's in scope, because ambiguity about boundaries is where scope creep originates.
Identify the slowest-iterating component first. In most deep tech projects, that's hardware fabrication. Scope and lock that component's requirements earliest and most rigorously, because changes to it are the most expensive to absorb later. Software and integration layers built on top can iterate faster and tolerate more flexibility in the specification.
Separate "must work" from "nice to have" explicitly, in writing, agreed by both parties before work begins. This single document becomes the reference point for every later conversation about whether something is in scope or a change request — without it, that conversation happens informally, repeatedly, and inconsistently throughout the project.
The cross-domain dependency problem
The core operational challenge in a project spanning software, hardware, and AI is that the disciplines depend on each other in ways that aren't always obvious at the start.
Firmware development genuinely cannot be fully completed until hardware exists to run on — but firmware development also can't wait until hardware is finished, or the project timeline simply adds up sequentially instead of running in parallel. The practical resolution is developing firmware against a breadboard prototype or a development board approximation early, in parallel with PCB design, accepting that some integration work happens later once the real board exists.
Similarly, AI model development that depends on real sensor data from the physical product faces a chicken-and-egg problem — the model needs data from hardware that doesn't exist yet, and the hardware design sometimes depends on knowing what data quality the model will need. The practical approach: use proxy data, simulation, or a quick early hardware iteration specifically to start collecting real data sooner, even before the final hardware design is locked.
Mapping these dependencies explicitly at the start of the project — which component blocks which other component, and where parallel work is genuinely possible versus where it's sequential by necessity — is one of the highest-leverage planning exercises available, and one most teams skip in the rush to start building.
Structuring milestones that actually protect budget
Milestones tied to vague descriptions ("hardware development phase complete") are weak protection against budget overrun, because "complete" is subjective and easy to dispute. Milestones tied to specific, verifiable deliverables are much stronger.
- Tie milestones to testable outputs — "five working prototype units passing the defined test procedure" rather than "prototype phase complete"
- Tie payment to milestones, not to calendar time — this aligns incentives between client and team around actual progress rather than time elapsed
- Build in an explicit review point after the highest-risk, slowest-iterating component — typically right after the first hardware prototype is validated, before committing to the next, more expensive stage like a production-volume PCB order
- Include a contingency line in the budget explicitly, rather than treating any overrun as a failure to be absorbed silently — 15–20% contingency on the hardware-dependent portions of a deep tech project is a reasonable starting reference, since this is where the most unpredictable delays originate
Handling change requests without derailing the project
Change requests are normal and expected in any real project — the mistake is not having a defined process for handling them, which causes them to silently expand scope without anyone formally agreeing to the corresponding budget and timeline impact.
A workable process: every change request gets documented, evaluated for its actual impact on timeline and budget — including downstream impact on dependent components, not just the immediate cost — and explicitly approved before work proceeds, with the approval including the revised timeline and cost, not just a verbal "yes, go ahead."
The specific risk in deep tech projects: a seemingly small change to a hardware component, requested casually in a meeting, can require dimensional changes, sensor reselection, or layout redesign that cascades into a full PCB respin — a dramatically larger cost than the change appeared to warrant at the moment it was requested. Hardware changes specifically deserve a higher bar of formal evaluation before being approved, precisely because their downstream cost is so often underestimated at the point of request.
Vendor and supply chain risk — specific to hardware
Hardware-involving projects carry a category of risk software-only projects don't: component availability, fabrication lead times, and supply chain disruption.
Practical mitigations: identify single-sourced or long-lead-time components early in the specification phase and either find alternatives or order them with enough lead time, build buffer time into the schedule specifically around fabrication and assembly stages rather than treating them as instant, and maintain a secondary supplier relationship for critical components where realistic, particularly for anything sourced internationally with longer and less predictable shipping timelines.
Confirming component availability before finalising a design — not after — avoids the scenario where a design is complete and validated, but a key component goes out of stock before production volume can be ordered.
Communication cadence that catches problems early
Most budget overruns aren't discovered when they happen — they're discovered weeks later when someone finally asks for a status update and learns the project quietly drifted off track. A regular, structured communication cadence catches this earlier, when course correction is still cheap.
A weekly status update covering what was completed, what's blocked and why, and any change to the projected timeline or budget — kept short and consistent rather than skipped when things feel fine — surfaces problems while they're still small. The instinct to skip status updates specifically when a project is struggling is common and exactly backwards; that's when visibility matters most.
A scoping checklist before kickoff
| Check | Why it matters |
|---|---|
| Written specification with explicit in-scope and out-of-scope items | Removes ambiguity that otherwise causes informal scope creep |
| Cross-domain dependencies mapped explicitly | Identifies what can run in parallel vs what's sequential |
| Slowest-iterating component identified and prioritised | Usually hardware — locking this early prevents costly late changes |
| Milestones tied to testable deliverables, not calendar time | Makes "done" objective and verifiable |
| Contingency budget built in (15–20% on hardware-dependent work) | Accounts for the unpredictability inherent in fabrication and supply chains |
| Change request process defined before it's needed | Prevents scope expansion without corresponding budget/timeline adjustment |
| Single-sourced or long-lead components identified early | Avoids late-stage supply chain surprises |
| Regular status cadence agreed and committed to | Surfaces problems while they're still cheap to fix |
None of this eliminates risk entirely — deep tech projects are inherently more complex than single-discipline ones, and some unpredictability is unavoidable. But the difference between a project that overruns its budget by 10% and one that overruns by 100% almost always comes down to whether these practices were in place from the start, not whether the team encountered problems. Every real project encounters problems. The ones that stay on budget are the ones that catch them early and have a defined process for absorbing them.
If you're scoping a project that spans software, hardware, or AI and want a second opinion on the plan, get in touch with us. We work across all three disciplines at Manthrix.