How to Hire Someone to Build Your Lead Generation Software

Hiring someone to build lead-generation software is not like hiring someone to build a website. A website either looks right or it does not. A data pipeline can look perfect the day it is delivered and be quietly wrong six weeks later, and you will not know unless the checks were built in on purpose. This guide is about picking a builder who understands that.

It is written for the person paying, not the person coding. You do not need to know Python. You need the questions that separate a vendor who has run a scraper in production from one who has only written one.

The four kinds of people you can hire, and where each one breaks

Almost every option falls into one of four buckets. Each is sometimes the right answer.

A freelancer from a marketplace

Strengths: cheap, fast to start, no sales process. If you need one source scraped once, a good freelancer beats any firm on price and speed. That is often the correct call.

Failure modes: the work is usually a script, not a system. No scheduler, no logging, no alerting, no deduplication across runs. When the source changes its markup, the script fails silently and you find out when your sales team says the list is stale. The freelancer may be unavailable by then.

Hire a freelancer when the job is one source, one time, and the output is a spreadsheet you will use and discard.

An offshore agency

Strengths: capacity. If forty sources need mapping, a well-run offshore team can put more hours on the problem than a boutique will.

Failure modes: the gap between the person who scoped your project and the people who build it. Requirements get transcribed rather than understood. Data work is unusually sensitive to this, because most of the value sits in judgment calls — is this the same company under two names, is this the property address or the mailing address, does a blank field mean no or unknown. Those get decided by whoever is on the keyboard, and will not be documented unless you insist.

A generalist dev shop

Strengths: they can build the whole product. If your system needs a real interface, user accounts, billing, and integrations, a shop that builds applications for a living will do that layer better than a data specialist.

Failure modes: they treat the data as an input rather than the product. Scraping gets scoped as a small task at the end. Then the source paginates strangely, or rate-limits, and the estimate doubles. Ask how many production scrapers they currently maintain. If the answer is none, the data half of your project is being learned on your money.

A specialist data firm

This is what we are. Strengths: the failure modes above are the day job. Deduplication, source drift, verification, run scheduling, and the legal boundaries of public-records work get decided before the first line of code.

Failure modes, honestly: we cost more than a freelancer on small jobs, and we push back on scope. If your real need is a polished multi-tenant product with the data as a side dish, a product shop is the better hire. And if lead data is the permanent core of your business — new sources every month for years — hire a data engineer instead. A firm is the right shape for building a thing and handing it over. It is a poor substitute for an employee whose whole job is your pipeline.

Our builds start at $1,500. That number sets the floor: below it, you want a freelancer, and we will tell you so.

Why "can you build a scraper" is the wrong screening question

Everyone says yes. A first-year developer can pull a table off a page in an afternoon, and that is not the hard part of the job.

Ask these instead. The answers tell you whether the person has operated a pipeline or only written one.

• How do you handle deduplication? You want matching keys, not "we remove duplicates." Ask what happens when the same owner appears with a middle initial in one source and without it in another. There is no perfect answer, but there is a large gap between a vendor with an opinion and one who has never thought about it.
• What does verification mean here, field by field? Verified is a word people use loosely. Which fields are checked, against what, and what happens to a record that fails. A good answer separates format validation from existence checks from actual confirmation.
• What happens when the source changes? This matters most. The right answer involves detection — the pipeline notices that yesterday it got four thousand records and today eleven, and tells someone. A vendor who does not raise monitoring here has not run anything for long.
• Who owns the code, and what are your sources by name? Ask early, in writing.
• Is there a dry-run mode? Can the pipeline run against a sample without writing to production or contacting anyone. If not, every test is live fire.

The contract term that matters more than price

Source code ownership and data ownership. Get both in writing before any money moves.

What to look for: on final payment, all code written for you is yours, assigned outright, and so is the data the system collects. The agreement should name the repository and give you admin access to it, not a zip file at the end, and leave you free to hire anyone to maintain it afterwards.

What to refuse:

• A licence instead of ownership. "A perpetual licence to use the software" means they own it and you rent it. Fine for off-the-shelf tools. Not fine for something you commissioned.
• Code held on the vendor's infrastructure with no export path. If leaving requires their cooperation, you do not own it in any way that counts.
• Any claim on the output data. Some vendors reserve the right to reuse what your system collects, including selling it. Strike it.
• Per-lead pricing on your own pipeline. If you paid to build the machine, you should not pay a toll on what comes out of it. That is a data vendor's model, and it quietly makes the vendor's incentive volume rather than accuracy.

