Short answer: off-the-shelf software is usually the right first move for a small team with a fairly standard sales or support process, since it is faster to start and cheaper to keep running. Custom software earns its cost when your workflow, approvals or record types genuinely do not fit a standard pipeline, or when several teams need one shared view that existing tools cannot give you without heavy workarounds. The decision should follow the shape of your process, not the size of your team.
What does off-the-shelf actually give you?
A standard CRM gives you a working pipeline, contact records, and reporting on day one, built by people who have refined that particular shape of workflow over many releases. For a business whose sales or support process looks like the common case, meaning a fairly linear pipeline with a handful of stages and one type of customer record, that is a genuine advantage. You are paying for a well-tested shape, not for something new.
The trade-off is that you adapt your process to the tool rather than the other way round. Most standard software lets you customise fields and some steps, but the underlying structure, such as what a record is and how it moves through stages, is usually fixed. If your process fits that structure, the fit is close to free. If it does not, the small mismatches tend to accumulate into a lot of manual patching.
When does a standard pipeline stop fitting?
The clearest sign is when your team already works around the tool rather than through it: a spreadsheet that tracks the thing the CRM cannot represent, a shared document that holds the approval history the software has no field for, a second system that a different team insists on using because the first one does not fit their part of the process. Each of these workarounds is a small, quiet tax, and taken together they can cost more staff time than a custom system would.
Another sign is that several teams, such as sales, operations, finance and support, need to see and act on the same customer record but with different information and different permissions, and no combination of standard tools gives you that without duplicating data between them.
How do you decide, step by step?
- Write down the actual stages your work moves through today, including the informal ones nobody put in a diagram.
- List every place your team currently keeps a workaround: a spreadsheet, a shared inbox, a private note.
- Ask whether a standard CRM's fields and stages could represent your process with only minor customisation.
- Count how many separate tools or teams need to see the same customer record, and whether they need different permissions.
- Estimate how often your process changes; a fast-changing process favours whichever option is quicker to adjust for your team.
- If a standard tool covers the process with only small adjustments, start there. Revisit the decision once you can point to specific, recurring gaps.
What does "custom" really mean in practice?
Custom does not have to mean building everything from a blank page. It usually means the pipelines, record types, approvals and permissions are designed around your actual process rather than adapted from someone else's, and the resulting system is a codebase your business owns rather than a subscription you rent. That ownership is also the responsibility: you decide what changes, and you carry the cost of building and maintaining those changes over time.
| Off-the-shelf | Custom | |
|---|---|---|
| Time to first use | Fast | Depends on scope, usually longer |
| Fit to an unusual process | Limited to available customisation | Designed around your process |
| Who owns the code and data | The vendor hosts it; data export varies | Your business, by agreement |
| Cost pattern | Ongoing subscription | Upfront build plus maintenance |
| Handling a new requirement | Wait for the vendor, or work around it | Scoped and built as a change |
When this is the wrong choice
Building custom is the wrong choice for a team whose process still looks like most other teams' process, since you would be paying to reinvent something that already exists and is already reliable. It is also the wrong choice for a team that cannot commit to maintaining a system over time, because custom software needs an owner on your side, not only at launch but for every change afterward. Buying off-the-shelf is the wrong choice when the mismatch between your process and the tool is large enough that your team spends more time working around the software than working through it; at that point the subscription is not actually saving time, it is hiding the cost of the workaround.
How we approach it at Ribhu Labs
We start by tracing your actual customer journey through sales, operations, finance and support, and we say plainly if a standard tool already fits it well. Where several teams need one shared, permissioned view of the same record and no standard combination gives you that cleanly, we design the pipelines, records and approvals around your process instead. Read more on the CRM & team operations page, and see the same idea of one visible workflow with a reviewable next step in the decision-path study in the Lab, which is an illustrative browser demonstration rather than a connected system.