Non-Recurring (and Usually Non-Believable) Cost Estimation in Startups
In a startup, non-recurring cost (NRC) estimation is usually performed on the same laptop that runs payroll, investor slide decks, and Spotify. The spreadsheet may be named CostModel_Final_Final_2.xlsx, and somewhere deep inside it lurks a formula that #REF! the hell out three weeks ago. The number it spits out is presented in investor calls as it were a law of physics, despite being the arithmetic average of guesswork, wishful thinking, ignorance, and numbers that fit the narrative.
For the uninitiated: non-recurring costs is the money you burn before you can build and sell a repeatable product. It’s the research, design, prototyping, integration, verification, and certification costs; the investment that gets you from “pitch deck” to “box on a pallet in a truck”. It is certainly not your unit cost. It is not your marketing budget. And it is definitely not the number you arrive at by multiplying last month’s payroll by three and adding a fixed margin.
In large aerospace orgs or defense integrators, NRC estimates emerge from structured Work Breakdown Structures (WBS), parametric cost models, and data: historical analogs, and Monte Carlo simulations. In startups, they emerge from a poorly aired room with bad coffee and founder’s optimism. The obvious trouble is, the uncertainty at startup scale is enormous: requirements are barely static, technology maturity is questionable (TRL 3, if we’re really generous), and integration plans are a cocktail napkin. Yet, you’re still expected to produce a number for the board or investors that looks precise to the nearest euro.
The first sin is blurring NRC and everything else. In your spreadsheet, there’s often no clean line between what’s one-time design/proto/certification effort and what’s recurring production or ongoing operations and support. This makes the estimate not just wrong, but wrong in a way that will blow up cash flow planning. The moment you try to scale production, you’ll discover that half your “NRC” was actually recurring labor, and now your unit economics are on their head.
The second sin is linear thinking. Excel encourages this—double the features, double the engineering time, double the cost. In reality, complexity grows faster than that, especially in integration and verification. Two modules don’t take twice the time to integrate; they take four times or more, because every interface can misbehave, every prototype can expose a requirement you didn’t know you had, and every test campaign will find the limits of your bullshit agile hardware process. Your spreadsheet doesn’t know this; it just believes all cells are created equal.
Then there’s heritage hallucination: assuming you can directly port effort from a vaguely similar past project without normalizing for scope, team experience, or toolchain maturity. If you’ve ever copied “engineering man hours” row from a previous project into your new cost model, you’ve engaged in the act of lying to yourself. In large orgs, at least someone probably tries to normalize historicals (inflation, scope adjustments, accounting differences). In startups, the normalization process is usually: “yeah, that number looks reasonable, let’s round it down”.
And of course the inescapable risk and uncertainty. In structured estimating, you’d assign ranges to each cost driver, model the correlations, and run some statistical simulation to get a probability distribution. In startups, the “uncertainty buffer” is often a single cell labeled “margin” with +10% slapped on top because investors won’t like a bigger number.
Unsurprisingly, non-recurring cost estimation in startups is often more uncertain than in big programs because the design is immature, the supply chain is unproven, and the team is a small set of multi-hat engineers who might be doing requirements analysis in the morning and desoldering BGA chips in the afternoon. Your learning curve isn’t just about manufacturing efficiency, but about figuring out what the hell the product even is. And figuring things out costs money.
Hardware startups in particular have a bad habit of neglecting integration and verification life cycle stages. The spreadsheet has a neat line for “prototype build” but no explicit cost for the weeks of wondering why the thing won’t boot. Debugging, rental of environmental chambers, extra boards spun because the connector pinout was mirrored, or the external lab fees for regulatory compliance. These get booked ad hoc and are later described to investors as unexpected but manageable. The truth is they were entirely predictable; you just didn’t price them because Excel didn’t have a row for “the pain of doing engineering”.
Then comes the tooling trap. In your first model, you optimistically tag tooling and test fixtures as “capital equipment” to be amortized over units, but in reality the design changes mid-stream, and you may pay for tooling twice. In structured estimates, this shows up as a risk with cost impact; in startups, it shows up as a surprised Slack message at 2 am in the morning.
Some survival tactics:
Fence off design, prototyping, integration, verification, and certification work from anything that scales with units sold.
Size before price. Use concrete, real METRICS—part counts, interface counts, lines of code, number of tests—to anchor labor estimates. Guessing “weeks” without a metric is pure fiction.
Use at least two methods for major cost elements (for instance, analogy + bottom-up) and reconcile them. If they differ wildly, dig into why.
Model risk as much as possible. Even a back-of-the-envelope, crappy Monte Carlo in Google Sheets beats a blind 10% fixed margin.
For the love of God, VERSION CONTROL YOUR MODEL! “CostModel_v3_final_final_NOT_DEPRECATED.xlsx” is not version control. There’s nothing as unsettling as not knowing where is the last cost model and how it differs from a very similar one you have just found. Use Git, or at least date-stamped copies and a maintain a change log.
Finally: communicate uncertainty like an adult. Present the number as a distribution, not a single point, and tie it to specific risks and assumptions. If your investor insists on a single non-recurring cost number, hand it over but also give them the 90% range. If they choose to believe the low end, that’s their choice, not yours.
The reality is this that bad non-recurring cost estimation in a startup is a strategic risk that can signal viability. Miss the target by a large factor, and you may not survive to build the thing at all. In the early days, every euro you misestimate on non-recurring costs is a euro you’ll have to explain in the next funding round, usually while explaining why your “non-recurring” work is still recurring 18 months later.
Excel doesn’t care. It will happily give you a number that looks clean, rounds nicely, and fits on a pitch deck. But reality will run the true calculation in the background, and it will present you the bill in full, sooner than later.