AX/G/001

How to pick an automation vendor: 8 questions

Concrete questions that separate a real engineering studio from no-code "automation experts".

The automation market in 2026 is crowded — no-code "consultants", marketing agencies with "AI" tacked on, freelancers with 6 months of Make.com in their portfolio. They all say the same thing on the first call. These 8 questions show fast who understands engineering and who is selling promises.

Ask at the end of the discovery call, not the beginning. After normal conversation you see the reaction — who improvises, who has the answer ready.

What will break in 6 months?

Every scraper stops working. The question is when. Layout changes, anti-bot updates, API rate-limits shift, certificates expire. A good vendor answers concretely — "we monitor target changes, parser updates are included in the retainer, average 3-5 fixes a year per pipeline". A bad vendor says "ours does not break". Run.

Show me the runbook for the last 3 incidents.

Every production system has incidents. A professional vendor keeps post-mortem docs — what happened, how we fixed it, what we changed to prevent recurrence. Does not have to be public, but should exist. If there is none — the pipeline has no observability, meaning the problem is visible from client complaints, not earlier.

What happens if a target changes layout at 3 AM on a Saturday?

A real situation. Trying to answer reveals the operational process. Good answers: Slack/PagerDuty alerts, on-call rotation, response time SLA (typically 4-24h for mid-tier, less for enterprise), dead-letter queue so backlog runs after the fix. Bad answers: "we will check in the morning", "the client will tell us".

Who owns the code after the project ends?

Should be clear: code transfers to client ownership upon full payment. Internal libraries/frameworks of the vendor stay theirs — but the client gets a perpetual licence to use them within the project. Any other construction (e.g. "the code is ours but you can use it") is vendor lock-in. Ask before signing.

What are your response and fix SLAs?

These two SLAs are different. Response time = from report to "we know about the problem, acting on it". Fix time = from report to working solution. Typical values for a 24/7 pipeline: response <1h, fix for critical <4h, for high priority <24h. If a vendor has no SLA at all — the pipeline is not production-grade.

Show the audit trail for a randomly picked day.

Every production scraper should have: timestamps of all requests, status (success/retry/dead-letter), parsing errors, sources, normalized output. Without an audit trail you do not know if yesterday's "247 SKUs" were really all of them or if 30% dropped silently. Ask for a screenshot of the observability dashboard. If there is none — the pipeline is blind.

What is your stack and why?

The stack reveals competence. Production-grade browser automation in 2026: Playwright (preferred) or Puppeteer, Temporal or a custom orchestrator for retry/scheduling, Zod or Pydantic at the boundary, Postgres or MongoDB for state, OpenTelemetry for observability. If someone uses only Make.com / Zapier / n8n — fine for small one-offs but not for a pipeline that must run 2 years.

How many active retainers do you have past 6 months?

A checking question. Clients stay on retainer when: system works, vendor answers questions, fixes are included. Clients leave when: system breaks, vendor disappears after build, fixes are extra-billable. A vendor with 0 retainers >6 months = build-and-disappear. A vendor with 5+ retainers >1 year = does production work. Important for automation that should live for years.

Bonus: what do failures look like?

Not from the list but valuable. "Tell me about a project that did not work" — who improvises invents "we have not had any". Who understands engineering: "client X wanted scraping of a service with aggressive anti-bot, we estimated 60% accuracy, ended up at 38% and the client withdrew. We added to internal docs that for similar targets we now recommend a 3× higher proxy budget or advise against the project".

The point

These 8 questions do not require technical knowledge — they require attention to the answers. Concreteness, runbook references, SLA values, transparent failure modes = engineering signal. Vagueness, "ours does not break", "the client will report" = sales signal. Pick the first category, automation should run for years.

Hitting a similar problem?

Most of these techniques we ship to production.

If this article resonates with something you are trying to solve — write. Initial project assessment is free.