The CFO slid a sheet of paper across the table. On it: the quote for a twelve-week engagement, circled twice, and one sentence in pen. "When do I get this back?" It is the only question about custom software that matters, and it is the one most proposals dodge with a paragraph about "strategic value."

She was right to ask. A mid-size logistics firm was bleeding roughly thirty staff-hours a week into manual rate reconciliation, and everyone in the room knew it. The question was never whether the problem was real. It was when does custom software pay for itself, and how soon.

Here is the direct answer. Custom software pays for itself in about three to nine months for automation-heavy operations work, six months to a year for workflow rebuilds, and a year or more for platform plays that change how a business sells or serves. The payback period depends on engagement type, the hourly cost of the pain, and whether anyone owns the number. If you cannot compute a breakeven week on a napkin, do not sign anything yet.

When Does Custom Software Pay for Itself? The Short Answer by Type

Not all builds pay back on the same clock, and pretending they do is how budgets get torched. Three rough bands cover most of what an FDE gets hired to do.

These are illustrative bands, not promises, but they hold up across enough engagements to plan around. The pattern underneath them is simple: the closer the software sits to hours already being burned, the faster it pays.

The Automation Payback, With Actual Numbers

Take the logistics firm. Thirty hours a week of rate reconciliation, done by people whose fully loaded cost averaged about $38 an hour. That is $1,140 a week, roughly $59,000 a year, spent on work a script finds delightful.

Five weeks of build time, about $30,000 all in. Naive division says payback lands around week twenty-six. But automation does not save 100% of the hours; it saved about 80%, because exceptions still needed humans. That is $912 a week back, which puts breakeven near week thirty-three, call it month eight. Still well inside a year, still a fine deal, and an honest number the CFO trusted precisely because nobody rounded it down to "next quarter!"

The real breakeven arrived faster than the math, for a reason the spreadsheet missed: the two people doing reconciliation were also the ones who caught carrier billing errors, and freed-up hours went into recovering about $2,000 a month in overcharges. Savings stacked. Count the primary number conservatively and let the second-order wins be upside, not plan.

Platform Plays Pay Slower but Compound

A customer portal or a rebuilt internal platform rarely shows a clean week-of-payback, because its value mixes cost savings with revenue effects that take quarters to show up. Say a distributor spends $120,000 on a portal where customers place and track their own orders. The savings side is real: order-entry staff time drops, call volume falls. But the bigger effect is that customers who can self-serve reorder more often, and that lift only appears in the data months later.

This is where honest modeling matters more than optimistic modeling. Put the cost savings in the plan at conservative rates. Put the revenue lift in a separate column labeled "upside if adoption hits X%," and define X in advance. When the softer side of ROI is measured against a prediction you wrote down beforehand, it stops being a vibes argument and becomes a scoreboard.

What Pushes Payback Out

Three forces reliably turn a six-month payback into an eighteen-month one.

Scope creep. The invoice automation grows a reporting dashboard, then a vendor portal, then a mobile app, and the payback clock keeps running while the finish line moves. The discipline of defending scope is not about being rigid; it is about keeping the breakeven week real.

Data archaeology. The plan assumes the order data is in the ERP. It is in the ERP, three spreadsheets, and a filing cabinet, and two of the three disagree. Budget discovery time for this or accept that week one becomes week four.

The nobody-owns-it problem. Software that ships without an internal owner decays. If nobody on the client side is accountable for adoption and upkeep, your beautiful automation is shelfware by quarter two, and the payback period becomes infinite.

How to Compute Your Own Breakeven

The napkin formula has four inputs: hours the problem burns per week, the loaded hourly cost of the people burning them, the fraction of hours the software will actually remove (be honest, 60 to 80 percent is typical), and the all-in build cost. Weekly savings times weeks until breakeven equals build cost. Solve for weeks.

Then run the pessimist discount: add 30% to the build cost, subtract 20% from the savings, and see if the deal still works. If it only works in the optimistic case, it does not work. If you want the full anatomy of what goes into the cost side, the FDE cost breakdown walks through where the money actually goes, and the FDE versus full-time hire math covers the alternative you are really comparing against.

Breakeven Red Flags

Sometimes the honest answer is "don't build it." If the problem burns five hours a month, no payback period exists that justifies a five-figure build; buy a tool or live with it. If the process is about to change anyway, automating today's version is paving a cow path scheduled for demolition. And if the sponsor cannot tell you the number the software is supposed to move, the project has no breakeven to hit, only a budget to consume.

The best engagements start with a CFO and a single sheet of paper. Write the number down, compute the week, and then go beat it.