My First SaaS Project and its lessons (3-Week Update)

After dedicating significant time to developing foundational tools, including a logo generator, a waitlist application, and a comprehensive boilerplate for my code, my primary objective was to accelerate the launch of new SaaS projects. With these preparations complete, I chose our first dedicated SaaS venture.

This initial project was not a typical Software-as-a-Service, but rather a Data-as-a-Service (DaaS) offering. The concept emerged from a collaboration with my colleague, Ayoub K., an expert in sales and marketing. He proposed a platform designed for entrepreneurs, businesses, and sales teams. The goal was to provide access to indexed information on thousands of companies, detailing private online data such as executive contact numbers, emails, LinkedIn profiles, and event participation history.

Upon validating the idea and identifying a clear market niche, we moved swiftly into development. Leveraging my pre-built boilerplate, we established a functional prototype within just two days. This included integration with Stripe, Google OAuth, magic link authentication, and a Convex database, making the core system operational.

However, this early progress soon led us into the challenging realities of the SaaS landscape. This account will detail our journey, specifically focusing on the intricacies of SaaS sales, effective strategies, and crucial missteps to avoid. It is particularly relevant for anyone embarking on their first B2B SaaS development. My "houndit" concept, regrettably, did not achieve its intended outcome, but the experience offers valuable insights.

The core idea for our first pick, the DaaS, came from my project partner Ayoub K., an expert in sales and marketing. He suggested a tool for entrepreneurs and business sales teams where they could have a platform to see, to begin with, 10k indexed companies. This platform would provide information on executives and CEOs, all public information available online. Users would have on-demand access to CEO contact numbers, emails, LinkedIn profiles, and a history of events the company had participated in.

This was the initial idea. We then started researching competitors. After we picked the idea and noticed there was a niche, we began the project.

I used my ready-to-use boilerplate, and in two days, we had a SaaS with Stripe, Google OAuth + magic link, and a Convex database up and ready.

The plan for the technology involved reliably acquiring data online. We needed a way to scrape data and ensure each company had a full profile. We wanted something feasible, not a process that would require manually inputting 10,000 entries, which would consume too much time. So, the first thing I needed was a list of companies. I could then expand by adding missing information later.

We started from there, researching where to find a really large list of company names. By using AI and conducting research, I discovered that a better starting point is by searching for information from major conferences. These are places where companies and organizations present their products, like CES Unveiled Europe, ESS NEC Birmingham, and Web Summit. We found that these events always list the exhibitors, providing a list of thousands of companies with logos, website names, booth numbers, locations, and year, all of which are valuable pieces of information we could scrape and use for our SaaS.

With the SaaS up and running, it was time to build the scrape engine. We had to consider that every website is built differently and might require a unique scraping approach. Server-side rendered (SSR) websites, where the server provides the data, are different from client-side rendering with API calls.

To start, I picked an easier target: a website that had an API with query parameters to scrape all the data in a filtered manner. I stored this data in our database (companies, companyEvents tables). With one click, boom, over 700 companies were indexed. Everything was working smoothly. You could now search for companies and view company details.

Now came the challenging part.

Scraping the CES Exhibitor Directory turned out to be far more complex than scraping a normal event site. The exhibitor list is powered by a heavily protected Vue SPA that loads its data from a Google Cloud Run API, and that API rejects almost all automated or non-mobile traffic. This meant traditional scraping methods such as HTML parsing, headless browsers, proxy rotation, or even JS-rendering services, never loaded the exhibitor data because the SPA simply refused to hydrate. As a result, the page appeared empty even though the URL loaded.

We attempted multiple scraping strategies:

All methods failed for one reason: the Cloud Run API validated device fingerprints and rejected anything that didn’t look like a real browser, our automated setups failed that check even though normal desktop browsers worked.

The only approach that successfully bypassed the protection was to manually render the full page with all pagination visible and then copy the raw HTML into a file. I know it’s a rudimentary move, but it worked. A script would then extrapolate data from this file and add it into our database. The system was designed to identify similar companies by using Fuzzy String Matching, and matching all other available information like their website and social links. This approach was not elegant, as it required manually scraping the information and feeding it to the script. However, we wanted to ship fast, so for an MVP, it was deemed acceptable. We noted this as something to resolve later. For now, it was sufficient, as our main goal was to get to 10,000 entries in our platform and ensure high-quality data with working information.

At this point, we had a list of data with logos, website links, and some companies with LinkedIn profiles, others without. The plan was (we stopped here) to create another script that would pick these data points, visit each company's website, and attempt to fill out missing information such as their LinkedIn profile, telephone numbers, and email addresses.

While I was orchestrating the technical aspects, Ayoub was researching the market and selecting the right name: "houndit." (The name derives from "hound," like a tracking dog, diligently pursuing its prey, and "to hound" meaning to relentlessly pursue). He also spent time validating the idea, in parallel with my technical work. He identified top keywords and open social links for our go-to-market strategy.

Up to this point, everything seemed to be progressing well. So, what went wrong?

While checking competitor feedback, we discovered a significant recurring theme: many one-star reviews. These reviews consistently highlighted issues such as "Useless service, horrible experience," "Mails ending up in spam," and "Not getting a response from the recipient." Other comments included, "If you don't mind having 1 tab taking almost 2GB of ram then this is for you," and "Apollo has been nothing but a resource-heavy, laggy program... Does the UX make you want to throw your laptop out the window? ABSOLUTELY." Another review stated, "If I could give negative stars I would. Apollo is full of a bunch of robots ad lib leaning unintelligence. Outdated information and piss poor customer service."

These comments, and many more, all pointed to a common problem: unreliable and outdated data.

This led us to a critical realization. If multi-million dollar companies could not resolve these data quality issues, how could we? We genuinely wanted to build a valuable portal, but relying solely on scraping might not be fully sustainable. Perhaps we could have pursued this idea further, but we did not want to risk our first major shot on a venture that could fail from the beginning due to foundational problems. Our app, at that stage, did not offer anything truly unique; it resembled a smaller version of apollo.io. Our initial thought was to differentiate by listing company event participation, which was not readily available elsewhere.

After much consideration, we decided to cut it short. We moved this project into our "micro-SaaS graveyard" and shifted our focus to the next challenge.