Why Not Try? How She Tackled 'Impossible' Tech and Built the Semantic Search Tool for Substack Readers

Build to Launch Friday: Meet Karen, the copywriter who says 'yes' first and learns the hard stuff after

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, meet Karen Spinner — the emerging builder creating StackDigest from her 143-acre farm in Arkansas, who embodies the fearless curiosity that makes vibe coding builders unstoppable.

---

What do you do when you encounter a builder so enthusiastic, so hands-on, and so genuinely collaborative that they make complex technical challenges look like weekend hobbies?

That’s Karen. While most people would hesitate before diving into vector databases and semantic search, Karen saw her users struggling with newsletter discovery and thought, “Why not try something that might be impossible?” From her farm home in Arkansas, she’s building StackDigest, a tool that combines the sophistication of enterprise-level search with the warmth of someone who genuinely cares about solving real problems.

When I connected with Karen, she didn’t just want to chat about her product. She offered to meet virtually, record our conversation, transcribe it with AI, clean up the Q&A, and hand over the polished content. That’s Karen in a nutshell: always looking for ways to contribute more value than expected.

Here’s our full 30+ min conversation where you can see Karen’s building philosophy and genuine enthusiasm in action:

Now she’s done most of my job here, it’s only reasonable to let her take it over!

---

Karen:

This interview took place several days before I pushed some major changes to StackDigest, including the introduction of a vector database, to production. I cringe slightly to read this now, especially my confidence that the sentence transformers I tested so successfully in my local environment would not blow up in production. You can read about that adventure here.

In addition to providing a snapshot in time of my rapidly evolving project, Jenny also asked lots of thoughtful questions during our live demo, both about the features and where this project could go next. I think these are great questions anyone should consider if they’re planning to take a vibe-coded project to production.

UI & Product Overview

Karen, your UI looks quite different from the last version I saw. Can you walk me through what’s changed?

I got feedback that the previous iteration felt too technical and included lots of duplicate action buttons. So, I took a step back and simplified the Dashboard, which now focuses on just four key functions—discover newsletters, manage newsletters, create a digest, and get a preset—as well as the Create Digest screen. I removed visual clutter by adding tooltips for text and removing redundant buttons and links.

---

Discovery & Semantic Search

Let’s talk about discovery mode. I see you can discover new newsletters, but where’s that data coming from?

This is where things get interesting. The last version used the Serper API to fetch Google search results and then filter them by criteria like publication date, but users said it was slow and didn’t surface enough results. One of the folks testing the tool suggested trying semantic search, and, after some initial research, I decided it was worth a try.

For this version, I scraped about a thousand newsletters and put them into a vector database for semantic search. My collection focuses on AI and technology right now, but if people like this approach, I can expand it to create a larger, curated piece of Substack focusing on newsletters that are active and proven, not ones that were published for two weeks and disappeared.

Note: Since building out the vector database and sharing the details here, I’ve heard from some readers who wonder if a vector database will really offer that much more than Google search, which does provide good coverage of articles that are optimized for SEO. I am currently running tests with standardized queries to objectively compare the results.

Wait, you’re using a vector database and semantic matching? How did you learn all that?

I knew relational databases, but vector databases were new to me. I’m still wrapping my head around it, honestly. But, again, I had one user who strongly recommended semantic search and others who struggled with the keyword search feature, so I accepted the challenge. At least in my testing, search is faster and the quality of the results is dramatically better now. I’m using sentence transformers to give each article a similarity ranking from 0 to 100. Most results on a digest show between 50-100% similarity based on the semantic search.

This is impressive because even senior developers don’t actively consider such solutions. You’re advancing yourself to tackle a problem most would handle traditionally.

Well, perhaps I just don’t know how difficult some things are, so I’m willing to try them! But really, when I found out the search quality improvement could be so significant, I knew it was worth the learning curve.

Walk me through how someone actually uses this. Say I want to find newsletters about AI agents.

