How I Built LeadScrapper From Scratch

I built LeadScrapper because I kept running into the same ugly workflow everywhere: find a business, check whether it looked weak online, collect a few contacts, then manually stitch together an outreach message. That is a lot of repetitive work before a single conversation even starts.

The annoying part was that each step was useful on its own, but none of the tools I was using were designed to live together. I would open search results in one place, scrape contact details in another, write notes somewhere else, and then finally try to craft a message that felt personal enough to send.

That is the kind of pain that does not look dramatic from the outside, but it eats time in a way that compounds. I wanted something that felt like a real workflow instead of a stack of tabs pretending to be a system.

The more I thought about it, the more obvious it became that the product had to speak to how people actually work. Most builders do not want another database. They want a path from curiosity to action that does not punish them for moving quickly.

The first version was intentionally narrow. It was basically a lead discovery loop with enough intelligence to make the data useful. I cared less about making it look impressive and more about getting from search to a usable prospect list without falling apart.

I did not try to solve everything at once. I wanted a loop that could move from business discovery to qualification fast enough that the product felt different from doing the same work manually.

At that stage, the biggest win was simply reducing friction. If I could get from a search query to a short, usable set of leads without losing context, the product was already doing something valuable.

That made the product feel less like a lead tool and more like a personal operator. The difference sounds small, but it changes how you design the rest of the experience.

I kept the stack fairly practical: Next.js for the interface, Node.js for the backend logic, PostgreSQL for persistence, and scraping / enrichment logic where it was needed. The point was not to build a tech demo. The point was to make a product I could actually keep improving.

The core decision was to put the workflow first and the model second. AI can help draft, classify, and summarize, but the product still has to be legible when the output is wrong or incomplete. That meant designing around control and review rather than pretending the AI would do everything perfectly.

I also wanted the UI to stay simple enough that the user always knew where they were in the loop. When products handle messy information, clarity is not a luxury. It is part of the feature set.

A lot of early product decisions came down to making invisible work visible. If a step takes time, the user should understand why. If a step returns a result, the result should feel immediately actionable.

The main bug class was not “the app crashed” so much as “the workflow got noisy.” Too many inputs, too many assumptions, too much data that looked useful but did not help a real person decide what to do next.

That pushed me toward tighter filtering and more opinionated output. I had to keep asking whether a field or a step made the user faster, or just made the app feel more complete in a superficial way.

The bigger pivot was accepting that lead generation software is only good if the transition from discovery to action feels fast. Once I stopped treating the product like a database of contacts and started treating it like a decision engine, the direction got clearer.

That pivot also changed the writing, the interface labels, and the way I thought about success. The product is not doing its job if it only creates more information. It has to create momentum.

Building LeadScrapper felt like constantly trying to make the invisible visible. A lot of the work was not glamorous, but it mattered because the product only became useful when the user could trust the shape of the output.

There was also a strange satisfaction in reducing the number of places a user had to think. Every time I removed another unnecessary step, the product felt more like a tool and less like a pile of features. That is the part of shipping that keeps me interested: not the big reveal, but the slow removal of friction until the workflow finally feels natural.

A lot of the product decisions were really about deciding what not to do. I did not want vanity metrics or extra charts that made the interface feel more complete than it really was.

The work got better when I focused on confidence in the result. If the user can trust the shortlist, they can move faster. If they cannot, the product is just a prettier way to waste time.

The newer version is tighter around the real workflow: discover, qualify, draft, and act. I stopped treating it like a generic SaaS and started shaping it around the part where users actually save time.

That shift changed the product in a few small but important ways. The navigation got simpler. The output got more focused. The screens started doing less, which made them feel more useful.

The latest version also feels more honest about the job. It does not pretend that automation replaces judgment. It helps with the repetitive parts so the user can spend more time deciding who is worth contacting and why.

That honesty matters because trust is the whole game in outreach software. If the product feels like it is guessing wildly, users stop believing it. If it feels grounded in the workflow, they keep coming back.

I want to keep tightening the loop, make the output more trustworthy, and keep the product focused on practical growth work instead of chasing features that only look good in screenshots.

The next version should make qualification smarter without making the product feel heavier. I care more about confidence in the output than raw quantity.

If I keep going with this, the product should feel less like a tool people use when they have extra time and more like the default way they start outreach work.

At some point I want the product to feel boring in the best way: predictable, sharp, and dependable enough that the user stops thinking about the software and starts thinking about the opportunities it reveals.

The part nobody sees is how much of this kind of product is really about judgment. The data is not the product. The judgment about which leads matter and why is the product.

That is why I kept pushing on the shape of the workflow. If the user has to interpret everything manually, then the software has only moved the labor around. It has not actually reduced it.

I wanted the product to feel like it was helping me decide, not just helping me store information. That difference is subtle but important, and it became more obvious every time I tested a new version.

Once I saw the product through that lens, the whole thing became more coherent. It was not a contact database with some AI on top. It was a small decision system for outbound work.

Lead generation tools can easily become bloated because it feels like every feature might be useful someday. That is usually how they get worse. The more the tool tries to be everything, the harder it becomes to trust anything it says.

I kept the product narrow because narrow products are easier to understand and easier to improve. They also make it easier to tell whether the core loop is actually helping or just producing activity.

That narrowness is a discipline, not a limitation. It keeps the product from drifting into generic CRM territory or from turning into a messy all-in-one app with no clear edge.

If the product remains narrow enough to be opinionated, it can keep getting better at the specific job it exists to do.

I think about the user as someone who wants to move from “I should probably do outreach” to “I know who I’m contacting and what I’m saying” as fast as possible. That is a different mental state from browsing a dashboard.

That shift in mindset matters because it changes the whole shape of the product. The interface should support action, not contemplation. The data should be easy to trust, not just easy to look at.

When I think about it that way, I can see why some earlier versions felt too broad. They were trying to be useful in theory instead of useful in the moment.

The current direction feels better because it is anchored in the moment where a real person is ready to do the work.