Build or buy software: compare the workflow, costs, and exit options

A subscription price and a development estimate rarely cover the same work. The subscription may exclude data migration, integrations, and tasks employees still have to perform elsewhere. The development estimate may stop at launch, leaving infrastructure, maintenance, and future changes outside the comparison.

I start by looking at how the company does the work now and what needs to improve. When I ran my web studio, I checked existing tools first: if a website builder met the client's needs, custom development needed a stronger justification. The same approach applies to internal business systems. Configuration, a small extension, or improvements to the current software may solve the problem without a new platform.

Test the complete workflow before committing

A vendor demonstration helps you understand a product's capabilities. A buying decision needs evidence that your employees can use it to complete their work, including the awkward cases.

For a CRM, try a month's real deals, including unfinished deals and those whose terms changed. For document processing, use the scans your accounting team actually receives, including incomplete and hard-to-read documents. Only use data you are authorized to share with the service. A quiet month may miss seasonal demand or rare failures, so choose the sample with someone who performs the work.

Before testing, agree on:

• The acceptable result, such as the maximum proportion of records needing manual correction.
• Errors that make an output unusable, even if most other operations succeed.
• Routine cases, common exceptions, and rare but costly errors to include.
• How to record workarounds: what happened outside the system, how long it took, and what a mistake could cause.

Let employees run the workflow themselves. A feature can exist yet be difficult to use. A confusing interface can increase training costs and errors, and make people reluctant to adopt the product.

In an ad fraud detection project, testing determined the choice. An advertising agency already used an off-the-shelf filter, but advertisers continued to complain about traffic quality. I extended the backend at stages the agency controlled, including landing pages and trackers, to collect detailed click data. I tested the existing filter and several alternative services against that traffic. None provided the required filtering quality, so I designed and built a custom system that assessed each click.

A product that passes your test and meets the other requirements is a strong candidate for purchase. A failed test should produce a specific list of limitations. You can then investigate whether configuration, an integration, a process change, or a custom feature would resolve them.

Compare the same scope of work

Give each supplier the same workflow and expected result. Otherwise, a software vendor may quote a standard implementation while a developer includes every exception. The prices will describe different jobs.

An API is an interface through which software systems exchange data and commands. Seeing “API available” in a product description does not establish that an integration will work. Check whether it supports the operations you need, whether its usage limits are sufficient, and how interrupted transfers recover.

A requirement to keep data on your own infrastructure also does not automatically justify custom development. First check products that can run there and support your approved software environment. Compatibility with an operating system is only one requirement; it does not establish workflow fit or security.

Put manual workarounds into the calculation

Parallel spreadsheets, copying between windows, repairing exports, and editing code reveal how much work the software leaves to employees. Some workarounds are reasonable. Others cost more than automating the missing step.

At an advertising agency, media buyers needed landing pages with custom logic and complex analytics scripts that standard page builders could not support. They edited code manually. An error could prevent visitors from reaching an advertiser or cause an advertiser identifier to be sent incorrectly. The agency could pay for traffic without receiving or recording the intended result.

I independently designed and built an internal landing page builder, selected templates for the required page variations, and migrated more than 60 live pages. Media buyers could then create and configure pages through a web interface without editing code, saving the team hours each week.

To investigate a similar problem, start with a week of observations. Record each operation outside the system, its duration, and its cause. Add other representative periods if the workload is seasonal or uneven. This gives you evidence for estimating labor costs.

The value of those hours is not automatically a cash saving. You still need to know how the company will use the released time and which expenses, if any, will actually fall.

Delayed errors need separate attention. In the landing page project, advertiser statistics could arrive several days late, so routing and tracking failures were not immediately visible. That does not mean all traffic during the delay was lost. Establish which visits were affected, what can be recovered, and which losses the available data supports.

Calculate ownership costs over the same period

Choose a common comparison period, such as three years, for the subscription, an extension, modernization, and a new system.

For a ready-made service, include implementation, data migration, subscriptions as user numbers grow, integrations, external modifications, manual work, and the consequences of errors. For custom software, include development, migration, infrastructure, maintenance, changes as the business process evolves, and preparation for a possible team handover. Estimate the cost of leaving either option.

Testing and observations provide a basis for estimating manual work. Errors require more care. Group them by type, estimate frequency and average impact, and apply those assumptions to the expected volume of operations. A small sample may not represent a full year. Where evidence is limited, use a range rather than a precise-looking total.

Avoid counting the same cost twice. If correction time is already included in manual work, do not add it again to the cost of an error. Lost revenue is also different from lost profit. For this comparison, use the relevant contribution margin: revenue minus the variable costs associated with earning it.

Allow for maintenance after launch

External services change, data changes, and employees' requirements develop. Maintenance includes adapting to those changes as well as fixing defects.

