Leonid Plokhykh
Compare buying, configuring, integrating, extending and building software. Use critical workflow tests, full costs and clear ownership to choose a workable route.
When staff copy information between systems, chase approvals or maintain a spreadsheet beside the main application, custom software can seem like the obvious next step. Yet the same symptoms can have different causes: an unused feature, an unclear process, disconnected applications or a workflow that existing products cannot adequately support.
Choosing between custom and off-the-shelf software means comparing the work each option can handle, its full cost and the responsibilities your business can sustain. That comparison should include buying a product, configuring software you already have, integrating systems, extending a platform and building an application. Test them against the same workflow before committing to one.
Define what a workable solution must do
Choose one important workflow and follow it from the event that starts the work to the result the business needs. For an approval process, that might mean an employee submits a request, an authorized manager approves it, and the approved details reach the person who acts on them. Include what happens when information changes or approval is refused.
This makes a vague complaint such as “the software is too rigid” easier to examine. Perhaps staff dislike the screen layout. Perhaps they cannot record a required approval. Perhaps the approval exists, but another department never receives it. Those problems justify different responses.
A critical gap has a consequence you can explain: work cannot proceed, staff make decisions without necessary information, or a recurring workaround consumes material effort or introduces an unacceptable error risk. A preference describes how people would like to work. Preferences still matter for adoption, but preserving every familiar step can make any replacement unnecessarily expensive.
Gather enough examples to distinguish the two. Ask staff to show a normal case, a difficult case and the workaround they use today. Record its frequency and consequences where evidence is available. If the claimed problem is repeated data entry, establish which information is copied, why, and what happens when it is wrong.
Turn these examples into a short workflow test that every shortlisted option must pass. State the result, who may authorize it and what must happen when the process fails. A feature list can help find candidates; this test reveals whether they can do the job. An option that fails an essential requirement should not win because it matches more preferences.
Compare all five routes
The routes below can be combined. A business might buy an application, configure its approvals and integrate it with accounting. The important distinction is which capabilities come from a maintained product and which additional responsibilities your organization takes on.
| Route | What you are choosing | What must be demonstrated |
|---|---|---|
| Buy | Adopt a packaged application. You gain existing capabilities while accepting its operating model, commercial terms and product direction. | The available product handles the important scenarios, and migration, training and remaining workarounds are acceptable. |
| Configure | Use supported settings, roles, fields and workflow rules in an existing or new product. The available controls define the limits. | The required behavior works through configuration and someone can maintain those settings as the business changes. |
| Integrate | Connect systems so information or actions pass between them. This preserves useful applications but creates a dependency between them. | Authorized interfaces support the required data and actions, including error handling, operational volume and recovery. |
| Extend | Add a specific capability to a platform through an add-on or custom component. The platform remains central, with extra software to maintain. | The extension closes a defined gap, uses supported extension points and can survive relevant platform changes. |
| Build | Create an application around the required workflow. This gives control over its design while creating responsibility for delivery and continued operation. | The unmet need justifies that responsibility, the scope is coherent, and the business can fund and own the application after launch. |
Inspect existing capabilities before pricing additions. In its Dynamics 365 implementation guidance, Microsoft recommends examining standard processes and configuration before deciding which gaps require customization. It also identifies maintenance and effects on connected processes as considerations for extensions. That is product-specific guidance, but it illustrates the questions to ask of a proposed platform. Read Microsoft’s fit-to-standard and fit-gap guidance.
Allow the process to change
A standard application may require a different sequence of steps. That can be acceptable when the current sequence exists mainly because of an old tool or habit. Preserve the business requirement—such as authorized approval—while allowing a different way to satisfy it.
Conversely, a process tied to a contractual obligation or an essential customer service may deserve stronger protection. Establish why the requirement exists before paying to reproduce it.
Deferring the investment is also a legitimate outcome. If the workflow changes every week, ownership is unresolved or the problem has not been measured, clarify those points first. A controlled manual process can provide useful evidence while avoiding premature software commitments.
Test the uncertainty that could invalidate the choice
A demonstration should concentrate on the difficult dependency. For a replacement product, that might be handling an exception without exporting everything to a spreadsheet. For an integration, it might be whether the source system exposes an approved record at all.
“There is an API” is only a starting point. The interface may provide some records but omit the field or action your workflow requires. Access may depend on permissions, a particular subscription or a separate agreement. Request limits can also affect whether a proposed connection works at your operating volume. Microsoft’s Power Platform documentation, for example, describes request allowances tied to product and licensing conditions. See Microsoft’s request-limit documentation.
Have the proposed supplier verify the required access and behavior before treating integration as a settled part of the solution. Use representative data and a permitted test environment where available. Separate demonstrated capabilities from assumptions that still need investigation.
In a safe test environment, simulate a failed handoff. If the destination is unavailable, who sees the failure? Can someone retry safely without creating a duplicate? If a record changes after transfer, which system holds the authoritative version? These questions reveal whether the business is buying a dependable handoff or inheriting another daily reconciliation task.
Assign responsibility across the whole handoff. Two suppliers can each support their own application while leaving nobody responsible for diagnosing a failure between them. Decide who investigates, who communicates with staff and what work can continue while the problem is resolved.
Compare the cost of keeping the workflow working
A subscription price and a development quote may cover different scopes. Compare complete alternatives over the same planning period, using the same assumptions about users, workload and required service.
Use the same criteria for each proposal. The “Integrate or extend” column below covers additions to useful existing systems; their costs and responsibilities come on top of the underlying products.
| Criterion | Buy or configure | Integrate or extend | Build an application |
|---|---|---|---|
| Workflow fit | Test product capabilities and supported settings. Some process changes may be needed. | Close a defined gap while retaining useful systems. Confirm the addition handles the actual exception. | Design around essential requirements. Validate those requirements before committing to scope. |
| Initial work | Include evaluation, setup, data migration and staff adoption. | Include access checks, mapping or development, testing and failure recovery. | Include discovery, design, development, testing, migration and rollout. |
| Continuing cost | Check licenses, plan limits, administration and remaining manual work. | Add connector or component costs, monitoring and compatibility work to product costs. | Fund hosting, support, security updates and future changes as applicable. |
| Integration limits | Verify what the offered connectors and interfaces actually permit. | Test required data, actions, permissions, limits and safe retries. | Custom code still depends on other systems granting the required access. |
| Change and maintenance | The vendor directs the core product; assign responsibility for configuration and use. | Assign ownership when either the product or the added component changes. | You can prioritize changes, but need the funding and capability to deliver and operate them. |
| Exit and transfer | Check usable exports, contract terms and the effort of moving. | Document mappings, dependencies, access and how the addition can be replaced. | Secure appropriate rights, documentation and operational access; source code alone is insufficient. |
Include acquisition or development, configuration, data preparation, migration, integration and staff training. Then account for the continuing work: licenses, hosting where applicable, support, monitoring, updates, changes to business rules and remaining manual tasks. An inexpensive product can become a costly option if employees must maintain a substantial workaround. A custom application can also be poor value when its ongoing responsibilities are left out of the proposal.
Keep uncertainty visible. Ask which costs are known, which depend on usage and which require further investigation. Compare plausible changes in workload or scope rather than relying on one optimistic forecast. Staff time saved is useful evidence, but it does not automatically become cash savings; explain whether the business expects additional capacity, reduced overtime or another concrete benefit.
Include security, support and exit in that comparison
Buying a product or commissioning custom software does not, by itself, establish how secure or well supported it will be. Examine the actual product, implementation, operating arrangements and evidence. NIST’s Secure Software Development Framework provides practices and a common vocabulary for discussing secure development with suppliers; it is not a guarantee that a particular application is secure. See NIST’s Secure Software Development Framework.
For each alternative, establish who manages access, addresses vulnerabilities, tests recovery and supports operational incidents. Specify the service the business needs, then check whether the proposed arrangements provide it. A product subscription and a custom development contract can leave very different tasks with your own team.
Consider leaving before signing. Can you export usable records, attachments and history from a product? For custom software, will the business have the rights, documentation, deployment access and technical knowledge needed to move support elsewhere? Possessing source code alone does not establish that another team can run the application. Price the work of transition as well as the work of arrival.
A worked comparison: completed jobs reaching finance
Consider a hypothetical commercial maintenance company. Technicians record completed jobs in a job-management application. A coordinator checks any additional charges, and finance then copies approved details into accounting. The owner wants invoices prepared promptly without billing for unapproved work.
The workflow test includes a normal job, a job with extra charges and a correction after approval. In every case, finance must receive the correct approved details with supporting evidence. Repeating a transfer must not create a second invoice.
Suppose a configuration demonstration shows that the current job system already supports a separate approval status and required supporting documents. That finding removes the immediate case for building a new approval application. The remaining question is whether the handoff to finance deserves further investment.
An available connector transfers completed jobs, but its demonstration does not show whether it excludes charges awaiting review. It must pass that test before the owner can rely on it. A more flexible integration remains a candidate only if authorized interfaces expose the approved state and the required accounting actions, and the correction and retry scenarios pass.
A replacement job-management product might handle the full workflow through configuration and a supported accounting connection. It deserves the same demonstration. If it passes, compare its migration, training and subscription implications with improving the current system. The owner should also identify which other useful capabilities would be gained or lost through replacement.
An extension to the current platform would need a separate justification. If configuration already handles approvals, adding custom approval code duplicates a supported capability. It becomes relevant only if testing reveals an essential rule that configuration cannot express and a supported extension can implement.
A standalone custom application would take on still more responsibility. It might be worth evaluating if the workflow spans several systems and contains important rules none of the product options can support. In this example, the demonstrated configuration capability weakens that case substantially.
The provisional choice is to retain the current application, configure approval and investigate the finance integration. Two findings could reverse it. If the interface cannot reliably expose approved information, reject unattended transfer and compare a replacement with a controlled manual handoff. If measured copying effort and error consequences are small, configure approval and defer integration. The owner has a defensible decision without assuming that every manual step needs software.
Commission the work the evidence justifies
Before approving an investment, ask for a recommendation that identifies the workflow, demonstrates the chosen route, explains the alternatives rejected and names the unresolved assumptions. The business should understand both what it will gain and what it will become responsible for.
Where an important gap remains, LegioSoft can map the workflow, check what the systems’ authorized interfaces allow and scope an integration, extension or application justified by those findings. That work sits within our custom software development services.
If you are weighing that decision, tell us which workflow is getting stuck. We can start with the work your business needs to complete and establish what the software must actually do.
