Buy software, integrate existing tools or build your own?

A company already uses a CRM, spreadsheets, email and several subscriptions. Another platform promises to bring everything together. After the demo, one question remains: should the company adapt its process or commission its own software? The answer depends on which details create value and which habits can reasonably change.

Consider an illustrative consulting business. Deadlines, document versions and employee access may be essential to its work. A familiar card colour or the order of two optional fields is a weaker constraint. Mixing these categories makes almost every off-the-shelf product appear unsuitable.

Describe one critical workflow and label requirements as mandatory, desirable or flexible. For mandatory conditions, record the consequence of failure: no accountable owner, a missing approval history or a client seeing another client’s file. This creates a decision framework you can test during a demonstration.

Check an established product first when your main workflow fits its standard model. Routine enquiry tracking, for example, may not justify a custom CRM. Configuring stages, importing data and agreeing how staff will use the system may be more valuable than recreating a familiar feature set.

Test the service with anonymised examples from your work: creating a record, moving it between stages, handling an error, finding history and exporting data. A feature list does not reveal how many workarounds daily operations will require. Also check whether the necessary permissions and settings belong to the plan you are actually considering.

Ask for an export of several related records and establish what survives a move to another system. Export formats, API terms, limits and deletion options matter alongside the first demo. Verify these details against the chosen provider’s current terms rather than assuming all products offer the same access.

Sometimes people are happy with each application but spend their time moving data between them. The problem sits at the handoff. An order arrives on a website, someone retypes it into the CRM, then creates a task for delivery. An integration may close that gap without replacing everyone’s workspace.

Decide which system owns each important fact. Where does the price change? Which system confirms payment? What happens when the same event arrives twice? Errors must remain visible and retries must be safe. Otherwise, the manual workaround becomes an automated problem that is harder to notice.

The flower-delivery case links addresses, delivery-zone pricing, orders and courier actions in a Telegram Mini App. The relevant idea is a shared workflow, with less need to reconstruct an order’s state from messages. Depending on existing tools, a similar goal may call for an integration or a focused additional interface.

Custom development becomes a stronger option when important, stable business rules fit poorly into available products. Look for recurring workarounds: approvals happen elsewhere, documents are scattered and different roles lack a suitable workspace. A single inconvenient screen does not establish the case for an entire platform.

In Banex, client documents, tasks, staff time, contracts and integrations sit in one CRM. It illustrates a problem involving linked records and access rules. The case describes the scope of that system; it does not imply that every company handling documents needs the same solution.

Ownership brings responsibility for maintenance, upgrades, permissions and future changes. Appoint a process owner and agree on a complete first-release workflow. If nobody can decide how the business rules should work, development will simply reproduce those unresolved disagreements in software.

“Subscription versus development price” is an incomplete comparison. Include setup, migration, integrations, training, manual exceptions, maintenance and the next substantial change. Use the same time horizon for every option and state assumptions. An unknown maintenance cost should remain an explicit unknown rather than quietly becoming zero.

Examine the exit route as well: exporting data, changing vendors or handing over code and infrastructure. Custom systems create dependencies too, through their architecture, documentation and the availability of specialists. Being able to continue without the original implementer belongs in the handover agreement.

A useful next step is one comparative test using a real workflow. Ask each supplier or developer to demonstrate an ordinary case, an error and its resolution. For a focused project discussion, bring the process, current tools and mandatory constraints. That is enough to compare realistic options on common terms.