Skip to content
sayak.webdesignerWeb · Software · Data · AI
Data & AI · Data & AI

Data collection at scale, engineered to keep working

A scraper is easy to write and hard to keep alive. Ours run for years across thousands of sources because we treat extraction as a monitored production system, not a script.

web scraping company indiaplaywright automation developers kolkataselenium automation services west bengallarge scale data extraction india
FrontierURL queue · priorityHEADLESS BROWSER FARM — 240 concurrentProxy MeshIN · residentialSG · datacenterDE · mobileUS · residentialPolitenessrobots · rate · backoffAnti-bot logicfingerprint rotationParseschema mapValidatepydanticStoreS3 + Postgres12M pages / week99.1% parse yield
12M
Pages per week at peak
99.1%
Parse yield
240
Concurrent browser sessions
<2h
Median time to repair a breakage
The short version

Web data underpins a surprising amount of commercial decision-making: competitor pricing, marketplace assortment, tender notices, regulatory filings, commodity quotes, availability and lead times, sentiment, and hiring signals. The information is public, but collecting it reliably at scale is genuinely difficult, and most in-house attempts stall at the point where the scraper works on a laptop and fails in production.

We build and operate collection systems as production infrastructure. That means a scheduler with a frontier of URLs prioritised by value and freshness, a pool of browser workers with realistic behaviour, proxy management across geographies, politeness controls that respect the target, parsing that fails loudly rather than silently returning empty fields, and monitoring that tells us within hours when a site has changed its markup.

We are also explicit about the boundaries. We scrape publicly accessible information. We respect robots directives and rate limits. We do not bypass authentication we have no right to, we do not defeat paywalls, we do not collect personal data without a lawful basis, and we will decline work that appears designed to harm the target. This is partly ethics and substantially self-interest: our clients depend on these systems continuing to run, and aggressive collection gets blocked, litigated, or both.

The same engineering also powers browser automation for internal workflows — filling portals, downloading statements, submitting returns, reconciling accounts — where the browser is the only available interface to a system your business depends on.

The architecture of a collection system that survives

The frontier is the heart of it: a queue of URLs with priority, next-fetch time and retry state. Priority is driven by business value and volatility — a competitor's price on a fast-moving SKU is refetched hourly; a company profile page monthly. This is what allows a system to scale to millions of pages without simply crawling everything constantly.

Workers pull from the frontier and fetch. For static content that is a plain HTTP request, which is an order of magnitude cheaper than a browser and should always be preferred where it works. For JavaScript-rendered pages we use headless Chromium through Playwright, in a pool sized to the target's tolerance rather than our capacity.

Parsing is deliberately strict. Every field has an expected type and a validation rule, and a page that yields a null where a value is expected raises a parse failure rather than storing a blank. This is the single most important design choice, because the failure mode that destroys a dataset is not the scraper crashing — it is the scraper quietly returning empty results for three weeks after a layout change.

Storage keeps the raw HTML alongside the parsed record. When a parser is later found to be wrong, or a new field becomes interesting, history can be reprocessed rather than recollected — which is both faster and far more polite to the source.

FrontierURL queue · priorityHEADLESS BROWSER FARM — 240 concurrentProxy MeshIN · residentialSG · datacenterDE · mobileUS · residentialPolitenessrobots · rate · backoffAnti-bot logicfingerprint rotationParseschema mapValidatepydanticStoreS3 + Postgres12M pages / week99.1% parse yield
Frontier, browser farm, proxy mesh, politeness controls and a strict parse-validate-store path.

Politeness, proxies and staying welcome

A collection system that hammers a target will be blocked, and it deserves to be. We configure per-domain concurrency and delay based on the target's size and observed response behaviour, back off automatically when latency rises or errors increase, honour robots directives and crawl-delay, and identify ourselves honestly in the user agent with a contact address where the client is comfortable with that.

Proxies are used to distribute load and to access geographically varied content — a marketplace shows different pricing and availability in different regions, and collecting that legitimately requires exit points in those regions. We manage residential, datacentre and mobile pools with health monitoring and automatic rotation away from degraded exits.

