Waveful is a gamified creator platform founded by Dennis Motta and Steven Motta. The company uses ScrapeGraphAI to identify which of its users already have meaningful reach on other social platforms.
TL;DR
Waveful needs a reliable way to understand creator reach outside its own platform. ScrapeGraphAI gives the team structured follower data without maintaining custom scraping infrastructure.
- Use case: enrich Waveful users with follower counts from external social profiles.
- Previous setup: an in-house scraper built on ScrapingBee.
- Problem: the scraper broke repeatedly and kept costing money after it stopped producing value.
- Current setup: Node.js calls to ScrapeGraphAI through the JavaScript SDK.
- Result: the pipeline is back in production, stable, and low maintenance.
What Waveful Does
Waveful is a social platform where creators build communities, publish content, and monetize from the first day they join. Users can share photos, videos, audio, and text. Fans can support creators through Superlikes, which convert into real earnings.
The company was founded in Milan in 2022 by Dennis Motta, Steven Motta, and Gianluca Sorgente. Dennis had already built consumer software that reached tens of millions of downloads worldwide; today he serves as Chairman and CTO.
Waveful has grown past 4M global users, raised $2M from consumer investors, and joined Andreessen Horowitz's a16z GAMES SPEEDRUN program.
At that scale, creator marketing depends on prioritization. Waveful needs to know which users already have an audience elsewhere, because those users can become stronger partners, stronger ambassadors, and stronger examples for the rest of the community.
The platform already has rich first-party signals: who publishes often, who receives support, who builds an active community, and which content performs inside Waveful. External reach adds a different dimension. It helps the team understand whether a promising user is also bringing distribution from Instagram, TikTok, YouTube, or another social network.
That combination matters because creator growth is rarely driven by a single metric. A user with strong Waveful engagement and a large external audience is different from a user with only one of those signals. The marketing team can use that distinction to decide where to spend attention first.
The Problem
Waveful's marketing team wanted to identify users with significant followings on other social networks.
The required signal was simple: follower counts attached to the right Waveful users. The implementation was less simple. Social profiles change structure often, and scraping them reliably requires handling layout changes, dynamic content, rate limits, and anti-bot systems.
This was not core product infrastructure. Dennis described it as a second-order system: useful to the business, but not the central thing Waveful builds. That distinction mattered. The team needed the data, but it did not want to spend engineering time operating a scraper.
Without reliable follower counts, the team had less confidence in whom to contact, feature, or support. With reliable counts, marketing effort could be focused on creators whose external reach made them more likely to move growth.
The output also needed to be structured enough to use directly. A raw HTML page would only move the maintenance problem from one place to another. The team needed a small set of fields, returned consistently, so the follower data could be connected to internal user records and used in analysis without a separate cleanup step.
The Old Scraper
Waveful first solved the problem in-house. The team wrote and maintained its own scraping logic, using ScrapingBee as the underlying scraping provider.
That setup worked until it did not. Because the scraper was built internally, Waveful owned every failure mode. The logic depended on page structures that changed over time. Each change created maintenance work: inspect the failure, update the code, redeploy, and wait for the next breakage.
The cost profile also stopped matching the use case. Waveful began on a small plan, spending roughly $20 to $30 per month. After a usage spike, the team moved to a $100 plan. When the spike passed, the cost stayed at $100.
Eventually, the scraper broke again and remained broken. Waveful was paying for a pipeline that no longer returned useful data.
That failure mode is common with internal scrapers. The first version is often cheap to build, especially when the target data is easy to see in a browser. The cost appears later, when page changes, bot defenses, and edge cases turn the scraper into a recurring operations task.
For Waveful, the cost was not only the monthly subscription. It was the context switching. Every repair pulled engineering attention away from the product, even though the data was meant to support marketing rather than core application behavior.
Why ScrapeGraphAI
When the old system failed, Waveful had two options: repair it or replace it.
The team chose to replace it with ScrapeGraphAI.
The decision was intentionally lightweight. Because this workflow sat outside the core product, Waveful did not run a long vendor evaluation. Dennis heard about ScrapeGraphAI through Marco, a trusted connection, and used that recommendation to make the call.
"I honestly didn't look too hard at the alternatives," Dennis said. "It's not a fundamental part of our business, so I just went with the product Marco suggested and that I trust."
For a non-core dependency, the requirement was not a perfect platform study. It was a credible recommendation, fast integration, and a system that would stay out of the team's way.
That framing shaped the evaluation. Waveful did not need to own proxy logic, browser automation, retries, or parsing. It needed an API that could take a profile-oriented request and return usable data. ScrapeGraphAI matched that requirement closely enough that replacing the old system was more practical than extending it.
How Waveful Uses ScrapeGraphAI
The integration is small by design.
Waveful's Node.js backend calls ScrapeGraphAI through the JavaScript SDK. ScrapeGraphAI returns structured follower data, which Waveful uses in its internal marketing analysis.
There is no HTML parsing layer for the team to maintain. There is no site-specific scraper to tune. The application sends a request and receives the fields it needs.
For social media scraping, that abstraction is the main value. Social platforms change markup, load content dynamically, and introduce bot defenses. ScrapeGraphAI handles that layer so Waveful can keep its own code focused on the business workflow.
Dennis and his colleague Gabri built and operate the integration.
The code path is intentionally narrow. ScrapeGraphAI is not embedded across the product or exposed to end users. It sits behind an internal workflow that enriches creator records for analysis. That makes the integration easier to reason about: inputs are known, outputs are limited, and failures can be handled without affecting the main user experience.
This is also why structured output mattered more than a generic scraping primitive. Waveful did not want to store pages and inspect them later. It wanted the extracted values. Returning those values directly reduced both implementation time and ongoing surface area.
The Workflow
The workflow is direct:
- Waveful starts from a user who may be a high-reach creator.
- The backend calls ScrapeGraphAI for external social profile data.
- ScrapeGraphAI returns structured follower counts.
- Waveful attaches those counts to the relevant user record.
- The marketing team uses the data to prioritize outreach, partnerships, and creator support.
ScrapeGraphAI sits at the boundary between the open web and Waveful's internal marketing workflow. Its job is to make external profile data usable without turning scraping into an internal project.
The boundary is important. Everything before ScrapeGraphAI is uncertain: public pages, changing markup, dynamic rendering, and platform-specific behavior. Everything after ScrapeGraphAI should be ordinary application data. The cleaner that boundary is, the less scraping complexity leaks into Waveful's own codebase.
Results
The result is a working data pipeline with less operational overhead.
Roughly one month after going into production, the ScrapeGraphAI implementation has been stable. "I think it's been pretty reliable, it's never given us issues," Dennis said. Gabri's assessment was similarly direct: everything is fine.
For this use case, that is the point. The system should run quietly. It should return the data the team needs. It should not create recurring maintenance work.
Waveful also moved away from paying for unused capacity on a broken scraper. Instead of carrying a fixed monthly cost for infrastructure that had stopped working, the team now uses a setup that fits the actual job.
The qualitative result is just as important as the technical one. The team regained a marketing signal without creating a new internal system to babysit. For a small team, that is often the deciding factor: the best implementation is the one that provides the data and then disappears into the background.
Why It Worked
ScrapeGraphAI fit Waveful's constraints for three reasons.
First, it returned structured output. The team did not need to build and maintain parsing logic around raw HTML.
Second, it reduced scraper maintenance. The team no longer had to update custom logic every time a social profile changed its page structure.
Third, it kept the ownership model small. Two people could build and operate the workflow without turning it into a platform effort.
That made ScrapeGraphAI a practical fit: enough control to get the data, without taking on the infrastructure behind it.
The lesson is not that every company should outsource every scraper. Some scraping workflows are core product infrastructure and deserve deeper ownership. Waveful's case was different. The data was valuable, but the scraper itself was not a strategic asset. ScrapeGraphAI let the team keep the value while removing most of the operational work.
FAQ
Which ScrapeGraphAI product should someone with this use case start with? For pulling specific fields like follower counts from social profiles, start with the Scrape endpoint. If your application is built in JavaScript or Node.js, the official SDK wraps the API directly.
How long does an integration like this take? Waveful's integration was small because ScrapeGraphAI returned structured data. The work was mainly wiring API calls into the existing backend and routing the returned fields into the marketing workflow.
How does this help with scale and changing websites? ScrapeGraphAI handles proxy rotation, anti-bot challenges, dynamic content, and markup changes behind the scenes. That lets teams work with social media data without maintaining scraping infrastructure themselves.