Key takeaways
- Start with the job, users, exceptions, and required controls before shortlisting a builder.
- Spreadsheets and scripts can be the right internal tool when scope is narrow and ownership is explicit.
- Low-code shortens common-path delivery; custom code buys control; a managed agentic approach can lower specification effort while still needing gates and evidence.
- Compare lifecycle cost: changes, failed runs, permissions, tests, observability, and retirement belong in the decision.
- Run a bounded proof with real exceptions and an exit plan before moving consequential work.
Choose a delivery model before a product
An internal tool is the employee-facing artifact around recurring work. A builder is only one way to deliver it. Starting with a feature list encourages teams to reshape the work around a demo before agreeing what correct, safe, and finished mean.
Write one page of requirements first. Name the process owner, daily users, normal path, three real exceptions, highest-consequence action, systems touched, evidence retained, and what users do when it is unavailable. That brief makes platform differences concrete.
- Who can see each record and who can perform each action?
- Which fields and systems are sources of truth?
- Which branches are deterministic, which need judgment, and which require approval?
- How is a duplicate, timeout, missing input, or partial update handled?
- Who detects a dependency change, approves a repair, and tells users?
Five ways to build the same internal tool
| Model | Use it when | Main ownership debt |
|---|---|---|
| Spreadsheet or shared database | The volume is modest, users can inspect the state, and formulas or views cover the stable path | Accidental edits, permission sprawl, weak action history, and logic hidden in cells |
| Script or small service | A narrow deterministic job runs on a schedule or request and the technical owner is explicit | Credentials, monitoring, retries, deployment, and dependency drift |
| Low-code or no-code builder | Forms, tables, permissions, and common integrations fit the process with limited custom logic | Platform limits, complex exceptions, test coverage, export, and cost at scale |
| Custom application | The workflow is differentiating, controls are specific, and the expected life justifies dedicated engineering | Product discovery, delivery queue, security review, operations, and long-term team ownership |
| Managed agentic workflow | Teaching the real process is easier than fully specifying it and some steps need bounded interpretation | Evaluation, authority boundaries, evidence, stopped-failure review, and confirmed repair or relearning |
Use a scorecard that survives the first demo
| Criterion | 0 | 2 |
|---|---|---|
| Real exceptions | Only happy path shown | Three representative exceptions route correctly |
| Authority | Shared broad credential | Per-action least privilege and durable approval where needed |
| Evidence | Result is visible now | Inputs, decisions, actors, effects, and outcome remain inspectable |
| Change | Edit live and hope | Version, test, approve, release, communicate, and roll back |
| Failure | Generic error or silent stop | Detect, contain, reconcile, assign, recover, and learn |
| Exit | No usable export or fallback | Data export, manual path, and retirement steps are tested |
NIST's Secure Software Development Framework is intentionally outcome-focused and includes preparing the organization, protecting software, producing well-secured releases, and responding to residual vulnerabilities. Those duties apply even when a builder hides the implementation details.
Run a proof that includes a bad day
- 01Bring real casesHuman approvalUse two normal runs, two common exceptions, one duplicate, one missing-input case, and one downstream failure.
- 02Build the bounded pathCodeLimit users, data, actions, and integrations to what the proof needs. Do not grant production-wide authority for convenience.
- 03Show the evidenceTriggerTrace input, state, decision, approval, effect, outcome, and failure so another owner can explain the run.
- 04Change one assumptionHuman approvalRename a field, alter a rule, or remove a permission. Observe how the option detects, tests, releases, and communicates the change.
- 05Exercise the exitHuman approvalExport required data, switch to the manual fallback, revoke credentials, and describe retirement.
Limitations and when not to use this
- This is a delivery-model comparison, not a review of current vendors, features, pricing, availability, or security posture.
- A builder can reduce implementation effort without transferring accountability for process policy, permissions, data handling, approvals, or user outcomes.
- High-consequence or regulated tools need qualified security, legal, privacy, financial, employment, or domain review as applicable.
Sources
- The Evolution of Automation at Google — Google Site Reliability Engineering Accessed 14 August 2026
- Secure Software Development Framework 1.1 — NIST Accessed 14 August 2026
Write the minimum requirements
Describe one normal run, two real exceptions, the permissions, the finish state, and the owner before evaluating a delivery model.
Write the minimum requirementsUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.