Resources
Practical notes on turning public business data into work.
Short guides on the ideas ZovaStore is built on — clean pipelines, reliable jobs, traceable data and honest usage.
Guide
From business discovery to a usable lead
A raw search result is not a lead. It is a name, maybe an address, and a source. It becomes useful only after it passes through a few deliberate steps: normalisation (consistent formats for names, phones, URLs and emails), enrichment (reading the business's own public website for contact details and services), validation (dropping what is malformed) and deduplication (making sure one business stays one record).
The mistake most lead tools make is throwing the intermediate data away. Keep the raw record and the cleaned record logically separate, and keep the link between them. When a phone number looks wrong six months later, you can see which source it came from and when it was collected instead of guessing.
Checklist
- Normalise before you compare — otherwise "www.site.in/" and "https://site.in" look like two businesses.
- Score only on signals you can show: website, email, phone, social presence, completeness.
- Hand the lead to the CRM only after it is clean.
Workflow
Designing lead jobs that survive slow websites
Public websites are slow, flaky and occasionally down. A discovery or crawling run that lives inside a single browser request will time out, and the user loses everything. The fix is to treat every long operation as a job: create it, queue it, and let a server-side worker process it in small batches.
Each batch saves its results before the next one starts, so a failure at item 180 of 200 costs one retry, not the whole run. Failed items get a bounded number of retries with a growing delay, and the job records its progress so the interface can show it — and so the user can close the tab and come back later.
Checklist
- Estimate the credit cost before the job is queued.
- Save partial results after every batch.
- Retry failed items a few times with backoff, then mark them failed with the reason.
- Notify the user when the job completes or fails.
Data
Why source IDs and timestamps matter
Every field in a lead record came from somewhere at some moment. Storing that — the source, the source's own ID for the record, and when it was collected — is cheap, and it pays for itself three times over.
Deduplication gets reliable, because the same source ID arriving twice is an exact match rather than a fuzzy guess. Change detection becomes possible, because you can compare today's value with the one you stored and record old value, new value and time. And debugging stops being archaeology: when a user asks "where did this email come from?", the answer is a lookup.
Checklist
- Keep source and source ID on every record.
- Timestamp both collection and last update.
- Log field changes as old value → new value with a time.
CRM
Turning a lead list into a working pipeline
An exported spreadsheet is a snapshot; it is out of date the moment it is saved. A pipeline is different: every lead has a stage — New, Contacted, Interested, Follow-up, Won or Lost — and moving it is an event that is recorded.
Add notes for what was said, tags for how you group leads, and a follow-up date so the next action surfaces on its own. Once status changes are logged, you can answer questions a list never could: how long do leads sit in Contacted, and which tags actually convert?
Checklist
- Keep one record per business and attach everything to it.
- Make status changes cheap: a menu, a drag, a bulk action.
- Put follow-up dates where you will see them every morning.
Usage
Building a credit system users can trust
Credits work when they are predictable. Before a large job runs, show the maximum it can cost. While it runs, charge through a ledger — one row per grant or use, each with a reason and a reference to the job that caused it — rather than by overwriting a balance.
A ledger makes the balance auditable and makes refunds explicit: if a job fails, the refund is its own visible row. And every limit must be enforced on the server; anything enforced only in the browser can be changed by anyone who opens developer tools.
Checklist
- Show the estimate before the job.
- Record every change as a ledger row with a reason and reference.
- Enforce limits on the server, never only in the browser.
Performance
Keeping a SaaS frontend lightweight
Most of a business tool's interface is forms, tables and lists. Server-rendered pages deliver that fast on a low-end Android phone and a 4K monitor alike, and a small amount of JavaScript can add drag-and-drop, bulk selection and live estimates on top — without making anything depend on it.
Motion should explain state, not decorate it. Animate only transform and opacity, drive it from IntersectionObserver instead of scroll listeners, pause it when it is off-screen, and switch it off for people who ask their device to reduce motion.
Checklist
- Server-render first; enhance with small, optional scripts.
- Self-host fonts and assets; version them for cache busting.
- Respect prefers-reduced-motion.