After I launched the custom fraud detection system, problem traffic fell more than 20-fold. Further reductions required increasing effort because the remaining cases were harder to identify reliably. Stricter filtering also risked blocking genuine visitors who generated revenue. Each improvement required weighing the expected benefit against research costs and the risk of rejecting valid traffic.

Before commissioning a system, identify the technical specialist responsible for the application and who will maintain it. If that capacity is not available, include its cost in the comparison. A supported commercial product may offer better value despite lacking some features.

Check how you could leave the supplier or change teams

Custom software still creates dependence. The critical party may be a contractor or a single developer rather than a subscription provider. I have worked through both kinds of supplier change.

A midsize company bought Google Workspace through a reseller. Restrictions affecting that reseller made Google's standard migration tools unavailable. I handled the migration of dozens of mailboxes and hundreds of thousands of emails and files to a new Workspace environment.

I selected third-party software using a different API, one not originally designed for migration. I analyzed folder structure and file ownership, configured the tool, and ran a test migration before the main transfer. The data moved with minimal loss, accounting for the original folder and ownership structures. Dependence on an intermediary had created an exit problem that required substantial engineering work.

The shared planning platform at Gazprom Neft, an energy company, illustrates dependence during custom development. No ready-made product met the requirements for personal-data protection, approved technologies, and vendor availability. IBM was developing the platform. I took over the project early and was responsible for delivery and vendor coordination. When IBM withdrew from the Russian market, I organized the handover to another contractor. Work continued, and the platform reached production. The company's business product owner led adoption within departments.

Before signing a contract, establish what your company can obtain and how another team could use it:

• Test a real data export. Check formats, completeness, and how long it takes.
• Identify where data is stored, who has access, and who handles licenses and payments.
• Confirm who holds the source code, documentation, and infrastructure credentials.
• Clarify the rights your company receives and the work needed to transfer maintenance or move to another product.

For a service, agree on export and termination terms. For development, specify the deliverables, documentation, rights, and handover of code and access. Third-party component licenses also matter: a contractor cannot grant rights it does not hold. A handover clause is useful only if another team can continue the work in practice.

Consider an existing foundation before a full build

Buying a subscription and writing everything from scratch are only two options. You can configure a product, connect it to other systems, or develop the missing part. Sometimes changing an awkward procedure is cheaper and more useful than reproducing it in software.

Standard components, such as a website engine, a language-model service, or an email migration tool, often make sense to reuse. In the Workspace migration, third-party software avoided rebuilding the transfer mechanism. Selecting and configuring it, understanding the data, and validating the transfer still required engineering work.

Choose data access methods source by source

Neither an API nor web scraping, the automated extraction of information from web pages, is inherently the cheaper choice. Compare the source's access and data-use terms, completeness, usage limits, reliability, and maintenance needs.

A website change may require a scraper update, although not every change breaks it. APIs can also change their terms and limits. The initial connection cost covers only part of the expense.

In an advertiser discovery system, I combined external tools with custom algorithms. The sales team had tried direct searches through ChatGPT and other language models without satisfactory results. I built a system that collects specialist industry analytics through APIs and source interfaces, processes the data, and identifies legal entities. Web search and language models help find contacts, partnership terms, and affiliate programs. Qualifying companies go into Google Sheets with context for outreach.

This combination regularly prepares potential partners in the selected advertiser category. It does not replace negotiations or guarantee a sale. The model handles part of the workflow; ordinary code handles data collection, structuring, and other processing.

When external services process personal data, review the full data flow: what is sent, where it is stored, who can access it, the service terms, and the legal basis for processing. Being able to replace a model is useful, but changing its provider or hosting location does not by itself establish lawful processing. Engineering choices need to implement agreed requirements.

Assess modernization before replacement

An old system with a long list of defects may still have a usable foundation.

I initially considered rebuilding a corporate WordPress website with several hundred pages. After reviewing it, I chose to retain and improve it. I completed more than 100 changes, updated WordPress and the supporting software, added tests, and documented the build and release workflow.

That workflow, often called CI/CD, defines how changes are assembled, checked, and deployed. The documentation covered component sources and the order for updating WordPress, plugins, and the runtime environment. It supported continued development of the existing site without requiring a complete replacement.

Assessing the current system before seeking new-platform estimates can reveal a more proportionate option: keep what works and fix what prevents further progress.

Make the next decision with enough evidence

The comparison should leave you with a tested workflow, the remaining manual work, costs over a common period, and a practical way to leave each option. That is enough to distinguish an acceptable trade-off from a problem likely to become expensive.

New development needs a clear reason: tested limitations in available products, an identifiable amount of custom logic, and someone able to maintain the result. I work on these tasks through my custom internal tools and web services service, including integrations and improvements to existing systems.

If you are choosing between these options, send the materials you already have or a few sentences explaining who does the work now, where it becomes difficult, and what needs to change. That is enough for a free initial written exchange to identify which options are worth investigating.