The Threshold Where Custom Software Pays Off Has Dropped

When does custom software pay off?
The cost of developing your own software solution has dropped so far that problems now pay off that never would have justified a project. For mid-sized companies that means: the stack of internal tasks that were too small for a software project suddenly lands on the other side of the ledger. The threshold is not zero. The scarce factor is no longer whether you can develop something, but knowing which problem is worth it and framing it well.

I could not decide which sun protection to put on our terrace. Awning, sail shade, cantilever umbrella? The seating area needed to be in shade at midday and in the evening, and no brochure answers that. The shadow depends on the position of the sun, the orientation, the dimensions, and the time of day, and the sun’s position changes over the day and over the year.

So in an afternoon I developed a 3D simulator. You enter the real dimensions of the terrace, the orientation, the material, set the date and time, and the tool computes the astronomically correct sun position and lays the shadow of each solution over the surface. Awning against sail shade against cantilever umbrella, at 1 pm and at 7 pm, clicked through until the answer was clear. Two hours of work.

That sounds like overkill for a buying decision about a sun shade. It is. And that is exactly the point that reaches far beyond the terrace.

What Actually Shifted

The obvious explanation is: AI makes development faster. That is true and boring, and it misses the real point.

What is interesting is not the speed, but the threshold. Every custom solution has always come down to the same inequality: is the effort of developing it worth it, measured against the damage the problem causes? A private buying decision about a sun shade was always clearly on the wrong side. Having software developed for it would have cost a multiple of what the awning itself costs. Nobody does that. You decide on gut feeling and maybe regret it later.

What has fallen is the left side of the inequality. The cost of developing something of your own has dropped so far that things now pay off that previously sat below any reasonable line. The threshold at which a custom solution makes sense has fallen below the level of a private terrace problem.

That is the mindset shift. Not “it goes faster”, but “the list of what is worth doing at all got longer overnight”.

Why the Math Tips

Two figures decide whether a custom solution carries its weight: what it costs, and what the problem costs that it solves.

The second figure was always the knockout criterion for small problems. A task that annoys one employee for two hours a month does not justify a software project costing tens of thousands of euros. The solution would have been more expensive than the problem, over years. So the problem stayed.

The first figure is the one that has moved. When the same solution takes an afternoon instead of weeks, the break-even shifts by an order of magnitude. Problems that sat on the “not worth it” side for years tip over to the other side, without anything about the problem itself having changed. They were always a bit of a nuisance. Now they are worth it.

What This Means for Mid-Sized Companies

This is where a terrace anecdote turns into a business question.

Every company carries a quiet stack with it: the small, annoying things that never justified a project. The Excel list that three people keep in sync by hand. The report someone clicks together from two systems every Monday for an hour. The plausibility check nobody automated, because it was too specific for off-the-shelf software and too small for a project of its own.

That stack was never a question of wanting to. It was a question of the math. And the math is being recalculated right now. Much of what was the right call for years (“no custom solution is worth it for that”) is the wrong call today, because the threshold has shifted and the decision has to move with it.

This is where “worth it” becomes true, and precisely so: the terrace tool is not worth it in that sense, it brings in no revenue, it got me a better decision. An internal solution that saves a team hours every week very much is. The same cost drop, two entirely different consequences, depending on whether a recurring operational effort sits behind it or not.

Where the Picture Lies

At this point the temptation is strong to think “then we’ll just develop everything ourselves now”. Here the picture lies, and it is worth naming the line precisely.

What has fallen is the cost of developing something. What has not fallen is the cost of operating it: maintenance, integration with existing systems, data quality, responsibility when the thing spits out a wrong number. A tool that takes two hours to create can tie up attention for years. Anyone who confuses the lowered development-cost threshold with lowered total cost produces a sprawl of half-finished internal tools that nobody maintains anymore. That is a real and expensive failure mode.

That also shifts what is scarce. Development used to be the bottleneck. Now it is judgment: recognizing which of the many now-feasible problems is actually worth it, and framing the solution so that it hits the right problem and stays maintainable. The threshold has fallen. The care about what you pull over that threshold has become more important, not less.

What You Can Decide Differently Now

You can reopen the “not worth it” stack. Much of it is priced with old costs. The right question is no longer “can this even be developed?”, but “which of these small problems is worth it now, and can we frame it cleanly enough that the solution helps more than it ties up in upkeep?”.

The one sentence to take away: the cards are being reshuffled not because AI is magic, but because it has shifted a cost line you had grown used to. Anyone deciding with the old line in their head leaves the half that has become cheap on the table.

The next question that follows is the harder one: how do you tell which problem a custom solution is truly worth, before you develop it? That is no longer a technology question. That is the question that will decide who captures the advantage and who merely piles up tools.

Frequently Asked Questions

Does custom software pay off for small problems today? More often than just a few years ago. The cost of developing your own solution has fallen sharply, so problems that used to be too small for a software project now add up. What matters is whether the problem carries a recurring effort that outweighs the maintenance effort of the solution.

What got cheaper, the development or the operation? Development above all. Maintenance, integration, and data upkeep have not fallen to the same degree. Confusing the two means underestimating the total cost and risking a sprawl of unmaintained internal tools.

Which internal tools pay off now in mid-sized companies? The typical cases are recurring manual tasks: reports clicked together by hand every week, lists several people keep in sync, special checks that were too specific for off-the-shelf software. The scarce factor is no longer feasibility, but selection and clean specification.