Off-the-shelf or custom: how to decide
In most cases off-the-shelf software is the right answer, and that is worth saying before anything else. It is cheaper, it goes live faster, and somebody else maintains it. This page is about the cases where it breaks, and how to spot them before paying for a build that did not need to happen.
Every page is the same offer: AI agents, an information system and a WhatsApp bot on the WhatsApp Business platform, as a Meta Tech Provider. Business automation, customer management and human approval. One software house.
Who it is for
For a business already running packaged software that feels the team working around it: a parallel spreadsheet, a field used for something else, a stage recorded in WhatsApp. A poor fit if you have not tried anything yet — start with the packaged option and see where it jams.
Problems this page addresses
The team works around the system
If there is a parallel spreadsheet, the system does not fit the work. It is only where things get copied at the end of the day.
A field used for something else
A "notes" field holding the real status is a sign your process has no place in the template.
The price grows with every seat
Packaged software is priced per user. On a growing team, the monthly bill eventually passes the cost of building.
What you get
An answer even when it is "no"
If packaged software is enough for you, we say so on the call and do not propose a build.
The list of signs, in writing
Exactly what in your work does not fit the template, so you can test it against another vendor too.
An estimate for both routes
What it costs to stay packaged and adapt around it, and what it costs to build, on the same facts.
Off the shelf or custom
| What it covers | Off-the-shelf software | Built for you |
|---|---|---|
| Time to go live | Days to weeks. Sign up and start working. | Weeks to months, depending on scope. |
| Upfront cost | Low or none. | A one-off project cost. |
| Cost over time | Monthly per user, growing with the team. | Maintenance, with no per-seat fee. |
| Fit to your process | Your process bends to the template. | The system is built around the process you run. |
| Who maintains it | The vendor, both faults and updates. | You, or whoever built it. It is on you. |
| When a change is needed | Wait for the vendor to decide, or work without it. | It gets built, at a cost and in a timeframe. |
| Data and code | With the vendor, on their terms. | With you, in your repository. |
Common questions
What does a custom system cost?
It depends on scope, and there is no single honest number. What raises it: the number of user types, connections to existing systems, and migrating historical data. What lowers it: starting with one workflow rather than the whole business. We estimate after seeing the process, not before.
When is off-the-shelf enough?
When your process looks like most businesses in your field, the team is small, and nobody keeps a parallel spreadsheet. In that situation building is waste, and we will say so.
Can we start packaged and move later?
Yes, and usually that is the right order. Using the packaged option teaches you exactly what is missing, which is the best possible input for a build. The cost of moving is mostly the data migration.
What if you disappear?
The code sits in your repository and the data is yours. It is a check worth running on any vendor, including us: ask where the code is, where the backup is, and get the answer in writing.
Could we adapt packaged software instead of building?
Sometimes, with automations and connections layered over the existing system. That is cheaper than building and works up to a point. It is worth finding that point before deciding.
Related pages
A management system built around how you already work
An off-the-shelf CRM asks the team to adopt someone else’s stages and fields. We build the record around the approvals, statuses, and fields that already decide who the customer is and what happens next.
AI agents for business that do not send on their own
A repeated request should not be written from scratch, and it should not go out before a person has read it. We attach classification and a draft to the system that already holds the case, with a clear rule for what stops for approval.
A core system instead of a pile of tools
When the central process - enrollment, handling, scheduling, follow-up - fits no product without bending it, the team becomes the glue. We build the core of that process and leave outside the tools that already do one narrow job well.
