In this note
The team has a working demo and a request to turn it into a service. Before writing more code, I'd open the application where the work happens today. It may already do enough. Or its missing capability may be exactly the one the demo depends on.
Buying a feature, changing a configuration, connecting two systems, and building a separate service leave different maintenance jobs behind. Compare them on the same work, including its awkward cases. A tick beside AI or integration won't tell you what happens when an order changes while someone is approving it.
We'll compare options for preparing a delivery-date change. This is a hypothetical example: the capabilities below are assumptions, not findings about inspected products. The exercise ends with the specific checks needed before choosing an option.
Give every option the same job
A customer asks support to move a delivery. We want the software to read the order the operator is allowed to see, prepare a proposed date, and show the supporting facts to a reviewer. For now it stops at a checked draft. Changing the order would require a separate approval to build that capability, current permission for the action, and a check of the result in the order system.
The draft needs the order number and version, the requested date, available dates, and any cutoff or hold that prevents the change. The operator can correct it, reject it, or ask the person responsible for the rule. If someone changes the order while the draft waits, the software must flag it as out of date and fetch the current facts before review continues.
For this example, the person responsible for deliveries also requires a saved correction history, someone to handle blocked requests, and a decision record the team can export. In your project, ask the actual owners to agree on these needs first. Don't let the product's feature list decide the requirements for them.
Inspect the smallest existing route first
Open the current order system and its review screen. Can a supported setting show the needed facts, save the order version, and make a blocked request visible? Ask someone to demonstrate a correction and a failed request with permitted test data. Check the installed version, license, settings, access rules, and network. A feature shown in a sales demo may not be available in your setup.
If the screen is usable but cannot collect the facts, consider a small adapter: code that reads the order and prepares the draft for the existing queue. Inspect what the API returns. Getting an order number is not enough if it omits a current hold or amendment. Check that it returns only the fields this user may see.
If the existing options fail a requirement you have checked, investigate a separate service. That may mean buying another product or building custom code. Give both the same source-access, review, support, and exit tests; a purchased feature still has to work with your order system. Owning custom code won't give anyone spare maintenance time or permission to change delivery policy either.
Keep failed requirements and unknowns visible
| Delivery route | What this example assumes, and what to check next |
|---|---|
| Existing native draft feature | It suggests a date but cannot save the order version with the draft. Reject it for this job: the reviewer cannot tell whether the draft is out of date. |
| Supported configuration of the current review screen | It can display and save the needed facts, but cannot fetch the current order. Investigate how those facts would reach the screen. |
| Narrow adapter into the configured review screen | We don't know whether the API returns the current version or enforces field access. Check those two things before recommending or fully estimating the adapter. |
| Separate custom draft service | The design includes version checks, but nobody has time reserved to support it and its export path is undefined. Keep it blocked until access, tests, support, and exit are settled. |
| Retained manual path | Assume the owner permits today's manual review with its existing checks. Keep it running during the investigation. Measure its time and errors before claiming an improvement. |
The first option fails a required check. The adapter has two unanswered questions. Treat those differently: reject the known failure for this job, and investigate the unknowns. Don't give an unknown a generous score because the price or interface looks good. If a later product version saves order revisions, you can reconsider it.
For this example, inspect the adapter's order-version and access behavior next, while retaining manual review. We have selected the next test, not a supplier. If it fails, try a narrower read-only job, another approved interface, custom work, or deferral. Giving the automation broader access would change the proposal and require its own decision.
Price the maintenance you will own
Estimate the remaining options over the same period. Include setup, licenses, connections, data preparation, testing, review, support, repairs, upgrades, and eventual shutdown. Keep upfront payments separate from recurring costs and accounting allocations. If an API uncertainty prevents an estimate, leave that cost unknown and assign the investigation instead of guessing a total.
Ask who fixes each likely break. The order-system team may maintain the API but not your adapter. A vendor may maintain the feature while your team owns settings, access, tests, and failed requests. A consultant may leave after building it. Put a name and reserved time against each remaining job.
Check how the team would leave the product or replace the service. Can it export pending requests, source references, decisions, corrections, and settings in a usable, approved format? Who retains access to needed records, removes old credentials, and finishes the remaining work? Test whether the replacement can use the export and reconcile the records before cutting over. A download button is only a start.
We cannot rank these options by full cost yet. Ask the order-system owner what the API can return, whoever manages the purchase for license and supplier costs, the service owner for reserved support time, and the delivery team for implementation effort. Measure the current manual work too. One engineer cannot supply all those answers.
Test the case that could disqualify the option
To test the adapter, prepare a draft with permitted test data, then amend the order. The screen should mark the draft out of date and require fresh facts before review continues. Also test a user who cannot see that order. Restricted fields must stay out of the draft, model request, error message, and ordinary logs. An unchanged order shown to an authorized user tests neither failure.
Then try a source outage, a conflicting cutoff, a correction, and an interruption with a request still pending. Check where the request is saved, who gets the alert, and how the operator resumes or falls back to manual work. These tests are proposed, not run. Save the actual product, settings, adapter, source versions, and test identities alongside their results.
Prefer a documented API when it supplies the needed facts under the organization's rules. If a later action is available only through a browser screen, assess that separately. It needs permission for that action, current screen checks, handling for interface changes, and independent confirmation of the result. The draft-only example does not authorize a browser agent to change orders.
Write down why you chose the next step
Keep the rejected options and the reasons. Record unanswered questions, who will check them, and what could change the choice. Later, a new product feature or higher maintenance bill may justify a different answer.
Here, ask the order-system owner to check whether the API returns the current version and the permitted fields. Ask the service owner to settle support time and export needs. Agree where they will record their findings and when you will review them. Keep manual review in place until those answers support a choice; automatic order changes remain outside this job.