Back to projectsCase study · InzerPro, own product

Sellers re-posted dozens of ads by hand. Every morning.

On Czech and Slovak second-hand marketplaces, listing age decides visibility. InzerPro writes the listing once and posts, re-posts and deletes it across every marketplace on schedule, unattended.

For
Marketplace power sellers
Role
Solo founder, design to production
Status
Live at inzerpro.cz, paying customers
www.inzerpro.cz
The production dashboard: one listing, posted and re-posted across marketplaces on schedule.
4marketplaces fully automated
~165categories, one picker for all
24/7unattended scheduled posting
1person, design to on-call
01 / Problem

New listings sit on top. Old ones sink.

Resellers, small e-shops and car dealers were deleting and re-posting dozens of ads by hand every day, and competitors still buried them overnight. The marketplaces sell paid promotion but give small sellers no automation at all: none of them has a public API.

Integration surface, no public API anywhere
Bazos CZ + SKBazar.czBazar.sk
Bazos CZ + SK: undocumented mobile API, datacenter IPs blockedBazar.cz: ASP.NET VIEWSTATE form replayBazar.sk: Azet OAuth sessionAukro: sandbox, beta
Before: delete and re-post every ad by hand, marketplace by marketplace
02 / Product

Write the listing once. The system does the rest.

A seller writes a listing once, picks marketplaces, and InzerPro posts, re-posts on schedule and deletes across all of them. One canonical category picker (about 165 categories) resolves to the right category on every marketplace through a database crosswalk; photos are re-encoded per platform to fit each site's rules.

Every feature is free up to 10 active listings, then one plan, 19 EUR / 479 Kč per month, for unlimited listings. The limit is enforced in the app and by a Postgres trigger, so it holds even if the client misbehaves.

03 / System

The pipeline behind one scheduled re-post

A React dashboard on Supabase (auth, Postgres with row-level security on all 41 tables, 34 edge functions) runs post, relist and delete as scheduled jobs per user. All marketplace traffic goes through a small Node relay with a residential proxy, because Bazos blocks datacenter IPs outright, including the ones edge functions run from. Each marketplace is its own reverse-engineered integration: replaying the real HTTP flows proved far more reliable than driving a browser.

The path of one listing
  1. 01Listingwritten once in the dashboard
  2. 02Schedulepost, relist, delete jobs per user
  3. 03CategoriesDB crosswalk, ~165 canonical
  4. 04Photosre-encoded per platform
  5. 05Relayresidential proxy, Node
  6. 06Marketplacereverse-engineered API per site
  7. 07Liveon every selected marketplace
Watchdog loop:An hourly canary probes the relay, the proxy exit country, credentials and image acceptance, and emails only on state transitions: one mail when something breaks, one when it recovers. A nightly Playwright suite posts real listings with real credentials against the live marketplaces.
StackReactSupabasePostgres + RLSDeno edge functionsNode relayRailwayStripePostHogSentryPlaywright
04 / Decisions

Decisions that kept it running

Marketplace access
PuppeteerHTTP replay
how listings reach Bazar.cz

Replay the form, not the browser.

Browser automation was the first approach and it flaked; replaying the ASP.NET form flow directly proved far more reliable. The cost: every marketplace is its own integration project with its own failure modes.

Alerting
every failuretransitions
when the canary sends email

One mail when it breaks. One when it recovers.

A check that fails for six hours sends one email, not six. Alert fatigue is a real risk when one person is the whole on-call rotation.

Pricing
3 tiers1 plan
billing model

Charge for volume, not features.

The credit-based tier model confused users. Now everything is free to 10 active listings, then 19 EUR / 479 Kč for unlimited: simple to explain, and enforced in Postgres, not just the UI.

Each of these replaced a version that was already built and worked worse.

05 / Operations

It runs while nobody watches.

The system is built to run unattended and to tell one person that something broke before a customer does: scheduled jobs, an hourly canary, Sentry on every function, and a nightly end-to-end suite against the real marketplaces.

The screens shown here are illustrative mockups with invented example data; the real dashboards live behind the app login.

www.inzerpro.cz/app/jobs
Scheduled jobsTodayAll marketplaces
IDActionMarketplaceListingTimeStatus
9312relistBazos.cziPhone 13, 128 GB06:00done
9311relistBazos.skiPhone 13, 128 GB06:00done
9310postBazar.czSkoda Octavia III 2.0 TDI05:45done
9309relistBazar.skDetsky bicykel 16"05:30retrying
9308deleteBazos.czHerna konzole PS5 (sold)05:15done
9307relistBazos.skSedaci souprava, rohova05:00done

Scheduled jobs

Every post, relist and delete is a job with per-marketplace status and retries; the queue is the product.

posting canary · hourly
Posting canaryall green
CheckDetailStatus
Relay reachablePOST /health via residential proxypass
Proxy exit countryCZ (required for Bazos)pass
Credentials valid4 of 4 marketplace loginspass
Image acceptancetest upload passed pixel deduppass

Posting canary

Hourly probe of relay health, proxy exit country, credentials and image acceptance, alerting on transitions only.

Post, relist and delete are verified green across all enabled marketplaces after every change.

Accepting new projects

Have a process a computer should own?

InzerPro is my own product: a manual daily workflow automated end to end, running in production with paying customers. If your team burns hours on work like this, I build the system that takes it over and the monitoring that proves it keeps working.

A workflow that runs itself, with the monitoring to prove it.