Build, configure or buy: how a committee decides with clear criteria

There is a scene that repeats in many committees. Someone presents a need: a process that today lives in spreadsheets, a portal that customers are asking for, an approval that gets lost in email. Three people at the table each bring an answer already formed. Technology says to build it, because "that way it ends up exactly as we need it." Finance says to buy a product, because "it is cheaper and it already exists." Operations says to configure what we already have, because "why spend more?"

All three answers can be right. None is right by default. The most expensive mistake in this decision is rarely choosing the wrong path among three reasonable ones: it is choosing without having put on the table the criteria that tell one path from another, and signing a contract without knowing what is actually being bought.

This article is for whoever answers for that decision: general management, finance and technology at a mid-size or large company. It is not a technical guide or a comparison of brands. It proposes six criteria for deciding, a table to take to the committee, the questions worth asking before signing a custom development, and an honest explanation of why so many custom-built systems end up needing a rescue.

The three paths, in the committee's words

Before comparing, it is worth making sure everyone is talking about the same thing.

Configure what you already have. Your ERP, your CRM, your workflow platform or your core system already come with capabilities that perhaps are not used, or are used only halfway. Configuring means adjusting parameters, rules, forms and reports within what the vendor supports. No new code is written, or very little, and the system remains the vendor's.

Buy a product. You acquire a solution already built for a problem that many companies share: invoicing, payroll, policy administration, reconciliation. You pay a license or a subscription, adapt it to your operation through configuration and accept that some things will be done the product's way. Here "buy" includes both the traditional package and the cloud service.

Build custom. A system is developed for the company's particular process. There is code of your own, decisions of your own and, if the contract is well made, ownership of your own. There is also responsibility of your own for what was built: someone has to maintain it, test it and change it.

There is a fourth path, worth mentioning so that it does not slip in unnamed: combining. Often the right answer is a product for the part that looks like what other companies do and a custom piece for the part that sets yours apart. The three paths are not mutually exclusive; what changes is where the line is drawn.

Six criteria for deciding

1. How much your process sets you apart

This is the underlying question. If the way your company does something is part of why customers choose it or why its margins are different, that process deserves attention of its own. If it is a process that any company in the sector does the same way (closing the books, issuing a tax receipt, running payroll), building it rarely builds an advantage.

A useful test for the committee: could a competitor buy the same product tomorrow and operate just like us? If the answer is yes, it is probably not worth building. If the answer is no, and that difference is precisely what you want to protect or scale, then building, or at least building the part that sets you apart, deserves a place on the table.

The test has a flip side that is forgotten: not everything the company believes sets it apart really does. Often what is "unique" is a habit accumulated over years, not an advantage. Before paying to reproduce a habit, it is worth asking whether the customer would notice its absence.

2. How urgent it is and what waiting costs

A product that already exists can be put into operation in less time than one that is only about to be designed, but "less time" is not "little time": it has to be configured, data has to be migrated, people trained and everything connected. A configuration within what you already have is usually the fastest of the three. A custom development is, in general, the one that takes longest to deliver the first result, unless it is delivered in parts and the first part is useful by itself.

Urgency should be expressed in money or in risk, not in anxiety: what revenue is postponed, what penalty is approaching, what customer is lost for each month of waiting. With that figure the committee can compare the cost of waiting against the cost of each path. Without it, urgency tends to end up deciding for the path that looks fastest in the presentation, which is not always the one that arrives fastest.

3. How much integration it demands

This is where many committees go wrong, because they look at the screen and not at the connections. A new system rarely operates alone: it reads from and writes to your ERP, receives data from your channels, delivers information to accounting, answers to an authority. The integration work tends to be the least visible part of the project and the one that surprises the most.

Each path faces it differently. A product brings connectors for the most common systems, and the question is whether yours are among them and at what cost. Configuring within what you already have reduces the number of new connections, because the system is already connected. Building custom gives freedom to connect whatever is needed, but each connection is work that is paid for, tested and maintained; and the vendor of the system you connect to may change its rules.

A concrete question to take to any provider, whether of product or of development: which of our systems does it connect to, through which interface supported by its vendor, and who answers when one of the two parties changes?

4. Who is going to maintain it

A system does not end the day it is delivered. From then on, faults have to be corrected, regulatory changes absorbed, components that stop receiving support updated and the business's requests handled. This is the part of the cost that appears least in proposals, and the one that weighs most after a few years.

