When custom software is worth it (and when it’s an expensive hobby)

Custom software is not a status symbol. It’s a bet that a tailored system will return more than a subscription plus the cost of living with the gap.

Most of the time, the subscription wins. That’s not a failure of ambition; it’s arithmetic. The interesting question is when the arithmetic changes.

The spreadsheet test

If the process still runs in a spreadsheet with three power users and no customer-facing workflow, you probably have a process problem, not a custom-software problem. Fix the process first. Software will happily automate a bad one.

The economics, plainly

Start with the cost of doing nothing. Add the hours lost each week, the errors and rework, and the revenue you can’t capture because the process is too slow. Then compare that with the build plus the annual cost of ownership.

annual cost of status quo =
  hours lost per week × loaded hourly cost × 46 weeks
  + error and rework cost
  + revenue you cannot capture

Example: 10 staff lose 8 hours a week to a manual process, at a loaded cost of ₹400/hour. That’s ₹14.7 lakh a year before errors. If a ₹15 lakh build plus ₹3 lakh a year in ownership cuts the lost time in half, the three-year saving is about ₹22 lakh against a ₹24 lakh cost. It’s close. Five years is better, but only if the system survives and the process doesn’t change.

This is why labour savings alone rarely justify custom software. The stronger cases are revenue growth, error cost, compliance risk, or a workflow no product can model. Be honest about which one you have.

Six signals custom is the right call

• The workflow is core to revenue, not a back-office convenience.
• Standard tools cover less than roughly 80% of the real process.
• Transaction volume makes a small time saving meaningful.
• Integration complexity is the bottleneck, not interface polish.
• Compliance, data ownership, or procurement rules require control.
• You have an internal owner who will still be there in year two.

Five signals it isn’t

• Volume is low enough that a spreadsheet and a weekly review work.
• Requirements are still changing every week.
• Nobody internally can own the system after launch.
• You can’t fund maintenance, hosting, and support.
• The real request is a nicer dashboard, not a different workflow.

The options between SaaS and build

What a responsible build looks like

• Discovery that produces a written scope, assumptions, and non-goals.
• A clickable prototype of the critical flow before the database.
• Milestones with acceptance criteria, not a single big-bang launch.
• Staging, automated tests, and a security review.
• Documentation for setup, deployment, and backup/restore.
• A handover with source code, credentials, and a runbook.
• A warranty period and a maintenance agreement.

The total cost nobody budgets

• Maintenance and small changes: often 15–25% of the build cost per year.
• Cloud, email, SMS, payment gateway, and monitoring fees.
• Security patching and dependency upgrades.
• Support and training for new staff.
• Reporting changes when the business changes.
• Migration or exit costs if the vendor relationship ends.

Ten questions to ask a vendor

1. Who owns the intellectual property on full payment?
2. Can we get the repository, credentials, and deployment documentation?
3. What happens if we stop working together?
4. How do you test, and can we see the tests?
5. Which third-party services will we need to pay for?
6. What is explicitly out of scope?
7. How do you handle change requests?
8. What does the first 90 days after launch look like?
9. Who is on the team, and who is the single point of contact?
10. Can you show a production system you built and still maintain?

Red flags

• A fixed price for a fuzzy scope with no discovery.
• No access to the code or hosting account.
• No staging environment or acceptance criteria.
• “AI will make it faster” used as a discount instead of an engineering plan.
• One hero developer with no backup or documentation.
• A contract that locks you into the vendor for every change.
• No plan for data export or migration.

When we say no

We’ve turned down builds that a ₹2,000/month subscription would solve better. It isn’t charity; it’s avoiding a project that fails in year two. We’d rather build the thing that changes the business — a restaurant billing engine that works offline, a learning platform with four portals, or a storefront with a buying model you can’t configure.

Our rule of thumb

Build when the software is part of the product. Subscribe when the software is part of the plumbing. The hard cases are in the middle, and those usually deserve a prototype, not a platform.

The number that matters

Custom software is worth it when it changes a number that matters — revenue, error rate, compliance exposure, or speed to serve a customer. If the best you can say is “it will feel more professional”, buy the subscription and spend the difference on the experience around it.