Key takeaways

  • Custom software can pay when licence cost scales with headcount, when staff work around the product with spreadsheets, or when several tools hold the same data.
  • It does not pay for common functions that a mature product already does well. Buy those.
  • Compare total cost over three to five years: licences, add-ons, integrations and workarounds on one side; build, hosting, support and change on the other.
  • Ownership must be in writing: who holds the copyright, the source code, the data, the accounts and the documentation.
  • A two-week prototype of the one painful workflow, used by real staff on copied real data, tells you more than a requirements document.

The question to ask first

Most companies run on software they rent by the user. The license is cheap on day one. Over time the bill grows with every hire, every module and every integration, and the product still does not match how the work is done. Staff keep spreadsheets next to it. Data is typed twice. A report that should take a minute takes a day.

Replacing a product with custom software is a big decision, and sometimes the wrong one. This article gives a way to decide. It is general guidance. The right answer depends on your firm, your regulators and your team.

Signs that custom software may pay

  • License cost scales with headcount. A per-user price looks small until you multiply it by staff, by twelve months and by the years you will keep the product. When the total is large and the product is only partly used, the math starts to favor building.
  • Your process is your advantage. If how you quote, schedule, produce, review or serve clients is what sets you apart, a generic product pushes you toward the average.
  • Workarounds are everywhere. Spreadsheets that shadow the system, copy-and-paste between tools, and a person whose job is to reconcile two lists are signs of a poor fit. Each one costs time and invites errors.
  • Several products hold overlapping data. Consolidating five tools that each do a slice into one platform removes duplicate entry and conflicting records. It also reduces the number of vendors, logins and renewal dates.
  • Integration is the main expense. If you pay more to connect products than to run them, a single system built around your data may be cheaper.
  • Hardware or the physical world is involved. Sensors, machines, scanners, kiosks and special devices rarely have a good off-the-shelf product, and a custom platform can combine the software and the hardware in one design.
  • Vendor risk worries you. A product can raise prices, remove features, change terms or be discontinued. Owning the system gives you control of the roadmap, as long as you also take on the work of maintaining it.

Signs that you should buy, not build

Do not build what a mature product does well and what every firm needs in the same way. Payroll, general accounting, email, office documents, tax filing and endpoint protection are examples. The vendor spreads the cost across many customers, tracks the law and ships security fixes on a regular schedule. It is hard to match that for a fair price.

Be cautious, too, if your process is still changing every quarter, if you cannot name one person who will own the system, or if the main goal is only to avoid a price increase. Custom software replaces a subscription with a responsibility. You need a team, internal or external, that will keep it secure and current for years.

How to compare the cost honestly

Use a three- to five-year view and put both options in the same table. Do not use industry averages. Use your own invoices and your own time estimates.

  • Buy: licenses per user per month, extra modules, storage and API charges, implementation and training, integration work, the price increase you expect at renewal, and the cost of the workarounds. For the last item, estimate hours per week lost to double entry and reconciliation, multiplied by the loaded hourly cost of the people doing it.
  • Build: design and development, the data migration, hosting and backups, security reviews, user training, support and maintenance, and a budget for change. Software is never finished; plan a recurring amount for fixes and improvements, and treat it as an operating cost.
  • Transition: running both systems for a period, retraining, and the productivity dip while people adjust. Include these in the build column.
  • Risk: for each option, ask what happens if it fails. For a bought product, what is the exit cost? For a built one, what happens if the developer leaves?

If the table shows a close call, choose the lower-risk option. If it shows the custom path winning by a wide margin over several years, move to a prototype. Do not skip that step. The estimate is a hypothesis, and the prototype tests it.

Fit: what you gain when the software matches the work

Fit is the second reason to build, and it is harder to put in a spreadsheet. A system designed around your workflow can remove steps rather than digitize them. It can show each department only what it needs, in the order it needs it. It can capture data once, at the point of work, and reuse it for billing, reporting and compliance. It can also add automation and AI in the places where they help, such as drafting, classifying documents or flagging exceptions, with your data staying in your own environment.

Our team has built this kind of platform for clients, including a consolidation of several outdated products into one system, and a self-hosted platform with modules for each department. The pattern we see is that the largest gains come from fit and from removing duplicate work, not from the license line alone.

Ownership: put it in writing

When someone writes software for you, who owns it is not automatic. The U.S. Copyright Office explains that a work is "made for hire" in two situations: when an employee creates it as part of regular duties, or when a specially ordered or commissioned work falls into one of nine listed categories and the parties sign a written agreement saying so. Software written by an outside contractor does not obviously fit those categories, so a common safe route is a written assignment of copyright from the developer to you, signed at or before delivery. Ask your counsel to draft it.