With a product, maintenance of the base is done by the vendor, and you pay for it. With a configuration, it is done by the platform's vendor, plus whoever made the adjustments. With a custom development, it is done by whoever you decide, and there lies the underlying question: does that person or team exist, do they have the necessary documentation and can they be sustained over time? A system that depends on the memory of whoever programmed it is a risk disguised as an asset.

5. Total cost, not the entry price

The most frequent comparison in a committee is between the price of the product and the budget of the development. It is an incomplete comparison. To decide, the cost must be seen over several years and with all its line items:

• Acquisition: licenses or subscription for a product; hours or project price for a development.
• Implementation: configuration, data migration, integration, testing and training. With a product, it is worth asking in writing, and separately, for licenses, configuration, migration, integration, testing and training.
• Operation: infrastructure, support, monitoring and the people dedicated to looking after it.
• Change: what it costs to adapt the system when the business changes. With a product, it usually depends on the vendor and its calendar; with a custom one, it depends on your maintenance capacity.
• Exit: what it would cost to leave the system and take the data and the rules elsewhere.

None of the three paths wins in every case in this analysis. A product can come out cheaper over five years and more expensive over ten if the business moves away from what the product assumes. A development can come out more expensive at the start and cheaper if what was built avoids paying per-user licenses that grow with the company. What matters is that the calculation exists, that it belongs to the committee and not to whoever is selling, and that it is made with the line items above.

6. Leaving the provider

It is the criterion that almost nobody puts on the sheet on the day of the decision and that is most regretted afterwards. Each path creates a different dependency, and it is worth naming it.

With a product, the dependency is on the vendor: on its price, its release calendar and its permanence. The question is what happens to your data and your rules if tomorrow you want to change products: can they be exported, in what format, with what documentation?

With a configuration, the dependency is double: on the platform's vendor and on whoever made the adjustments. The business rules stay inside the tool; if they are not documented outside it, they become hard to reproduce.

With a custom development, the dependency is on whoever built it, and it is reduced or aggravated depending on what the contract says. Code in your repository, documentation, tests, access credentials and a verifiable handover reduce the dependency and make it feasible to evaluate moving to another team. Without them, the original provider tends to become indispensable. The next section deals with that.

The table to take to the committee

The following table summarizes how each path behaves against the six criteria. It is a reasoning guide, not a measurement: the values describe tendencies, and your specific case may depart from them.

Two observations on how to use it. First: do not count how many cells "favor" each column; the criteria do not weigh the same for all companies. A committee under regulatory urgency may give the second criterion a weight that another committee would not. Second: the table serves above all to uncover disagreements. If two members of the committee rate a cell differently, there is the conversation worth having before hiring anyone.

Scenario (illustrative, no client). A mid-size distributor operating in several states wants to replace the process by which its account executives authorize special discounts, which today is handled by email and a shared sheet. The committee rates its six criteria. The authorization process has rules of its own that vary by customer and by product, and the business considers them part of its way of selling: high differentiation. Urgency is moderate: there are losses, but no deadline. Integration requires reading prices and stock from the ERP and writing the approval back: two connections. Maintenance would be the responsibility of a small internal team. When costs are added up over five years, a general approval-workflow product comes out cheaper in licenses, but it would force programming precisely the rules that set the company apart, inside someone else's tool. A full development comes out more expensive, but concentrates the effort on those rules. The committee decides to combine: a workflow product for the request's journey and a custom piece for calculating which discount can be authorized, with the code and documentation of that piece in the company's name. The scenario's figures are omitted on purpose: what matters is the order of the questions, not the numbers.

What to ask before signing a custom development

If the committee concludes that building is the right call, or building a part, the contract becomes the instrument that determines whether you end up with an asset or with a dependency. Four blocks of questions organize that review. All of them should have a written answer before signing.

Whose code it is

The question seems obvious and it is the one that generates the most misunderstandings. Whoever pays for a system usually takes it for granted that it is theirs. The Federal Copyright Law (Ley Federal del Derecho de Autor, LFDA) sets out specific rules and it is worth knowing them. What follows is a reading of its current text on the website of the Chamber of Deputies; it does not replace the opinion of your legal department.

