000 / Automation

Browser automation at production level

When Playwright scripts become production workflows, the fun starts: parallelisation, crash recovery, auth handling, multi-worker locking. That's what this service is for.

Send inquiry What you get

001 / Deliverables

What you get

Four building blocks that turn a script hack into a production system.

Multi-worker architecture

Three decoupled layers: UI (Streamlit), orchestrator (scheduler + CLI), worker subprocesses. Race-safe via asyncio.Lock round-robin. Multiple workflows run at once without killing each other.

Crash recovery

sys.excepthook as last line of defence. Crash-file bridge between subprocesses, no crash gets lost, even when a worker dies in init. You get a report, not silent death.

Auth without Manifest V2

CDP-based authentication via Fetch.authRequired. No Chrome-extension hack that breaks on every update. Works with basic auth, form auth, token refresh flows.

CI + tests

9 pytest test suites, GitHub Actions on every push. Multi-worker coordination is notoriously hard to test, it's done here anyway.

002 / How it runs

How the framework gets adapted to your use case

01
Discovery

Which workflows, which auth schemas, how much parallelisation. What hurts today. Out of that comes the scope.
02
Worker adaptation

The worker subprocesses get tuned to your workflows. Selectors, wait times, retry logic, phase definitions.
03
Integration + tests

Integrated into your infrastructure (Windows server, Docker, Kubernetes, whichever). Tests for the main paths.
04
Handover

Source with documentation, CI config, operations manual. Plus two hours of live coaching for your ops team.

003 / Price

Adaptation to your use case

€6,500 is the entry for an adaptation with one workflow type, 1–3 worker subprocesses, one auth schema.

More complex setups (multiple workflow types, browser profiles with cookies, IP rotation, CAPTCHA handling) scale accordingly. Fixed price after discovery.

Framework adaptation

from €6,500 net

One workflow, 1–3 workers, one auth schema.

Worker logic adapted to your workflows
Integration into your infrastructure
Test coverage for the main paths
CI config (GitHub Actions or equivalent)
Operations manual + coaching (2 h)

Send inquiry

Reply within 24 h

004 / Reference

What's inside the framework

This isn't a "could-build", the framework exists with ~17,500 lines of Python for a private client.

NDA client Private

17,461 LOC, parallel, fault-tolerant

Streamlit UI, scheduler+CLI orchestrator, worker subprocesses. SQLite with WAL + BEGIN IMMEDIATE for cross-layer IPC. CDP-based auth without Manifest V2. Windows Job Object cleanup. 9 pytest test suites, GitHub Actions CI on every push.

Read the full case study

005 / Frequent questions

What you should know about production-level browser automation

Why not just Selenium or Puppeteer?

For simple scripts, Playwright is enough. For production workloads you need multi-worker coordination, crash recovery and auth handling, none of which are in any library by default and which cost 80 % of the effort.

Does it run on Linux/Docker?

Currently Windows-centric (Job Objects), can be ported to Linux/Docker, that's part of the adaptation.

What if the target site has CAPTCHA?

CAPTCHA handling is its own legal and technical topic. If the site doesn't want you, that's their right. We discuss what's legal and sensible in discovery.

Can multiple workflows run in parallel?

That's exactly what the framework is for. asyncio.Lock round-robin between workers, deduplicated exception hierarchy, IPC via SQLite (WAL).

Who holds the browser-profile data?

Everything stays with you, locally or in your infrastructure. I don't touch it after handover unless a maintenance agreement is in place.

How does the framework stay current with browser updates?

Optional maintenance retainer covers Playwright updates, Chrome updates, CDP changes. Without retainer: I fix on day rate when something breaks.

006 / Related services

Often booked alongside this service:

Custom Apps