The first question in an automation project is not “which framework should we use?” It is whether the process has a stable input, a permitted execution path, measurable value and an owner when something fails. If those conditions are missing, code only makes the uncertainty run faster.
The reasons I reject or pause a project
- The workflow depends on prohibited access: bypassing authentication, access controls, rate limits or platform safeguards is not a sound requirement.
- There is no lawful data basis: collecting personal or confidential information without a defined purpose, retention policy and access controls creates unacceptable risk.
- The economics do not work: maintenance, human review, infrastructure and incident costs exceed the value saved.
- The target changes constantly: an undocumented interface with no fallback can turn the product into permanent emergency maintenance.
- Nobody owns exceptions: automation without an escalation path silently creates bad records, duplicate actions and customer damage.
Technical feasibility is only one gate
I separate discovery into four gates: permission, data, stability and return. Permission covers contracts, platform terms and applicable regulation. Data covers provenance, minimisation, retention and deletion. Stability covers supported APIs, change frequency and recovery. Return compares the full lifecycle cost with the operational benefit.
For public web data, “publicly visible” does not mean “free of obligations.” Scope collection to necessary fields, respect applicable rules and reasonable limits, identify the source and collection time, and retain traceability for corrections or deletion requests. The same discipline appears in this guide to turning public data into sales opportunities.
Redesign options before saying no
A bad initial specification can often become a good system. Replace browser imitation with an official API. Convert full automation into assisted review. Process exports supplied by the customer instead of extracting private screens. Run a small scheduled batch rather than continuous polling. Add approval for irreversible actions and stop automatically when quality falls below a threshold.
The best architecture is frequently a hybrid: deterministic rules handle predictable cases, a person reviews ambiguity, and every decision records its input, version and outcome.
Minimum production controls
Responsible automation needs idempotency keys, bounded retries, rate limits, timeouts, a kill switch and per-job audit records. Credentials belong in a secrets manager, logs must redact sensitive values, and permissions should follow least privilege. Dashboards should report success, rejection, latency and data-quality rates—not just whether a process is alive.
If the workflow uses multiple workers, define queue ownership and recovery explicitly. The principles in designing work queues for mobile bots apply to most distributed automation.
Common mistakes
- selling a guaranteed outcome on an external platform
- treating every visible field as acceptable to collect forever
- estimating only initial development
- hiding unstable selectors behind endless retries
- automating irreversible actions without approval
- sharing credentials across customers or workers
- logging personal data and tokens for convenience
- running a large launch before measuring a representative pilot
Practical go/no-go checklist
- document the business outcome and manual baseline
- confirm permission, terms and applicable data obligations
- prefer supported APIs and customer-provided exports
- list every external dependency and likely change
- calculate build, infrastructure, review and maintenance costs
- define quality thresholds and exception ownership
- add rate limits, timeouts, bounded retries and a kill switch
- store source, timestamp and decision traceability
- pilot with limited volume and reversible actions
- set an explicit condition for stopping the project
When hiring a technical person makes sense
Bring in a senior automation engineer when several platforms, sensitive data, queues or irreversible actions interact; when the provider claims zero risk; or when nobody can estimate maintenance. A short technical discovery can expose a fatal dependency before a large contract is signed. My approach to that phase is explained in how I assess a technical project before coding.
Final takeaway
Saying no is part of engineering. I reject automation that depends on prohibited access, uncontrolled data, fragile economics or invisible failure. If the useful core can be made compliant, traceable and stable, I redesign it and test the smallest version. To assess a real workflow, review my technical services or contact me.