What we do not do is treat proxy rotation as a way to evade a target's explicit refusal. If a site has clearly signalled that it does not want automated access, the correct response is to stop and, where a commercial relationship is plausible, to ask about an API or a data licence. Several of our clients now receive data by agreement rather than collection, which is cheaper and more reliable for everyone.

In practice

Per-domain concurrency and delay tuned to the target, not to our capacity.
Automatic backoff on rising latency or error rate.
robots.txt and crawl-delay honoured; sitemap-driven discovery preferred where offered.
Geographic proxy pools with health monitoring and rotation.
Raw HTML retained so history can be reparsed without recollection.

Every engagement starts with a conversation, not a proposal template.

Thirty minutes with a senior engineer. You leave with an architecture sketch and an honest cost range, whether or not you hire us.

Book that call

Detecting breakage before your dashboard does

Every collection system breaks, because websites change. The question is only how quickly you find out. We monitor extraction health continuously: parse success rate per source, field-level fill rate, distribution shift in values, page-size anomalies and response-code patterns. A source whose price field fill rate drops from 99% to 40% triggers an alert within the hour, long before anyone notices a gap in a report.

Repairs are usually small — a selector change, a new page variant, an added consent overlay. Our median time from alert to fix is under two hours during working hours, and our maintenance agreements commit to it. Across a large estate we typically see a given source require attention two to four times a year.

We also version parsers, so a repair can be applied retroactively to raw HTML captured during the broken window. In most cases a breakage produces no permanent gap in the dataset at all.

Fill-rate monitoring is the whole game

Almost every catastrophic scraping failure we have been called in to fix had the same shape: the system kept running, kept reporting success, and quietly returned nulls for weeks. Monitoring per-field fill rate against a historical baseline catches this within hours.

What clients actually use this for

Competitive pricing and assortment monitoring across marketplaces and brand sites, feeding a pricing team or an automated repricing rule. This is the most common request and the one with the clearest return.

Tender and notice monitoring across government and PSU portals — a niche with enormous value for engineering and construction firms, where missing a notice means missing a quarter. We monitor dozens of portals and deliver structured, deduplicated notices with attachments the same morning.

Commodity and input price collection for manufacturers whose costing depends on volatile inputs, joined into the same warehouse as production data so margin impact is visible immediately.

Regulatory and filing monitoring — company filings, licence registers, compliance databases — for financial services and diligence use.

And browser automation of internal processes: downloading bank statements for reconciliation, filing returns on portals with no API, checking status across supplier systems, and any workflow where the browser is the only interface available.

Use caseTypical scaleRefreshDelivered as
Marketplace price monitoring80k–2M SKUsHourly to dailyWarehouse tables + alerting
Tender and notice tracking40–120 portals2–4× dailyStructured feed + email digest
Commodity price collection200–800 seriesDailyTime series into the warehouse
Regulatory filings10k–500k entitiesWeeklyDocuments + extracted fields
Internal portal automation5–200 sessions/dayOn scheduleFiles into your systems

Legality and the questions your legal team will ask

We are not lawyers and we do not give legal advice, but we have had this conversation many times and can tell you where the questions usually land. Publicly accessible factual data collected without circumventing access controls, at a rate that does not burden the target, is the least contentious position. Personal data brings India's Digital Personal Data Protection Act into scope regardless of public availability. Content that is copyrightable — articles, images, substantial text — raises different questions from facts like prices and availability. And a site's terms of use may create contractual obligations, particularly where access required accepting them.

What we do operationally: document the basis for each source, keep collection within stated limits, avoid personal data unless the client has established a lawful basis, retain raw evidence of what was collected and when, and stop immediately on a request from a target. Where a source looks contentious we say so before building rather than after.

We had two people checking tender portals every morning and we still missed things. Now we get a structured digest at 7 AM with attachments, and we have not missed a notice in fourteen months.
S. BhattacharyaBusiness Development Head, EPC contractor, Kolkata