When you type in a search query like “how to use AI agents,” you get two options: newsletters and articles. Let’s start by picking newsletters.
The newsletters populate based on semantic search. They are ranked by how closely they match your query. You can preview recent posts from each newsletter to get a feel for their content. Then with a single click, you can add them to your library, assign categories, and organize them into collections. The categories are preset for now, but you can create custom collections—maybe ten newsletters about ChatGPT or recipes—and give them custom names.

I noticed you can also search articles, not just newsletters.

Exactly. The articles use the same semantic search. In the future, you’ll be able to build custom reading lists just by clicking on articles. There’s a copy link function so you can grab URLs without opening each article.

---

Digest Creation

Show me how the digest creation works. This seems like the real magic.

We can set up a digest based on semantic search. Let’s say I search for “how to build AI agents.” The system shows newsletters ranked by relevance score—usually medium means 50% relevant or higher. Right now, I’m combining the relevance score with engagement, with a 70% weight for relevance and a 30% weight for combined comments and likes.

You can pick up to 10 summaries for featured articles, plus the top 40-50 results will appear as single links with a title and engagement data. There’s even an option for folks who don’t want AI processing; they can just get the links.

How are the summaries generated?

Articles assigned for summaries go to Claude Sonnet. I have a prompt in the backend explaining how to format them. It mostly follows the prompt and outputs nicely formatted HTML. Sometimes the AI misbehaves and makes errors, so I’ve got cleaning functions to ensure the formatted summaries look proper, not like chaos.

Note: Now I’m using Claude Haiku, which is faster and generally more available than Sonnet.

The progress bar during digest creation is interesting. What’s happening behind the scenes?

That’s a JavaScript polling function receiving messages from the Celery backend. Every time it gets a certain message, it pops up information on the screen. If you’re writing a digest and it’s taking a while, you’re reassured it hasn’t died. That’s probably been the hardest part to get working correctly.

I was impressed when you mentioned using Celery in your last article. That’s enterprise-level implementation.

I used it for Good Bloggy, my previous project, so I knew how to implement it. But yes, it’s been challenging. The good news is that it makes the whole system much more robust and user-friendly.

---

Data Management

Let’s talk about data management. How do you handle importing newsletters?

There are multiple ways. You can scrape from your Substack subscriptions using a bookmarklet that finds all newsletters on your subscription page. You can also paste URLs directly, and there’s an automatic categorization feature using Claude Haiku that looks at newsletters and assigns appropriate categories.

Do you preserve digests? What if users want to reference old ones?

Everything’s preserved unless you manually delete it. Right now, I don’t have storage limits, though eventually I’ll need to address that when server space becomes an issue. The digests as they stand are space-efficient—tiny HTML pages with simple CSS, no visual elements. Some users are using this feature to create reading lists they can paste at the end of their Substack articles.

---

Business & Audience

Let’s talk business. Who are your main audiences, and what features would they pay for?

There are two main audiences. First, readers doing personal research who subscribe to newsletters but don’t have time to read them all.
Note: Recently, I’ve discovered that readers are also looking for curated collections of newsletters, sort of like Spotify playlists but for reading. This is now on the roadmap.

Second, publishers want to curate newsletters on different topics and create formatted digests they can drop into Substack. I’ve also talked to folks interested in aggregating not just Substack but Beehive and other platforms to create hybrid collections.

The publisher-side features are what people seem more willing to pay for. For hardcore readers, maybe five bucks a month, but I want to keep the reader side seriously free.

What about adding other platforms beyond Substack?

That’s a heavy lift. Every RSS feed has its own weird format and data structure. You have to update every function that deals with that structure. I’d probably need to pre-process different platforms to look like Substack feeds so I can feed them into existing functions instead of writing separate code for each platform.

I want to be sure there’s demand and that the Substack part is polished before tackling that challenge.

---

Costs & Productivity

How much have you spent building this?

Claude Code is the single most expensive thing; I’m 10 times faster with it, so I’m OK paying for it, at least for now.

Hosting runs about $100 monthly for this and my other projects. I’m probably going to need to kill a couple of projects just to nudge costs a bit lower. The API calls for StackDigest itself are cheap, just fractions of a penny per call, maybe five or six bucks monthly. AI access is really on its way to being commoditized.