The money side is covered in what custom lead-generation software costs, and the prior decision in build versus buy.

Red flags

• Promises of data public sources cannot contain. Company revenue, bank balances, and verified marketing consent do not sit in public records at scale. If a vendor offers them as standard fields, they are either guessing and calling it data, or buying it somewhere they will not name. Ask which.
• A vendor who will not name their sources. "Proprietary methodology" is how people describe a source they are not comfortable disclosing. You need to know where every field comes from, because you will answer for it.
• Anyone offering to get behind a login for you. Scraping while logged in usually means agreeing to terms of service and then breaking them, on somebody's account. Offering it casually tells you how they will treat your risk.
• Refusal to do source mapping first. A vendor who quotes a full build off a one-page brief has either not looked at the sources or plans to renegotiate later. A quote inside an hour is the same signal.

Pay for scoping before you pay for building

A source-mapping phase is a short, paid piece of work before development. The vendor goes to every source you care about and reports back: what fields actually exist, how the data is served, how often it updates, how clean it is, and which of the things you asked for are not obtainable.

This sounds like it protects the vendor. It protects you more. It is the cheapest point at which to discover that the field your whole plan depends on is not in the record. Learn that in week one and you can change direction. Learn it in week six and you have spent the build budget on a system that does not do the thing.

The projects that go badly wrong are the ones where nobody looked at the actual data until development started.

Fixed price, hourly, and a sane payment schedule

Fixed price is usually right for a defined build, and it is only possible after scoping. It puts estimation risk on the vendor, where it belongs. The trade is that scope changes require a conversation.

Hourly is right for maintenance and exploratory work. It is a bad fit for a first build with a fixed goal, because you carry all the risk of an estimate you cannot check.

A reasonable schedule: a paid scoping phase billed separately, then a deposit, then payments tied to working milestones, then a final payment on handover. Milestones should be verifiable — "the permit source is ingesting and deduplicating into the database" — not calendar dates. Keep the final payment meaningful. It is the only pressure you still hold on handover day. Refuse full payment up front.

What handover should actually include

Handover is not a phone call and a folder. Put these in the contract.

• Repository access as owner or admin — full history, on a platform you control.
• A runbook — plain language. How to run it, where it runs, how to add a source, what to do when a run fails. Written for someone who is not the author.
• The run schedule, documented — what runs, how often, and why. Sources that update weekly do not need hourly runs.
• Alerting that reaches a human — on failure and on suspicious success: record counts far outside the normal range, a spike in blank fields, an unexpected structure.
• A dry-run mode — so you or your next developer can test without touching production or contacting anyone.
• A recorded handover session. You will not remember it otherwise.

How we structure the build is described under custom lead-generation software, and the scraping layer under lead scraper development.

Maintenance is not optional, so plan it before launch

Sources change. A city moves its permit register to a new portal. A site adds pagination. A field that was always populated starts coming through empty. That is not a sign anything was built badly. It is the normal weather of data work.

What matters is that someone notices and someone fixes it. Decide which before launch:

• Retain the builder on a small monthly arrangement covering monitoring and source repairs. Fastest fixes, since they know the code.
• Take it in-house. Reasonable if you have a developer, and it only works if the handover was real. That is why those terms belong in the contract.
• Leave it unmaintained and accept the decay. Sometimes correct for a system with a known short life. Say so out loud, so nobody is surprised later.

The option that fails is assuming it keeps working because it worked on delivery day.

Questions to paste into an email

Send these to every vendor you are considering, including us. Compare the answers side by side.

• Which specific sources would you use, by name?
• Which of the fields I listed are not obtainable from public sources?
• How do you deduplicate across sources and across runs?
• What exactly do you mean by verified, field by field?
• When a source changes its structure, who finds out, and how?
• Do I own the source code outright on final payment, and the data it produces?
• Do you offer a paid scoping phase, and what is the deliverable?
• What does handover include — runbook, alerting, dry-run mode?
• What is the maintenance arrangement, and what happens if I do not take it?
• Have you built something like this before?

Any vendor who answers all ten clearly is worth talking to, whether or not it is us. If you want our answers, send us the list with what you are selling and to whom. We will tell you what is in the public record and what is not before quoting.