Questo contenuto è disponibile in Italiano
The inconvenient truth that no one wants to admit in the software world
When a client asks us to price the development of a custom software component, we are often faced with one of the most complex questions in the entire technology industry. It is not simply a matter of calculating hours of work for an hourly rate: we are talking about estimating the unknown, predicting the unpredictable, putting a price on something that, by its nature, is unique and unrepeatable.
The reality is. making correct estimates in custom software is virtually impossible, and the costs of a project are only really known when it is finished. This is not a confession of incompetence, but an acknowledgement of a fundamental truth that characterizes the software industry: we are creating something that has never existed before, using ever-evolving technologies to solve problems that often turn out to be more complex than initially imagined.
The statistics speak for themselves: according to recent industry studies, 70% of software projects go over the initial budget, with an average overrun of 27 percent [1]. But these numbers tell only part of the story. When we analyze deeper, we find that IT projects on average overrun the budget by 45 percent while delivering 56 percent less than expected value [2]. It is a paradox that should give anyone involved in software development pause: we spend more to deliver less.
The dilemma of small projects: when error becomes proportionately devastating
Contrary to what you might think, making an accurate estimate is much more difficult on small projects. The margins of error are proportionally much greater: getting it twice or three times wrong on a one-day task is easy and devastating, whereas on 20- or 50-day projects there is ample room to catch up and correct errors or snags.
Let’s take the example of a simple custom data import/export plugin. On the surface, it looks like a straightforward activity: reading data from one source, transforming it, and writing it to another destination. But the reality hides numerous unknowns that emerge only during development. Is the source data format really the documented one? Are there unintended edge cases? Does the destination system have undocumented limitations? Any negative answer to these questions can multiply the time required.
This phenomenon is amplified by the fact that small tasks still involve several interactions between different people and external controls. The time spent is always greater than expected, and the many interactions cost developers’ time. In a large project, these costs are better diluted; in a small one, they become proportionately huge.
The anatomy of uncertainty: why custom software escapes prediction
Custom software, by definition, is something that does not yet exist. We are not assembling standardized components according to an instruction manual; we are creating unique solutions to specific problems. This uniqueness brings with it a level of uncertainty that is impossible to eliminate completely, no matter how detailed the preliminary analysis is.
The sources of uncertainty are multiple and interconnected. I changing requirements can increase project costs by up to 50 percent [3], while the underestimated complexity contributes to 43% of overruns in software projects [4]. But there is more: the concept of technical debt introduces an additional layer of complexity. For every dollar spent in new software development, an average of $0.41 additional technical debt is accumulated [5], costs that often emerge only in the later stages of the project.
The scope creep represents perhaps the most insidious challenge. What starts as a seemingly simple request-“let’s just add a little report”-can turn into a substantial rewrite of business logic. Fifty-seven percent of projects fail because of a lack of communication [6], often because expectations were not aligned from the start.
The key difference: body-based development vs. technical assistance
To address this inherent complexity, at F.technology we have developed an approach that clearly distinguishes between two types of activities: the body software development and thehourly technical assistance. This distinction is not just a matter of pricing, but reflects two completely different philosophies in approaching software projects.
Custom Software Development: commitment to excellence
When we talk about custom software development, we refer to activities that require a thorough preliminary analysis of the client’s specifications, detailed documentation of the process, interventions in the logic and structure of the software, and a “safe” development process with rigorous testing and deployment procedures.
This approach necessarily involves a dual environment (test/production) and controls from at least two different programmers. Development activities are normally slower and require planning in the development team’s calendar. They always imply a double step: first from the test environment (stage/quality) with end-customer verification, then deployment to production environment.
Our system of Sprint Points (SP) is designed specifically to handle this complexity. As we explained in our dedicated article [7], SPs represent more than just metrics: they are a commitment to quality and accuracy. Each SP reflects the time and effort required to complete a specific feature, considering not only coding, but also analysis, documentation, testing, and quality assurance.
Development activities are quoted at required function (Task#) following preliminary analysis and enjoy a 90-day warranty from the date of release. This guarantee is not just a commercial gesture, but a reflection of our confidence in the structured development process we follow.
Technical Assistance: flexibility and responsiveness
L’technical assistance, on the other hand, represents a completely different model. These are “hourly” activities that are performed in the presence of a prepaid software package. These activities are quoted against the time actually spent and documented, and are not subject to budgeting but only to rough estimation.
Technical assistance is designed to be faster in intervention and problem solving. It is the ideal model for small changes, urgent fixes, or when the scope of work is too uncertain to justify extensive analysis. However, this speed comes at a price: technical assistance activities do not enjoy extra warranty support, and each subsequent intervention is charged at an hourly rate.
The paradox of control: why paying by the hour and asking for a fixed quote is nonsense
One of the most common mistakes we see in the marketplace is the request to pay an hourly rate while simultaneously getting an out-of-pocket estimate. This approach is not only a logical nonsense, but also carries great risks on the quality of the work done.
When a programmer is constrained to stay within a budget he or she has been asked to estimate, often with very little to go on, it creates pressure that inevitably impacts quality. The developer is forced to take shortcuts, to avoid necessary refactoring, to put off documentation, in order to meet a budget that may have been underestimated from the beginning.
This phenomenon is particularly evident in small projects, where the pressure of fixed budgets can lead to technically fragile solutions. The technical debt that accumulates in these cases can consume more than 20 percent of the development team’s capacity [8], creating hidden costs that will inevitably emerge in the future.
Transparency as a competitive advantage
Many software vendors prefer not to expose these issues, simply failing to discuss the inherent complexities of software development. This approach may seem more “commercial” in the short term, but it leaves customers unprepared to deal with the inevitable challenges that will arise during the project.
Our philosophy is different: we believe that transparency is a competitive advantage. When we explain to a client why a simple plugin can cost between 3K and 8.5K euros, we are not trying to justify a high price, but to educate the client about the real complexity of the work we are going to do.
This transparency also extends to our budgeting process. When we devote 10 hours of work and involve 3 people just to do a quote, we are not wasting time: we are investing in the in-depth analysis that will allow us to identify potential pitfalls before they become costly problems during development.
The importance of Application Maintenance: protecting your investment over time
One aspect often overlooked in the discussion of software costs is long-term maintenance. Maintenance and upgrade costs can account for more than 60 percent of the total cost of software during its life cycle [9]. Failure to budget adequately for ongoing maintenance can lead to substantial unexpected expenses.
Our approach to Application Maintenance (AM) contracts [10] stems precisely from this awareness. Custom software, if not properly supported, is likely to become quickly obsolete or vulnerable to technical problems. The software market is extremely fluid: tools evolve, practitioners move, and technologies update rapidly.
Programming languages, frameworks, and development tools can change over time, becoming obsolete or less supported by the market. Technical skills within a software house can also change: professionals changing companies, updates in technical knowledge, or the introduction of new technologies can impact business continuity.
An AM contract provides clients with the assurance that they will always have a trained and helpful team on the technologies used in their software, ensuring timely and targeted interventions throughout the life of the product.
The Sprint Points pricing system: transparency and scalability
Our fee system based on Sprint Points is designed to provide transparency and incentivize appropriately sized projects. The tiered structure reflects the economies of scale achieved in larger projects:
- 1-3 SP: 800 per SP
- 4-9 SP: 625 per SP
- 10-29 SP: 500€ per SP
- 30+ SP: €400 for SP
This structure is not arbitrary, but reflects actual project management costs. Smaller projects have proportionally higher fixed costs: development environment setup, initial analysis, documentation, and management overhead. In larger projects, these costs are diluted, allowing for more competitive rates.
In addition, customers with active AM contracts can benefit from the lower rates even for smaller purchases, recognizing the value of the long-term partnership.
When to choose body development vs. technical assistance
The choice between body development and technical assistance should not be based only on cost, but on the nature of the work to be done and the client’s goals.
Choose body-based development when:
- The work requires more than 8 hours of development
- You need assurance on results
- The project involves changes to business logic
- You want complete documentation of the work done
- Quality is prioritized over speed
Choose technical assistance when:
- You need quick and timely interventions
- The scope of work is very limited (less than 4 hours)
- Are you troubleshooting or debugging
- Speed of action is a priority
- You already have a prepaid package of hours
The evolution toward compliance: the case of the Cyber Resilience Act
A perfect example of how uncertainty is inherent in custom software is the introduction of new regulations such as the Cyber Resilience Act (CRA) [11]. This European legislation, which will become operational by 2027, introduces new security requirements for all software products sold in the EU.
For our customers, this means that software developed today will have to be updated to meet new security standards. Who could have predicted these costs three years ago? Yet, they have become a reality that impacts all custom software projects.
This is a perfect example of why AM contracts are essential: not just for routine maintenance, but to adapt to an ever-changing regulatory and technological landscape.
Conclusions: embracing uncertainty as an opportunity
The truth is that uncertainty in custom software is not a bug, it is a feature. It is the price we pay for innovation, for the ability to create unique solutions that solve specific problems in ways that no one has ever attempted before.
Our approach at F.technology is not to eliminate this uncertainty-that would be impossible-but to manage it transparently and professionally. Through the distinction between body development and technical assistance, we offer our clients the tools to choose the approach that best suits their specific needs.
When you choose to work with us, you are not just buying hours of development or software functionality. You are investing in a partnership that recognizes the inherent complexity of custom software and has developed processes, methodologies, and tools to successfully navigate this complexity.
The next time you are faced with a quote that seems “too high” for a seemingly simple task, remember that in custom software, as in few other areas, apparent simplicity often hides deep complexity. And that complexity, properly managed, is what turns an idea into a robust, scalable and successful software solution.
References
Questo contenuto è disponibile in Italiano