Delivery and integration

Collected data is only useful where your people already work. We deliver into your warehouse as modelled tables, into an API your applications call, as scheduled files to S3 or SFTP, into a dashboard, or as an alert on email, Slack or WhatsApp when a threshold is crossed — usually several of these at once.

Because our data engineering and scraping practices are the same team, collected data lands in the same lakehouse as your ERP and plant data, with the same quality gates and lineage. That is where the compounding value is: a competitor price series is interesting; a competitor price series joined to your own cost per tonne and margin by SKU is a pricing decision.

Every engagement starts with a conversation, not a proposal template.

Thirty minutes with a senior engineer. You leave with an architecture sketch and an honest cost range, whether or not you hire us.

Book that call
Capabilities

What is actually included in web scraping & browser automation

Each of these is something we have shipped and still support in production — not a list of things we could do if asked.

01

Large-scale crawling

Prioritised frontier, distributed workers, and millions of pages a week with polite pacing.

02

Browser automation

Playwright and Selenium for JavaScript-heavy sites, multi-step flows and authenticated internal portals.

03

Proxy and geography

Residential, datacentre and mobile pools with health monitoring and region-specific collection.

04

Structured extraction

Strict parsing with typed fields, validation, and failure rather than silent nulls.

05

Health monitoring

Per-field fill rates, distribution shift detection and alerting within the hour.

06

Document collection

PDF and attachment retrieval with text extraction and field parsing.

07

Internal process automation

Portal filing, statement download, status checks and reconciliation where no API exists.

08

Warehouse delivery

Collected data modelled and landed alongside your operational data with lineage.

Technology

The stack we actually use for this

Chosen for what your team can maintain in three years, not for what looks impressive in a proposal.

Collection

  • Python
  • Playwright
  • Selenium
  • Scrapy
  • httpx
  • Puppeteer

Scale

  • Kubernetes
  • Celery
  • Redis
  • Kafka
  • Docker

Parsing

  • lxml
  • BeautifulSoup
  • Pydantic
  • PDFPlumber
  • Tesseract OCR

Delivery

  • S3
  • PostgreSQL
  • Snowflake
  • BigQuery
  • REST APIs
  • SFTP
How it runs

From first conversation to something in production

Two-week slices, a demo you can share every alternate Friday, and no phase where you are waiting without seeing progress.

011

Source feasibility

What is available, what it costs to collect politely, and whether there is a legitimate concern.

022

Schema design

The fields you actually need, with types, validation rules and expected fill rates.

033

Pilot collection

A small slice run for a week to establish real yield, latency and breakage risk.

044

Scale-out

Frontier, worker pool, proxy configuration and politeness tuned to observed behaviour.

055

Monitoring

Fill-rate baselines, anomaly detection and alert routing established before full volume.

066

Operate

Continuous running with repair SLAs and periodic review of source value versus cost.

What you receive

Everything hands over. No lock-in, ever.

Source code in your Git organisation, infrastructure in your cloud account, domains in your name and documentation written for the next team rather than for us. If you part ways with us in year three, a competent engineer should be able to take over in a fortnight.

Deliverables checklist

  • Collection system deployed in your infrastructure or ours
  • Documented schema per source with validation rules
  • Health monitoring dashboard with fill-rate baselines
  • Raw archive enabling historical reprocessing
  • Delivery into your warehouse, API or file drop
  • Source register documenting basis and limits for each target
  • Repair SLA and runbook
Indicative investment

What this typically costs

Real ranges from real projects. The variable is almost always scope and integration count — the calculator will get you closer in two minutes.

Single source

₹45,000 – ₹1,20,000

One site, structured extraction, delivered on schedule.

  • Feasibility check
  • Schema design
  • Collection and parsing
  • Monitoring
  • Delivery integration
Get a fixed quote
Most chosen

Collection programme

₹3,50,000 – ₹14,00,000

Dozens of sources feeding a warehouse.

  • Frontier and worker infrastructure
  • Proxy management
  • Multi-source parsing
  • Warehouse modelling
  • Alerting
