Dataset Labs
    Back to blog
    Product update · April 2026

    Cost per row is coming down

    Our first round of cost optimizations is live. Most projects are around 15-20% cheaper per row. The most data-heavy ones, up to 70% cheaper.

    The numbers

    We run evals across dozens of representative projects before shipping changes. They range from simple directory builds to data-heavy multi-contact enrichments. Each runs under the same fixed budget, so we can compare cost per row between runs.

    Here's how the latest batch of changes moved the numbers:

    • Global average: 20¢ → 17¢ per row. About 17 percent lower across the full regression.
    • Yield: 39% → 45%. The same budget produces more rows.
    • Biggest drops on the most data-heavy projects. The lists with lots of enrichment per row (multiple contacts, heavy verification, deep research) saw 45-70% lower cost per row.

    Why a row costs what it costs

    The cost of a row is the cost of the research behind it. A clean, well-documented contact can run a few cents: a targeted search, a page check, a cross-reference. A harder one, like a direct phone for a niche role or a signal buried in a conference bio, can run a few dimes. It depends on how deep the research has to go.

    Add a few signals per row (tech stack, recent funding, a verified phone) and a standard contact row adds up. On a longer list, that compounds.

    The cost per row isn't arbitrary. It's the sum of a lot of small decisions made on every row before the data reaches you.

    The trap of over-enriching

    The easy mistake is to check every possible source for every row, hoping one will land. That's how a $5 project becomes a $50 project. The opposite mistake is stopping too early and handing back partial data. We watch both.

    The part most tooling gets wrong is the order of operations. Expensive lookups should be the last step, not the first. They should be skipped entirely when cheaper signals have already shown a row isn't worth the spend. This is obvious, and most legacy tooling still doesn't do it.

    What changed

    Three shifts, described in plain terms.

    • Smarter tool selection. The system now starts with a smaller set of capabilities and only pulls in specialized ones when the row actually needs them. It stopped defaulting to the most expensive answer.
    • The first few rows teach the rest. Instead of every row rediscovering the right approach, we figure out the pattern on a handful of candidates first. The rest of the list follows without redoing that work.
    • Order of operations. Cheap signals run first. Expensive lookups run last, and only when earlier signals have said the row is worth it.

    The metric

    We track the cost of every row we ship. As a list scales up, that number should come down. Each project learns from its own early rows and runs the rest of the list more efficiently.

    If yours doesn't get cheaper as it grows, tell us. Those are the cases we chase hard.