Software decisions
Custom software or existing tools: which should you choose?
By Artek NexusUse existing software when it handles your essential workflow well. Consider a custom build when a material requirement remains unmet and the value justifies developing and maintaining it. Often, the useful middle option is to connect or configure the tools you already have.
Describe the job before listing features
Start with a real sequence: a request arrives, someone qualifies it, a quote is approved, work is delivered and an invoice is issued. Identify the people involved, the information each needs and the conditions that change the next step.
Separate essential requirements from preferences. A familiar screen layout is a preference; controlling who can approve a payment may be essential. Ask what would happen if a requirement were missing, how often that would happen and whether a simpler process could address it.
A poor fit is not always a software problem. If ownership is unclear or employees cannot get an exception resolved, a new application may add another place to wait.
Compare buying, connecting and building
Evaluate all three options against the same workflow. Demonstrate your difficult cases, not only the clean scenario shown in a sales demo.
| Option | When it is worth considering | What to check |
|---|---|---|
| Buy or configure | A supported product covers the essential work | Permissions, exports, support and pricing as usage grows |
| Connect existing tools | The tools work individually, but people copy information between them | Available interfaces, duplicate handling, failures and monitoring |
| Build a scoped application | Important requirements cannot be met acceptably by the other options | Delivery capacity, testing, maintenance, ownership and a useful first release |
Compare the cost of operating the solution
A licence price and a development quote do not describe the same thing. Use a common planning period and include setup, migration, configuration, integrations, training, support and the time your own team must contribute.
For purchased software, ask how seat counts, usage limits, add-ons and renewal terms affect the cost. For custom software, ask who handles hosting, security updates, dependencies, monitoring and changes after launch. For either option, establish how you can export your information and move to another provider.
Your domain, data, source code, deployment accounts and third-party subscriptions are separate items. A proposal should state who controls each relevant item and what handover includes.
- One-time implementation and migration costs
- Recurring software, hosting and support costs
- Internal training and administration time
- Expected changes and integration maintenance
- Exit, export and handover arrangements
Use a pilot to test the difficult parts
Ask each option to complete the same representative journey with realistic data and roles. Include an exception: a duplicate customer, a revised quote, a missing document or a user who should not have access. Record what needs a workaround and who maintains it.
Our products illustrate different design decisions. Marcel uses a conversational request to find business records; Nomad connects client details, quotes, invoices, payments and costs. They demonstrate our work without implying that every business should commission a similar custom system.
Choose the smallest approach that meets the essential requirements and has an owner after launch. A build decision is stronger when it identifies precisely what an existing product cannot do, instead of relying on a general wish for more flexibility.