You mentioned moving from copy-paste coding to Claude Code. What’s the difference in your productivity?

I spent about a year doing cut-and-paste with my previous project, Good Bloggy. I was teaching myself to code while working full-time. That was educational—I definitely learned a whole lot—but slow. It took months to get things set up.

With Claude Code, the model still makes errors and does annoying things, but because it can see your whole codebase and you can direct it to specific files, the results are dramatically better. I just have to be careful to commit when the project is in a good state, because sometimes Claude changes too much, and you have to trash everything.

---

Roadmap & Scaling

What’s your timeline for production readiness?

I’d like to add another 5,000-10,000 newsletters to the vector database so semantic search is really robust. I want to add a feature for people to nominate newsletters—maybe they enjoy one or started one and have been faithfully publishing for months. That could help grow the database organically.
Monday will be a big test; everything with the vector database is running locally right now, so I need to migrate it to production. Hopefully, it goes well, though it might take a while to get it to behave. Then I’ll implement features my helpful testers have requested. That may take a couple of weeks. Once that’s done, I’ll pause and see if I can market it.

Note: OMG, the migration took three days instead of one afternoon, but it is working now.

What if demand is low after all this work? Or what if it’s so popular it overwhelms your servers?

If there’s no demand, I’ll release it as an open-source project on GitHub, like I plan to do with Good Bloggy. It’s another platform I thought was super awesome, but nobody else wanted. In that case, I’d keep StackDigest as my own pet project locally and publish the code so others can explore or implement it themselves.

If it gets overwhelming traffic, I’d need to look at scaling the backend. If people weren’t paying, I’d say, “Okay, now we need to chip in to keep this alive.” I might institute waitlists or digest limits; if someone has 1,000 newsletters, I might have to say you can’t run a digest on all of them. But honestly, that would be a really good problem to have—things crashing due to excess demand!

---

Advice & Reflections

After everything you’ve learned, what’s your number one piece of advice for domain experts wanting to build tools with AI?

Domain expertise is really important. If you have a really clear vision of what you want to do, I’d say start by documenting it in detail. Be really specific about outcomes, what it would look and feel like as a user. Even have AI mock-up fake screens. Only once you have a really clear, specific vision should you start coding with AI to make it alive.

With Good Bloggy, I just started building without planning much, and it became an unholy mess. With StackDigest, I wrote a spec and was much more methodical. That’s been far more efficient. When I have a new feature now, I write it out and spec it out, really trying to think it through before building to see what happens.

Any final thoughts on using semantic search to solve newsletter discovery?

For me, semantic search feels a lot easier than using Substack’s discovery pages or going through Google. I don’t want to click into hundreds of links to find what I want. Ultimately, I’m planning to use it to create interesting reading lists for my own articles. I think, especially for people browsing in their own field, this is going to be really useful.

If you’re curious, StackDigest is live (and free to test) at stackdigest.io

---

Final Words

Reading through Karen’s journey, what strikes me most isn’t her rapid mastery of complex technologies, though building vector databases and semantic search from scratch is genuinely impressive.

It’s her approach to not knowing.

Most builders hesitate when they hit the edges of their knowledge. Karen? She accepts challenges precisely because she doesn’t know they’re supposed to be difficult. That willingness to try “impossible” things, combined with genuine care for her users, is what makes vibe coding builders like her so powerful.

Karen represents something essential about this movement: domain experts who refuse to let technical barriers define what’s possible. She’s not building to show off her skills, she’s building because she sees problems that need solving, and AI collaboration has made the “how” finally achievable.

From copywriting to vector databases, from XCode hobby projects to enterprise-level search infrastructure, Karen’s story proves that curiosity plus AI assistance can take you anywhere you’re willing to explore.

If Karen’s fearless building spirit resonates with you, connect with her. She’s exactly the kind of collaborator who makes everyone around her better.

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 “impossible” technical challenge have you been avoiding?
What would you build if you stopped worrying about not knowing how?

Karen went from copywriter to vector database architect by simply refusing to let complexity intimidate her. What will your breakthrough be?

— Jenny