Most companies that ask us about custom software already run on packaged products, and most of those products are doing their job. The accounts are fine in Tally and the CRM covers the sales pipeline well enough. The trouble sits in one or two workflows that never fit anything the company bought, and the decision worth making is about those workflows, not about the whole stack.
The decision is usually about one workflow
Take a distributor in Indore that runs quoting on an Excel sheet, scheduling on WhatsApp, and month-end reporting through one person who knows every exception by heart. It would be easy to call that a case for a new system. The real question is narrower. Which of those three is costing the business time or money every week, and can a product be configured to do it the way the team actually works?
Packaged software is quick to adopt and often the right answer. It starts to cost you when your process does not match the product's assumptions. Your team changes the process to suit the tool, even where the process is what makes you different from the next distributor. You pay for forty features, use twelve, and still lack the two you need. Data sits in three systems and someone copies it between them by hand, usually in the last week of the month. And your plans depend on the vendor's roadmap, pricing and support terms, none of which you control.
None of this makes packaged software a poor choice in general. For accounting, email or HR we would nearly always point a client at a product. So before comparing build and buy, write the requirement as the job someone does today, with the spreadsheet open, and price that job on its own.
Four options, not two
Build or buy sounds like a choice between two things. In most of the first conversations we have, there are four realistic options on the table, and the one people skip is usually the right one.
| Option | Fits when | What you maintain |
|---|---|---|
| Buy and configure | A product covers the workflow with settings and fields | Configuration and user access |
| Buy and connect | The products are fine; moving data between them is the problem | A small integration layer |
| Build the one workflow | One process is specific to how you win work | That application and its integrations |
| Replace the stack | Several core processes fit no product at all | A full system, for years |
The second row is the one that gets missed. If the CRM and the accounting tool both do their jobs, and the pain is the hour a day someone spends re-keying orders from one into the other, the answer is often a small custom tool between two products you keep. That is still custom software, but it is a much smaller commitment than replacing either product.
Criteria that point towards building
Five criteria do most of the work. The process is part of how you win or keep customers, so a generic version would make you worse at it. Several systems are being stitched together by hand. The rules change often, and people outside the tech team need to change them. The output has to reach other systems, such as a GST invoice in Tally or a dispatch request to a courier portal. And there is a named person on the business side who will decide what the rules are.
- The process is standard in your industry
- A vendor covers most of it with configuration
- The data does not need to reach many systems
- The process is part of how you win work
- Several systems are stitched together by hand
- Rules change often and non-developers edit them
Use it to start the discussion, not as a formula.
The decision rule we use is simple. If the process is standard and a product covers most of it, buy. If only the movement of data hurts, build the connecting layer only. If three or more of the five criteria hold, price a custom build for that workflow. If there is no business owner, wait until there is one, whatever else applies.
Back to the distributor. A custom order portal could take a retailer's order the way the retailer actually places it, by brand and scheme rather than by SKU code. It could push the confirmed order into Tally for the GST invoice and give the owner one report across all three depots. Tally stays, and so does the CRM. The custom part is the order flow, because that is the part no product handles the way this business works. Our software development work usually starts at that scale.
What the Nebula estimator shows about a good fit
Nebula Digital Accessibility sells audits, remediation, document testing and training to organisations that need their websites and documents to meet accessibility standards. Their sales team scoped every request by hand, from spreadsheets, email threads and personal experience that lived with a few people. Small details changed the effort a great deal, such as the number of templates versus pages, languages, dynamic states and third-party widgets.
BizHues built a guided estimator for them. Advisors answer practical questions about property type, page and template counts, component complexity, frameworks, assistive technology coverage, languages, WCAG level and add-ons. A rules engine converts the answers into effort by role (auditor, developer, project manager, QA), applies pricing logic, buffers and rush factors, and returns three package options (Essential, Enhanced and Partnership) with scope and timeline ranges.
- 01Scoping answersguided form
- 02Rules engineeffort by role
- 03Three packagesscope and timeline ranges
- 04Proposal and SOWapprovals for discounts
- 05Delivery planafter acceptance
The estimator replaces a spreadsheet and an email thread with one path.
It meets the criteria above almost point for point. Scoping is how Nebula wins work, so a generic quoting tool would have flattened the detail that makes its estimates credible. The logic lives in explicit rules rather than one person's memory, so anybody can inspect it. Operations staff edit rates, multipliers and question wording without raising a ticket to a developer. And the output keeps going into the next step, with a proposal and draft SOW, CRM and e-signature integrations, and a delivery plan once the quote is accepted. A dashboard tracks win rate, average selling price, margin health and time-to-quote. The Nebula project story has the full scope.
Where custom projects go wrong
The commonest mistake is automating the process exactly as it is today, workarounds included, before agreeing what it should be. We ask for the current spreadsheet before we talk about screens, and the first finding is often that two branches follow different rules for the same scheme discount.
Hard-coding rules that change is the next one. Prices, credit limits, approval thresholds and the GST rate for a product category end up in code, so every change needs a developer and a release. Close behind it is building the interface and leaving out the integrations, so staff still re-key the same order into Tally and the courier portal after the new system has accepted it.
Two more are about people rather than code. Without a named owner on the business side, the software ends up encoding the disagreement between sales and accounts. And projects that count only the build cost get a surprise later, because hosting, upgrades, security patches and support continue after launch and need their own line in the budget. Finally, some teams choose custom for its own sake, where a configured product would have done the job in a month. We say so when we see it, because a cheaper answer that works is a better start to any working relationship.
What to bring to the first conversation
You will get a far more useful first call with a development team if you prepare four things.
- The steps of the process as people actually do it, including the spreadsheets and WhatsApp groups.
- A mark against each step showing whether it is a rule, a judgement or copying data.
- The rules that change, how often, and who changes them today.
- The systems the output has to reach, with the name of whoever owns each one.
Start with the spreadsheet. A process that cannot be written down in an hour, with the files open, usually needs agreeing inside the business before anyone should build it. If the list shows that several subscriptions overlap as well, our guide to deciding what to replace when SaaS tools pile up covers that side of the decision.
From our work
Nebula Digital Accessibility
Automated Quotation and Estimation tool
Read the project story
