Christopher Rosil

I write Actors for public web data. Mostly extraction and change monitoring: pricing pages, changelogs, status pages, listings, structured fields off arbitrary URLs.

A few things I try to get right.

Cost. Plenty of Actors default to a headless browser and 4 GB of RAM because that's what the template hands you. I start with plain HTTP and a parser, and only reach for a browser when the target genuinely needs one. Memory defaults sit at 512 MB or under. There's no reason to pay browser prices to read a static page.

Limits, stated up front. Every README says what the Actor can't handle. If a site ships an empty shell without JS, or sits behind a login, that's documented before you spend anything.

Built to run on a schedule. Named key-value stores so state survives between runs, a baseline pass on the first run, idempotent charging so a retry doesn't double-bill you.

Output that doesn't move. Field names stay put. If I have to break one, I'll say so in advance.

Maintenance: smoke tests run against live targets on a schedule. Sites change their markup and things break, that's ordinary. The failure I actually work to avoid is an Actor that returns zero rows and exits clean.

If something's broken, or you need a field I left out, open an issue on the Actor. I answer inside a business day. Several of these started as someone asking for a variant of an existing one, so it's worth asking.

Argentina, UTC−3. Open to custom Actor work.