• Computer programs are protected in the same terms as literary works, both in source code and in object code (art. 102).
• Every transmission of economic rights is for consideration and for a limited time, and the contracts by which they are transmitted, as well as use licenses, must be made in writing; otherwise, the law declares them null and void (art. 30).
• Article 33 provides for a five-year term when the transmission does not set one; for computer programs, article 103 expressly exempts them from that limitation. The wording of the assignment and its scope should be reviewed with your legal department.
• For a commissioned work, article 83 establishes, unless otherwise agreed, a rule in favor of whoever commissions it. For a work to be considered made on commission, article 83 bis requires that the terms of the contract be clear and precise, and in case of doubt the interpretation most favorable to the author prevails.
• The economic rights over a program created by employees in the exercise of their duties belong, unless otherwise agreed, to the employer (art. 103, first paragraph). If the people who develop the program are employees of your provider and act within their duties, those rights arise with your provider; if subcontractors or independent contractors are involved, it is worth verifying the chain of ownership in writing. What reaches you reaches you through what the contract says.

The practical conclusion is not that the law takes the code away from you; it is that ownership is best left in writing, in explicit words. Questions for the contract:

1. Who holds the economic rights over the delivered system and its documentation, and is it written down?
2. Is the transmission an assignment of rights or a use license, exclusive or non-exclusive? They are different things, with different consequences.
3. What happens with the provider's own tools, libraries and components that are reused in your project? It is common for the provider to keep its own and grant you a use license; in that case it is worth knowing whether that license is perpetual, whether it is transferable and whether it allows another team to maintain the system.
4. Are there a term, a territory and conditions for the transmission, and are they registered where the law provides for them to take effect against third parties (art. 32)? This is a question for your lawyer, not a general statement.

Third-party licenses

Almost no modern system is written from scratch: it is assembled from open-source components, commercial libraries, cloud services and development tools. Each has its own license, and each component can impose different conditions. The contract must identify which ones apply to each component and to the specific use you will make of the system.

Questions for the contract:

1. Is there a list of all the third-party components, with their license and version? Ask for it as a deliverable.
2. Does any license limit how you can operate, modify or distribute the system?
3. Which components have a recurring cost (subscriptions, cloud services, keys) and in whose name are they contracted? If they are in the provider's name, the day the relationship ends the system may stop working.
4. Who answers if a component stops receiving support or a security flaw appears in it?

Acceptance criteria

"Delivering the system" is not a date, it is a condition. If the condition is not written down, delivery is negotiated at the end, when the budget is spent and the pressure is at its maximum, and the party that loses the most is the one with the least margin to wait.

Questions for the contract:

1. What must the system be able to do in order to be accepted, expressed in situations that you can observe and repeat? "That it works well" is not a criterion; "that a request with these characteristics is approved along this path and is recorded with who, when and why" is.
2. Who runs the acceptance tests, in what environment and with what data? It is worth having someone take part who did not build the system.
3. What happens with defects found after acceptance, and for how long does the provider fix them at no cost?
4. Are automated tests delivered along with the code? They are what allows the system to be changed later without gambling.
5. Are payments tied to parts that have been delivered and accepted, and not only to the passing of time?

Handover

The day of delivery is when knowledge of the system is concentrated in whoever made it. Handover is the process by which that knowledge passes to whoever will operate it.

Questions for the contract:

1. What is delivered besides the program: source code in your repository, documentation of how it is put together and how it is installed, operating instructions and recovery from failures?
2. Who will receive the handover on your side, are they identified and do they have the time for it? A handover to "the IT team" with no names tends to stay in a presentation.
3. Can the system be rebuilt from scratch from what was delivered, and did someone outside the provider verify it? This is one of the most revealing tests of whether there was a true handover.
4. What support is there during a later period and under what conditions, and what happens if you prefer another team to maintain it?

Clear answers make it possible to detect the issues the contract must resolve; the sufficiency of its clauses must be validated by your legal department before signing. If an answer turns vague, that vagueness is a piece of data and is worth treating as such.

Why so many custom systems end up needing a rescue

"Rescue" is the word used when a company has a system that works, that nobody wants to touch and that can no longer evolve at the pace of the business. It did not always start badly. The causes accumulate, and several are visible from the signing.

