We build custom software for a living. The honest advice for most businesses is still: buy something off the shelf first. Custom software is worth the money only in specific situations.
Why off-the-shelf is usually right
A commercial accounting package has been used by thousands of businesses, has had thousands of bugs fixed that you will never encounter, and its development cost is spread across all those customers. You pay a few hundred dollars a year for something that would cost six figures to build.
More important than money: off-the-shelf software works next week. Custom software takes three to nine months before the first real user touches it. During those months, your business still has to run somehow.
Four signs you genuinely need custom
1. Your process is a competitive advantage
If the way you handle orders is 30% faster than your competitors, and off-the-shelf software forces you into its own workflow, you have just paid money to give up your advantage. This is the strongest reason to build.
Conversely, if your process differs only because of historical accident and brings no benefit, then being forced to standardise is a good outcome, not a bad one.
2. You have already hit the ceiling of a packaged product
The clearest signal: staff use the official system but maintain a spreadsheet alongside it for the parts the system cannot handle. When that spreadsheet becomes the real source of truth and the software is just where you retype things, it is time to consider alternatives.
3. Licence costs scale absurdly with headcount
Many products charge per user. At 20 users that is reasonable. At 300 users the annual figure can exceed the one-time cost of building your own. Work out where that crossover sits before you reach it, not after.
4. The real problem is that five systems will not talk to each other
When the problem is not "we lack a system" but "our five systems are disconnected", what you need to build is usually the connecting layer, not a sixth system.
The most common way money is lost: rebuilding what exists
Many custom software projects fail not on engineering quality but because they rebuild things that already exist and work better. Authentication, permissions, email delivery, report generation, payments, file storage — all available as mature, cheap services.
A practical rule: build only what is specific to your business. Use libraries or services for everything else. A healthy project has 20 to 30% of its code as genuine business logic; the rest is assembling existing pieces.
Three questions to settle before signing
Who owns the source code
Ask this directly and get it in the contract. If the vendor keeps the code, you are locked in permanently — whatever they quote for maintenance, you pay, because nobody else can touch it. TRIUNITECH hands over 100% of the source code, and we would advise demanding the same from any vendor.
Who operates it after handover
Software is not a building that is finished when construction ends. It needs security patches, updates when the operating system changes, fixes for problems that emerge. Three years of operations typically costs 40 to 60% of the original build. If a proposal says nothing about this, the proposal is incomplete.
What happens if we part ways
Can the data be exported, and in what format. Is the documentation good enough for another team to take over. Ask while the relationship is good, not after it has soured.
The cheapest step, and the one most often skipped
Before building, prototype for two weeks with a no-code tool. Google Sheets, Airtable, something similar. If the prototype solves 80% of the problem, you may not need a software project at all. If it exposes the genuinely hard parts, you have just saved months of walking in the wrong direction.
If you do build, build in stages
Do not sign a nine-month contract for the whole system. Break it into six to eight week increments, each ending with something genuinely usable. This gives you three things: visible progress instead of percentage reports, the ability to change direction when a requirement turns out to be misunderstood, and the ability to stop if the vendor underdelivers — losing one increment rather than the whole project.
Written from the team's hands-on experience delivering infrastructure and software. No sponsorship, no product placement.