Ownership has more parts than copyright. Specify each one in the contract.

  • Source code and build scripts, delivered to a repository you control, at every milestone and not only at the end.
  • Data and database schemas, with an export in open formats.
  • Accounts and credentials: the domain, the cloud account, the code repository and any app-store accounts, registered in your company's name.
  • Documentation: architecture notes, deployment steps, and a list of dependencies and their licenses.
  • Third-party and open-source components, with their licenses listed, so you know what obligations come with them.
  • Support terms: who fixes defects, how fast, and what happens if the developer closes or you change vendors.

Risks, and how to manage them

Custom software has real risks. Most are manageable if you name them early.

  • Scope growth. Features accumulate. Fix a first release that covers the painful workflow, and keep a visible list for later.
  • Key-person dependence. One developer who knows everything is a risk. Require documentation, a second person who can deploy, and code in your repository.
  • Security. You are now responsible for flaws in your own code. CISA's Secure by Design guidance asks software makers to treat customer security as a core requirement, to build security in during design, and to ship secure defaults such as multi-factor authentication, logging and single sign-on. NIST's Secure Software Development Framework (SP 800-218) describes a core set of high-level secure development practices that can fit any development method. Ask your builder how they apply both, and request a security test before launch.
  • Data migration. Old data is messy. Plan time to clean it, and run a trial migration before the real one.
  • Adoption. A tool people do not use is a failure, however good the code. Involve the users from day one, and plan training.
  • Compliance. If the system holds health, financial or client-confidential information, the rules that applied to the old product apply to the new one. Our articles on the HIPAA Security Rule and on data protection explain what regulators ask for.
  • Operations. Hosting, backups, monitoring, updates and recovery do not go away. Decide who runs them, and test the restore.

Running a two-week prototype

The prototype is the best tool for deciding. Its purpose is to answer one question: does a system built around our workflow remove enough friction to justify the investment? It is not a small version of the final product. It is a test. In our own work, a prototype of the core workflow in about two weeks has been a practical target, and it led to a clear go or no-go decision. Here is a plan any firm can follow.

  • Days 1 and 2, choose the target. Pick one workflow that is painful, frequent and visible, and that touches real data. Write the success measure: for example, time to complete the task, number of steps, or number of errors. Pick three to five users who do the work every day.
  • Days 2 and 3, map the real process. Watch people do the job. Collect the screens, spreadsheets, forms and reports they use. Note every workaround. Decide what the prototype will not do.
  • Days 3 to 5, design and data. Sketch the screens on paper or in a simple tool and review them with the users. Prepare a copy of real data with sensitive fields removed or protected. Do not test on live records.
  • Days 5 to 10, build the thin slice. Build the one workflow from login to result, with real data and just enough security: sign-in with MFA, a role or two, and an audit trail. Hold a short demo with the users every two or three days and adjust.
  • Days 10 to 12, put it in front of the users. Let them do real tasks while you watch. Record time, errors and comments. Compare with the baseline you wrote on day 1.
  • Days 13 and 14, decide. Review the numbers and the feedback. Produce a plain written result: what worked, what did not, an estimate for the full build with ranges, the risks, and a recommendation. The answer may be "go," "change the scope," or "buy a product." All three are good outcomes, because you learned them cheaply.

Agree before the work starts on what happens to the prototype. A good default is that it is throwaway code, or that it becomes the base of the real system only if it passes a code and security review. Either way, you own it.

A short decision checklist

  • Can we name the workflow where the current product costs us the most, and measure it?
  • Have we compared three- to five-year costs using our own invoices and time estimates?
  • Do we have an owner inside the company, and a plan for security, hosting, backups and support?
  • Will the contract assign the code, data, accounts and documentation to us?
  • Have we run a prototype on real data with real users, and did it meet the success measure?
  • Do we have an exit plan if the project or the builder fails?

How Clayton Cybernetics can help

Our Tailored Software team designs, builds and operates custom platforms, including self-hosted systems with AI built in, sensor and device integrations, and consolidations of several tools into one. We start with a short discovery and a two-week prototype so that you decide with evidence. You own the result. To talk through a candidate workflow, contact us. We will tell you honestly if buying is the better route.

Sources

This article is general information, not legal, tax or accounting advice. Intellectual-property ownership and contract terms depend on your facts and jurisdiction. Have your counsel review any software development agreement. Last reviewed .

Keep reading

Need help with this?

Software built around your business in weeks, and you own the code.

Tailored Software