Custom software buyer guide
When does custom software development make sense for a South African business?
Custom software makes sense when an important workflow cannot be served adequately by existing tools or configuration. Start with the problem, systems and users, then define a focused release and estimate it with the delivery team.
Start with a workflow that is not working
Custom software is an application or capability designed around specific requirements rather than used solely as a standard packaged product. It might be a customer portal, an internal approval tool or a mobile application connected to existing business systems. It does not necessarily mean replacing the systems that already hold your records.
Useful starting evidence includes repeated re-entry, requests lost between teams, inaccessible customer information or staff having to reconcile conflicting records. Name the task, its frequency and the consequence when it fails. Avoid turning every irritation into a software project before checking whether clearer ownership or configuration would solve it.
LCR’s software services cover portals, automation, mobile apps, AI-enabled workflows and product development. This guide helps assess a business-wide project; it does not prescribe a particular platform or claim that custom development is always the right answer.
Compare configuration, integration and custom development
Ask the current supplier to demonstrate the required journey in the existing product. Check whether configuration, a supported extension or a better operating process is enough. When the underlying records are reliable but the user journey is missing, an application layer may be more appropriate than replacement.
A standard product is a strong candidate when the business can adopt its workflow without material harm. Custom development becomes more plausible when distinctive rules or interactions are central to the outcome. Use the custom versus off-the-shelf comparison to test the same scenario across both options.
GOV.UK’s technology-selection guidance is a useful reference for assessing technology in context. It is not a South African procurement rule or an endorsement of a particular supplier.
What should a South African brief make explicit?
| Area | Question to answer | Useful evidence |
|---|---|---|
| Users and devices | Where and how will the task be completed? | Actual devices, language needs and connection conditions. |
| Systems | Which existing records must remain authoritative? | Approved samples, interface documentation and an access owner. |
| Data handling | What information is involved and who may process it? | Data categories and decisions reviewed by the responsible owner. |
| Commercial terms | Which costs are in rand and which depend on external suppliers? | Current quotations, assumptions and renewal responsibilities. |
| Support | When does the operation need help and who provides it? | Business hours, escalation contacts and acceptable recovery expectations. |
These are discovery questions, not claims that every South African business has the same constraints. Obtain appropriate privacy, security or sector-specific advice for the actual use case. Do not infer compliance from local hosting or a supplier’s location.
Prove the difficult boundary early
Bring the accounting, CRM, ERP or other system owner into the discussion before promising integration. Confirm interface access, permitted actions, identifiers and how changes are reconciled. A spreadsheet export may support one use case but be unsuitable for another that needs a confirmed real-time action.
Keep an explicit owner for each important record. If an application changes a customer address, decide which system accepts it and what users see when that system is unavailable. The application-on-existing-systems guide examines this boundary in more detail.
Hypothetical example: a distributor wants customers to see reviewed order status. A portal using approved order data may meet the first need without replacing the accounting system. Automatic order changes would be a separate decision requiring additional permissions and acceptance tests.
Agree a first release and demonstrated acceptance
Choose the smallest complete workflow that improves the situation. Record exclusions, dependencies and who can accept the result. Review working software with representative users and check corrections, access denials and unavailable systems as well as the happy path.
AI-assisted tools such as Cursor, Claude and Codex belong in the delivery-method discussion. Ask the team how generated work is reviewed and how sensitive information is protected. They are not substitutes for discovering business rules or testing the final outcome.
Use the release readiness checklist even when the project is an internal capability rather than a new commercial product. Adapt its evidence to the actual risk and audience. Agree price and timing from that scope instead of relying on a national average or a promised development-speed multiplier.
Make operation part of the buying decision
Clarify source-code rights, third-party licences, hosting accounts, deployment access, documentation and support terms before appointing a team. Having the code does not automatically mean another developer can operate it. Ask what a handover would contain and which accounts the business controls.
Security verification should also be explicit. OWASP ASVS can help structure application-security requirements, but it does not certify a supplier or remove the need for project-specific review.
Start with workflow automation for internal process friction, client portals for external self-service or MVP development for a new product. If you are unsure, bring one real process and the result you want to a scope discussion. A good next step may be configuration or discovery rather than a build.
Sources and review date
Primary sources reviewed on 7 September 2026 and linked beside the claims they support. Decision tests are planning recommendations, not measured research. Examples are hypothetical, not client case studies. Confirm scope, price, timing and specialist-review needs with the responsible team.
Questions
Frequently asked questions
Does custom software mean replacing our ERP or CRM?
No. A focused application can use existing systems as sources of truth, provided the required interfaces, permissions and recovery behaviour are verified.
Is a local development team automatically the best choice?
Location alone does not establish fit. Assess understanding of the workflow, communication, technical evidence, ownership and the support arrangements your operation needs.
How should we compare quotes?
Ask each team to estimate the same first-release outcome, dependencies, acceptance work and operating responsibilities. Make exclusions and change assumptions visible.
Plan the next useful step
Bring the workflow and the result you need.
Discuss the users, existing systems and first-release boundary before committing to a build.