8 Hours to 3,000 Users: How He Built a Viral Year-in-Review That Spotify Tried to Stop
Build to Launch Friday: Meet Alejandro again — the data engineer who turned ego into distribution and shipped a viral hit for less than $10
Welcome to Build to Launch Fridays, where we meet the builders turning domain expertise into AI-powered products.
Every Friday, I’m spotlighting someone from the vibe coding builders collection who’s doing exactly what I believe is the future: using AI not as just another tool, but as a true collaborator to transform curiosity, passion, and years of professional knowledge into something scalable and ownable. No VC funding, no technical co-founders, no permission required, just domain experts who decided to build.
Today, I’m bringing back Alejandro — the data engineer I featured when he built an MCP server for Substack authors. But this time, he went viral with something that took him just 8 hours to build.
What would you build if you knew it would go viral in 48 hours?
And what if I told you it would cost less than a fancy coffee, take 8 hours to build, and get so popular that Spotify’s legal team would ask you to change the name?
That’s exactly what happened to Alejandro.
When I first featured Alejandro in October, he had just built an MCP server that solved his own context-switching hell. He went from scattered Python scripts and messy local setups to a clean, remote tool that any Substack author could use to analyze their content performance.
But here’s what I love about Alejandro: he doesn’t stop at solving his own problem. He keeps pushing, keeps building, keeps asking “what if?”
So while testing his MCP server, asking Claude for summaries of his own content, he had a realization: “Wow, I actually created a lot this year.” And then the idea hit him: what if every Substack author could see their year wrapped up like this?
Eight hours later, Substack Wrapped was live. Within days, 3,249 publications had been processed. His launch article got 519 likes, 238 comments, and 231 restacks. Then Spotify’s lawyers showed up.
Alejandro comes from a marketing and advertising background, evolved into website tracking, and eventually became a data engineer. Now he spends half his time building AI use cases. He’s shipped three official products: Voice2Blog, Substack Author MCP, and now Substack Recapped.
None of them are monetized. And that’s intentional. He already has a job, and he’s experienced the 14-hour workday grind. He’s not interested in going back. For him, building is about creating things he enjoys using, things that serve the community, things that are fun.
What makes this story fascinating isn’t just the viral success. It’s how Alejandro thinks like a data engineer even when building creator tools. He treats content creation like a data pipeline, applies single-responsibility principles to his code architecture, and measures everything. But then he puts on his marketing hat and understands that ego drives distribution.
You can explore Alejandro’s Vibe Coding Builders profile to see all his projects and how he’s building in real time.
Builder Background & Origin Story
What’s your background, especially on the data/engineering side, and what were you building before Substack Wrapped?
I come from marketing/advertising, evolving to website tracking and later life recycled me into a Data Engineer. Now I spend half of my time building AI use cases so my role will still shift as every other year of my career 😂
I like building things I can enjoy using, that’s why Voice2blog or Substack Author MCP came as relevant tools after many processes. Many of those were scripts, workflows and random local apps that I eventually turned into something more powerful, like Substack Recapped (the name it got after Spotify asked me to change it because Wrapped is a trademark).
Haha, I totally relate to that “life recycled me into a Data Engineer”, so real about how modern careers evolve. Life has its own judgment; you don’t plan it, you accept and adapt. And the Spotify trademark issue? We’ll get to that drama.
How many products or tools have you shipped so far, and which ones (if any) were monetized?
Officially 3:
No monetization. I am already covered with my job and experienced the 14hr work days years ago and don’t want to come back. Putting a price tag means responsibility and if I do that I put 150% of my energy, which implies other sacrifices I don’t want to make now.
This is refreshing honesty. Not everyone needs to monetize. Not every product needs to become a side hustle. Sometimes building for the joy of it, for the community, for the learning, is enough. The most important part is to protect our own boundaries.
What pattern from your past projects directly influenced how you approached this build?
I got to know the Substack underlying API responses really well after experimenting with everything that led to the MCP. I got used to think on code design and functional programming a lot with one single responsibility principle, tool decoupling logic and other concepts around it.
For this one I wrote a prompt by hand and then started talking with Claude to plan the architecture. It was so fast because I used all the knowledge & codebase from the MCP project, the stack is also a pattern I am really used to so it was also straightforward.
This is what compound learning looks like. You don’t have to work on a brand new idea each time. You don’t have to start fresh. Your first try might be completely out of order, the second follows suit, the third starts to spark interesting ideas, and the fourth connects the dots. Eventually, you realize every path you walked amplifies on top of each other. None of those efforts were wasted. That’s what happened here.
Why Substack Wrapped Exists
Why build a Substack-focused product specifically — what gap or opportunity did you see for writers?
I was reviewing some ideas for my content and started stress testing the MCP I built to see how far it could go. Then I asked Claude for summaries… then I realized how much I did and then I thought about the wrapped idea.
Substack gives you a lot of metrics but nothing like this that allows you to confirm that all your journey made sense. If they do something like this they will keep way more writers on the platform because looking at all your effort in a retrospective is quite motivating no matter if you had 500 or 5000 reactions in one year.
The opportunity was purely empathetic with other writers. It was community service, never intended to charge for it even though I knew it was well executed.
That’s the insight right there. I’ve been taking for granted that I could capture all my content in one vault inside Cursor, continuously iterate and reflect, look back on everything. But that’s not what’s happening for most writers. We’re grinding away, publishing weekly on platforms we don’t control, losing the bigger picture. A mirror that shows everything you created, all in one place? It might look simple from the outside, but that emotional hit is powerful.
What led you to the “Wrapped / Press Kit” concept (shareable cover + persona) instead of a traditional analytics dashboard?
I put on my marketing hat and knew that this was all about ego in the end. So giving them a souvenir made it about them and not about the tool, which created a huge viral effect. It’s also a Spotify copycat so there’s no new concept since they already give you an image to share on social media.
Also it’s worth mentioning that I discovered that not every mortal knows how to read data, that’s why I kept that super simple and easy to digest. Most of users shared other images of the slides and the chart with evolution barely showed up, that made me assume quite fast that a dashboard was not a quick win.
To compensate for my broken heart I created substackrecapped.com/stats but that’s for all the publications accumulated.
“All about ego in the end” - this is marketing genius. I used to be puzzled about why people didn’t love dashboards. I was personally okay with them, gave me a clean overview of everything. But my boss absolutely hated dashboard pages. Now I get where that’s coming from. You gave me ideas on what I should change about my old substackexplorer.com.
And building a stats page anyway “to compensate for my broken heart”? That’s both funny and so relatable.
Who is this _not_ for? What use cases did you intentionally avoid?
I avoided cross posts, which some publications create a lot of false positives since they looked quite consistent and they were cross posting the same way someone restacks notes. Also API wise they were not working properly as common posts.
This was not avoided, but concluded I could have handled it better: A lot of authors with 2 articles in the whole year tried using it anyway out of FOMO 😂
Cross posts as a great catch! That would’ve created so many false positives. And the fact that people with only 2 articles still tried to use it out of FOMO? Hilarious. But hell, why not? That’s the power of FOMO-driven distribution right there.
From Idea to V1
What did the very first version look like, and what was the minimum feature set needed to ship?
You put your Substack publication URL, wait some seconds and get the output to go through the slides until there’s an image to download for sharing. Let’s say the tool itself is an MVP that could scale in more complex analysis.
I tested with 5 different publications that had nothing to do with one another to make sure everything was working smoothly.
I tweaked some things based on feedback on the first 2 days, but then all the additions were a stats page and help page for people having issues to understand what URL to use, so V1 did not change too much.
Five test publications, then ship. No beta program, no waitlist, no private launch. This is going to be the new norm.
Walk through the exact user flow. What inputs does a user provide, and what outputs do they receive?
Input: A Substack publication URL
Output: 8 images combining nice visuals, an interactive chart to see your growth evolution, and a sharable image for social media with your stats.
Yup, I know (I played with it). Asking for you (who’s reading now) just in case ;)
Where did you first share it publicly, and what were the initial reactions?
Substack with an article and tagged around 35 users I knew due to interacting at some point.
I timed it with Spotify Wrapped so I could launch it without explaining too much. That article is the shortest I ever written.
Nobody knew about it before it was published since I only tested it myself. The beta users ended up being the real users.
Great timing. Launched right when Spotify Wrapped was trending, so zero explanation needed. And that timing also got Spotify lawyers’ attention. Congratulations… and sorry ;)
How It’s Built
Which parts are AI-generated, and which parts are deterministic “regular” code?
Topic Extractor is done with Claude Haiku.
The rest of the project are logic wrappers around Substack API based on your data so it’s fully deterministic. If you regenerate it, only the topics will change.
If this question is about vibe coding, the frontend is 100%, the backend + postgres are long prompts and super nit picky iterations because that’s usually my area, but also vibe coded. I touched some things here and there but because it was faster to do it myself.
Thanks for being so thoughtful answering this. Yes, I’m asking about vibe coding, and that answer is satisfying. Hybrid approach: AI for the creative parts, deterministic code for everything else. I’m seeing the future here. Vibe coding is iterating so fast, getting so powerful, that human in the loop is becoming less restrictive gatekeeper and more true manager role.
👉 Try Substack Recapped | View on Alejandro’s Vibe Coding Builders Profile
What were the main failure modes early on, and how did you mitigate them?
Nobody said something bad about the topics generated, which was nice.
Some publications apparently don’t have name and just use a logo, so the logic was not able to fallback and the name was the main thing for everything else.
Some people with multiple publications had issues where the first publication name got repeated across all of them but the data was good. I thought it was caching but the problem was that the script was always getting the latest publication found, so I fixed that one and it stopped.
People not understanding how to get the URL was the main issue, mostly for publications with edge cases. They represented 20/3350 so a nice number to handle manually, I added a /help page and those messages stopped.
That’s a 0.6% edge case rate, handled beautifully. I didn’t know you could have a publication without a name. What about the publication domain then? Always learning something new.
What tech stack did you use, where is it hosted, and how long did it take to go from 0 to launch?
FE: React-Vite-Tailwind
BE: FastAPI, PostgreSQL
LLM: Claude Haiku
Hosting: Railway
Around 8 hours until it was ready to share with users. Funny thing is that 80% of the time was on refining the messages depending on data thresholds users would get.
8 hours — can you imagine this in 2020? I can relate to the 80% time on copywriting so much. Truthfully, code is no longer the barrier. The barrier becomes understanding the logic of the structure and getting AI to cooperate.
What does traction look like so far, and which distribution channels mattered most?
3,249 publications processed. The main article had 519 likes, 238 comments and 231 restacks. Traffic is around 6k unique users. LinkedIn had some small traffic but is nothing compared to pure Substack. Of course, my subscriber count went up by 150, but that was never the intention because my content is not for everyone. They are likely to unsubscribe eventually.
Every time I think the traction will stop, I see around 30 avg being processed everyday, and many people asked if they could run it again by the end of December, so we might have a curve there.
Each publication processed going to postgres was my main metric, I was also tracking how many times someone processed a publication in case of multiple runs.
Only Substack and LinkedIn (some awareness there, but it was meant for people writing on Substack mainly).
519 likes on the launch article. 231 restacks. 3,249 publications processed. 6,000 unique users. This is already a little crazy. And you know what? You could have also published on the Substack subreddit and other related communities to gain even more momentum in one shot. But we’ll talk more about that subreddit case later.
Roughly how much does it cost to run as usage scales?
I paid $7 USD on Claude’s API to process 3.3k Substack publications.
On Railway I paid $1 USD because I had a serverless setup also, which was convenient.
The database I used is shared across other projects but I don’t get to more than $1 USD a month so it’s not worth breaking it down.
Let’s do the math together: $8 total to process over 3,000 publications that reached 6,000 users and generated massive engagement. This is the economics of vibe coding at scale. Traditional development would have cost thousands before you even launched.
Strategy, Monetization & What’s Next
Is Substack Wrapped intended to stay free, and what does “sustainable” mean to you?
Yes, maybe I would prompt users to “buy me a coffee” next time but I don’t really see an ultimate goal besides doing something cool and have fun while building it.
Based on my costs, I don’t need 200 people paying a fee to cover expenses so I can handle this. Maybe next year the scale will be different and it might change how I think through it.
So true. He reminds me of those devoted hackers, so committed to contributing to a better community without asking anything in return.
There appear to be two “Wrapped” URLs in circulation. Do you own both? What’s the story?
The ones I own are substackwrapped.com, which is a page telling that we “moved” to substackrecapped.com after Spotify asked me to change the name.
Bittersweet drama. Funny thing: when I searched for Substack Wrapped on Perplexity, it surfaced a subreddit post (not by Alejandro) about a different variant from a day or two after he launched. The original work and iterations though, are all captured in substackrecapped.com.
Where do you want this to go next: a seasonal year-in-review, or a broader creator toolkit?
Adding notes would be interesting, also doing some author matching for co-authoring collaboration proposals.
Another idea was tracking all the publications during the year to snapshot some evolution on other metrics that I can’t have such as subscriber count over time.
Yes, notes wrapped would be really interesting. If you check out Orel and WriteStack, he’s got something about that going on. But the most important thing? Now I know Alejandro is not going to stop. Let’s keep building.
If Substack launches an official Wrapped, what’s your differentiation or pivot plan?
They have data and resources to make something way better than I did so I might not even try to fight it, but I would have no idea when or how they would launch it when I am building mine.
On the other hand I think they benefit from the engagement that a “community” project that goes viral generates, and people are more likely to share and use something that someone like them created rather than the “company” creation, but that’s just a vision I have.
That second point is gold. He’s right. Encouraging community projects benefits Substack more than trying to control everything. When an indie tool becomes a corporate one, it stops bringing fun.
For anyone vibe coding, or building tools around Substack, what’s one advice you’d offer them?
There are no rules right now, there’s no API and everything you do relies on how creative you can be. Whenever Substack decides to open an official API it won’t be fun anymore in the same way and use case will become limited, so play around and enjoy!
This is the window of opportunity — for Substack, for vibe coding, for all of us. It’s there. Why not have some fun with it?
Connect & Explore
Here’s what strikes me most about Alejandro’s approach: he treats building like a data engineer even when he’s creating consumer-facing tools.
When I first featured him with the MCP server, I was impressed by how he simplified complexity. He went from scattered scripts and authentication hell to a clean, remote tool anyone could use. But what he did with Substack Recapped shows something deeper: he understands the psychology of distribution. He knows when to put on his marketing hat, when to prioritize ego over analytics, when to ship souvenirs instead of dashboards.
This is the future I keep talking about: domain experts using AI to build tools that would have required entire teams before. Alejandro knows data engineering, knows marketing, knows creator pain points. He combines all of that with vibe coding and ships products in hours that get thousands of users.
If Alejandro’s approach to systematic building and strategic distribution resonates with you, connect with him. He’s exactly the kind of engineer-who-thinks-like-a-marketer worth knowing.
[
The Pipe & The Line
Hands-on guides, tools, and experiments to sharpen your Data & AI Engineering skills from someone who learned it all in the wild.
By Alejandro Aboy
If you’re turning your expertise into products, building with AI, or helping others do the same, you belong here. Join the vibe coding builders community and get featured on Build to Launch Friday. Curious why it all started? Here’s the full story behind Vibe Coding Builders.
Your turn:
What would you build if you had only 8 hours and knew it would go viral?
What souvenir could you create for your audience that they’d be proud to share?
What problem are you overthinking that actually needs a simpler, ego-friendly solution?
Alejandro went from stress-testing his MCP to 3,000 users in a weekend for $8. What will your builder story be?
— Jenny