Revised 24 October 2026.
Custom software is worth considering when an important business process cannot be supported reliably by the systems you can buy. It is not automatically the best answer to spreadsheets, slow reporting or an ageing application. A configured ERP, a specialist subscription product, or a small integration may solve the problem with less ongoing responsibility.
The useful question is: which option can support our critical workflows, at an acceptable cost and risk, and remain maintainable after launch? This guide gives business owners and operations teams a practical way to answer it before commissioning development.
Compare three realistic options
| Option | A reasonable starting point when | What to verify before committing |
|---|---|---|
| Ready-made software | Your process resembles the product's standard workflow | Demonstrate exceptions, export your data, and check the limits of the subscription you will actually buy |
| ERP configuration and selected extensions | Finance, sales, purchasing and inventory need to share records and controls | Map each requirement to a standard feature, configuration, integration or custom module |
| Custom software | A distinctive workflow, customer experience or integration is central to the business | Confirm a named product owner, a support budget, acceptance tests and a practical handover plan |
These options can coexist. An ERP may hold orders and stock while a custom customer portal manages approvals. The comparison should include that hybrid option rather than assume every function belongs in one new application.
Start with a workflow, not a feature list
Choose one process that causes recurring work or business risk. Write down its trigger, owner, inputs, decisions, outputs and exceptions. Then show the same examples to every supplier.
For an order-approval process, include an ordinary order, an order exceeding a customer's credit limit, a partial delivery and a cancellation after approval. Record who can approve each case, what must be logged and which downstream records must change. A presentation showing only a successful order does not demonstrate the whole workflow.
Build a short evidence table with four columns: requirement, current problem, acceptable outcome and proof. For example, “prevent duplicate orders when an integration retries” is more testable than “seamless integration.” Ask the supplier to explain what happens if a request succeeds but the response is lost.
Decide which gaps justify custom development
Classify each gap found during the demonstration:
- Configuration: an existing setting or workflow can meet the requirement.
- Process change: the business can adopt the standard approach without losing an important control.
- Integration: another system needs to exchange records or events.
- Custom behaviour: the required rule or user experience is not available through the supported standard features.
Challenge the last category. Sometimes a requested feature reproduces an old workaround that should disappear. In other cases, forcing staff through several manual steps would preserve the problem you are paying to solve. Record the trade-off and the person responsible for accepting it.
Our ERP and Odoo implementation page covers the configuration and integration route. For workflows that need their own application, see custom software development.
Check Odoo integrations before choosing a plan
Do not treat “connects to Odoo” as a complete requirement. Identify the Odoo version and hosting arrangement, the records to exchange, the direction of each update, the permitted delay and the owner of a failed transaction.
Odoo's documentation states that external API access under its pricing plans is available on the Custom plan and is not included in One App Free or Standard. Confirm the applicable subscription and deployment with the vendor before relying on an API integration. This is a plan constraint to investigate, not a quoted project price. Source: Odoo external API documentation.
For each connection, ask for a field mapping, a least-privilege service account, duplicate prevention, retry rules, error visibility and a reconciliation report. Decide which system is authoritative when two records disagree. A successful demonstration with one record is only the first test.
Compare the full cost over the same period
Ask every supplier to cost the same scope over a stated period, such as three years. Separate one-time implementation from recurring operation:
Total cost = discovery + configuration or development + migration + integrations + subscriptions + hosting + support + upgrades + internal staff time + exit or replacement work.
Document exclusions beside the price. Are historical records included in migration? Who corrects poor source data? Are third-party fees and additional users covered? What counts as a defect, and what becomes a paid change? Which assumptions would require a revised estimate?
Use measured operating data when estimating benefits. In an illustrative process with 300 orders per month and four minutes of duplicate entry per order, the current task consumes 20 staff hours per month. That is a baseline to investigate, not a promise that software will save all 20 hours. Run a pilot and measure the time still needed for exceptions and checks.
Define what the first release must prove
A small first release should complete one useful business outcome. For example: receive an approved order, create it once in the ERP, expose its status to the customer and show staff any failed synchronization. Leave optional dashboards and secondary workflows for later if they are not needed to prove this outcome.
Agree acceptance examples before implementation begins. Include user permissions, invalid input, retries, unavailable dependencies and recovery after interruption. Specify the expected response and the evidence required to pass each test. Business users should review these examples alongside the development team.
Security requirements also need concrete evidence. Use an agreed version and suitable requirements from OWASP ASVS as an input to the test plan. ASVS provides a framework for verifying application security; mentioning it in a proposal does not establish that a product is certified or secure.
Plan migration and handover before launch
For a replacement system, decide which records move, which remain read-only and how totals will be reconciled. Rehearse the migration using representative data. Document the cutover owner, the decision to proceed and the conditions for reverting to the previous process.
A gradual replacement can reduce the size of each change when old and new systems can coexist. It also creates temporary integration and operational work. Microsoft's Strangler Fig pattern describes this approach and its constraints; it is not suitable for every system.
Before the final handover, verify repository access, deployment instructions, environment ownership, backups and a demonstrated restore. Record who maintains dependencies and handles incidents. If your supplier works remotely, agree meeting overlap, review deadlines and escalation contacts. Continuity depends on these arrangements as well as on the code.
What to send with a request for proposal
Prepare one page containing the business problem, the users and roles, current systems, three representative workflows, required integrations and known deadlines. Include approximate record volumes and who can make scope decisions. Add sanitized examples rather than live customer data.
Ask suppliers to respond with their proposed approach, assumptions, exclusions, milestones, acceptance process and ongoing support responsibilities. Compare those answers before comparing headline prices.
If the decision is still unclear, discuss your workflow with Tarawud. Share the process and current tools so the discussion can distinguish an ERP configuration project, an integration and a separate application. You can also review our project portfolio and procurement information.
