A developer's year-long side project is one experience, not a forecast for every firm. We have removed the recommendation to budget a year of debugging and the use of Hacker News discussion counts as proof of buyer demand or implementation difficulty.
Specify the job before choosing the build route
Our recommendation is to write down the workflow, required connections, data restrictions and acceptance criteria. Identify who will operate it, update its source material and respond when a dependency changes. Ask which requirements can be met with existing software before assuming a custom build is necessary.
Compare feasible alternatives on the same basis
For an internal build, request an estimate with explicit assumptions, dependencies and staff ownership. For a managed implementation, request the same account of responsibilities and continuing work. Include testing, maintenance and exit requirements in both comparisons. A prototype's visible feature does not establish its total operating cost.
Use milestones that produce evidence
Agree a bounded first workflow and a demonstration using representative cases. Separate a successful demo from operational acceptance. Record remaining limitations and decide what must be resolved before broader access is granted.
A proposed acceptance test
For a workflow the firm is considering, write down the permitted task, the identity it runs under and the records it may access. Mark the actions that need a person to approve them. Include a stop condition and an identified staff owner for escalation. These are implementation recommendations, not evidence that the firm currently has a problem.
Test a normal request, an ambiguous request and a request outside the permitted task. Inspect the actual records and logs rather than relying solely on the agent's explanation of what it did. Keep the test and expected result so it can be repeated after changes.
Make the comparison specific
Ask the implementer to show the behavior on the proposed configuration. Distinguish what is enforced by software from what is merely requested in a prompt. Record unresolved limits and decide whether the remaining work and risk are acceptable before expanding access. A demonstration is evidence about that test, not a promise about every future interaction.
Editorial correction: unsupported or unavailable-source claims were revised. Original publication date retained; this correction does not certify every other article in the archive.