Rynek automatyzacji w Polsce w 2026 jest pełen — no-code "konsultantów", marketing agencji z dopisanym "AI", freelancerów z 6-miesięcznym Make.com w portfolio. Wszyscy mówią to samo na pierwszej rozmowie. Te 8 pytań szybko pokazuje, kto rozumie inżynierię, a kto sprzedaje obietnice.
Zadawaj je na koniec dyskovery callu, nie na początku. Po normalnej rozmowie widzisz reakcję — kto improwizuje, kto ma odpowiedź gotową.
Co się popsuje za 6 miesięcy?
Każdy scraper przestaje działać. Pytanie kiedy. Strona zmieni layout, anti-bot się zaktualizuje, API rate-limit się zmieni, certyfikat wygaśnie. Dobry dostawca odpowiada konkretnie — "monitorujemy zmiany targetów, parser updates są wliczone w retainer, średnio 3-5 fixów rocznie per pipeline". Zły dostawca odpowiada że "u nas się nie psuje". Uciekaj.
Pokażcie mi runbook na 3 ostatnie incydenty.
Każdy production system ma incydenty. Profesjonalny dostawca prowadzi post-mortem dokumentację — co się stało, jak naprawiliśmy, co zmieniliśmy żeby się nie powtórzyło. Nie musi to być publiczne, ale powinno istnieć. Jeśli nie ma — pipeline nie ma observability, czyli problem widać po reklamacji klienta, nie wcześniej.
Co zrobicie, gdy target zmieni layout o 3 nad ranem w sobotę?
To realna sytuacja. Próba odpowiedzi pokazuje proces operacyjny. Dobre odpowiedzi: alerty na Slack/PagerDuty, on-call rotation, SLA na response time (typowo 4-24h dla mid-tier, mniej dla enterprise), dead-letter queue żeby zaległe operacje wykonały się po fixie. Złe odpowiedzi: "rano sprawdzimy", "klient nam zgłosi".
Komu należy się kod po zakończeniu projektu?
Powinno być jasne: kod transferowany na własność klienta po pełnej zapłacie. Wewnętrzne biblioteki/frameworki dostawcy zostają jego — ale klient dostaje wieczystą licencję wykorzystania ich w ramach projektu. Każda inna konstrukcja (np. "kod jest nasz, ale możesz go używać") to vendor lock-in. Pytaj o to przed podpisaniem.
Jakie macie SLA na czas reakcji, a jakie na fix?
Te dwa SLA są różne. Response time = od zgłoszenia do "wiemy o problemie, działamy". Fix time = od zgłoszenia do działającego rozwiązania. Typowe wartości dla pipeline'u 24/7: response <1h, fix dla critical <4h, dla high priority <24h. Jeśli dostawca nie ma żadnego SLA — pipeline nie jest production-grade.
Pokażcie audit trail dla losowo wybranego dnia.
Każdy production scraper powinien mieć: timestamps wszystkich requestów, status (success/retry/dead-letter), parsing errors, sources, normalized output. Bez audit trail nie wiesz, czy wczorajsze "247 SKU" to były naprawdę wszystkie, czy 30% dropowało po cichu. Pytaj o screenshot dashboardu obserwacji. Jeśli go nie ma — pipeline jest ślepy.
Jaki jest stack i dlaczego ten?
Stack pokazuje kompetencje. Browser automation production-grade w 2026: Playwright (preferowany) lub Puppeteer, Temporal lub własny orchestrator dla retry/scheduling, Zod lub Pydantic na boundary, Postgres lub MongoDB dla state, OpenTelemetry dla observability. Jeśli ktoś używa tylko Make.com / Zapier / n8n — to OK dla małych one-off, ale nie dla pipeline'u który musi działać 2 lata.
Ile macie aktywnych retainerów po 6+ miesiącach?
Pytanie sprawdzające. Klienci zostają na retainerze gdy: system działa, dostawca odpowiada na pytania, fixy są w cenie. Klienci odchodzą gdy: system się sypie, dostawca znika po build'cie, fixy są extra-billable. Dostawca który ma 0 retainerów >6 mies = robi tylko build'y i znika. Dostawca który ma 5+ retainerów >1 rok = robi production. Ważne dla automatyzacji która ma żyć latami.
Bonus: jak wyglądają porażki?
Nie pytanie z listy, ale wartościowe. "Opowiedzcie o projekcie który nie wyszedł" — kto improwizuje wymyśla "nie mieliśmy takich". Kto rozumie inżynierię: "klient X chciał scrape'u serwisu z agresywnym anti-bot, oszacowaliśmy 60% accuracy, finalnie wyszło 38% i klient zrezygnował. Wpisaliśmy do internal docs że dla podobnych targetów teraz rekomendujemy proxy budget 3× wyższy lub odradzamy projekt".
Sedno
Te 8 pytań nie wymaga wiedzy technicznej — wymaga uważności na odpowiedzi. Konkretność, runbook references, SLA values, transparent failure mode = sygnał inżynierski. Vagueness, "u nas się nie psuje", "klient zgłosi" = sygnał sprzedażowy. Wybierz pierwszą kategorię, automatyzacja ma działać latami.