Custom software guide
How should a company decide whether to build or buy software?
Buy when the job is the same in every company, a product already does it and the per-seat cost over five years is lower than owning a system. Build a custom system when the job is specific to how you operate, the data lives in your own systems and you would otherwise pay year after year to bend a product toward your process.
| What you are comparing | A product | A custom build |
|---|---|---|
| How standard the job is | Best when the job is the same everywhere, such as accounting, task tracking or support tickets. The vendor has already solved it for many other companies. | Best when the job is particular to you, such as how you quote, schedule, fulfill or serve customers. Nobody sells a product for a process only you run. |
| Cost over five years | A fee that repeats every year, plus onboarding, add-ons and the admin or consulting time needed to configure and change the product. It usually grows with headcount or usage. | A one-time build scoped in writing, then running costs such as hosting, database and email. No licenses, so the total does not climb with headcount. |
| Per-seat fees | Most products charge per user. Others meter by task, credit, flow, login or support agent, and a few charge a flat fee. Find the meter before you compare. | A custom system has no per-seat fee. Staff, managers, read-only executives and customers can all be given access at no added fee. |
| Fit to your process | You adapt to the product and configure what it allows on your plan. Whatever it cannot model ends up in spreadsheets and email beside it. | Built from your process as you run it, including the rules, approvals and handoffs that are yours alone. |
| Time to launch | You can sign up at once. A rollout across a company of 50 or more is still a project, with configuration, data migration and training. | Starts with discovery and a written scope. Working screens are shown during the build, and the schedule is set in that scope. |
| Who maintains it | The vendor maintains the platform. You, an admin or a consultant maintain your configuration, automations and integrations. | Any competent developer, since Black Badger writes the code to be read and extended and sets up every account in your name. |
| Changes after launch | Limited by your plan and by what the vendor exposes. The roadmap is the vendor's, and features can move between plans. | Anything can change, because you own the code. Changes are scoped and built when you need them. |
| Your data and other systems | Data sits in the vendor's system and reaches your other tools through its API, inside whatever rate and automation limits your plan sets. | The system is built against your own data and the tools you keep, and the database is yours to query and report on directly. |
| Leaving later | Records usually export. Automations, reports, permissions and layouts do not, and have to be rebuilt wherever you go next. | There is nothing to leave. You hold the code, the database and the accounts, and can move maintenance to another developer. |
Start with how standard the job is
How standard the job is settles most cases, and that question comes before any question of cost. If the job works the same way at most other companies, buy. Accounting, payroll, email, task tracking and support ticketing are solved, and a product gives you the solution for a modest fee.
If the job is where you differ from competitors, look harder. The way you quote, plan work, serve customers or move data between your systems is rarely standard. A product built for every company at once will fit that job loosely, and the gap gets filled with spreadsheets and people.
Run the five-year number
Do not compare a first-year subscription with the cost of a build. Take the per-user price of the plan you would need and multiply by your seats and by sixty months. Then add onboarding fees, add-ons and the admin or consulting time you will pay for.
Then find the meter. Some products charge per user, some per task or credit, some per customer login. Estimate where that meter will be in year five. A product that is cheap today can be the expensive choice once the company has grown into it.
The custom number is a one-time build plus running costs. Black Badger does not publish a price, because the figure depends on what the system has to do. A written scope gives you the number to set beside the product total.
Ask who will maintain it
Every system needs an owner. With a product, the vendor keeps the platform running and someone on your side owns the configuration. That someone is often a consultant, and their time belongs in the comparison.
With a custom system the usual fear is a developer who disappears, and ownership removes it. When the code is written to be read by others and every account is in your name, any competent developer can take over.
The middle route, a build platform
Between buying and building sits the build platform, where you rent the foundation and build the app yourself. It suits companies with staff who can build and maintain apps, and it is covered on our home list.
It carries traits of both sides. You get speed and a maintained foundation. You also keep paying per user or by usage, and what you build cannot leave the platform.
A common result is to buy most systems and build one
For a company of 50 or more employees the answer is almost never all one or all the other. Buy the standard systems. Build the one or two that are specific to how you operate, and connect them to what you bought.
On this site, buying ranks first for CRM, ERP and project management, where most needs are standard. Building ranks first for customer portals and integration layers, which are made of your own data and systems.
What a custom build involves, and how to ask about one
Questions buyers ask
Is building always more expensive than buying?
Building is usually more expensive than buying in the first year. Over five years the answer depends on headcount and on how much you pay to adapt the product. A subscription repeats and often grows. A build costs once and then costs what it takes to run.
What is the biggest mistake companies make in a build or buy software decision?
The biggest build or buy mistake is deciding for the whole company at once. The question has a different answer for each system. A company that buys everything ends up with spreadsheets filling the gaps, and a company that builds everything spends money rebuilding what it could have rented cheaply.
Can a company buy software now and build a custom system later?
Yes, a company can buy now and build later, and that order is often sensible. Running a product for a while teaches you what your process is. Check before you sign what exports cleanly, because records usually come out and automations, reports and permissions do not.
How do we know our process is specific enough to build for?
A process is specific enough to build for when workarounds surround your current product. If people keep workbooks beside it, copy data between systems by hand or route approvals through email, the product is not holding the process. Those workarounds are the outline of the system you would build.