Get a fixed quote

Managed collection

₹1,40,000 / month upwards

Ongoing operation with repair commitments.

  • Continuous running
  • Repair SLA
  • New source addition
  • Cost and value review
  • Compliance register upkeep
Get a fixed quote

All figures exclude GST. Fixed-price options available on defined scope. Build your own estimate →

Straight answers

The questions clients actually ask

Including the ones where the honest answer is that you may not need us. If your question is not here, call +91 70033 91355 — you will speak to an engineer, not a call handler.

There is no blanket answer and we are not lawyers, but the practical position is that collecting publicly accessible factual information without circumventing access controls, at a polite rate, is the least contentious activity. Risk rises with personal data, which brings the DPDP Act into scope; with copyrightable content rather than facts; and where a site's terms of use were accepted to gain access. We document the basis for every source, stay within stated limits, and will tell you before building if a target looks contentious. For anything sensitive we recommend your counsel reviews the specific source list.

Our monitoring detects it, usually within an hour, through per-field fill-rate anomalies rather than waiting for a crash. Median repair is under two hours in working hours and is covered by maintenance agreements. Because we retain raw HTML, the repaired parser can be applied retroactively to the broken window — so in most cases there is no permanent gap in your data at all.

With your credentials and your right to access, yes — for example your own supplier portals, your own marketplace seller accounts, or a subscription your company legitimately holds. We will not bypass authentication we have no right to, defeat paywalls, or use credentials the client is not entitled to share. Where a subscription's terms prohibit automated access we will tell you rather than proceed quietly.

Mostly by not triggering them. Polite pacing, realistic browser behaviour, sensible session handling and geographically appropriate exits avoid the great majority of challenges. Where a site deploys aggressive anti-bot measures, we read that as a signal about their intent, and our recommendation is usually to approach them for an API or a data agreement rather than escalate. Several clients now buy data by arrangement, which is cheaper and far more stable than fighting.

Yes. We deploy on your Kubernetes cluster or cloud account so that data never leaves your environment, which matters for clients with strict data policies. We provide the code, the deployment manifests and the runbooks, and can either operate it for you or hand it to your team.

Our current peak across one client estate is around twelve million pages a week with two hundred and forty concurrent browser sessions, and the architecture scales horizontally beyond that. The practical limit is almost never our capacity — it is what the target sites can tolerate politely, which is the constraint we design to. If a requirement genuinely needs more aggression than a target will accept, we will say the requirement is not achievable responsibly.

Kolkata & West Bengal

Why being local to you matters here

Kolkata firms bidding on government and PSU tenders across eastern India face a specific, unglamorous problem: notices are spread across dozens of portals with no common format and short response windows. Automated monitoring is one of the highest-return systems we build here, and it is almost entirely absent from the local market.

For web scraping and browser automation services in Kolkata, call +91 70033 91355 or WhatsApp us. Send a list of target sources and we will assess feasibility and any concerns within a few days.

KolkataSalt Lake Sector VHowrahNew TownDurgapurAsansolSiliguriHaldia
SEALDAH · KOLKATA · WEST BENGAL
Next step

Tell us what is slowing your business down.

A 30-minute call with a senior engineer — not a salesperson. You leave with an architecture sketch and an honest cost range, whether or not you hire us.

Direct line

+91 70033 91355

Mon–Sat · 9:30 AM – 7:30 PM IST · Sealdah, Kolkata

Reply within one working hour NDA signed before any brief Fixed-price option on every scope
Verify us independently

Don’t take our word for it — ask an AI

Every page on this site is written to be read and quoted by AI answer engines, and we publish llms.txt and llms-full.txt so they can read us properly. One click opens the assistant with the question already typed.

The question we will ask for you

Tell me about the Web Scraping Automation service from Sayak Web Designer (sayakwebdesigner.in), an IT company in Kolkata, India — what is included, how it works, and what it costs.

Opens in a new tab. We do not see your conversation.

Call now WhatsApp Get quote