Your company needs custom software when you have a repeated, documented process that costs you measurable time or money, you tried off-the-shelf tools and they could not run it, and you can afford to maintain the system after handover. If any of these is missing, a cheaper answer usually exists.
Most writing on this topic comes from companies that sell software development, and that includes us, so this article starts with the cases where you do not need a system. You will finish with six tests for your own problem and a way to work out the cost of each option over three years.
Try these four steps before building anything
Custom software is the last step on a five-step ladder. Move up only when you can say exactly why the current step failed.
| Step | Solution | Enough when |
|---|---|---|
| 1 | Change how the work is done | The cause is extra steps, unclear ownership or needless approvals |
| 2 | An organized shared spreadsheet | Little data, few users, no need for detailed permissions |
| 3 | An off-the-shelf product | Your process resembles most companies', such as accounting or customer management |
| 4 | Off-the-shelf products plus integration | The tools work but staff copy data between them by hand |
| 5 | Custom software | The six tests below apply to you |
Do not skip step one. Software built around a chaotic process gives you the same chaos, faster and at a higher cost. Step four solves a lot with simple connections, and our article on business process automation shows how to order them.
Six tests that show if your problem deserves custom software
Answer yes or no, with evidence for each answer. A yes without evidence counts as a no.
| # | Test | Evidence needed |
|---|---|---|
| 1 | The process repeats often | How many times a month it runs |
| 2 | You can write it down step by step | A page the people doing the work agree with |
| 3 | You tried ready-made alternatives | Product names, and the step each one could not do |
| 4 | The current cost is calculated | Hours, errors or lost sales, in numbers |
| 5 | You have an internal project owner | A named person with time to review and authority to decide |
| 6 | You can fund it after handover | A clear yearly budget for maintenance, hosting and new work |
Six out of six means the project deserves serious study. Four or five means fix what is missing first, which is usually test four or five. Three or fewer means go back to the ladder. These cut-offs are practical judgment from how projects get assessed, and they are not a scientific scale.
Test five is the one people neglect. Custom software depends on daily decisions about how the company works, and a developer cannot make them alone. Without someone who has the time and the authority, you end up with a system that matches what the developer understood instead of what the company needs.
How to calculate what you lose now and what a system costs over three years
Work out both sides in hours and percentages before you ask for a quote. This example is entirely hypothetical.
The cost of the current situation
Three employees copy order data between two spreadsheets for two hours a day, 22 working days a month. That comes to 132 hours a month and 1,584 hours a year. Multiply by your hourly staff cost, then add the cost of mistakes such as a wrong shipment or a late invoice.
The cost of the system
The build price is only part of it. A common rule of thumb puts yearly maintenance at 15% to 25% of the initial development cost. It comes from a consultancy and is no official standard, though it is good enough for planning. If the build costs X and you use 20%, three years of operation come to:
X + (3 × 0.2 × X) = 1.6 × X
So in this example you pay 60% more than the build price over three years, before hosting and any new features. Compare that figure with the current cost over three years, and with the subscription price of ready-made tools for the same period. The detailed comparison and its table are in off-the-shelf or custom software.
Where custom software fits and where it does not
Custom software usually suits work that connects several parties under rules specific to your business, or where the way you do the work is part of what sets you apart.
- A long approval chain that changes with contract type and value.
- Factory work orders that tie requests to materials and production stages, when no ready system covers them.
- A portal where your clients or suppliers follow their orders.
- Pricing built on many rules specific to your sector.
On the other hand, what the market has already standardized rarely deserves a build.
- Accounting and invoicing. Tax requirements keep changing, and a specialist vendor should carry that burden.
- Email and meetings. Owning your own version gives you no competitive edge.
- Standard customer management. Start with a ready product and build only what it cannot do.
- Company-wide resource planning. If you are unsure here, start with the readiness test in when your company needs an ERP.
If your idea is to sell the system to other companies, that is a product and the math changes. We cover it in building a SaaS product.
What your company should own in a custom software contract
In many countries, paying for development does not transfer ownership by itself. The World Intellectual Property Organization's guide says a third party keeps the copyright, even when paid, unless a written agreement transfers it, and its handbook on app contracts recommends dealing with assignment early. Review these points with your lawyer, since rules differ by country and this section is not legal advice.
- Rights to the code written for you, transferred in writing, with a list of components the developer keeps or licenses to you.
- The code repository in your company's name, or a copy delivered after each stage.
- Hosting and domain accounts in your company's name, with admin access on your side.
- Your data, and a way to export it in a readable format at any time.
- Documentation that lets another team run and change the system.
- Use for other clients, and whether the developer may reuse what you paid for.
- Support after handover, response times, and the cost of new changes.
Also ask how the team handles security. The OWASP Top 10 is a well-known reference for the most common web application risks. It is enough to ask how the team covers these risks, how it tests for them, and what the backup and recovery plan is.
Start with the smallest version that solves the problem
The most dangerous decision in these projects is trying to build everything in the first release. Pick one process, specific users and one measure of success, such as the time it takes to issue a quote. Run that version with the real team, then decide what deserves building next.
This shows you the mistakes early and cheaply. In their first week of use, staff find cases that nobody mentioned in the meetings.
What to prepare before your first talk with a developer
You do not need a technical document. These five pages are enough to get a quote you can compare:
- The current process step by step, and who does each step.
- Your calculation of what the current situation costs.
- The products you tried and where they stopped.
- The systems the new one must connect to.
- The name of your project owner and when you need the result.
Your next step
Take the problem you are thinking of building for, and run it through the ladder and then the six tests. If you stop at step three or four, you have saved a large cost. If you reach step five with clear evidence, write the five pages and ask for at least two quotes. You can review those pages with PlanKit's custom software team, and we will tell you if a ready-made product is enough.