First cause: size and duration raise the risk faster than assumed. There is empirical evidence on this. Bent Flyvbjerg and Alexander Budzier analyzed 1,471 IT projects and found that the mean cost overrun was around 27%; but that average hides a tail: about one in six projects had an average cost overrun of 200% and a schedule slip of almost 70% [1]. A later study, with a sample of 5,392 IT projects, found that cost overruns follow a power-law distribution: many projects with small deviations and a tail of projects with extreme deviations, so that IT projects are "far riskier in terms of cost than normally assumed by decision makers and scholars" [2]. The authors propose as a possible explanation the interdependence among components: a problem in one can set off reactions in others [2].

What it means for a committee: the right question is not "how much will it deviate on average," but "what happens if we land in the tail." A budget that withstands only the average case is not a prudent budget. These figures are of high confidence as to their origin (checked at the source), but they describe samples of IT projects in general, not only custom developments; they should not be read as the probability that your project will fail.

Second cause: failure is measured poorly and cited worse. It is common to see in sales presentations percentages of software project failure attributed to the Standish Group's CHAOS report. It is worth knowing that those figures have been challenged with method. Eveleens and Verhoef, in IEEE Software (2010), argue that Standish's definitions of success are based solely on the accuracy of the estimate of cost, time and functionality; that this measure is one-sided and inflates the percentages of "failed" projects; and that averaging figures produced by different estimation processes, each with an unknown bias, makes the results meaningless. Applying those definitions to their own data (5,457 forecasts from 1,211 real projects), they concluded that the Standish figures did not reflect the reality of the cases studied [3]. That is why this article does not cite CHAOS percentages as data. If someone presents them to you in a proposal, ask for the source and for the definition of failure it uses. The caveat applies in both directions: there is also no basis for claiming that all projects turn out well.

What does stand, with the two sources above, is a prudent conclusion: the risk exists, it is asymmetric and it is underestimated if judged by the typical case.

Third cause: a screen is bought, not an asset. Many custom systems are contracted for what can be seen: the screens, the flow. What cannot be seen (the tests, the documentation, the repository, the list of third-party components) is what decides whether the system can evolve. When those deliverables were not requested, the system works on the day of delivery and becomes unmanageable at the first important change. This is the most avoidable cause of all, and the four sets of questions in the previous section exist for that.

Fourth cause: the system depends on one person. A programmer who knows the whole system is a strength while present, and a risk when they leave. It is the reason documentation and handover must weigh in the contract as much as the features.

Fifth cause: what already existed was built. Frequently, a part of the system reproduces capabilities that a product would offer at a lower maintenance cost. When that part requires constant changes because of regulation or standards, the company ends up sustaining, out of its own budget, what a vendor sustains for thousands of customers. The differentiation criterion in the first section exists to avoid this.

Sixth cause: there is no exit criterion. No system is permanent. If the contract did not anticipate how data and rules are extracted, replacing it is another high-risk project. A system that cannot be abandoned ends up being kept out of inertia, which turns it into a slow version of a rescue.

None of these causes is inevitable or exclusive to custom developments: products have their own versions (adapting the business to the product without realizing it, for example). The difference is that in a custom development several of these causes can be reduced with decisions made before signing and with follow-up during execution, which is the reason for this article.

How to bring it to the committee: one sheet, five questions

So that this conversation does not stay general, we propose a one-page sheet that any committee can put together in an afternoon:

1. What process is it, and how much does it set you apart? Using the test of the competitor who could buy the same product.
2. What does waiting cost? In money or in risk, per month.
3. Which systems does it connect to, and through which interface? A list, not a phrase.
4. Who will maintain it three years from now? By name or by profile, and with its documentation.
5. How do we leave? What you take with you, in what format and in whose name it stays.

If the committee cannot answer one of the five, that gap is the first deliverable, before any proposal. And if several answers are "we don't know," what is probably missing is not a provider: it is information to decide.

What Hábil does

Hábil helps organizations put this decision in order before committing to a path: what is worth configuring, what is worth solving with a product and what is truly worth building. That is the idea behind the page Custom software development, which explains how the scope is agreed, what is delivered and in whose name it stays.

If part of what you need resembles what other companies do, review the scope, the conditions and the applicable integrations of our products: Retícula, Pauta and Cuadre. What one of them covers is configured instead of programmed, and a custom project can concentrate on what is solely yours.

If your committee has already identified the process, the integrations and the exit criteria, you can compare your case with Hábil in a first conversation, at no cost. Write to us on WhatsApp to request it.