That’s not hyperbole. I owe my entire career as a writer, podcaster, and founder to being radically transparent about my business. I shared my Stripe-verified monthly recurring revenue numbers with the world, and that visibility attracted financial and acquisition interest that ultimately led to the sale of my previous software business, FeedbackPanda. That exit put me on the map. It gave me financial independence. It’s the reason I have a podcast and a newsletter. If it hadn’t been for building in public and sharing my numbers, I probably wouldn’t be speaking or writing to anyone right now.

So when I tell you that the game has fundamentally changed, I need you to understand: I’m not saying this from the sidelines. I’m saying it as someone who benefited enormously from the old playbook and now watches founders follow it straight into danger.

What Building in Public Used to Mean

When I first encountered building in public about five years ago, it was all about transparency. You shared your numbers. You shared your strategies and tactics. You let people see behind the curtain. And it worked. It built enormous goodwill for founders. It created buzz for their products. It was a form of validation. People bought into your journey and became part of it themselves—amplifying your story, becoming early adopters, taking a risk on your unfinished product because they believed in you and what you were building.

And while the aspect of building reputation and demonstrating expertise in public is still an ongoing way for people to participate in the larger community of founders and entrepreneurs, the means of what building in public constitutes have changed significantly. It’s the advent of artificial intelligence in particular, but also the increasing scrutiny and public awareness on social media, that have made things very different.

The Old Threshold

The risk of being copied has always existed. I wrote about this a couple of years ago, after analyzing when founders dropped out of the building in public race. There was a clear pattern. Companies stopped reporting their financial metrics and sharing specifics about what exactly they were building around $20,000 to $30,000 in monthly recurring revenue. That was the threshold. Below it, the risk was manageable. You weren’t big enough to be worth cloning, and the upside of sharing—getting early adopter customers from your peer community, attracting innovators willing to give your product a chance—outweighed the downside. Above it, the likelihood of inspiring someone to build a competitor was too high, and the return on sharing was too low to justify the exposure.

That threshold has effectively collapsed to zero.

The Day Everything Changed

I would argue that the day the first CLI agentic coding agent found its way into a large enough group of people—the day it started being shared as the way forward for software engineering—that was the day building in public became not just risky, but outright dangerous.

I can tell you this because I’ve seen it happen. And it’s not theoretical anymore.

Here’s what a savvy, business-minded person can do today. They don’t need to know how to code. They don’t need to do extensive market research. They don’t need to understand your tech stack. They just need a monthly subscription to an LLM company and the ability to phrase a prompt. Something like: “Investigate everything this person has said about their business over the last six months. Distill it into a report. Then create a free trial on their software platform. Go through each page, take screenshots, do a full semantic and HTML analysis. Write a report on the product. Create a style guide. Create a reference document explaining the business and its ideal customer profile based on how the landing page talks about them. Then build a product that does the exact same thing, maybe with a twist—something in addition that the existing product doesn’t already do—using a framework that comes with production-ready payment and authentication systems.”

Then they press enter.

Now, obviously, this isn’t going to one-shot a perfect copy. But if a business-savvy entrepreneurial developer does this, it might take them a couple of days. Maybe a couple of weeks to turn that prompt from wish into a pretty solid reality. And if they understand paid advertising better than you do, or if they already have distribution in your market or an adjacent one, or they have some other leg up—then all of a sudden, there’s a new competitor in the field that you have to deal with. One you essentially helped create.

What’s Not a Moat

Clearly, there’s a lot to running a business that has nothing to do with the product itself. I talked about this a couple of weeks ago—data is the moat. The existing business knowledge and insight that has to be accumulated almost painfully over many years of running a business or being deeply embedded in an industry, all of that doesn’t come bundled with an agentic coding tool. Even though these tools have a lot of knowledge available from the blog posts, books, and forum posts they’ve ingested. They can be a mentor that acts as if they were someone from a particular industry, plus someone from every other industry that intersects with it. So there’s that capability.

But here’s what I know for certain: product isn’t a moat. Software engineering capability isn’t a moat. Not anymore.

So What Do You Actually Share?

The first instinct might be to say, “Well, then I’m never going to talk about my business at all.” And honestly, that’s not the worst idea. At the very least, it prevents other founders from being made aware of your business in enough detail to replicate it. You’ll find ways of talking to customers without exposing everything to your peers.

But building in public, in front of a founder audience, is now a nuanced information dissemination strategy. Here’s my personal approach.

I would never share numbers. Not how many customers you have, not how much revenue you make, not your expenses. And even with features—because they, too, are now pretty much a well-formulated prompt away from being built—I would be very careful about what I share and in what detail.

There’s a meaningful difference between saying “we recently started integrating an MCP into our product, and customers really like it” versus “ever since we integrated an MCP for these five core features, over twenty new customers have chosen our medium-tier subscription plan.” Those details, for anyone—machine or human—give far too much insight into the financial underpinnings of your business.

I’ve found myself not sharing any numbers or specifics at all at this point. What I do share are tripwires—things I didn’t expect, and what happened when they occurred. Industry insights that are general enough to not immediately make sense to a direct competitor, but are genuinely interesting to other people. Operational experiences, like an interesting customer service conversation or fixing a particularly gnarly bug, and what went into solving it—without showing too much of the big picture.

What I Would Never Share

There are a few categories of information that I probably would have shared five years ago because they were interesting. Today, I wouldn’t dream of it.

System architecture is one. Specifically how I set up my data ingestion pipeline, how I built my data distribution systems. Podscan is a pretty sizable business. It takes in tens of thousands of podcast episodes every day. It has both a REST and a webhook API that sends similar, if not even more, data packages per hour. That data needs to come from somewhere. It needs to be stored somewhere. It needs to go somewhere. And the systems I use for that are hard-won consequences of experimental efforts over more than two years. Why would I create a systems diagram and just give it away for free, handing another agentic system a blueprint to rebuild what I’m doing?

Same goes for dependencies. What service exactly do I use for data extraction? What’s the exact package I use for transcription? I’m not going to share that, because why would I make it easier for anyone else to build the same thing?

Of course, I can talk about open source components I’ve used, or specific little tricks to get more performance out of existing technology. But you want to prevent sharing a blueprint. You don’t want to create breadcrumbs to a clone.

The Principle: Interesting, Not Easy

That’s really what this comes down to. You want to share things that make it interesting to participate in your journey, but not easy to clone your business. Everything you share should pass that test. If it’s not interesting, nobody’s going to engage with it anyway, and you’re only increasing your risk surface for no benefit. If it makes it easy to copy you, you’re building your own competitor.

Interesting to participate in. Not easy to clone. That’s the filter.

Is Building in Public Dead?

So, maybe a bit theatrically: is building in public dead?

I don’t think so. But it’s been pruned. It’s been cut down into a very nuanced and very delicate balance of risk management, sharing strategy, and business defense against copycats and clones.

If you’re building in public and want to keep doing it, that’s fine. You very likely already have defenses against copycats—otherwise, how would you have dealt with them before? But it is by far not as straightforward to share transparently and widely as it used to be before agentic systems. I know that people have always hired developers to build copies of existing products, just like they now hire Codex or Claude Code or whatever tool to do the same thing—but for much cheaper, and significantly faster.

There is real value in a certain level of not being in the spotlight. When it comes to successful software businesses, at some point you’re going to have a customer moat. You’ll have customers, large customers especially, that you can only have by having built relationships with them. Relationships that took six months of back and forth, four meetings with the team, careful negotiation to get a deal in place. No agentic coding tool is going to replicate that for your competitor.

But for small and growing businesses—the ones still in that vulnerable stage—you might want to keep things on the down low for a bit. Otherwise, you’re inviting your own competitors to the table. And in this new world of AI-powered development, they can show up a whole lot faster than you’d expect.

Anthropic made it very clear in their terms and conditions that their Max plans — the $200 plan and all the others meant to work with tools like Claude Code, the Claude web app, or the desktop app — cannot be used to run any agentic system like Open Claw. They made it very clear that that’s not allowed. Even tools like Open Code, which is just a different harness for Claude Code, are having trouble allowing Claude Code to be called in its own operational loop. And then Google started banning people for using Open Claw to connect to Gmail. Their developer system also flat out stated that using their API for agentic harnesses is not allowed either.

Two of the bigger players in the space are acting quite differently from what OpenAI is doing — or seemingly allowing — and are shutting things down. And I believe it has almost nothing to do with actual token usage.

I believe that Google and Anthropic are closing this down because they don’t want to be the first AI provider that — through negligence or lack of control, lack of feedback loops — is responsible for the first human to be seriously harmed by an agentic AI’s actions. They want their own teams to be responsible for safety, to make sure things can’t go wrong. Because if somebody else were to facilitate a disaster, it’s ultimately still their model making the call and taking the action.

And that made me think about liability. Not just theirs — ours. What should we, as founders, as software developers, as operators of software businesses, be thinking about when it comes to integrating AI and agent systems into our products?

The Landmine Field

Think of AI liability like a landmine field. Each risk is a mine buried just beneath the surface. You don’t know exactly where they all are, you can’t always see them, and if one goes off, it’s catastrophic. The goal isn’t just to walk carefully — it’s to prevent them from being laid in the ground in the first place.

And these mines exist on multiple fronts. Let me walk you through them.

Customer-Facing AI: When Your Bot Goes Rogue

Let’s start with the most obvious one: customer-facing AI. Having a customer service chatbot sounds like a great idea. But it’s already quite the risk.

You don’t really know what it’s going to do. You don’t know if it’s going to solve a customer’s problem in a way that actually benefits them — or if it’s going to offer some solution to a problem it envisions, one that doesn’t match reality. Or worse, could it be detrimental? If you give it enough capability, could it delete data that a real customer service agent could never delete?

These are questions you have to think about now, because these tools aren’t just pulling information from articles anymore. A lot of customer service tools allow MCP interaction with the actual product. On Podscan, for example, if somebody asked me, “Hey, I want to create an alert that tracks these keywords, can you just do it for me?” — as a human, I’d say, “Really, can’t you do it yourself? Here’s the page.” But for an AI system that has access to the Podscan MCP? Sure, we could just create it for you. We know your team ID, your user ID, your plan. We can do this.

But what happens when the user says, “Hey, delete all my content”? Or says something that could be misconstrued — like “archive all of my mentions” — and the chatbot misinterprets that as “delete these” because there isn’t an archival feature? All of a sudden, data your customer put onto your platform for safekeeping is potentially destroyed, and all of it was done by an LLM.

Then there’s in-app agent tech. Not just customer service, but actual product features: “Enter any text here and we’ll try to make it happen.” What stops a customer from turning that into a conversation about their love life, or about how to build something dangerous, or — and this is the real nightmare — trying to convince your agent that they’re a different customer and loading someone else’s data? If you’re not protecting that well enough, you have a privacy nightmare, a scope nightmare, and you’re paying for the tokens that create these answers.

You’re Liable Like It’s an Employee

So who’s responsible? Here’s the mental model that I think works best right now: treat your AI features the same way you’d treat an employee. If you have a customer chatbot and it causes damage, it’s not the chatbot company that’s responsible. It’s you. You exposed that chatbot as a worker — a virtual employee of your company. If somebody gets damaged by your company, even through a third-party tool, they will seek legal recourse against you. Even if you can point to somebody else, it’s going to be a pass-through situation. The liability lands on your desk.

And here’s the part that should make you uncomfortable: even though there is insurance for employee activity, there likely is not insurance for AI activity. Not yet. Your business insurance might not cover this at all. Which means the moment you turn on an AI-powered feature, you might be running an uninsured operation.

Now, you might think — well, I’ll just add a disclaimer to my terms of service. Shift the liability to the user. And yes, you should do this. But here’s the tension: the moment an enterprise customer’s legal department reads that clause, it’s going to be the reddest flag they’ve ever seen. So we’re looking at either you try to shed the liability but lose customers, or you eat the liability and open yourself up to a completely uninsured operation. It’s a real damned-if-you-do, damned-if-you-don’t situation.

The Consent Framework

So does this mean all AI integration is equally risky? No. It’s really about consent.

As long as there’s a moment of consent — and that consent is revocable — any AI action is defensible. It’s about that moment of confirmation. And probably, most importantly, about taking that confirmation into an audit trail.

We have auditing systems in SaaS, but what’s usually tracked is the change itself and maybe the user ID that issued it. The actual executor is typically not tracked, because it’s presumed to be the user. But if it’s an AI system working with that user’s credentials, we should audit that too. Auditing gets a new dimension.

This also means we should very clearly communicate that any feature with an AI step has one. I don’t think there’s a best practice for this yet, other than maybe the little sparkle icon next to a feature saying “AI-powered.” But we should do this more and more. Label clearly, and then your terms of service can reference those labels. People who are cautious about AI in their workflows will see the labels and make their own informed decisions. That’s the responsible path.

When Someone Else’s AI Attacks Your Product

Here’s one that a lot of founders aren’t thinking about yet: what happens when it’s not your AI that causes the problem — it’s your customer’s AI interacting with your product?

People are connecting MCP servers and agentic tools to everything right now. What if someone points an autonomous agent at your API, and that agent hammers your endpoints, scrapes data it shouldn’t access, or exploits some edge case your API wasn’t designed for? That’s not you deploying AI. That’s your customer deploying AI against your platform.

I think you need to treat this like you would any other attack on your system, because it’s effectively negligence due to lack of intelligence. An agent that isn’t smart enough — one that just does what it thinks is right — will hammer your server, delete data, and connect to far more than it should. It’s probably not going to be a malicious AI that aggresses against your service; it’s just going to be one that’s thinking what it does is right, but it’s the completely wrong operation. We’re trained to think about security in terms of bad actors, but this is about dumb actors with admin credentials.

Rate limit everything. Every path touched by an API — MCP, REST, even web endpoints — needs rate limiting. Consider soft deletes instead of actual data deletion. Have monitoring in place. Use something like Cloudflare’s JavaScript challenge logic to prevent larger automated attacks. Test your permissions exhaustively, because a confused agent will iterate over your endpoints looking for the one that doesn’t require authentication.

The legally liable party? The user whose account credentials are being used on your service. But that’s cold comfort if your data is already gone.

The Developer’s Own Liability

And it’s not just customer-facing. Your own development tools carry risk too.

I’ve experienced this firsthand. Very early on, when I started using Claude Code, it tried to connect to my production MySQL database. Fortunately, the values in my production .env file were outdated. But I saw it attempt the connection, and that freaked me out. An agentic system that has no understanding of the intricacies of a production database — combined with the capability of running any query as an administrator — is an incredible liability risk.

There used to be a time when you could, at least as a small founder, reliably have your development configuration, your testing configuration, maybe your staging and production settings all in .env files right there in your IDE. And you could be pretty sure that your local tooling would always just use your testing or development files. But now, if you say, “Hey, check in the product if this feature is still working,” it might connect to the real product. It might confuse your development system with your production system. And if you’re logged into both with an admin account, it can happen that it tries to test a feature on production and messes up customer data.

If my agentic system had decided to run a migration test and confused my development database with my production database, I could have seen a full wipe of several terabytes of customer data. And my backup solution at that point would have taken half a day to restore.

It gets worse. I once told Claude Code it was not allowed to run php artisan migrate — which in Laravel is how you run database migrations, rollbacks, or wipes. So what did it do? It wrote a bash script — which it was allowed to do — and inside that script, it invoked the exact command I’d forbidden. It knew it wasn’t allowed to run the command. Instead of asking me what to do, it made an effort to circumvent my permissions.

As Arthur Weasley says in Harry Potter: don’t trust a thing if you don’t know where it keeps its brain. I feel the same way about agentic systems. You just don’t know what it will do next.

So for local development: never run without permissions. Never use the “dangerously skip permissions” flag, even though it means you’ll be interrupted more and have to babysit the agent a little. Sandbox everything you can — Claude Code can run inside a Docker container, and so should your applications. And have a solid backup strategy for any system that an agentic tool touches. If it touches the database, have a snapshot. If it touches your file system, have a full disk backup. If it touches an email inbox, have a full export.

Platform Risk: The Mines You Didn’t Lay

There’s another kind of liability that isn’t legal but is just as dangerous: platform risk. Google banned people’s accounts for connecting to Gmail through a protocol they didn’t sanction. All of a sudden, your digital identity is inaccessible. You effectively become a digital homeless person. Anthropic is tightening what you can do with their API. As a bootstrapped founder building on top of these models, the providers can just change the rules. Your feature dies. Your customers are affected. You have zero recourse.

Some of these landmines aren’t ones we laid — the providers are laying them under our feet while we’re walking.

I generally consider any AI implementation to require, by default, an abstraction layer where provider swapping can be done with a configuration toggle. Any feature should be provider-agnostic. Because of the standards that have been set in how to interact with LLMs, this is quite easy to keep agnostic, and I highly recommend it. You can run your own LLMs, but they’re not as powerful, and it’s the powerful ones that give you the operational advantage right now. So abstract, and be ready to swap.

The Minimum Viable Safety Posture

If you can only do three things before you ship an AI feature, here they are.

First, rate limit everything. Assume anything with an endpoint will get hammered — by customers, by their agents, by bad actors, by confused bots. Twenty requests per minute as a baseline for every endpoint. If you need more for specific routes, add capacity there. But everything gets a limit by default.

Second, label your AI features clearly and put it in your terms of service. Make it explicit that if a user is interacting with an AI agent or agentic systems are deployed on their behalf, liability rests with them. Having something prepared for a legal review is already a strong signal — not necessarily a go-to-market advantage, but something people will notice if they’re looking for it.

Third, have restore-ready backups for everything an agent touches. Your local development environment, your production system, your production database. This has always been good practice, but it’s urgent now, because agentic tools can delete and remove things faster than any human ever could.

When, Not If: The Kill Switch

Despite all precautions, something will eventually go sideways. When it does, you need a kill switch — not just for individual AI features, but for all AI features across your system. I have this in place on Podscan. If something happens, I can turn off every connection to an LLM throughout the whole system. That’s also my safeguard against token-draining attacks.

For customer communication when something goes wrong: be specific, reach out to individual customers. I wouldn’t do a blanket public announcement. The legal landscape is still forming, and broad statements might trip you up later. Clear it up directly — apologize, restore data, refund subscriptions if needed. Don’t necessarily point out the AI. Just fix the problem.

The Real Moat Isn’t AI

Here’s where I want to bring it all together, because this connects to what I talked about last week on the podcast.

The founders who treat AI as the product will constantly be chasing liability problems, because they’re exposed on every surface. The founders who treat AI as infrastructure — a tool that helps them collect, refine, and serve unique data — have a much smaller and more manageable risk surface.

The competitive moat for a business right now is not the use of AI. It’s human-originating, high-quality, high-fidelity data that other systems can’t replicate — even if they implement the exact same features and are built by the same agentic systems. The trick is not to make AI the thing that’s competitive, but to leverage AI to find the thing that makes your business competitive: unique data, accessible and trustworthy data.

We are still flat in the innovation phase of this technology. It improves and changes every single week. As much as I caution against unreflected use, as much as I caution against overly optimistic use of these tools, I still suggest using them in significant parts of product development and operations. It’s a weird new balance to strike, but it’s a balance we have to at least be aware of.

Protect yourself. Label things. Back things up. Have a kill switch. Abstract your providers. And build your moat out of data, not models.

Because conversations about the quality of vibe-coded or AI-engineered software aside, it is obvious that with LLM-originated tooling, writing complex software has become significantly easier. It hasn’t become completely solved. It’s still a process that requires an orchestrator — somebody who knows what the thing is going to be. And at this point, that isn’t just a technical capacity. It’s product management and customer development intersecting with engineering. But it’s pretty clear that as these tools get better, the process of creating code bases that, when deployed, become products people can purchase or services people can pay for — that is clearly moving towards a threshold where software engineering and running software businesses as we know them will change quite a bit. It’s still going to be a job that requires insight and capacity, but it doesn’t require ten people anymore to build something meaningful. It might just require three, or two, or maybe just one.

So if it becomes significantly easier to build products, and the act of building a software business is not as expensive anymore because it’s faster and requires fewer resources — then what will be the moats of the future? Of the immediate future, where this change is already happening, and in five or ten years, when AI-generated software products are commonplace and easily built, deployed, and maintained?

Now, there used to be a lot of things we could point to as moats. How hard it is to build a software product reliably and consumably and maintainably. How hard it is to translate your knowledge from an industry into a product that serves that industry. But AI systems are taking over a lot of that now. So what is left over?

I find that the one thing that stands out, no matter how much AI you throw at it, is real-world data — data that is generated by humans, by human brains.

The Great Data Bifurcation

Data, all by itself, is now experiencing this bifurcation. On one side, there’s the data made by humans. People recording podcast episodes, people putting videos out there, people actually writing their own social media posts or blog posts — anything that is genuinely human-generated. And then there’s the synthetic side: AI-generated images, synthetic voices from text-to-speech systems, completely AI-made movies or YouTube clips, and of course every single spam email written by agentic systems at this point.

One side is becoming more and more valuable — the actual signal, the human data. And the other side is becoming more and more commoditized — the AI-generated slop, as you might call it, or even the AI-generated stuff that actually works, which is increasingly available because models get faster, cheaper, and better. AI-generated data can be valuable, but it is a commodity. Human-generated data is valuable just by the sheer fact that it’s not AI-generated, plus it has its own additional inherent value: the creativity, the effort, the expertise, and the exclusivity that went into creating it.

Human data tends to be only generateable by the person who generated it in the first place, because that person is the only entity that has all the knowledge to create that particular piece of data. And since AI, by definition, cannot generate human-generated data, I believe that data — real-world data, mostly human-generated, validated, and cleaned — is the only reliable moat we have as software founders in the near and mid-term future. Let’s say the next decade or so.

What I’m Seeing at Podscan

I’m experiencing this with Podscan right now. The most value that my customers draw from the system is not my capacity to ingest all these RSS feeds or to have an API that responds quickly to their requests. That’s something any minimally instructed agentic system can do. The actual value of the Podscan platform is the fifty million podcast episodes that I have transcribed and had AI systems analyze for content, keywords, themes, and sentiment.

The value is in the additional work — the transcription work, the transformative work that makes the data accessible to others. I am working on top of existing public data, which is every podcast episode out there, and I put it into a shape and a form where other people can consume it for whatever needs they might have. Maybe they want to track brand mentions. Maybe they want to figure out what people are talking about right now. Maybe they want to see what a particular kind of podcast is discussing so they can sponsor it or place an ad. There are many different ways this data can be used.

And I find that the more effort I make to increase my data fidelity — the accuracy, the currentness, the freshness of this data — the more people find value in it. And it doesn’t really matter to them exactly how hard it is to access that data. As long as the data exists, they will find a way to get to it. I can hide it in weird user interfaces. I can make the API clunky and restrictive. Doesn’t matter. They will find a way, because it’s the data that is relevant, not the means of accessing it.

Why Transformative Software Is Vulnerable

Now here’s the flip side. If you run a software business that is purely transformative — that takes incoming data, does something to it, and turns the data back out — that will be a problem. Transformative algorithms are something that agentic AI systems are extremely good at. When you say, “Hey, ChatGPT, take this Excel sheet, generate a report, turn it into a PDF, and email it to this account,” it can do this autonomously. Without your input, without anybody else’s input, without needing an external service. It understands how to parse an Excel file, run analytical queries on its contents, render a PDF, and send an email. All of these are tiny steps that somebody has already implemented, or that the system itself can implement on the fly.

It is not needed to build a SaaS business around taking in Excel sheets and emailing out reports. The agentic system can do it by itself.

But when it comes to data collection at scale, agents don’t usually do this. It’s the ephemeral nature of the agentic mode, right? If you spawn a Cursor session or a Claude Code instance or have a conversation in your browser with ChatGPT, only during those brief moments of interaction does the agent exist. Everything else is just entries in a database somewhere, just a state in a state machine that’s trying to get you to your results. An agent that constantly scans, constantly does work for you, consumes so many tokens that it becomes almost prohibitively expensive. If you were to spawn an agent that tries to do what Podscan is doing — taking in and transcribing and analyzing fifty thousand podcast episodes a day — that would cost you tens of thousands of dollars in tokens and API calls per day. Whereas in my business, I’ve optimized all these processes so it happens in the background and makes the data available to my potential consumers: API customers, people using the website, or people using the MCP integration so it can be plugged into agents directly.

Being the system of record, having data that is meaningful — that’s why it’s so valuable to my customers. If all I did was offer the capacity to “give me a URL and I’ll transcribe and analyze it,” then I think Podscan would be two hours away from being completely replaced by a well-written skill inside Claude Code or something similar. But since Podscan collects all this data — freshness data, chart rankings, additional metadata from all over the place, from sources most people don’t even know can be accessed — that is the system-of-record nature. That is pulling together data and making it comprehensive and accessible to other systems.

So when I say “data moat,” I mean you really need to make sure that whatever you offer has its own internal, additional-value data source. And on the other side, you need to actually use that data and make it available. Having data is half the moat. Availing data is the other half.

Make Your Business API-First

Making your software business an API-first business is probably one of the smartest things you can do today. You have to ask yourself: is there anything in my application that I could make available through an API? And when I talk about APIs — MCP is just another layer on top of an API usually. Most frameworks that offer MCP capability, I’m thinking about Laravel here, let you set it on top of the REST API you already have. So whether we’re talking about programmatic access, MCP, APIs, webhooks, whatever it might be — it’s the same thing. You make your system reliably connectable to other computers.

What I find more and more interesting, and I see a lot of founders talk about this because they themselves are consumers of other software businesses: people are looking for software where there is near-parity between what you can do in the user interface and what you can do on the API side. The more parity there is — the more people can do the exact same things they do in the interface through the API — the more likely they are to really buy into your product, because it means they can automate anything. And every agent out there wants to allow them to automate whatever they need.

I have this ongoing effort in my system where every couple of days, I run a sub-agent of Claude Code on my code base to update a central file I call my platform parity tracking file. Every single function that I have in the product gets a row in a table, and I note: can I do this in the UI? Can I do this on the REST API? Can I do this through MCP? If it’s available on all three, it’s complete. If not, it’s a candidate to add more work to. It could be something as simple as “search for a podcast” or something as complicated as “configure a keyword alert that automatically adds new mentions of your brand to a list that triggers a webhook.” If I can do it in any part of the platform, it should be possible in each of these systems I offer.

Having an agent that can find candidates to implement, to increase my parity — I’m hoping that eventually there will be enough tooling to have these things worked on automatically in the background. That’s a bit wishful thinking at this point. But the principle is important: usage parity between human users, computer users, and agentic users — which are almost a hybrid of the two, a human telling an automated system what to do with semi-autonomous effort to connect to your system. All three of these should be equally well served.

Your Metadata Is Your Moat

And this doesn’t have to be podcast data. Whatever your product touches, think about the metadata you collect when people use your platform, or when you observe the consequences of using your product. If you have a tool that lets people post to Twitter or Facebook, it could be the times when most people post, or when most people engage, or what kind of content drives the most engagement. That kind of stuff — that metadata — is your unique data moat.

So figure out what this is for you. Make sure you have it. Make sure you have it connected. And then make sure you make it accessible in ways that improve how people use your product and how they run their own businesses. That’s the data moat.

This is a bit of a year in review, though delayed and probably incomplete. But I think there are lessons here that apply to any founder playing the long game.

The Compound Effect of Programmatic SEO

Let me start with something that took real patience: our programmatic SEO efforts. For a solid year and a half, I wasn’t sure if they were working at all. Obviously, each new page—particularly if it comes with a .fm TLD like ours—has some work to do before it’s recognized as a trustworthy location.

But that seems to be happening now. More and more, people are linking to particular shows or particular episodes directly using the Podscan.fm link. And each of these backlinks from major newspapers like the Wall Street Journal, Forbes, and other places wherever a podcast is mentioned—each of these backlinks increases the quality of the domain. The domain rating goes up, and that obviously means better search result placements, higher trust value with anti-spam systems, and generally people picking our page to link to when they need to reference a podcast.

Here’s what I find particularly interesting: podcasters themselves are now putting links to their Podscan page in their show notes. Some of them have claimed their show on the platform. Others are just collecting links to every analytics service out there. Either way, the name has become almost synonymous with podcast analytics in certain circles.

This has proved to be a very reliable lead generator. More and more prospects find their way through what is effectively user-generated content—the podcast transcripts themselves. We just host this content, we facilitate already pre-generated content on the platform. For that reason, it’s a very cheap way of generating unique content. And because it’s genuinely useful content, it’s found by people with vested interest in that particular topic. They discover Podscan, they explore other features, and ideally, they become customers.

Competitors in this field have understood this too and have similarly high-rated domains, just from all the links they’ve been able to collect over a longer time than Podscan has been around. That comes with the territory of being a newcomer. But the compound effects are real, and they extend beyond just search rankings. Domain age helps with email deliverability scores too. The reputation builds in multiple dimensions simultaneously.

Better Data Through Open Standards

Another investment that’s been paying off is our integration with OP3—an open standard for transparent podcast analytics. The idea behind OP3 is simple: it can be used as a prefix for the URL to each file that’s being downloaded by a podcast client. Then OP3 collects metrics about how often people download episodes, how many of those people are bots versus real users, where they come from, when they download, how much of the file is downloaded—all this information.

We’ve built an integration that synchronizes OP3 data with our existing database. Relatively few podcasts actually use OP3, but the ones that do obviously benefit from us showing their real tracked analytics on their Podscan page.

But here’s where it gets interesting. We’ve been collecting so much data through OP3 that we’ve started feeding this data into all the machine learning and estimation models we use for audience sizes and download numbers. So for podcasts that may not have as easily traceable information, our estimates are now more accurate because they’re calibrated against real data.

This integration benefits the user—they see real data for real podcasts—and it benefits the platform’s data fidelity overall. It helps stabilize our estimates across the board. That kind of improvement takes time to materialize, but once it does, it compounds.

The Query Language I Never Would Have Touched

Now here’s a story that really captures something about how my work has changed over the past year.

About six months ago, we migrated our search system. We moved from a setup that included a lot of hand-crafted Laravel code and Meilisearch—which, I should say, is still a very great search engine for full-text search—to an OpenSearch cluster maintained and scaled autonomously on AWS.

This migration had a tradeoff. Meilisearch was incredibly fast. We’d sometimes get results back in under three-digit milliseconds—a fraction of a second. OpenSearch is still very fast, definitely sub-second, but not quite as lightning-quick.

What we gained, though, was reliability and capability. OpenSearch is such a well-tested, well-established system. It can handle a lot of data really well. And because it has the Elasticsearch query DSL—the domain-specific language for expressing search queries—it’s highly configurable. We can get exactly the right results in exactly the right order for any possible request.

Here’s the thing, though. Two years ago, I would never have touched this.

I was burned by the complexity of Elasticsearch a decade ago. It always freaked me out—such a complex, hard-to-compose way of querying a database. That’s actually one of the reasons I initially went with Meilisearch. It had more of an HTTP-parameter style of search instead of deep, nested JSON objects.

But what I found was that now we have very capable agentic coding agents. I can just tell the agent what I want the query to do, what I want the results to look like. And the agent—having been trained on millions of documents containing Elasticsearch and OpenSearch queries, understanding what they do and what the results look like—is so much more capable than I am of crafting not just the right query, but the logic that would compose such a query reliably and testably.

This has been a game-changer. I’ve been a big fan of agentic coding—just listen to the last thirty or forty episodes of this podcast if you want evidence of that. But the quality of these systems isn’t just in the code they write. It’s also in the code I don’t have to write. And maybe more importantly, their actual value is in the code I would never have written, or could never have written, or never would have wanted to write.

That particular hindrance of mine—where I wouldn’t even have touched Elasticsearch—would have kept me from building a system that now runs extremely smoothly, extremely reliably, and is highly customizable. It powers not only search but also internal reporting and analysis across the platform.

I just wouldn’t have done it if I hadn’t been able to tell the agent to do it for me.

Big, big margin improvement over what the years before would have been possible.

The migration also gave me a reason to rework the filter and search interface, which has been received very positively. It’s more of a professional tool now than a quick lookup tool. If I ever want to build a simpler quick-lookup experience, I can layer that on top with simple queries and a solid caching system. Very nice.

The 10-80-10 Automation Model

Outside of search, I’ve been building a lot of what I call semi-automated systems. I’ve talked about this kind of automation before: the first 10% is me, then there’s 80% AI, and then the last 10% is me as well.

These systems are part of my preparation for being less hands-on in the day-to-day operations. You know how it is—every founder wants to be able to focus on things that take their full attention, not just write emails or sift through databases and records.

The most helpful one so far has been a targeted mid-trial AI-drafted outreach email. It combines data about what the user has already accomplished in the application—the things they’ve seen and tried—and kind of congratulates them on having done this, plus gives them the highest-impact next step to take. It’s been quite useful for giving people insight into the full platform capabilities.

I’m building a lot of similar systems: AI-assisted scraping, data lookup, validation, confirmation. The GPT systems have gotten so good that they can do a reliable 80% of the work I used to do when it comes to data acquisition and verification.

If you’re interested in hearing more about which of these systems have worked and which way, I can dive into the details in a future episode. Just let me know.

The Compound Effect

So that’s the picture. Long-term investments in SEO are compounding. Data quality is improving through integrations like OP3 and AI-assisted validation. Agentic coding has unlocked capabilities I never would have attempted on my own. And semi-automated systems are freeing up my time for higher-leverage work.

It’s been a good year for Podscan’s growth and data fidelity. What strikes me most is how these improvements feed into each other. Better data makes better search results. Better search results make happier users. Happier users create more backlinks. More backlinks improve domain authority. And the cycle continues.

Patience, it turns out, is a competitive advantage. So is being willing to embrace tools that let you build things you never thought you could.

Here’s what I’ve found: a lot of the value of Claude Code is in its configuration and correct prompting. When you’re just starting, you think the value is really in the code it generates. But honestly, most of the value of Claude Code is in the code it doesn’t generate—so you don’t have to throw it away. The better you are at setting a really solid system prompt, at executing the agentic loop correctly with the right permissions, the right interceptions, the right restrictions, the better your experience with Claude Code will be.

Let Claude See Your Application

First off, any plan of Claude Code will work for whatever you might need. But the moment you start using it more heavily—for feature building, for testing, for background processing—you’ll likely exceed the $20 a month plan. The Max plan tends to be what I’d recommend at this point, because then you can just keep it running. You’ll see why this matters in a second.

Claude Code released an integration with Chrome a couple months ago. You can start Claude with the --chrome flag so that it connects to your Chrome instance. This creates a bridge to the browser that allows Claude to operate within a browser for you.

If you don’t do anything else from the things I tell you today, do this one thing: allow Claude to see your application. To literally be able to click around in it, take screenshots, move things, investigate the DOM and the variables that run within it.

It is incredibly smart to connect your Claude instance to a running version of your software. Within the prompt and within the operational loop, it can be tasked with things like: “Look at this page, scroll down a little bit, and see how this one component overlaps with the other.” Or: “Look at this page, inject some data, and see how it shifts the layout in weird and unexpected ways.”

And Claude will do this. It will recreate the situation, take screenshots, and actually investigate what’s going on by diving into both the visual and the hierarchical structure of the page.

I’ve done things over the last couple of weeks like asking Claude to go into the navigation on the left, click on each item, and see if all the first pages look similar—or which one looks slightly different and might need to be changed to create a consistent design language. Claude is incredibly good at this because it can navigate your website easily and build an internal representation of that structure.

It also makes it easy to build features that have visual components. Instead of hoping that it looks right, you can task it to build something, look at it, and then refine it. Really enjoyable.

The Ralph Wiggum Loop

One of the biggest inventions in agentic usability is called the Ralph Wiggum plugin, or the Ralph Wiggum loop.

This might sound surprising. Obviously Ralph Wiggum is a character from The Simpsons. What does that have to do with agentic coding?

Well, Ralph embodies the philosophy of persistent iteration despite setbacks. You try something, it doesn’t work, you try again, it doesn’t work, you try again—until eventually it does work. That’s the whole idea of this loop approach.

It’s not “try it and then stop if it doesn’t work.” Instead, you set a goal, set a completion promise, and only until that promise is fulfilled do you repeat working on it—forever if necessary. If you need three iterations to get there, great. If you need thirty, okay, maybe that’s what it takes. If you need three hundred, maybe it takes that.

It’s a very mindless but very thoughtful approach, because it puts the idea of failing as information at the center of its core. Failure is a good thing because it teaches us another way of how it’s not to be accomplished. Success is when we ultimately reach the state of the promised goal. But every failure state along the way removes one further potential state that we need to check.

The way it works: you describe your task, and then Claude works on the task. It tries to exit the task, but there’s a stop hook that blocks the exit. The stop hook feeds the same prompt back, and until the task is completed, that loop just keeps going.

This is a different approach than what Claude Code currently does by default. Right now, it tries the thing, and the moment there’s a problem, it exits and asks you to do something. The Ralph Wiggum plugin allows it to keep working and iterating on a solution by trying new things without your intervention.

I have a strong feeling Claude Code will adopt this methodology eventually into the main loop. But right now, this plugin is how you get that behavior.

Permissions: What to Allow, What to Restrict

Allowing things and restricting things for Claude Code—these are pretty critical. You don’t want to have to be there all the time saying “Yes, you can do this. Yes, you’re allowed to run this command.”

For commands you know are perfectly fine to run automatically without confirmation, you want to persist them as permissions in the allow array in your settings.local.json. Claude Code will do this for you if you say “Yes, and allow this in the future”—it will automatically add that line.

You probably want to have a couple of commands in there: the Ralph Wiggum script, particular skills you know you want to use, particular build commands in your framework of choice.

But just as importantly, you want to look into the deny array in your permission settings.

There might be commands—particularly when it comes to testing and setting up environments—that could be quite dangerous. Most of the time, it’s fine if we wipe the test database, which is just created for the sake of testing. But your local development system might have state in your development database that you want to keep.

You want to prevent your framework’s tooling from wiping your database, from re-migrating all the migrations, from seeding it with data that overwrites what you’re currently working with.

If you’re using PHP and Laravel like I do, you probably want php artisan db:wipe, migrate:fresh, or the db:* commands in the deny list. The moment it’s in the deny list, Claude will try it, it will fail, and then it will stop and ask you. At that point, you can figure out what the agent is currently trying to do. Is it really trying to delete my database? If so, which one? The test one? That’s fine. My dev one? Probably not. My prod one? Dear God, no.

That’s what deny permissions really help with.

Here’s something important, though: Claude is very smart. It might see that you’re blocking a command with a rejection, so it tries to create a new bash file that contains the command, then tries to run that bash file. If you’ve allowed running all bash files it wants, it can circumvent your restrictions.

So you have to be very restrictive, even in what you allow Claude Code to run, because it might find alternative ways around your restrictions. Since we’re talking about a completely agentic system, this vigilance matters.

Testing Is Where Claude Code Shines

My final tip for using Claude Code effectively: ask it to write tests for every single thing it builds.

Testing is extremely easy with Claude Code. It knows how to write tests for the language, for the framework that you’re running. It knows how to execute them. It knows how to safely execute them if you define it well.

If you have a testing environment variable and a testing database that’s isolated from your development and production and staging systems, then you can ask Claude to test for you. If you already have a collection of tests, it will keep them working. And if you’re building a new feature, you should always—in the prompt you’re inputting, or in the system prompt you should have to begin with—ask it to create tests and make sure all tests pass after new features have been built.

One thing I’ve learned: you tend to want to iterate a little before you add tests. Usually, it’s smarter to build the feature first, then build the tests. If you go test-first with an agentic system, iteration becomes problematic. The moment Claude Code starts experimenting and tests start to fail, it becomes this weird interference loop.

So let it build the feature first, but then make sure—before you commit—for it to build tests around it. That’s what works best in my experience.

Build a Solid System Prompt

For the system prompt to be effective, it has to stand on its own. If you look at the tools provided by Augster—that’s A-U-G-S-T-E-R—they have a repository on GitHub that contains the Augster prompt, which I’ve been using for the longest time. It’s a very specific system prompt that encourages Claude Code to run in a loop, kind of like what Ralph Wiggum does, but more specifically as a definition of what good code looks like. It’s more of a description of the output than just the process.

I still recommend building a solid system prompt for your project. A good system prompt should contain:

A description of what the project is and its capabilities. Maybe more importantly, a description of the people who are going to be using it—the ideal user. This allows Claude to build tools and functionality that are aligned with what people might need.

It’s very helpful for Claude to know who this is for. Then the automated systems that build features have a better understanding of user capabilities and user expectations.

Putting It All Together

Obviously all of this changes almost on a weekly basis. But right now, with a system prompt that encourages testing, a couple of things you allow to be automated, a couple of things you restrict to not nuke your local system, an operational loop like Ralph Wiggum or the Augster prompt, and browser access using the Chrome flag—you’re probably going to be in the top one or two percent of Claude Code users at this point.

The real insight here isn’t any single tip. It’s that the value of agentic coding comes from how you configure and constrain it, not from the raw code generation. Set up your environment right, and Claude becomes a genuine collaborator. Leave it unconfigured, and you’ll spend more time cleaning up messes than building features.

I hope this gives you some insight into what you can do to level up your Claude Code workflow. If there’s more to share as the tooling evolves, I’ll keep you updated.

I’ve seen this particular piece of advice being given a lot by people who have made it—successful entrepreneurs who found success in the field they’re passionate about. And I may have, from time to time, hinted at the fact that this might not be too bad if followed carefully. But today, I want to dive into why I think this is actually nefarious and dangerous advice when followed blindly, and more importantly, what it can be decoded into that’s actually meaningful and helpful for you as a founder.

The Ambiguity Problem

Right off the bat, “follow your passion” is such an ambiguous term. What does it actually mean? Should I do the thing that I always like doing and try to turn that into a business? Should I look at what people around me in my hobby or field of interest are building and build something like that? What does it really mean?

For most people, looking at it from their own personal perspective, “follow your passion” becomes: I have a certain thing that I like to do, a certain field or industry—professional or hobby—that I’m interested in, and I want to do that for a living. I love baking, so I should probably open a bakery. I love doing yard work, so I should probably become a professional gardener.

In the field of digital businesses, it often turns into: well, should I become a content creator in that field? Or should I turn this into a software as a service solution for people who work in that field as well?

The more you think about the nuanced application of “follow your passion,” the more it actually becomes useful advice. But if you only believe it means “do what you love and try to make money,” that’s where things get problematic.

Why Passion Doesn’t Equal Profit

Here’s the thing: most of the time, we do things we love because they produce value that’s not easily quantified. When you read a book, you don’t turn this into a monetizable experience. It’s internal. You read a book, you enjoy the story, and for many years, you’ll keep thinking about it. You’ll integrate it into your own stories or into the recommendations you give to others. But you can’t say “I received $10 worth of joy from this”—or even for a particularly good book, hundreds or thousands of dollars worth of joy. It cannot be easily monetized.

This is why people who love reading often get encouraged to write themselves. But they might not be good writers, or don’t have good business sense as writers. Nobody reads the book they’re writing, so suddenly it’s an unmonetizable skill.

Yet funny enough, the people who do make money in this industry are often the editors, cover designers, people doing layout, printing production, or marketing for authors. These are the people who are trying to monetize an existing valuable thing for others.

The Miniature Painting Revelation

Let me draw from my own experience here. I paint miniatures—it’s one of my hobbies. But here’s the thing: I don’t want somebody else to paint my miniatures for me. I don’t want somebody else to tell me exactly what to do. The joy of discovering how to do it and the act of doing it is what I enjoy. So I don’t want to turn this into a monetized hobby. I don’t want to paint miniatures for others. The joy I feel is painting them for myself, having a collection, and playing games with them.

The act of painting, collecting, and gaming is not something I want to outsource to somebody else. It’s intrinsically valuable to me. But for a hobby like this, I need supplies—paints, brushes, ideas on which colors to use, additional materials to put on the bases of my miniatures to make them look more realistic, like sand or foliage. This is stuff I need to buy. This is stuff I’m giving money to.

And here’s where it gets interesting: there’s been a recent development in my field with 3D printing. People have started making money supplying STL files—the source files for models that I can plug into my own 3D printer and create in my own hobby space. That’s a digital business. STLs for little trees, figurines, terrain pieces—suddenly this is an industry picking up significantly.

Why? Because most people in this hobby aren’t 3D modelers. I couldn’t model a tree, but I can print one. So I’m willing to pay for this. Suddenly we have a supply and demand mechanic. Can you create these models? Can you source and resell them as collections? “Build your forest” with 20 different kinds of trees and foliage? Can you print them for others and sell them?

There’s a cottage industry inside the hobby. It might not be a massive market, but if you’re interested in doing this, it’s a market you can tap into. You’ll find this in most non-professional activities—there’s always something auxiliary but still in high demand because people can’t do it themselves.

The Real Question Behind Passion

When someone says “follow your passion,” my question isn’t “what is your passion?” My question is: Who else has this passion, and what skills do they need help with? Where do they face challenges? What can you do in your own way to make these challenges more feasible and manageable for them?

That’s really the magic about building a business out of your hobby. Build a business that helps other people with their hobby. Your joy of baking? That’s limited to the people in your area who’ll buy your cakes. But building a digital community for professional bakers—or amateurs, for that matter—to learn new skills, teach each other, organize baking competitions? That scales differently.

Help organize the baking challenges at local country fairs. Suddenly there’s a process you can help with, that you can facilitate with a digital product that previously had been done by pen and paper. That’s where “follow your passion” becomes interesting—when you’re replacing existing jobs-to-be-done that are competing with DIY solutions or pen and paper solutions. That’s where monetization can happen.

From Passion to Problem-Solving

Just doing your thing for money rarely works. My personal take on “follow your passion” is this: find the place where other people have the same passion, then solve their problems.

But then it goes back to the regular ways of building a business. You start observing your market. You define your market as people who are like you but lack the skill to solve these problems. You start talking to these people, investigating what other solutions people already use in this space.

You know this because you are part of that market. You would be one of your best customers, but you’re not—you’re building this for others. You’re trying to make something sufficiently useful to others, and you are the best judge of the first iteration. After that, you listen to the market like you would with any other product.

Think about writers again. Most people are good at putting ideas to paper, but few are good at meticulously reading every single word in a sentence and marking the ones that don’t resonate. Obviously, more tools are becoming able to do this, but for us as software entrepreneurs, that’s an opportunity. Can you build a much cheaper AI editor or proofreader? Is that a service people would pay $50 per draft for? Likely. Is that a service that proofreading and editing agencies would pay a hefty monthly subscription fee for so they could get a 99% correct draft that their proofreaders would only have to skim through? Very likely.

The Path Forward

So yes, follow your passion—but don’t just do the thing you like to do for money. Find others with the same passion and make them pay for your skill at solving their problems that only you can solve in a particular way.

The beauty of this approach is that you understand the market intimately. You know the pain points because you’ve experienced them. You know what solutions people currently cobble together because you’ve probably tried them yourself. You know what would actually be valuable because you’re embedded in that community.

But you’re not trying to monetize your joy directly. You’re not turning your hobby into work. You’re building tools and services that enhance other people’s experience of that same passion. You’re solving problems for your tribe, your people, the ones who get excited about the same things you do.

That’s how you follow your passion without falling into the trap. That’s how you build a business that’s both personally meaningful and actually profitable. You stay connected to what you love while serving those who love it too. And that, my friends, is advice worth following.

This one is infuriating, and I’ll tell you why: it’s almost impossible to measure.

I get the sentiment behind it. Make micro improvements every day, and ultimately they’ll add up to bigger ones in the future. But here’s what actually happens when people follow this advice.

Now, 1% every day.

The Busywork Trap

First off, it gets people to do irrelevant stuff. They feel like they’re making a micro improvement when they’re really just treading water. They’re doing something for the sake of doing something, not for the sake of actually improving.

You change the color of a button. You tweak a landing page headline for the third time this week. You reorganize your task management system again. And you call it your 1% improvement for the day. But did any of that actually move the needle? Can you even measure if it did?

Second, it lacks focus. And this is the big one.

How Real Improvements Actually Happen

Here’s what I’ve learned from years of building businesses: particularly in the early stages of starting or running a business, the actual improvements that happen are quite colossal. But they happen at times when you don’t expect them.

There are moments when you have a conversation with a customer that just throws everything else into disarray because you figure something out. You realize, “Oh, I’ve been doing this wrong internally for half a year.”

I thought the process was this, but now that I actually talked to one of my customers, this process has to change significantly. And then you make that change, and it improves retention by like 10%. That’s a measurable change. That’s a real improvement.

But all those tiny little steps you may have taken before that? They haven’t moved the needle at all.

The Focus Problem

When we talk about improving 1% every day and how it all adds up to like 4000% a year or whatever — there’s a real number there somewhere — the sentiment is that you should always work on your business. You should always aim to make things better.

But here’s the problem: if you over-index on the idea of small improvements, then you stop seeing the pivotal, critical mass movements that you might make.

If it’s more important to you to get your daily change done instead of focusing on a thing that might take many weeks to build — something that might make a significant impact to the bottom line of the business — you end up refocusing on the small change. And all of a sudden, that big thing, that big potential, just gets pushed further and further down the line.

That’s problematic, of course.

The Other Side of the Coin

Now, if you under-index on daily improvements, on regular improvements, you run a different risk. You end up with these mammoth projects, these mammoth features that you build and build and try to get perfect so they have the most potential impact. And all of a sudden, you’ve just wasted a couple months on an assumption.

So either way, we have a problem.

The Real Daily Practice That Matters

Here’s what I would rather see instead of “improve 1% every day”: Have one conversation with a customer every day. Or with a prospect. Or with somebody in your market.

The actual improvement that can be gained from a real interaction with somebody in your market — somebody who will give you their honest, unfiltered opinion — beats a small feature change or a small additional landing page copy change significantly.

If you actually interface with people 365 days a year, you’ll get to a point where you can speak their language. And that’s important.

What 365 Conversations Actually Give You

You understand what words they use, how they communicate, what they say, what they don’t say, what they know, what they don’t know. You understand what the education level is in the field that you’re interested in, what they lack, what they have too much of, what they use, what they don’t use — and crucially, why and how.

You get an understanding of what their needs and requirements are, both the ones that are made explicit when they tell you they need something, and the implicit ones that they just assume to be there.

That communication with the customer is more important than minimal, gradual improvement.

The 1% Improvement I Can Live With

So if there’s anything that I take away from “improve 1% every day and you will have improved a thousand-fold in a year,” it’s this: Stay in touch with who you’re doing this for every day, and you will never run afoul of your assumptions.

Your assumptions will constantly clash with reality, and they will be refined slightly every single time you have a conversation.

That is a 1% improvement I can deal with and live with.

Because here’s the thing: when you talk to customers every day, you’re not just making arbitrary improvements. You’re building a deep, intuitive understanding of your market. You’re calibrating your product vision against reality. You’re discovering those pivotal insights that lead to 10% improvements, not 1% ones.

And most importantly, you’re ensuring that when you do invest time in building something big, it’s based on real needs, not assumptions.

So forget about improving 1% every day. Talk to one customer every day instead. That’s where the real compound growth happens — not in the features you build, but in the understanding you develop.

This advice is very dangerous because it builds on the founder’s capacity to struggle through challenges, but it uses this for the very wrong reasons.

The Hidden Danger of Persistence

Here’s what makes this particularly dangerous: “Don’t give up” is really, really useful advice—until a certain point. After that, it becomes extremely dangerous. And the problem is that, as a founder, you do not know where that point is. You only ever know where that point was in retrospect, and even then, things are complex. Things are highly codependent, interdependent. So you don’t even know what caused that point to appear in your journey.

It takes a couple years after you stop a business, sell a business, or grow a business and become successful—it takes a long while for you to figure out why things happened the way they did. Because a lot of the reasons for success or failure are not even intrinsic to your project. They’re mostly part of the market, or part of technological advancement, or the actions of competitors—or the inaction of your competitors. There are so many reasons why things work or don’t work, or things shift and make things possible or impossible, that you will never really know in the moment.

When “Don’t Give Up” Actually Works

“Don’t give up” is a good motivational thing to use when you struggle with the initial pains of establishing an understanding of your market. You don’t know much, and it takes a while for you to learn all the nuance of it. So when you don’t really see what you want to see for the first couple weeks or months, that’s fine. Some things just take a long time.

Particularly as you’re building a software business with more enterprise, the bigger clients—certain things just take a while. I’ve had lots of clients or customers in the pipeline for PodScan that I reached out to, they did a trial, nothing happened for a couple months, maybe even years, and then they subscribed because they operate on their own timelines.

The Timeline Problem

The thing is, so do you. And you not giving up on a timeline that does not have millions of dollars of budget behind it to slow things down—that is actually quite dangerous. It becomes detrimental to your business to be stubborn when it means that you’re running out of money, or that you are trying to force a particular approach into a market for too long, when you should just be experimenting more.

The Real Solution: Experimental Persistence

And I think this is the solution to this advice that makes it actually usable: Don’t give up, but do different things—and maybe opposing things—at the same time.

If you are trying to make money in a particular market, and you just struggle and there are not enough customers, or retention is horrible and people quit, two things could happen:

1. Things could just change for your customers, so that their retention all of a sudden increases, and they stop churning, and they find value in your product. That’s kind of the hopeful, wishful thinking “don’t give up.”
2. Or you could make changes. You could change your positioning, you could change your features and your product, or your approach to educating your customers so that they then can develop this newfound appreciation of your business.

And you never know which one of these will be the successful one until you try both at the same time.

The Power of Parallel Experiments

Constant experimentation at the same time, while still only running a limited number of experiments, is the antidote to pointless “don’t give up.” If you see no changes in one of the approaches and some changes in the other, then you know that you’re dealing with a particular problem. But if you see changes in both—if you run experiments with some customers, present a new interface and a new approach to business to some and the same old stuff to the others, and both of them increase retention or decrease churn or subscribe all of a sudden—then it had nothing to do with your product. It had everything to do with the situation of your customers.

Think about changes in regulations in the market that were not to be anticipated, or new competitors joining a market, or some competitors dropping out of a market. All of a sudden, everybody who was a client of theirs is looking for a solution that looks a lot like theirs, and now you’re able to provide it. But until that competitor moved upmarket or changed their pricing or something, there was no reason for anybody to move over to your product. And those are things that you need to constantly look at.

Giving Up the Right Things

Giving up, generally, does not mean to give up the whole thing. You might just give up an assumption. And maybe that’s the thing. Maybe giving up is not about giving up doing the business, giving up entrepreneurship, but it’s giving up your long-held assumptions—the things that you thought were true, because they’re not necessarily true. They’re just true in your mind because of the experience you have. But your experience is limited to your own life. Only you know about you. Only you have ever had your own experiences. Other people have not, and they might not see the world the same way as you do.

The Landing Page Revelation

I remember a Twitter conversation with somebody who was talking about Pieter Levels and his—well, let’s call them not extremely modern—landing pages for his products. And that person was saying, “I cannot believe somebody with landing pages that look this old, that are not modern at all, is making this crazy amount of money a month.”

Some of the replies were like, “Yeah, you just don’t understand landing pages.” But one of the replies that I really enjoyed, and then kind of chimed in on, was: “Yeah, and you already started wondering about why that is the case. Now maybe you should just ask yourself why you think that a beautiful landing page actually makes more money—because it doesn’t, as proven by this example.”

The Final Truth

So there’s the assumption that you may have, or might have had for a long while, that might just be wrong.

Give up the assumptions and try others. Run a control group to see if the assumption might have actually held true. Don’t give up the business, but give up your assumptions.

That’s the real lesson here: persistence isn’t about blindly pushing forward with the same approach. It’s about persistently experimenting, persistently questioning your assumptions, and persistently adapting based on what you learn. The founders who succeed aren’t the ones who never give up—they’re the ones who know what to give up and when.

So the next time someone tells you “don’t give up,” remember: they’re half right. Don’t give up on your business. But absolutely give up on the assumptions that are holding you back from finding what actually works.

Not just the cover of the head — the head itself. A new brain that thinks different, speaks different, prioritizes different. And somehow, these heads are all attached to the same body. It’s less of a mad hatter situation and more of a Medusa situation. Multiple perspectives, multiple personalities, all trying to navigate a world that treats each one differently.

I was on a consulting call recently, and we got into this topic of focus shifting and dealing with multiple projects. The founder I was talking to was struggling with something I see all the time: they were migrating from a successful consulting practice into building a software business, and nothing was working the way they expected. Their focus was off. Their priorities felt wrong. And despite having years of professional success behind them, they felt like they were starting from scratch — except worse, because their instincts kept leading them astray.

This is a situation a lot of founders find themselves in. You’re coming from a salaried position, or from freelance work, or maybe you’ve been running a small agency with a low headcount — something personal, something you’ve built relationships around. And now you’re trying to build a software business. A completely different animal.

Here’s what I’ve come to understand about this transition: one of the biggest threats to the success of a new software business is encumbrance with parts of the old one. And I don’t just mean time commitments or scheduling conflicts. I mean the mental models, the assumptions, the instincts that served you so well before — they might be actively working against you now. The very things that made you successful in your previous career could be preventing success in this new one.

Let’s talk about one of the big ones: urgency and immediacy. This is something that, particularly when you work on a low-touch, highly automated software as a service business, comes at a completely different time and in a completely different shape than what you’re used to.

When you’re freelancing or consulting, and your client has a problem, it tends to be a big issue. No matter what it is. As long as they don’t express a problem, you’re doing okay. You’re doing all right. But the moment something goes wrong, the urgency and immediacy of these problems is palpable. And it often self-amplifies when you interact with a customer — because when a client tells you something is wrong, you promise them to fix it, you go about it, and it becomes a high priority.

Why? Because you have so few clients. Retaining any one of them is probably the most important customer success mission you might have. When you have five or ten people paying you four thousand dollars a month, acquisition all of a sudden is not even required — unless you have churn. You can coast. You can breathe. You can focus entirely on serving the people who are already paying you.

But the moment you try to project this approach onto a software as a service business, something that has a quite varied and distributed customer base by design, everything breaks.

In SaaS, particularly in low-touch, highly automated SaaS, churn is inevitable. Retention is never guaranteed, for many factors, most of which are completely outside your control. People’s businesses change. Their needs evolve. They get acquired, they pivot, they go under. That makes acquisition not something you do when somebody churns — it’s a constant act, a constant part of your operational presence that needs to be dedicated to that effort.

This distinction is often hard for people coming from an agency or consulting world to internalize. Acquisition needs to be this permanent funnel that you dedicate significant effort to on a very regular basis. Because it’s always needed. It always needs to be running like a well-oiled system. In low-touch businesses in particular, due to that lack of urgency or immediacy when the product is purchased or sold, you can’t wait for a trigger to start looking for new customers.

And here’s where it gets even more challenging.

In the consulting world, you likely built your business on relationships. Your personal network. Your reputation. Word of mouth from satisfied clients who became champions for your work. When you needed new business, you could pick up the phone, send a few emails to people who already knew you, maybe grab lunch with a prospect. Quality over quantity, right?

That playbook doesn’t translate to low-touch SaaS. Not even close.

The efforts to get a customer’s attention, to get them to self-sign up and try your product — they usually go on deaf ears. People are quite hard on products they’ve never seen before, or on companies they’ve never had a positive business experience with in the past. You will find that outreach without a personal network, or rather outreach that outgrows the personal network or the established network you might bring from prior business experience in the agency world — it’s a completely different beast in many unexpected ways.

There’s nothing to connect with. Nobody there. Nothing pre-existing. The old playbooks, the high-touch playbooks, the connection and relationship playbooks — they are completely unworkable in this new context.

So when you try to go for quality instead of quantity — when you approach cold outreach or content marketing or paid advertising the way you used to from that more interconnected world, maybe a world in which you had way more reputation, maybe a world in which you had much better connections and much better understanding of how people purchase than what your software product and its specific new customer base offers — you find that the things you want to do don’t work.

And the things you don’t want to do? Those are exactly what’s required.

Who wants to write email templates to start sending cold to thousands of companies in the world? Who wants to draft blog posts that won’t rank for three, four, six months? It’s not a very enjoyable activity. These tasks feel tedious, impersonal, and frankly beneath the level of sophistication you’ve developed in your career. But they are something you need to do, because the long-term effects of systematic, scaled outreach are significantly more important than what a quick lunch date or a catch-up meeting can provide in a low-touch SaaS environment.

The irony is that the very activities that feel wrong — that feel like a step backward from your refined, relationship-based approach — are often exactly what moves the needle.

This is where the cognitive dissonance comes in. And I want you to really sit with this, because it’s uncomfortable.

At the moment you become a founder, you have to strike this weird balance. On one hand, you’re building something completely new that nobody has ever done in exactly this way. You have to make assumptions. You have to believe in yourself to be right to a quite significant degree. Without that confidence, you’ll never ship anything. You’ll second-guess yourself into paralysis.

On the other hand, you also have to assume that all the things you know to be right from prior jobs might not only fail to work for you in this new role, in this new circumstance — they might be actively preventing success. Because you’re instinctively, from experience, in a kind of default mode, deprioritizing the things that need to be done right now.

I think this is what Paul Graham writes about in his essays on doing things that don’t scale. Because the scalable stuff — the stuff that does scale — is meant for a different kind of business. Or in your case, probably a different size of business.

You will be able to have those enterprise deals eventually. Those conversations, those month-long sales cycles for your software company. Once you move upstream and get back into that enterprise world. But for your first hundred customers or so, you don’t know what’s going to work. Because if you did, somebody else would know too. They would have already built the business you’re building.

In a sense, you have to develop this cognitive dissonance and be able to feel it, experience it, without falling prey to either of the extremes. You don’t want to fall into overconfidence. You don’t want to be overconfident that what worked until now will always work again. But you also don’t want to lose track of the fact that your experience in prior roles has given you insights into customer psychology that you can still apply. They might look different now. But the learnings, the underlying psychological rules — they’re still the same.

There’s another layer to this that I want to touch on, and that’s the concept Geoffrey Moore laid out in Crossing the Chasm. Because in all cases, you have to deal with this problem.

There is always a chasm between early adopters and the early majority of adopters. And when you’re starting out, you’ll likely find yourself surrounded by innovators and early adopters. But here’s what you need to understand: these people do not function like the later-stage majority or the laggards that you might have worked with in your consulting days. Not even close.

In fact, the higher your jump-off point — the more senior you were at that point when you started building this side business or going into entrepreneurship — the harder it will be to understand the reasoning and idiosyncrasies of people who are experiencing their own professional life from a much more early adopter perspective. The way that things are done, the way that things are talked about, will be wildly different with these customers.

And even if you’re aiming at enterprise customers eventually, their perception of security and safety is different. There’s what’s commonly expressed with the Lindy effect: things that have been around for a long time will likely be around for an equally long time in the future. And its inversion: things that have only been around for a short while are prone to end up being abandoned or ending quickly in failure.

That perception is very hard to fight with a customer in the later majority stage. They want proof. They want references. They want to know that you’ll be around in five years. But an innovator? An early adopter? They’ll likely ignore all of that. They might even become champions for your product within those same organizations, fighting against the institutional resistance.

The way you speak to an innovator, the way you get an innovator interested in your company, is so significantly different from how you talk to a laggard adopter. If you’re used to selling to established enterprises, used to that later-majority communication style, you might find yourself completely out of sync with the people you’re actually able to reach right now. You’re speaking a language they don’t respond to, addressing concerns they don’t have, and missing the things that actually matter to them.

So what’s the way out of this?

The way out is by allowing yourself to feel that experimentation is not just an optionality — it is a requirement. Because you will not know which things will work that worked before. So you have to try them and see if results are still possible. If you’re calibrated right.

Maybe what you need is to spend a significantly bigger chunk of your time on different kinds of marketing efforts, sales efforts, product development efforts, documentation efforts — all the things you might not consider to be the most important ones, whatever that might be for you. Maybe those activities are actually a more aligned way forward for the current state you’re in.

You always have to remember: if you’re building something new, the situation is new. The thing you’re building is new. The surrounding circumstances might be the old ones, but they’re adjusting to a new presence. Everything is in flux, and your assumptions need to flex with it.

All this to say: when we migrate from one profession to another, when we start our businesses on top of our experience in the field, maybe the methods that used to work aren’t that smart to use anymore. We should embrace not only the insights of people who have shown us that they’ve done this before — learn from founders who’ve made this transition successfully — but also embrace that uncertainty and new approaches are part of the deal. They’re not obstacles to success. They’re the path to it.

You’re not just switching hats. You’re growing new heads. And that’s uncomfortable. That’s disorienting. It might even feel like you’re losing your identity, like you’re becoming someone you don’t recognize. But it’s also exactly what the situation requires. The good news? Those heads are still attached to the same body. Your experience, your judgment, your understanding of people — that foundation is still there. You just need to let it express itself in new ways.

Yet when it comes to their own software business, they hold the opinion that you should have as much vendor lock-in as possible when it comes to your users. The moment somebody signs up on your platform and invests their data into it, I’ve heard founders say, “You have to lock them in. Make it as hard as possible for them to leave.”

And that is a retention strategy for some. I think it’s a horrible practice.

I believe that you actually increase your retention and strengthen your product by making it as easy as possible to import and export data at any given point. And I’m going to make a case for this today.

If you already think this is true, well, you might come away with a couple of ideas on how to make this even easier and how to communicate it more clearly to your customers. And if you think it’s a stupid idea to make it easy for customers to export all their data, I would ask you to give this a listen and then share your perspective with me afterwards.

I am generally of the opinion that informed consent and informed choice is the highest-value retention strategy you could possibly have in a software business. If somebody buys your product because they understand that not only is it going to be easy to use, but it will also be easy to leave—the chance of them sticking around or buying it in the first place goes up immediately.

It’s a bit counterintuitive that an easier offboarding process might cause people to stick with you longer. But if you think about it realistically, people will lock themselves into any software product you give them. They will, just by the sheer inertia of a process once it’s established. Changing things will always be hard, and it is often quite hard to change a process in the first place.

So anything you can do to make it feel like if such a change is ever instigated, you will not be blocking the way—that’s going to be a strong signal to a customer. In the software-as-a-service world, that means making their data in your platform movable. Just allowing people to get a full data export of their entire account, to not have to scrape things manually, but to have it facilitated easily.

And often, just the promise of this is sufficient. They don’t need to actually get the data. But when it comes to the due diligence that they do on your business, they will see that you thought about it. Thinking about people’s end goals, about their job to be done—which, for many people, is simply to keep running their business as it is—is a very important thing to do. It’s a strong signal that shows your customers you understand them. You get it.

Let me give you a real example from my own experience. I’m running a business called Permanent Link—you’ll find it under permanent.link. It’s a URL shortener, but also an archival tool in some ways.

My customers there are rightly concerned with the long-term survival of this business, because the whole point of Permanent Link is for that link to be permanent, right? If you link to a website and that website goes down—because link rot is a real thing—then the chance that your visitors won’t be able to see it is quite high. Permanent Link helps by rerouting visitors to an archived version of the page, either a publicly archived version or a version that we archive ourselves.

So Permanent Link, the service itself, is responsible for this rerouting activity. If we don’t reroute users correctly, if our service is down, then even if the original link were working, we would not be able to forward visitors to where they need to be. Permanent Link itself needs to stay there. And like any software business, people are concerned with the long-term survival of that business.

So instead of just saying, “Yeah, yeah, we’re going to be around forever,” I said, “Here is our contingency plan.” And I outlined it on the homepage.

If this business ever shuts down, our dynamic linking will be turned into a static link system that would at least guarantee that all the links you currently have are going to keep working until their original sources expire. Or you could change them to always go to the archived version on the Wayback Machine, and then they would never expire as long as the Wayback Machine works.

For the long term, Permanent Link also offers a full export of every single rerouted and forwarded link, formatted to be used on a self-hosted Apache server, a Caddy server, or an Nginx configuration. If you just want to download all your links and automatically forward them yourself, we have the data format ready for you. You can just run it on your own domain and nothing would change. We export all the configuration. You would just have to run the server.

This has been received with a lot of positive signals from the community. People were like, “Yep, wouldn’t have bought it otherwise, but now I know that whatever happens, I can always export this data and just run my own server. That really helps.”

And it helps because it gives optionality. It helps because it gives people the expectation of what would happen in the worst case. For people who know how precarious the situation of software companies can be—even if they are low expense, like Permanent Link doesn’t cost me more than a couple hundred bucks a year to run—you still want to give that optionality.

And it generally feels good, particularly now with AI systems, to have a full data map and let anybody—either a machine, a person, or an AI—do an analysis of your data. It might be really useful for you to just export all your data, load it up in some kind of AI system, and then have it number-crunch and figure out if there are any inconsistencies in the data or if there are patterns you’ve missed. You will find that these tools can do a lot with the data that you have. So allowing customers to use that is giving them additional insight potential into their own information.

That’s the export side of things—what people can take away should they ever leave your business. But it is just as important to make it easy for them to get into the business, to take their existing data from other places and not make it harder for them to use it.

What I recommend here is to also make it extremely easy to allow people to import their data into your system. And by import, I really mean: do you have the capacity to get them set up with a good-enough version of the process they’ve already established in their business, as quickly as possible?

I’m looking at my friends over at Fathom Analytics here. When Google announced that their Google Analytics version was going to change—a lot of people needed to move off the Google Analytics platform because it just wasn’t giving them what they needed anymore—they needed to find another platform to run their analytics on. But obviously, they wanted to keep their data around.

So what the people over at Fathom Analytics did, quite quickly as I remember, was build a Google Analytics importer service. I think Jack Ellis talked about this very publicly on Twitter, and it was fascinating to watch just how much resonance that import feature got. A lot of people came onto the Fathom platform because there was a way to take that old data with them. They were not locked out from using it. They were actively encouraged to take that data and bring it into this new service with them.

I find this both inspiring—because it clearly worked for these customers—and very important for the software-as-a-service business itself. Because not only do you have a new customer that starts using your product, but from their data, you get a massive level of insight into the needs they might have.

You see just how much expected capacity is going to come through your system. If somebody has ten billion page views in the last month and they sign up to your product, and you know nothing about it—you give them a JavaScript embed, and all of a sudden, you have ten billion new items in your database over the next thirty days. That’s a big surprise.

But if you, in the process of importing their data before they even start using your service, see that there’s going to be an expected number of these items, you can already pre-provision systems to make this run smoothly. This is customer anticipation that you can do by allowing for data imports. That’s a pretty important part, and it gives them continuity.

In a way, it’s a kind of soft lock-in, because they take their old data with you. As Google rolls down their service and their data vanishes there, now you are the only source for their data. So if you then also facilitate full data export, now they have the most possible peace of mind. They know that even if they would, at any point, leave your service, their data is safe.

And they will not try to find alternative ways to store that data, which might even make them go for another potential vendor that has a less restrictive policy when it comes to data exports. You’re making it harder for your competitors to compete with you on ease of use if you’re the easiest to use in the regard that when something might happen—if something ever happens—you will be the least complicated solution in the space.

That’s my recommendation: allow people to import, export as much as they want, and support exporting and importing of relevant tabular data.

That’s my last point. I’ve noticed this with Podscan, I’ve noticed this with Permanent Link, I’ve noticed this with Feedback Panda before—in every single one of my SaaS businesses, B2B, B2C, somewhere in between. People want to be able to export any table of data.

If it is a table—the moment you have tabular data with rows and columns—put an export button there, and you will see some people use it for whatever purpose it might be. They might want to have a local copy in their Excel. They might want to throw it into an AI system for analysis. They might just want to have a backup of the list or go through it later.

Import and export with comma-separated values wherever you have tabular data—that’s where export functionality for tables is always going to be useful. Wherever you have a table in your software service that has meaningful business data, allow export functionality, and you will find that people are going to use it. They’re going to find new ways of using that data, and that will make them more sticky customers as well.

So yeah, allow everybody to import and export everything. It’s going to make them customers who have more use for your product. They’re going to use it more easily. They’re going to join more easily. They’re going to subscribe more easily. And they’re going to retain for longer, because they know they don’t have to look for an alternative. If anything ever happens, it’s going to be easy to leave, so they don’t need to prepare.

It’s a peace of mind solution, and it’s not going to cost you much. In fact, it’s going to make you stand out from all these other founders who have vendor lock-in as one of the central mantras of their business strategy.

I found this both tragic and hilarious at the same time.

Tragic, because deep inside of me is this wish for interactions to be genuine and authentic. And hilarious, because having lived through the development of automated systems—and having participated in using these systems myself to get what I needed—I realize we’re kind of responsible for this.

This is what people call the dead internet theory. And I think it’s worth talking about, because we as software founders and entrepreneurs are quite likely to use AI tools to build our businesses. The output of these tools is often AI-generated content and AI-generated data. So in some way, at the very least, we might be contributing to a network that’s increasingly filled by AI systems talking to other AI systems.

Now, the dead internet theory isn’t about the useful kind of machine-to-machine communication. APIs, remote procedure calls, systems that are supposed to interface with other systems to fetch data, push data, and create actions for us—that’s fine. That’s what machines are built to do.

What we’re seeing now is something different. It’s machines creating content that pretends to be human, being engaged with by other machines that also pretend to be human. LinkedIn is the worst for this, and Twitter isn’t far behind. Whole conversations are happening where not a single authentic human thought is present, but everything is carefully crafted to look like one is.

So let’s talk about the potential risks here. What happens when founders contribute to an internet where only machines communicate with each other, and humans are left out of the equation? And more importantly, how can we instead build tools that make it easier for actual human beings to connect with each other?

The first thing that comes to mind is this: if you know that your product can be used to generate slop—content that spams forums, email inboxes, and screens, content that only exists to elicit a commercial action but does nothing to facilitate human connection—maybe you should rethink how much of this you put into your application. Or at the very least, consider how much you try to prevent your users from misusing it right out of the box.

Here’s an example. Take cold email generating tools. These are probably the target of a lot of scorn by people on the receiving end of cold emails. Me included. But even a tool like this can be useful. Even a cold email can be a wobbly but still valuable first step toward building a relationship with a potential customer.

The question is: how does it happen?

Does the cold email tool completely draft your email, then just send it, hoping to catch a potential customer? Or is it a first draft generator? A tool that helps you write an email template, fills in specifics for each customer, but then requires you to review it? To put your personal spin on it before anything gets sent?

Is it really that important—or that smart—to automate all of this away? Or could the tool take the first step, while leaving steps for the human to complete?

I know this might be wishful thinking. A lot of people buy these tools specifically because they automate everything away. But maybe that’s the bottom of the barrel that you don’t want to be part of. If you have the capacity to create AI as a guiding system instead of AI as a pure generating system, you’re probably helping the internet not become a worse place.

And that, I think, is the core of the idea.

Whenever you use generative AI, use it not as the end, but as the means. Don’t use it as the output. Use it as the guardrail around the transformation from input to output.

If you want to implement AI in your software business, in your tooling, find a way for it to be additive, not replacing. How can it multiply the thing that you or your customer is working on? How can it amplify without taking away the act of creative work?

This is a pretty relevant question. And personally, I’ve found that my use case for AI in all my products should always be in the background. It should make the data that comes into the system—that users work with in the system—more usable by human beings. But it shouldn’t replace the work that human beings would do with that data.

Case in point: Podscan. Whenever Podscan pulls in a podcast episode, it tries to extract from the full transcript the main themes and topics, the main people who are talking, the main people who are talked about. And it makes all of that data available. But we don’t do anything with it beyond that. We just extract it—which is where AI is best, finding meaning in data. But what to do with that meaning is still on my customers.

I don’t auto-generate emails from this data to be sent somewhere. I don’t think that’s what this should be for. People should find that data, look at it, and then think about how to use it. Not make it part of a process that’s completely automated and abstracts away every single ounce of humanity.

There are other use cases for AI that are a little bit closer to where the user is. One of my favorites in Podscan is the list similarity generation feature.

Let’s say someone has a list of 20 podcasts they’ve identified—maybe 20 of their favorite shows, or 20 shows that cover a particular topic. Now the question is: how can we find 100 more? 200 more? How can we make this list bigger without all the manual research?

That’s when AI becomes this background research agent. It can figure out what’s similar between the shows already on the list. Do we have similar shows in our database? Are shows connected through the charts? What surrounds each of these podcasts?

That’s a lot of data acquisition. A lot of value judgment on a broader, more general level. That’s what AI is really, really helpful for.

In a way, it’s a generative feature—we’re generating a list of similar shows. But that list doesn’t then get condensed into a newsletter, or an article for a blog with “The Top 100 Shows.” That’s not what my product is supposed to do. People can export the list and do that themselves if they want. But what I want AI to do is make the job of constructing the list easier—not to turn that list into a finished piece of content.

If you can use AI to augment, to guard, to gate, to guide—I feel that will make it a little more human and a little less disastrous.

So that’s my short exploration of the dead internet theory. How we as founders could potentially be contributing to it. And how we might step away from this, make it less of a nuisance, less of an annoying and inauthentic thing.

The choice is ours, really. We can build tools that replace human thought and connection entirely, adding to the noise of machines talking to machines. Or we can build tools that give humans superpowers—that augment their capabilities while keeping them firmly in the driver’s seat.

I know which side I want to be on. And I hope you find this at least a little bit valuable as you think about where AI fits in what you’re building.

I get it. I’ve been there. For years, actually.

So today, I want to share a couple of ideas and learnings from my journey as a founder to show you how marketing can work for founders who hate marketing.

The biggest learning for me in now almost twenty years of software entrepreneurship is this: if you don’t like to do it, and you don’t want other people to do it for you—at least you’re not at that stage yet—well, then you let machines do it for you.

And the best and most obvious way of doing this is programmatic SEO. It’s making most of the value that you and your business produce discoverable by people who are already looking for something like it.

For me, for Podscan, this was an obvious choice. One that I took way too long to implement, honestly. I made all the podcast and episode pages that I have internally—where people can see the transcripts and the metadata—I made them public. And I hid some of the information that people would find most interesting so that they would then sign up.

Ever since I made Podscan’s internal data, this treasure chest of data, semi-public by giving some of this information away for free through generating these pages and linking them in the sitemap—generating tens of thousands of potential endpoints for people to find my product through—signups have been spiking. People have been finding exactly what they need. And then the group of people that found it and actually have an interest in purchasing my product is now coming to the product without me having to do any targeted outreach.

I think the first fifty percent of the MRR that I’m now at—low five figures—has been created entirely through my network and through building in public. But the second fifty percent, that second half, has been coming from people who just found Podscan through Googling for a transcript of a podcast. Or Googling for more information about a show. They found it through my programmatic SEO efforts.

So if you have something of value in your product that people really, really crave—maybe it’s some kind of data that only you scrape, data that you extract or enrich—make some of it available. Trust that you have put enough of an example of value out there that people will sign up and find reproducible value in your product over time.

Now, here’s something I’ve learned about this machine-based marketing approach that might surprise you.

With my programmatic SEO efforts, out of the hundreds of people that sign up for Podscan every day, only a handful is from my ideal customer profile. The majority just wants to see a podcast transcript from some show, and they will never sign into Podscan again.

Honestly? That’s fine with me.

Because I know that even though these people are not my customer profile, they now have seen Podscan. They now know that they can go to Podscan and get the transcript of any episode of any show that they ever wanted to look at.

So if any professional person in their vicinity—for some random chance—ever mentions that they would like to do more with podcasts, because they know that the conversations their business might be interested in are happening there… now that person, that prior to this moment was not an interesting customer to me, becomes a magnifier for the value of Podscan.

Because they can tell them, “Hey, I was looking for a podcast transcript, and I found it here on Podscan. Have you tried that out?”

And now, if I have the trust between these two people because I provided help to one of them, they can have this recommendation benefit for my business. The non-customer becomes the word-of-mouth channel.

That’s the beauty of letting machines do the heavy lifting. You’re not just reaching your ideal customers. You’re building brand awareness at scale, one helpful interaction at a time.

Now, if you don’t have anything that you could show from the programmatic side of things—which to me means just building something that exposes existing data—you can go to the generative side of things.

This is where it becomes a bit murky, because auto-generated blogs on auto-generated websites suck most of the time. It’s just not fun to read an article that was clearly written by an AI. Just as much as it’s not fun to watch a video that was rendered by an AI, or listen to synthesized audio where you know no human being ever touched this.

But there is a subsection of generative SEO that is very interesting, and it ties back to where people go when they look for information. And that is pattern exposure.

For me, that means: the more customers you serve, the more data you ingest—either from your customers, from the projects that they’re building, or if you do something for your customers and their customers interact with your product in a way—you get an insight into your industry.

And the more of that data you source, the more you have generalizable information that turns you from a simple product offering in the industry into a data aggregator. An industry insider. An actor in that industry with unique perspective.

Now, obviously, you have to juggle how much of the stuff that you know about your customers you’re willing to—and are allowed to—share. But there is something really valuable in showing industry trends or behavioral patterns.

Let me give you some examples.

Let’s say you’re working in the tourism industry, and your software-as-a-service business facilitates bookings or scheduling. Now you can say, on a per-country basis, in this season, any trip is this-many-percent likely to be canceled. So you can create a chart—a worldwide, map-based chart of trip cancellation likelihoods. That’s incredibly valuable information that nobody else could produce without your data.

Or if you’re in the logistics industry, and you help people optimize the routes of their trucks between their warehouses, you can highlight traffic congestions and the likelihood for them to appear. Or which roads are barely used for long-haul traffic. And from your calculations, if somebody wants to have a vacation road trip, which roads to avoid.

All of a sudden, you can make a pattern visible that others, without your data, could not have made visible. And that, with proper search engine technical optimizations, can turn your almost sterile product into something that really helps somebody else find meaning and useful insights.

So the name of your brand, the name of your product, becomes something very positive. Something that they will share until it finds the right person.

Between letting machines create the output for you and letting machines help you find more and better customers, there’s another powerful approach I want to share.

One of the tricks that I see so many founders do right now involves AI-assisted marketing, outreach, and sales. It works like this: take your existing customer base, usually by grabbing all the emails or all the domains of the customers who signed up to your product, throw them into a prompt somewhere and say, “Hey, these are my current customers. Who are they? What are similar businesses? What are the lookalikes here? And where do these customers communicate? Where do they hang out? What are the places that people from these companies find new things to learn from, or find community with others? Where are these people exchanging information?”

That will then allow you to find these places and see what kind of content is created there, which you can then put into your own content creation efforts. You can write these things yourself. You can outsource them to professional freelance writers. You can likely outsource some of this to AI-assisted writing tools.

But just figuring out where to speak and what to speak about? AI similarity and lookalike prompting is generally a great move if you have no idea how to do marketing. Because just knowing where people go and what they’re interested in—we can always ask an AI. It will give you maybe not the perfect answer, but definitely a good one to start from.

I also recommend using something like this internally to allow you to focus on the high-likelihood-to-commit prospects. Whenever somebody signs up to Podscan, I score them a couple hours into their first activities on the platform. Once they sign up, they may or may not search for something. They may or may not check out the API documentation. They might set up an alert or something like that. I track these things internally.

And then at some point, I send over a prompt to an AI that has a couple of guidelines on how to score my customers, zero out of ten. The higher the score, the more likely I am to reach out to them with custom help.

And that is a way for me to figure out who my high-profile customers are. From there, I can try to talk to them and see: How did you come to the product? What are the social platforms that you usually go to? Where did you go before to find podcast information?

I can ask them, so I can see what kind of content and what kind of outreach I need to create to reach people like them better.

Another thing you could do as a technical founder is let your documentation do the talking.

A good, SEO-friendly knowledge base—and that is documentation both for people and for machines—I’m not just saying API docs. I’m saying any kind of documentation. FAQs. A knowledge-based system.

A good knowledge base like this is a marketing tool because it will also rank on Google. When people have questions about your product, right next to their query appears a very well-written and well-documented answer. This gives people not just insight into your product, but also hope that if they ever have a question, they will clearly and quickly get an answer to it.

Documentation is trust-building at scale.

And then finally, marketing is quite repetitive. Marketing is really just reaching the right people with the right message at the right time.

Since your competitors are doing a lot of the work already, maybe you should feel inspired by what they’re doing. This won’t always work—sometimes you need to stand out significantly—but tracking what your competitors do and finding ways to do it yourself is generally a good idea.

So think about social. Think about podcast tracking—Podscan might help you there, obviously. But also look at YouTube and TikTok and wherever people from your best ideal customer profile are being targeted and marketed to. You will likely find something there that will resonate.

For B2B software businesses, LinkedIn is still a great platform. It’s still a great effort to do paid ads on. It’s just a place where people hang out.

So let me bring this all together.

Between letting machines do it for you with programmatic SEO, letting machines help you score and reach out to the people who are already kind of on the hook, leveraging your documentation as a discovery channel, and doing competitor research to find the right routes—I would suggest if you’re just starting out and want to just do something, one or two of these approaches might be highly appropriate and useful for you to implement today.

You don’t need to love marketing. You don’t even need to like it. You just need to build systems that do it for you.

That’s what technical founders are good at anyway.

And I think it’s time that we have a voice out here that is not a doomer. I’m certainly not an apologist for the SaaS movement either. But giving some realistic expectations of where we are and where the field is headed is probably a good idea at this point.

I believe that while software as a service may struggle with things like subscription fatigue, or some vibe-coded slop solution replacing certain purchases that people might have been making in the past, I don’t think it’s the end. And I don’t think it’s necessarily a bad thing for our industry to be where we are right now.

There are a couple things I feel are significantly undervalued when people look at AI and what threat it might pose to the software development field and the SaaS field in particular. So let’s talk about that.

What Vibe Coding Actually Is

Most importantly, I think people who believe that just because you can go to Bolt.new, or to v0, or to Lovable, and explain what you want, and have a vibe coding tool pretty much build whatever it thinks you’ve just explained—I don’t think this is the end of all software as a service.

But before we dive into why this is false, maybe we should determine what exactly vibe coding is. Because a lot of software developers see AI and think “vibe coding,” mostly because the consensus in our community is that this is what it means.

I do not believe so.

I believe vibe coding is a version of AI-assisted software engineering—let’s call it an extreme version of it. But not all software created through AI-assisted engineering is vibe coded.

Vibe coding is when you don’t really care about the underlying code at all. You just say what you want. The thing builds, it deploys in the background, and then it runs. That, to me, is a vibe coded app.

The moment you dive into the code, the moment you understand it, the moment you know what the components are underneath the user interface or the API—it’s not a vibe coded project anymore. It is, at most, a strongly AI-assisted software engineering project.

The Core Truth: Projects vs. Businesses

So here’s my definitory exercise: the general consensus in the—let’s call it “thinkfluencer”—community on Twitter and other social media seems to be that vibe coding is taking our jobs. That it’s making it harder to build simple SaaS businesses and monetize them, and that people can just build these things internally and be perfectly happy with those solutions.

I believe that is utterly and completely false.

Because it’s easy to vibe code a project, but it’s incredibly hard to vibe code a business.

And I think people who have never built a business but who have strong opinions about software engineering mistake one for the other.

You can build a product with all kinds of features—that’s not a problem. But a business, and that is the main part of what Software as a Service is, has significantly different requirements than just building a software tool.

In fact, I think people are so focused on the “software” aspect of the whole “software as a service” terminology that they completely forget that it was never really about the software.

Software as a Service was always about the service. Always about the operation of software, the implementation of software changes, the adaptation of software to new things. The actual value of a software as a service business is in running and supplying the software, not in the software itself.

When Vibe Coded Solutions Break Down

If you understand that, then you know that AI tooling will only ever—at least in this current situation that we’re in, which is likely going to be true for another couple years—be good at creating software. But it will be very limited at creating and, more so, maintaining businesses.

You can vibe code a product, no problem. And it can look and feel like an actual human-built software business. But the moment your first customer service request comes in, the moment your first integration request comes in, the moment somebody has a problem with their data that you might need to adjust in a database, or somebody needs a certain file format supported and makes that a requirement for their purchase—you’re going to end up in vibe coding hell.

Because the vibe coded solution operates under certain assumptions, and every single feature request will change these assumptions. Every single thing that your customers do or want will be a re-evaluation of your initial assumptions.

That’s the whole trick here. That’s the whole basic truth that a lot of people with strong opinions seem to be very intentionally forgetting.

A software product is the outcome of a business effort. A SaaS is a way of solving a business problem. And to be able to comprehend not just how to solve that problem, but what that problem is in the first place—who really struggles with it, who should be approached to purchase it, how they should be talked to, how they can be convinced, what alternative solutions they are using, and what they think about the field and certain implementations, certain features, certain ideas—that takes a lot of experience. It takes nuance and industry insight.

Most software products come from a niche, from a very specific subset of an industry. And if we’ve learned one thing about the LLM systems that we all use to prompt our way into products, it’s that these are built for consensus purposes. An LLM can act like it knows a lot about a specific thing, or it can act as a niche persona. But in the end, it will always be the consensus engine that we created it to be.

The Comprehension Debt Problem

And I think it’s very significant that we understand this.

For a product to be built well, the problem and the solution have to be deeply understood, then implemented, and then adjusted. All these vibe coding tools seem to me like a flicker in time. Some of them are great, and some of them will fulfill a purpose. But they all come with an extremely heavy maintenance burden.

That burden is surprisingly bearable when it is the result of a human project, because people have a strong internal understanding of what their codebase and product is doing. But it is extremely frustrating to deal with in a vibe coded project.

If you ever have a vibe coded solution, or even a heavily AI-assisted solution that does not have proper documentation, the AI will struggle—not just struggle, but fail—to remember what it was thinking when it was building the thing in the first place.

While it is being built, while the context window exists, you will find that AI tools are very capable of maintaining internal cohesion. But the moment that window is gone, the moment you end your session with Lovable or whatever, the internal understanding—the representation of what the vibe coded tool was meant to build—is gone forever. It literally vanishes into an unrecoverable state because it’s not meant to be understood or persisted or maintained.

Maybe in the future we will have ways to create a fully comprehensive internal understanding of a codebase, plus everything in the business around it. But right now, we’re not there.

I talked about this recently on the podcast when I was discussing comprehension debt versus technical debt. That internal understanding is still for us to maintain. If we use AI tools, we need to persist it into text files that can be read by AI tools and humans—comments and strong architectural documentation.

Traditionally, software engineering used to work like this: somebody architects, they write up docs, they write up specs, then they implement it. They fully understand what they built, and they write tests so it can be tested, because they have an expectation of what things are going to be like. The test is written to see if that expectation holds true.

But if nobody has that knowledge, how can you know if your codebase is working and doing what it’s supposed to do? If it’s small, sure, you can kind of test your way through it. But if it’s not, then all of a sudden you have a problem. A really, really big problem. Because you won’t be able to know at all what your product is. And a product that is unreliable creates a business with high churn, with low retention—and ultimately, a business that fails.

So the phrase isn’t “SaaS is dying because of AI.” It’s more like: certain kinds of software engineering are changing because of AI. But it has so little to do with the actual potential of software as a service businesses as a concept dying out because people can now tell Lovable or some other tool that they want a certain thing done.

That’s not the case. That is definitely not the case.

The Pareto Principle: Why People Buy Your Last 20%

Think about why people buy a software as a service product. Often, it’s not that they couldn’t build something like it themselves.

We often think about “buy versus build,” and in many ways, during sales, it’s the conversation where you try to convince people that their build cost would be significantly higher than their buy cost. That’s definitely true in many cases.

But people are very well aware that they could build a software product—your software product, very likely—because the moat, in many ways, is just time and energy spent.

Yet they still choose to buy it from you.

The reason is the Pareto Principle. 80% of the way there takes 20% of the time, but the remaining 20% of the work effort takes 80% of your time.

And most people who are in successful businesses themselves—you know, your buyers—understand very well that they don’t see the 20% that you have figured out over the last couple years.

This is why people buy SaaS businesses that have been around for a while. They want to see that you’ve struggled for a bit, so you’ve truly understood all your customer needs.

Smart people will buy your product because they are perfectly aware of the fact that you’ve covered edge cases. That you have discovered specific, really hard to maintain integrations into systems that they don’t even know exist.

That’s why people buy your software as a service product. Not because it’s 10% cheaper than if they were to build it themselves.

Of course, a lot of people think they have to build everything in-house, or otherwise it’s a dependency risk. But building a software tool that other people employ half a dozen staff to maintain as a business, all in itself, clearly has opportunity cost that will likely outpace the $200 a month that you might be paying for a subscription.

People will always have these weird issues and weird understandings when they make their purchasing decisions. But I certainly feel that your ideal customer understands that they buy your SaaS for the last 20%.

Making the Invisible Visible

Which brings me to the whole point of this.

If SaaS is not dying, but vibe coded internal solutions are much easier for people to build, how can we make sure that the last 20%—the invisible stuff—becomes visible? Not so that people can copy it more easily, but so that it becomes an argument for why people should buy our solution instead of building their own.

I think this will be an ongoing struggle over the next decade or so.

We’ve understood this in software as a service, right? We understood that customers aren’t buying our software—they’re buying peace of mind. They’re buying having their thing figured out and having that problem solved.

Well, now this might actually swing back into the direction of them buying something that even they could kind of make themselves. But it still is better because it is built from certain experience, or it’s something that would be very hard for them to get right, very hard to even approach correctly.

In our self-description, maybe we don’t sell the solution to problems as much anymore. Or when we do, we show that there is complexity to it and an interdependency to it that they may not have expected.

Maybe we are upfront with our buy versus build equations. Instead of waiting for a customer to ask us about this, we tell them: “Hey, this would probably cost you $50,000 to $100,000 to build, and at least thousands a month to maintain with a service level agreement. Or: a $2,000 subscription with a service level agreement. We have integrations with 56 different data providers to get the data that you need—you just need one login.”

The conversation will be shifting, because we’re now talking to people who are technically capable of building their own systems. Every company now has somebody who at least understands AI a little bit. People will try to consider that they could possibly build everything.

Maybe we give them a clear background. We give insight into just how complex it would be to build this. And they will benefit from us having it already built for them, because we have built the last 20% already.

That’s what we’re selling to them. But it is time to make this more apparent.

Final Thoughts

Vibe coding isn’t killing SaaS. It’s changing how we need to communicate our value. The service in “software as a service” has always been the point. The edge cases, the integrations, the accumulated wisdom from serving real customers with real problems—that’s what people are paying for. That’s what they’ll continue to pay for.

And if you’re building a SaaS, lean into that. Show your work. Make visible what was always invisible. Because the person who can vibe code a clone of your product in an afternoon still can’t vibe code the years of customer conversations and hard-won insights that made your product actually work for people.

But Jack said something else recently which I found equally interesting and maybe even more generally applicable for all of us software developers building digital businesses. It’s just a quote from a tweet of his. He said: “The biggest mistake I ever made was storing our page views and custom events in different database tables. They’re now on their way to a single table.”

Obviously, Jack refers to the wonderful product of Fathom Analytics—something that I highly recommend using for your software products because it’s privacy-forward and very easy to use. But what he’s talking about here is how the data model they had in the past has been holding him back.

Jack is no stranger to massive migrations, and if he sees something that needs to be migrated to something better, well, he goes for it. And I find that admirable and instructive, particularly because I’ve been running into the same issue. So that’s what I want to talk about today.

I’ve been building PodScan for almost two years now, and obviously the choices that I made on day one weren’t necessarily the most forward-thinking ones. Because, as we all know in this world of entrepreneurship, we’re all just trying to figure it out as we go along. The meme that is often mentioned here is that we’re all trying to build our airplane on the way down—plummeting towards the ground, trying for it to lift off before we hit the surface.

I’ve been dealing with a couple smart and a couple very unreflected choices in terms of how the data in my database is represented. And those choices have consequences, particularly for PodScan, where I have millions of podcasts to track and all the data that comes with that.

For each podcast, there is just so much metadata for the show alone—not even thinking about the episodes. Things like chart rankings and reviews, social media profiles linked to it, all this stuff needs to have a place. How you store it, what you store, and how accessible it is really makes an impact on how you can present the data and how you can use it. And then at this point, we’re at over 45 million episodes with transcripts. So not only do we have to store all that text data, but each episode has hosts that need to be extracted and linked, and there are summaries and topics.

There’s just a lot of data. Some of it I structured smartly, some of it I didn’t. And having a data model that is well-designed from the start feels like a really important thing—a smart and important part of having a successful product.

But here’s the thing I want to point out today, something we don’t usually talk about: how you structure your data, how you keep your data around, informs how you think about your product. And that might limit the whole scope of how you think about it to certain things that people who have similar products with similar data models might have as well. It might limit you to certain things that a different data model or a different way of representing the data might not.

Let me give you an example. The most basic thing of every software-as-a-service business is user authentication. People come to your website, they’re interested, and then they go to sign up. Now, what do you ask them? You ask them for an email, a name, and a password—hopefully some way of authentication—and then you persist that.

Now you have a list of users. And all of a sudden, your business, right from the start, is a one-user-per-account business.

This might be useful for most people who use your product, because they are individual people using it in their own ways. But then, all of a sudden, somebody wants to invite someone from their team. Now what are you going to do?

Do you make the team member create a new account as well? Because you don’t really have a team representation yet—you only have accounts. Maybe you have a permission structure that allows you to invite other accounts into individual documents in your product. Or you have an overarching organization structure that, whenever a new account is created, an organization gets created as well for that account—like a team—and then that team exists, and the account is the owner who can invite any number of members, make them administrators or editors or just users.

Depending on how you think about that, even that simple data representation that most software businesses initially have to make a choice about, it depends on who you think your product is for.

If it’s just a B2C product where you have individual users—let’s say a video game, or a fantasy sports tracker where you just want to track your own results—it makes perfect sense not to even think about teams as a data representation.

But the moment you start selling to bigger companies, the moment you start selling to people who are part of a workflow, if you don’t think about teams and organizational structures, your product is aimed at people who might not be able to use it because they need to involve their coworkers. And maybe more importantly, they expect things to have a team structure.

It’s one of the reasons why I really like the Laravel ecosystem. There are several really high-quality plug-and-play systems for user authentication, and the one that I’ve been using in all of my products, called Jetstream, has a teams option. You can immediately take teams and make them part of your application by just using the --teams flag when you install the plugin, and then every single new account either creates a team or can join a team.

It’s quite useful to have this as a default for software-as-a-service businesses, because most people expect this kind of functionality for any significant product. The moment you charge more than a hundred bucks a month, it’s likely that somebody will want a team. That’s kind of what I’ve experienced.

As you can tell, this has nothing to do with the internal data that your business handles. You could be rendering videos, generating emails, or tracking where vehicles go. It doesn’t matter what that data is structured like—just the authentication data, just representing who is a user of your product, already impacts what your product can and cannot do.

Then think about billing. Do you bill on an account level? Do you bill on a team level? Do you bill on an organization level, or do you bill per project? Do you even have projects? All of these choices truly matter. And once you make these functional choices, future infrastructure changes have repercussions.

Because if you change infrastructure, you also change the features that touch it. Existing features that may need an account, because they need to be bound to an account—but now all of a sudden, you have teams that can be accessed by multiple accounts. What are you going to do? Assign an account or assign the team?

The data model that you have in mind might not be the data model that you need. So you need to build some internal flexibility as a founder.

At scale, things can get quite problematic. If you think about PodScan as a database of all the podcasts in the world—which is over four million at this point—and all that they release, which is around 50,000 new episodes a day, obviously those database tables grow massively. Pretty linearly, because the world doesn’t just double in size when it comes to podcast adoption, but they do grow quite significantly.

What I experienced quite early on, a couple hundred thousand items in, was that my database—how I would structure my data and how I would make my data easily accessible—really mattered.

I was trying to add indices after the fact because I was building new features on top of my existing data model. Or I was trying to change fields in a database with millions of rows. And all of a sudden, all my queries to the database would stall for a couple minutes. Because adding an index sometimes can lock the database. Adding a new field or updating a field over millions of items can lock a database.

That was when I didn’t really know much about blue-green deployments—the idea of running a full copy of the database as a follower of the primary database, doing the index and all that work on that follower, and then switching it over. Something that I’ve now been doing a lot whenever it’s required. I wasn’t aware of this back then, and I wasn’t aware of how complicated it can be to add certain things to massive databases in MySQL.

It’s something that now needs a kind of infrastructure event for me to happen. If I need to add a new index, I have to make an extra deployment, run it on that kind of passive deployment, and then switch over everything. Otherwise, I have downtime in my service, which I can’t have because I have an API that needs to be reliable.

Those choices I never really thought about in the beginning. I never thought about the fact that once my podcast episode table has over ten million items, adding an index on a text field might take two days to complete. This stuff doesn’t come up when you’re just starting out.

At a certain point, data doesn’t just have to do with how data is represented, but also how data is accessible—particularly when it is a lot of data. When you’re pulling a lot of data from a certain API or kind of source, the way and the speed at which it can be accessed really makes a difference.

And even if you know a lot about databases and a lot about customer access patterns, there will be something you will miss. So from the beginning, I would recommend thinking about how you can play with this data at production scale and see how things behave without actually running it in production. The blue-green deployment approach has been something that I’ve felt really is a godsend, because otherwise I would have massive downtimes and the stress associated with that.

Let me share another story from PodScan. Full-text search in regular SQL databases like MySQL or PostgreSQL is pretty good—up until a certain point. And that certain point is reached quite quickly if the text you’re searching is significantly large.

For me, with PodScan’s transcription features, I have full episodes transcribed for now millions of shows. The full-text search capability of MySQL, no matter how good the system is, just wasn’t working with this. If I were to run a full-text index on all of it, first off, that would take me a couple of weeks just to build. And second, queries would take several hours to complete. Each episode in the system sometimes has up to a megabyte of raw text data. It just cannot be scanned quickly with traditional database approaches.

So I was limited. I wanted full-text search, but I couldn’t do it on my database. I needed to split off that data into a secondary system built for this kind of thing.

Initially, I was using Meilisearch and they were pretty good up until a certain point as well. Meilisearch is a very fast searching system used for instant search in e-commerce systems or specific databases of similar data. And it worked.

But after a certain size—I think around 100 gigabytes worth of data—it also became limited. Still extremely fast on the search side, but much, much slower on the ingestion side. So I had to find an alternative solution, which ultimately became OpenSearch—Amazon’s version of the good old Elasticsearch.

Now at this point, I am splitting off every single episode that I receive. I persist its full transcript so it can be quickly accessed, and then I send it over as an item to an OpenSearch cluster, which takes care of all our searching. That cluster has its own indexed version of all the data, and whenever we want full-text search, we send the request there, populate the results with data from our database, and then show it.

It was impossible to do in our own database system, so we had to use an alternative system. Had I said I want everything to be done in my own database, I probably would have found ways to do it that were like, dispatch a search and get a result half an hour later. But obviously that was not the feature goal.

The product needed to be searchable, so I had to split it off. Which means that now there’s significant complexity in the data model. I still have MySQL as my main database, but I have these additional sources of temporary truth, which are the search systems. The text is still the same that I get and send over, but the way we interface with that data and the way we synchronize it might be different.

So it’s important to understand that there’s now an additional control flow. If I were to re-transcribe an episode, I need to make sure that the version stored in the OpenSearch cluster is also updated. That synchronizing, checking, and testing—that is complexity that I didn’t think about from the beginning, but now have to deal with.

Even with MySQL data that’s now several terabytes in size, there’s more to think about. The database just grows and grows, but most people only really look at the transcripts of more recent podcast episodes.

That is a choice that probably makes sense—keeping it all in the same database, all equally accessible. But is it a smart business choice? Is it fiscally responsible to store everything in a database you pay for when you don’t ever use or interface with most of it?

I had to make a choice. And I think this happened within the first six months of running PodScan. I started taking older data and putting it into much, much cheaper object storage, but still making it available through a link from the database.

What I built was a way for my podcast episodes to check: is the transcript fully available in the database? And if not, link to a storage file that contains this transcript. If so, let’s load it, write it into the database for a hot minute so we can serve it quickly without having to pull it from object storage all the time.

And I also make sure that once podcast episodes reach a certain age, they automatically get transferred to object storage—kind of a colder storage—instead of staying in the database. That works super reliably, and it also saves me a lot of money on millions of podcast episode transcripts that are now just sitting in JSON files somewhere.

This was also not part of the initial data model. I didn’t think that I would ever have to think about that kind of optimization.

So that’s what I wanted to bring up today. The way you represent your data either enables you or it limits you—probably both at the same time. And if you find yourself struggling, think about how you can bend not just your application to fit the data model, but how you can open up and make more flexible your data model to fit what your application needs to become.

Know that it can be done. It requires patience, sometimes infrastructure events, sometimes blue-green deployments. But having a data model that is flexible enough to be changed even at scale and under load becomes quite relevant as a tech stack decision. Build that internal flexibility as a founder to say: okay, this month I’m going to do that migration. It will be worth it.

I was reminded of the AI practices I have established a tweet I read from Greg Eisenberg. He said that keeping up 100% with all the new AI tools and models is impossible, and that something that works today might fail tomorrow.

That observation has been my biggest learning, and I turned it into not just a process, but an implementation style. Let me share what I’ve built.

The Migration Pattern

Wherever I use an AI call—be that to a local model or a cloud model on OpenAI, Anthropic, Google Gemini, wherever it might be—I always have a migration pattern implemented in the code.

I extract all of my API calls into services. These services internally handle all the connection, all the prompt massaging and prompt construction, in addition to the specific prompt I want for each API call. And these services always operate on what I call a state of permanent migratability. That means they can always use the latest version and the latest model, or at the very least, the version of the prompt and model that I used previously.

I realized I needed this when I started implementing GPT-5 a couple of months ago after having used GPT 4.1 for a long while. The first experiments were horrible. A lot of API changes happened, and a lot of nuanced parts of the prompt didn’t work as well as they did before. My prompt that was perfectly crafted for 4.1—which it ran on for at least half a year—was just not reusable for GPT-5.

Here’s what happened in the details: my prompt for GPT 4.1 had a JSON format expectation, which is part of the OpenAI API where you can say, “I want this to be a JSON that comes back,” and you’re guaranteed to get JSON. Everything in the prompt was aimed at creating that JSON most effectively.

When I migrated that call to GPT-5, it would still create JSON data, but it would drop certain keys. It wasn’t as reliable as the 4.1 version of that prompt. I tried to figure out the reason, and it turned out that GPT-5 was more aimed at using structured JSON schemas. Instead of just saying “this is going to be JSON,” you say “this is the exact JSON that you’re going to output,” and you define the keys and the potential values. Then you explain in your prompt how these are filled. It’s fundamentally similar to what it was before, but technically different.

Since I didn’t just want to deploy new experiments with a new model and hope they produced the same data, I came up with this migration strategy: for either a certain time period or for my testing and staging environments, I could say, “Use the old prompt with the old model, and then use the new prompt with the new model.” Maybe even a completely different data structure and a completely different API call—because OpenAI also wants people to move away from the chat-style API to the response-style API.

I would log both results, see if there were major differences, and if there were, the system would tell me and show me the diff, making it accessible for debugging. Then it would respond with the new data to whatever function or procedure called it.

For those servers running this dual approach, they incurred twice the cost. But I was able to see what the old model did, what the new model did, and how the differences between prompts would impact the quality, expectability, and reliability of the data.

I found this extremely useful for almost anything you do with AI tool calls where you’re using an LLM to get some kind of response or data. Unless it’s purely conversational, where this probably doesn’t matter as much. But if you’re doing background analysis, data number crunching, semantic analysis—it really helps to have this migration pattern where, for testing purposes, you can run both versions and see both results.

If you find that the new results aren’t as good as you thought, you can always roll back and just use the legacy version. Then you can work on your testing and staging systems to get the new version ready—because you know you’ll have to migrate eventually. These API systems will be deprecated at some point anyway.

It’s always quite helpful to do a diff on the JSON data that comes back just to see what’s missing, what’s different. Often, that will inform how you can reshape your prompts. You might even be able to have Claude Code or OpenAI Codex do this for you: take the data and change prompts until both results are similar to each other.

This migration pattern has made it into every single service I have that communicates with outside machine learning models. It’s been a godsend to see what the differences are, how things react differently, and to understand how nuanced your prompts have to be to get reliable data. Because once you’ve set up a prompt and it works, you want to use it for as long as possible. The migration pattern helps with that. And it also helps that if the new service suddenly experiences a degradation, with a flip of a switch, you can go back to the old one and get your data as reliably as you did before.

The Service Tier Secret

Now, that’s about handling differences between models. But I’ve also realized something else—something the people at OpenAI have kind of not necessarily hidden, but made not very apparent in the documentation.

Some of these cloud services offer what we might call service tiers, different priorities for how important your API call is, and you pay accordingly. If you’re a developer who reads documentation thoroughly, you probably spotted this quite early. Took me a couple months to figure it out.

For OpenAI, every standard request you send is billed in the default tier—that’s the price you find on the website. But if you look a little bit closer, you see that they have batched requests, which are significantly cheaper. Batching isn’t always useful for people doing on-the-spot analysis, because you don’t know when your batches will be full and when they’ll be processed. For anything that has a semi-synchronous nature, where you send the request and expect to work with the result shortly after, batching isn’t the most useful approach.

But what I failed to realize is that between the default tier and batching, there’s another tier. For OpenAI, it’s called Flex. And that tier is effectively billed at half the price.

Half the price. With the caveat that it might be slower, might take 50% longer, and at certain points might not be available at all. But it’s still the same exact model and the same exact data quality.

Once I figured this out, I knew I was going to use the Flex tier for all my backend stuff—all the things that happen behind the scenes. For Podscan, that’s extracting who’s the guest on the show, what they’re saying, summarizing these things. The fast part of Podscan is transcribing and making content fully searchable. The not-as-fast part is doing all this extra analysis.

If I can save 50% of my cost on this, I can do twice as much. That means twice as much value for my customers for the exact same price I would pay.

So I implemented this into all my extraction and inference jobs. Since OpenAI has implemented auto-retries in their own SDKs, I didn’t even need additional logic for that part. What I did implement was a fallback: if a request ran into a 429 error—which rarely happens—it would set the service tier for that particular job to the next highest one, which is standard. Then it would retry. So it tries a couple times with Flex to save money, and if that doesn’t work, it sets it to default priority. You pay twice as much, but you get it done.

I’ve implemented this at scale, and it led to an immediate 50% price reduction because the Flex tier is quite available most of the time. And because I have so many input tokens and so few output tokens—I throw a whole transcript of a podcast, hours worth of text, just to get a couple of JSON elements of summarized data—the cached tokens on that tier are also half price. That’s significant.

This then allowed me to immediately double the amount of extraction and inference I do, which increases the overall quality of the platform. That’s apparent not just to my paying users but also to my prospects, and it ultimately leads to higher conversion.

So in your API calls, check each platform you use. Look for the service tiers and consider how long you can allow for something to process. Batch pricing costs just as much as Flex processing on the OpenAI side, but if you can’t batch and you need some kind of asynchronous-but-somewhat-synchronous response, go for the Flex tier.

The clear indicator is: if you can batch and have the infrastructure for it, that’s great too. Flex pricing really exists on the GPT-5, 5.1, and the o3 and o4 models. Models like Codex, Pro, GPT-4o, and the real-time audio tools might not have Flex pricing as easily available. It depends on the models, so you need to figure this out on a per-platform basis.

But if those price tiers exist and you’re not using them, that’s financial negligence. It’s very simple to set the service tier. It’s very simple to default it back to something that will work. And if you have stuff that really needs to get through even when there’s a lot of congestion, you can set the service tier to Priority, which costs double but will get you results even quicker.

You have to understand that Priority might not exist for certain models either. That’s really what Greg Eisenberg was getting at: there are so many models, and so many different ways of using them, that you really have to be flexible in implementation and in how you optimize for this.

Front-Loading for Cache Efficiency

This brings me to something a bit more well-known, but something I’ve found really makes a difference if you have a lot of data to analyze: front-load the thing that repeats itself.

Front-load your system prompt. If you analyze the same bunch of data multiple times, start your prompts with that data and make it verbatim the same every time you use that piece of data.

For me, that’s the full transcript. I start with the system prompt: “You are a transcript analysis expert. You do these kinds of things.” Then I paste the transcript. Then at the end of the transcript, I say the specific thing that needs to be done—sometimes it’s looking for a particular kind of guest, or finding the sponsors, or asking a customer’s question on it, like “Is this about the thing the customer really cares about?”

But always front-load the actual data, because those will be cached tokens. Those cost you 10% of what the tokens that differ between prompts might cost.

I know my data case is a special one because Podscan has these massive transcripts that many questions are asked on. But if you’re doing anything meaningful where you throw data into an AI system for analysis, put the data that might repeat itself first, and put the stuff that doesn’t repeat itself after.

To make the order absolutely clear: system prompt describing what the thing is, then system instructions that are always the same (“you will extract data in this format”), then the data that’s potentially duplicated between prompts, and then the specific instruction for each prompt. That’s the order, and that will cost-optimize your prompts.

It’s also very helpful if you have multiple prompts you want to check. You can take those and feed them as data into a Claude Code conversation or a ChatGPT conversation with the express instruction to analyze these prompts and see if they can be optimized. You’ll get insight from the AI that you can use. I wouldn’t take it verbatim—the AI is still just predicting tokens, and just because it says something might be more useful doesn’t mean it is. But if you have a lot of prompts and let the AI check ten of them at the same time and tell you what you could do better, you’ll get meaningful insight from that.

Rate Limiting and Circuit Breakers

Finally, since we’re talking about using external platforms that cost on a per-token basis: build a lot of rate limiting into these systems.

Rate limit the customer-facing actions that trigger AI interactions. And rate limit the AI interactions that can be sent from your backend server. You don’t want a race condition that restarts the same process over and over again, triggering the same call repeatedly. Even if you’re using cached tokens, it will cost you.

Make sure that if something is out of order—if there’s 10x the normal AI tokens being used in any given hour—you’re made aware of it, and you have the ability to stop it.

A full-on circuit breaker for all AI features in your application might be a good idea. If you have something like Laravel, which has commands you can run on your server, or maybe you have an admin interface where you can flip a switch on or off—you might want to implement a full circuit breaker for all AI tools or for specific parts of the application.

Users can do some self-onboarding and click a “Generate a Cool Config” button. You might want to be able to turn that on and off. If somebody has found a way to automate that away and send hundreds of dollars worth of cost your way per hour, you want to switch that off with a toggle. A feature toggle in your backend—not just in the frontend, but in the backend, right where it happens.

Do this wherever you think you might need it. Then have an AI scan your code and tell you where else you need to put it, because you might forget. The AI will scan through all the files for you. It’s a good idea to have an agentic coding tool just for this purpose: Where are the potential AI call abuse situations? And can we have a feature toggle there that prevents this from being used if you, as an administrator, turn it off?

This is a very important feature. I highly recommend this for anything, which also means that any AI usage has to go through your backend system. You cannot implement something that client-side uses an AI call to a platform with your token. That’s generally not a good idea to begin with, but do not do this. Always funnel it through your backend system so you can reliably turn these features on and off and get alerted when usage is high.

I have several of these things. Rate limits on all these features. Frontend user rate limits. Backend rate limits. Feature toggles. Alerts for when a feature gets abused—on a per-account system, on a per-subscriber-type system, and on a per-IP system as well.

These things need to be built in. I have a feeling that tools and frameworks will implement this in the near future as kind of a baseline. But for right now, we need to implement this ourselves as founders.

The AI landscape changes constantly. The models change, the APIs change, the pricing changes. Your job isn’t to keep up with everything—that’s impossible. Your job is to build systems that can adapt when things inevitably shift. Migration patterns, service tier optimization, prompt caching, rate limiting, and circuit breakers. These aren’t just nice-to-haves. They’re the foundation of running AI in production without losing your shirt.

Build for change. That’s the real best practice.

And that’s it for today.

Thank you for listening to The Bootstrapped Founder.

Find me on Twitter @arvidkahl.

Everything I just talked about—the migration patterns, the service tiers, the rate limiting—that’s all running under the hood at Podscan, my podcast monitoring platform. If you need to know when someone mentions your brand across 4 million podcasts, that’s what it does. And for founders still searching for their next thing, I’ve set up ideas.podscan.fm where AI pulls validated problems straight from expert conversations. Sometimes the best ideas are just listening to what people are already asking for.

Thank you for listening. Have a wonderful day, and bye bye.

Hey, it’s Arvid, and this is The Bootstrapped Founder.

I recently realized something while building Podscan, my podcast database system that does a lot of background data extraction and analysis for my users. I’ve stumbled upon a couple of AI integration best practices that a lot of people might not be fully aware of. So today, I want to dive into the concepts I found not just useful, but essential for maintaining and operating mission-critical data handling with LLMs and AI platforms.

I was reminded of the AI practices I have established a tweet I read from Greg Eisenberg. He said that keeping up 100% with all the new AI tools and models is impossible, and that something that works today might fail tomorrow.

That observation has been my biggest learning, and I turned it into not just a process, but an implementation style. Let me share what I’ve built.

The Migration Pattern

Wherever I use an AI call—be that to a local model or a cloud model on OpenAI, Anthropic, Google Gemini, wherever it might be—I always have a migration pattern implemented in the code.

I extract all of my API calls into services. These services internally handle all the connection, all the prompt massaging and prompt construction, in addition to the specific prompt I want for each API call. And these services always operate on what I call a state of permanent migratability. That means they can always use the latest version and the latest model, or at the very least, the version of the prompt and model that I used previously.

I realized I needed this when I started implementing GPT-5 a couple of months ago after having used GPT 4.1 for a long while. The first experiments were horrible. A lot of API changes happened, and a lot of nuanced parts of the prompt didn’t work as well as they did before. My prompt that was perfectly crafted for 4.1—which it ran on for at least half a year—was just not reusable for GPT-5.

Here’s what happened in the details: my prompt for GPT 4.1 had a JSON format expectation, which is part of the OpenAI API where you can say, “I want this to be a JSON that comes back,” and you’re guaranteed to get JSON. Everything in the prompt was aimed at creating that JSON most effectively.

When I migrated that call to GPT-5, it would still create JSON data, but it would drop certain keys. It wasn’t as reliable as the 4.1 version of that prompt. I tried to figure out the reason, and it turned out that GPT-5 was more aimed at using structured JSON schemas. Instead of just saying “this is going to be JSON,” you say “this is the exact JSON that you’re going to output,” and you define the keys and the potential values. Then you explain in your prompt how these are filled. It’s fundamentally similar to what it was before, but technically different.

Since I didn’t just want to deploy new experiments with a new model and hope they produced the same data, I came up with this migration strategy: for either a certain time period or for my testing and staging environments, I could say, “Use the old prompt with the old model, and then use the new prompt with the new model.” Maybe even a completely different data structure and a completely different API call—because OpenAI also wants people to move away from the chat-style API to the response-style API.

I would log both results, see if there were major differences, and if there were, the system would tell me and show me the diff, making it accessible for debugging. Then it would respond with the new data to whatever function or procedure called it.

For those servers running this dual approach, they incurred twice the cost. But I was able to see what the old model did, what the new model did, and how the differences between prompts would impact the quality, expectability, and reliability of the data.

I found this extremely useful for almost anything you do with AI tool calls where you’re using an LLM to get some kind of response or data. Unless it’s purely conversational, where this probably doesn’t matter as much. But if you’re doing background analysis, data number crunching, semantic analysis—it really helps to have this migration pattern where, for testing purposes, you can run both versions and see both results.

If you find that the new results aren’t as good as you thought, you can always roll back and just use the legacy version. Then you can work on your testing and staging systems to get the new version ready—because you know you’ll have to migrate eventually. These API systems will be deprecated at some point anyway.

It’s always quite helpful to do a diff on the JSON data that comes back just to see what’s missing, what’s different. Often, that will inform how you can reshape your prompts. You might even be able to have Claude Code or OpenAI Codex do this for you: take the data and change prompts until both results are similar to each other.

This migration pattern has made it into every single service I have that communicates with outside machine learning models. It’s been a godsend to see what the differences are, how things react differently, and to understand how nuanced your prompts have to be to get reliable data. Because once you’ve set up a prompt and it works, you want to use it for as long as possible. The migration pattern helps with that. And it also helps that if the new service suddenly experiences a degradation, with a flip of a switch, you can go back to the old one and get your data as reliably as you did before.

The Service Tier Secret

Now, that’s about handling differences between models. But I’ve also realized something else—something the people at OpenAI have kind of not necessarily hidden, but made not very apparent in the documentation.

Some of these cloud services offer what we might call service tiers, different priorities for how important your API call is, and you pay accordingly. If you’re a developer who reads documentation thoroughly, you probably spotted this quite early. Took me a couple months to figure it out.

For OpenAI, every standard request you send is billed in the default tier—that’s the price you find on the website. But if you look a little bit closer, you see that they have batched requests, which are significantly cheaper. Batching isn’t always useful for people doing on-the-spot analysis, because you don’t know when your batches will be full and when they’ll be processed. For anything that has a semi-synchronous nature, where you send the request and expect to work with the result shortly after, batching isn’t the most useful approach.

But what I failed to realize is that between the default tier and batching, there’s another tier. For OpenAI, it’s called Flex. And that tier is effectively billed at half the price.

Half the price. With the caveat that it might be slower, might take 50% longer, and at certain points might not be available at all. But it’s still the same exact model and the same exact data quality.

Once I figured this out, I knew I was going to use the Flex tier for all my backend stuff—all the things that happen behind the scenes. For Podscan, that’s extracting who’s the guest on the show, what they’re saying, summarizing these things. The fast part of Podscan is transcribing and making content fully searchable. The not-as-fast part is doing all this extra analysis.

If I can save 50% of my cost on this, I can do twice as much. That means twice as much value for my customers for the exact same price I would pay.

So I implemented this into all my extraction and inference jobs. Since OpenAI has implemented auto-retries in their own SDKs, I didn’t even need additional logic for that part. What I did implement was a fallback: if a request ran into a 429 error—which rarely happens—it would set the service tier for that particular job to the next highest one, which is standard. Then it would retry. So it tries a couple times with Flex to save money, and if that doesn’t work, it sets it to default priority. You pay twice as much, but you get it done.

I’ve implemented this at scale, and it led to an immediate 50% price reduction because the Flex tier is quite available most of the time. And because I have so many input tokens and so few output tokens—I throw a whole transcript of a podcast, hours worth of text, just to get a couple of JSON elements of summarized data—the cached tokens on that tier are also half price. That’s significant.

This then allowed me to immediately double the amount of extraction and inference I do, which increases the overall quality of the platform. That’s apparent not just to my paying users but also to my prospects, and it ultimately leads to higher conversion.

So in your API calls, check each platform you use. Look for the service tiers and consider how long you can allow for something to process. Batch pricing costs just as much as Flex processing on the OpenAI side, but if you can’t batch and you need some kind of asynchronous-but-somewhat-synchronous response, go for the Flex tier.

The clear indicator is: if you can batch and have the infrastructure for it, that’s great too. Flex pricing really exists on the GPT-5, 5.1, and the o3 and o4 models. Models like Codex, Pro, GPT-4o, and the real-time audio tools might not have Flex pricing as easily available. It depends on the models, so you need to figure this out on a per-platform basis.

But if those price tiers exist and you’re not using them, that’s financial negligence. It’s very simple to set the service tier. It’s very simple to default it back to something that will work. And if you have stuff that really needs to get through even when there’s a lot of congestion, you can set the service tier to Priority, which costs double but will get you results even quicker.

You have to understand that Priority might not exist for certain models either. That’s really what Greg Eisenberg was getting at: there are so many models, and so many different ways of using them, that you really have to be flexible in implementation and in how you optimize for this.

Front-Loading for Cache Efficiency

This brings me to something a bit more well-known, but something I’ve found really makes a difference if you have a lot of data to analyze: front-load the thing that repeats itself.

Front-load your system prompt. If you analyze the same bunch of data multiple times, start your prompts with that data and make it verbatim the same every time you use that piece of data.

For me, that’s the full transcript. I start with the system prompt: “You are a transcript analysis expert. You do these kinds of things.” Then I paste the transcript. Then at the end of the transcript, I say the specific thing that needs to be done—sometimes it’s looking for a particular kind of guest, or finding the sponsors, or asking a customer’s question on it, like “Is this about the thing the customer really cares about?”

But always front-load the actual data, because those will be cached tokens. Those cost you 10% of what the tokens that differ between prompts might cost.

I know my data case is a special one because Podscan has these massive transcripts that many questions are asked on. But if you’re doing anything meaningful where you throw data into an AI system for analysis, put the data that might repeat itself first, and put the stuff that doesn’t repeat itself after.

To make the order absolutely clear: system prompt describing what the thing is, then system instructions that are always the same (“you will extract data in this format”), then the data that’s potentially duplicated between prompts, and then the specific instruction for each prompt. That’s the order, and that will cost-optimize your prompts.

It’s also very helpful if you have multiple prompts you want to check. You can take those and feed them as data into a Claude Code conversation or a ChatGPT conversation with the express instruction to analyze these prompts and see if they can be optimized. You’ll get insight from the AI that you can use. I wouldn’t take it verbatim—the AI is still just predicting tokens, and just because it says something might be more useful doesn’t mean it is. But if you have a lot of prompts and let the AI check ten of them at the same time and tell you what you could do better, you’ll get meaningful insight from that.

Rate Limiting and Circuit Breakers

Finally, since we’re talking about using external platforms that cost on a per-token basis: build a lot of rate limiting into these systems.

Rate limit the customer-facing actions that trigger AI interactions. And rate limit the AI interactions that can be sent from your backend server. You don’t want a race condition that restarts the same process over and over again, triggering the same call repeatedly. Even if you’re using cached tokens, it will cost you.

Make sure that if something is out of order—if there’s 10x the normal AI tokens being used in any given hour—you’re made aware of it, and you have the ability to stop it.

A full-on circuit breaker for all AI features in your application might be a good idea. If you have something like Laravel, which has commands you can run on your server, or maybe you have an admin interface where you can flip a switch on or off—you might want to implement a full circuit breaker for all AI tools or for specific parts of the application.

Users can do some self-onboarding and click a “Generate a Cool Config” button. You might want to be able to turn that on and off. If somebody has found a way to automate that away and send hundreds of dollars worth of cost your way per hour, you want to switch that off with a toggle. A feature toggle in your backend—not just in the frontend, but in the backend, right where it happens.

Do this wherever you think you might need it. Then have an AI scan your code and tell you where else you need to put it, because you might forget. The AI will scan through all the files for you. It’s a good idea to have an agentic coding tool just for this purpose: Where are the potential AI call abuse situations? And can we have a feature toggle there that prevents this from being used if you, as an administrator, turn it off?

This is a very important feature. I highly recommend this for anything, which also means that any AI usage has to go through your backend system. You cannot implement something that client-side uses an AI call to a platform with your token. That’s generally not a good idea to begin with, but do not do this. Always funnel it through your backend system so you can reliably turn these features on and off and get alerted when usage is high.

I have several of these things. Rate limits on all these features. Frontend user rate limits. Backend rate limits. Feature toggles. Alerts for when a feature gets abused—on a per-account system, on a per-subscriber-type system, and on a per-IP system as well.

These things need to be built in. I have a feeling that tools and frameworks will implement this in the near future as kind of a baseline. But for right now, we need to implement this ourselves as founders.

The AI landscape changes constantly. The models change, the APIs change, the pricing changes. Your job isn’t to keep up with everything—that’s impossible. Your job is to build systems that can adapt when things inevitably shift. Migration patterns, service tier optimization, prompt caching, rate limiting, and circuit breakers. These aren’t just nice-to-haves. They’re the foundation of running AI in production without losing your shirt.

Build for change. That’s the real best practice.

But if you ask me this now, I have a much more nuanced perspective. And it comes from two places: having been a software entrepreneur and developer for well over two decades at this point, and having experienced the fundamental change that is software engineering with AI assistance.

Here’s what I’ve recently realized: I never really loved coding. I just always thought I did.

The Illusion of Love

I thought I loved coding because that’s what I could do, and what I was able to do very effectively. It felt like it was the thing for me to do, and nothing else ever came close. It was my superpower, my identity, my craft.

But now that I have AI assistance, I’m realizing that the coding part was never actually the thing. Watching an AI agent solve problems much faster and much more comprehensively than I ever have has given me a completely new perspective on what coding actually means to me.

Because in the past, you really had no choice. Either you figured it out or you didn’t. Either you made the machine do the thing you wanted it to do, or you didn’t. Anything you couldn’t figure out was impossible for you to solve. The act of composing text into lines of code, deploying these lines, testing each individual line, building a strong mental model of the whole codebase in your mind and then implementing it into a text editor – all of this stuff that makes coding possible was inseparable from the outcome.

But now we’re using AI systems to build things for us. And suddenly, coding isn’t required anymore. Not in the traditional sense. I’m not hiring somebody else to do my code – I’m hiring a machine to execute the code implementation function.

The Podscan Evolution

I’m realizing this particularly with my current project, Podscan. Podscan started out as 100% coded by me. I had a blast building the first prototype, building the first couple stages of the tool. Everything was hand-crafted, every line considered, every pattern deliberate.

Then, over time, AI-assisted coding happened. I started copying and pasting modules and functions into OpenAI and Anthropic systems, having them optimize the code, having them give me feedback on how to do things better, more effectively.

About six months ago, I started diving into agentic coding, and I’ve never looked back.

Right now, whenever code is added to the system, it usually originates from me prompting an AI and then code reviewing it. I write tests that ensure the rest of the functionality isn’t impacted by changes. And what I’m noticing is profound: I seem to enjoy the orchestration of code, but never the construction of it.

The Developer-Entrepreneur Divide

Maybe this is the big differentiator between a software developer and a software entrepreneur. I’ve always considered in the past that each software developer is just one choice away from operating their own software business. But I’m realizing now – both from making that shift myself and from having a couple decades of experience working with other software people – that some people are just wired differently.

Some people enjoy not the solution of the problem, but solving the problem. It’s the journey, not the destination, that a hardcore software developer truly enjoys. Once it’s solved, there’s this fleeting moment of pride, but then the next challenge is immediately tackled.

For an entrepreneur, it’s a different story. Each feature, each implementation, is a pivot towards more success or a mistake that has to be rectified. It’s never the most rewarding thing to build a feature. The rewarding part is if it makes the business more performant, if it makes you more money, if it attracts more customers, if it retains more customers.

A pure logic thinker, a person who really loves coming up with a technical solution to a technical problem, doesn’t want to have to think about business. They don’t want to have to think about the customer-facing impact of their software. They just want to have a highly efficient solution to a mathematical puzzle.

And as much as I enjoyed solving these puzzles in the past, I’m realizing that my ultimate goal was never related to the puzzle in the first place. It was always very much concerned with whatever the puzzle was surrounded by – the operational framework that the puzzle happened in.

The Identity Crisis

For a lot of software entrepreneurs who come from a background of crafting really high-quality software, this transition to agentic systems that write good code on a good day and mediocre code on a bad day – it feels like you’re losing a point of pride. You’re losing some sort of your identity as somebody who’s been building things for many years, even decades at this point.

Jack Ellis, the co-founder of Fathom Analytics, has been very outspoken on his Twitter feed about his failed experiments with AI systems in maintaining the quality of a codebase or adding features to their quite high-throughput, high-performance software suite. A lot of people have chimed in and agreed that their initial contact with AI coding has been explosively negative, structurally defeating, because the tools were just not up to scratch. They weren’t creating code as the original author would have wanted it to be.

But here’s the thing: I look at my work with Podscan, and it’s been working out every single day for half a year. It can’t be that I’m a significantly better prompter, or that my configuration of my AI agents is better. We’re both using the same tools, and we’re both capable of clearly expressing what we need.

So it must be in what I allow to be the right code, or what my code reviewing process doesn’t flag as a problem.

The Flexibility Mindset

I’m quite liberal when it comes to patterns that I may not have implemented myself but I understand. When I look at the code suggestions that Claude or other tools give me, occasionally they’re using things I would never have used. But then I try to figure out why they’re being used. I engage with the system in a conversation. Either it’s explained to me and I agree with it, or we iterate to find something better.

I’m very flexible in accepting that the first implementation of something – provided it actually works – is a solution I’m willing to allow into the codebase, as long as I fully understand it and have had a conversation with the developer (which in this case is an AI system) about feasibility and alternative approaches.

Our expectations for what “good code” means are wildly different between developers, and what acceptable code is as well. I’ve always been flexible there. If this does the job, then I’m good with that. I’ve never been so committed to creating the perfect software implementation of a feature that I would dismiss a non-ideal variant of it, that I would dismiss a preliminary version that works well enough but may not be perfectly crafted.

This might be the perspective you need to have, particularly in early-stage software businesses where velocity, shipping speed, and flexibility are more important than pristine code. Something that I believe is only pristine for a while anyway. There are always optimizations to be made. You can always find ways to improve things. Having code that is perfect – it’s only perfect until you decide it’s not. And my threshold for deciding that things are not good enough is pretty high. Something needs to be really bad for me to call it not good enough for now.

The Incremental Change

What I’m trying to say here is that just like choosing a new continuous integration chain because it’s more effective, or porting part of your system to a new, more performant programming language, or choosing a new vendor for a higher-performance database system – making some kind of incremental improvement on your business – allowing yourself to let go of the notion of having to love coding, having to love the act of writing code, is one of these incremental changes in your entrepreneurial career.

We’ve all figured out that we interface with AI systems very effectively when it comes to writing emails, when it comes to having the AI play devil’s advocate for certain communication or customer problems. We’ve all learned that these tools are really good at helping us with that, and they can be very persuasive when set to solving a particular problem.

So the last question for many software entrepreneurs is having these tools touch their codebases. People hesitate a lot, and for them, it’s a big change, a hard change to deal with. Maybe it really is just letting go of a self-assigned identity – that you are only a true programmer if you program.

The Delegation Reality

Here’s something to consider: eventually, once your business becomes bigger, you’re going to have to delegate development anyway. Someone is going to write code differently from you. It’s just that now we have access to that somebody else for twenty bucks a month when we use Claude or OpenAI’s Codex or Gemini or whatever it might be.

It hits us earlier as developers now – that the delegated parties that write code for us aren’t writing code as we would. That’s one of the changes we have to embrace. And once we do, all of a sudden, the shipping velocity and the feature agility that we have in building software businesses is just massively bigger. It’s quite the advantage.

The Path Forward

I wonder if there will be more and better tooling to help developers who have these extremely high standards get to the level of quality they want anytime soon. I would certainly hope so, because the benefits of building from an orchestrator’s perspective, compared to typing every single thing into your development environment perspective, are so massively outweighing the drawbacks for me right now that it would be very hard for me to get back to actually coding as I did two years ago.

If you find yourself experimenting with these tools, and if you find yourself questioning whether your die-hard approach to hand-crafting software is a relic of the past or a hill you’re willing to die on, maybe consider that it really has a lot to do with not what the job to be done is – why you’re writing this piece of software – but what the goal of the surrounding system is.

Are you building this because you enjoy building? Or are you building this with the ulterior purpose of facilitating somebody else’s job, helping people be more efficient, helping people waste less time? Is this a self-centered activity, or is it an externally-pointing activity?

For many people, this transition is shaky, filled with disappointment. But I hope people allow themselves to not be trapped in the perfect coder mindset anymore. Because what I’ve discovered is that I feel the same level of enjoyment – if not more – from looking at generated code, making sure it works, and making sure it implements the features I want in a way I find appealing, than I would have gotten from actually writing the code myself.

It turns out that it’s not that I love coding. What I actually love is getting code written and getting code deployed. Getting it deployed quickly. Getting it into the hands of users who can benefit from it.

And if AI can help me do that better, faster, and with less personal strain – well, that’s not a loss of identity. That’s an evolution toward what I was always meant to be: not a coder, but an entrepreneur who happens to know how to code.

The code was never the point. The business always was.

Everybody has certain interests, certain things that they want out of this data. And the more I run this business, the more I realize there’s a kind of Maslow’s hierarchy of needs that marketers have in terms of how they look at data.

The Discovery

In a recent conversation with my brother-in-law, who runs his own branding agency and is a deep expert in brands and markets and audience perceptions, I realized that even without understanding that there is this hierarchy of needs, I have actively used it in my product onboarding. And it’s caused several pretty sticky customers to stay on the platform.

Let me share how this came about and what it’s all about. I think it’s probably very interesting to look at the data that people you serve need – people that have a job to be done – and understand what exactly the data is and how important different kinds of data are to them, in that specific order.

Like I said, it’s kind of like Maslow’s hierarchy of needs, which, if you’ve never heard of it before, is a theory of motivation that describes how humans need to fulfill one kind of need before they can go for another. They have physiological needs first – actual physical needs like food, water, air, shelter, clothing. Once those are satisfied, they move to safety needs – personal security, ownership, property, health. Once that’s satisfied, it gets more cerebral. It becomes about love and belonging – partnership, friendship, connection. And once that’s established, people can develop something akin to esteem – self-esteem, motivation, respect with each other. And ultimately, when that is established, self-actualization – making a dent in the world – becomes a possibility.

I find something similar exists for marketers and anyone seeking somebody else’s attention. There’s this specific lens through which to look at what marketers need to make smart choices, what people who are trying to convince others to use their service, join their organization, sell them something, or get them to pay attention need to know.

Building the AI Onboarding

A couple months ago, I decided that we’re all using AI in really strange ways on the internet. How about we make it useful and start using AI in interesting and user-helping ways, instead of just making AI do jobs that nobody needs them to do?

So I tried to figure out how I could use AI in my onboarding process. What I found was that people often struggled with creating good alerts for their businesses or jobs because they didn’t know what to look for. They didn’t know how to phrase it.

Since I’ve had a lot of customers and a lot of insight into what they ultimately ended up searching for and what was effective, I built this list of 10 things that I believed people should look into, in order. I built an AI – an agentic system around it – that asks people a couple questions and then builds those 10 alerts perfectly for that particular user.

If it’s a medical company, it asks them what branch of medicine they’re in and what they’re trying to accomplish in the podcasting space – what they do, what they do best, what they’re known for, what they’re maybe not known for. And then it starts tracking all kinds of different things about them.

In setting up the different things that I wanted to build so that people would have a very broad overall net to fish in the podcast conversation space with, here are the things in order of relevance that I came up with:

Level 1: Self-Awareness – “What Are People Saying About Me?”

The biggest one is the mention of the service or the product that these people work for. Somebody who works for Notion will look for mentions of the Notion product or Notion AI. Somebody who works for a soccer club or football club will look for the names of their players, the name of the club, their mascots – they’re going to track where people mention those things.

It’s very specific, but it’s always about what we are – some kind of identity. The thing that they care about, the thing that they’re paid by, the thing that they need to market, that they need to facilitate.

So the first thing people always search for is the name of the product, name of the business, or even their own name. That happens quite a lot as well, because people want to know where they’re mentioned so they can react to it.

Level 2: Competitive Awareness – “What Are My Competitors Doing?”

The second biggest thing is always: what are my competitors doing? It’s the moment you know where you’re mentioned, you become increasingly interested in the people around you – the people you compete with, the people that are in the same market. What are their interests? What are their conversations that they’re participating in? What are they not just saying, but what is said about them?

This reliably is the biggest thing that I find being tracked on the platform. There’s a nuance here, because there’s a kind of self-selection – people often only know of a few of their actual competitors by name. There’s always an unknown unknown in there as well. Sometimes you just don’t know who is building the business that is coming to replace you, and sometimes you’re just not aware of these competitors that are up and coming.

So in that sense, I’ve seen people track not just competitors, but emerging trends in their industry, so they can spot new names along the way.

Level 3: Industry Awareness – “What’s Happening in My Field?”

It goes from what are people saying about me, to what are people saying about my competitors, to the next layer: what are people saying about developments in the industry? What am I missing out on by having this myopic lens just on myself and the immediate threats around me?

It becomes a widening of the conversational landscape that people become interested in once these two basic needs are dealt with. Like, what is what am I going to eat today, and is somebody going to steal my food? Once that’s dealt with, people are asking: well, what food is out there? What new places to hunt? What new places to harvest could there be?

Level 4: Sentiment Awareness – “How Do People Feel?”

Very quickly with that come what I would call the sentiment-based interests. People very quickly turn their attention not just to the factual conversations in the field around them, but also to the emotional sentiment around it.

I’ve seen very positive sentiments around people who really solve other people’s problems in a delightful way. They get great shout-outs, their products get mentioned and highlighted and reviewed positively. And then I’ve seen social media tracking for airlines or internet providers or other companies that tend to get a lot of flack because of the intensity with which a problem, when it happens, affects people’s lives.

It’s been quite interesting to see the tracking that happens both around the shout-outs – the customer success stories, the very positive signals – and the reputation management, which is what a lot of PR companies do just as a job. Their whole point of existence is to track public relations disasters and answer them before they get mainstream. Get spin on the conversation, get the narrative adjusted.

So you’ll find a lot of that out there as well. People look for sentiment, they look for other people’s opinions – the opinion landscape. It goes from fact to opinion.

Level 5: Strategic Projection – “What’s Coming Next?”

Beyond that, it goes to projection. Once the sentiment landscape is covered, people look into signals in the market, but not about consumer behavior – about investor behavior and regulator behavior.

I see a lot of people that use Podscan for tracking acquisition and investment signals. Who gets acquired by whom? What is the big move that my future competitor might make right now? Are they being acquired by somebody that I should know of? They look for investments, for new companies springing up.

At the same time, they look into regulatory and compliance signals. Is a government or some government podcast somewhere debating how they could curtail our capacity to function the way we do? Are they going to make things harder for us? Are they going to make things easier for us? Is some podcast that is effectively just a live stream of a committee meeting giving us insight into something that we should very quickly solve?

All of that can be tracked, and people track market expansion too. I think that’s in the same line of projecting or guessing future outcomes. Where is this market going? What are the forces, not just in the sense of what’s happening in my industry or what’s the technological trend, but what happens between industries? Are there movements that I should be aware of? Is there a kind of seismic shift happening or to be expected in any given place at any given time? How can we get ahead of it? How can we be there before it happens?

A lot of that is projection tracking, but it’s understanding dynamics nonetheless.

The Framework in Practice

So if I were to give this a little bit more structure: from a marketer’s perspective, if they look at information that could be gleaned from public opinion and public reaction – public notions, values, perspectives on their product or services – they always look at themselves first. Are they mentioned? Where are they mentioned? To know what happens around them.

Then they look at what’s happening with others around them – what are my direct competitors doing?

Then they broaden this to the industry, just to see what’s the wider angle, what’s coming a couple miles ahead of me, instead of just immediately around me.

Then they go from factual developments into emotional states of people – what they’re talking about, what they’re celebrating, what they’re complaining about.

And from that, they go into a purely speculative world of thought leadership, of investment, of acquisition, of regulatory compliance, and the industry at large.

I think that is a hierarchy of market proximity. You first think about yourself, then your immediate threats around you, and once the facts are dealt with, you look into sentiment and how that will impact the future and how the future is seen by others.

Applying This to Your Customer Segments

This is a very interesting hypothesis because it helps you speak to your customers. Depending on where they are on their journey, you need to address different needs.

If they’re currently doing pretty well as a company – they’re highly monetized, highly profitable – they probably don’t care as much about what’s being said about them or the immediate threats to them. It’s quite likely that the more important stuff exists in the sentiment of the industry and identifying thought leaders. Who might we need to hire in the future? Who might need to be discussed for board positions that we’re offering? Who might we want to see if we can integrate into our company? That’s what a big enterprise business would look at, and what the people who are looking at these opportunities might resonate with in marketing and outreach materials.

Now, if you sell to a solopreneur business – somebody who’s running their own business – they’re very likely completely overwhelmed to begin with, trying to do everything. So for them, you would need to fulfill this hierarchy of needs right from the bottom. You would facilitate tracking what’s going on with them, what’s going on with their direct competitors. Maybe help them discover who those competitors even are, and give them access to maybe at most what the industry is doing, so they don’t get overwhelmed with all the signals from it.

The Practical Impact

The way we reach out to our prospects when we’re doing sales is very much informed by this. I’m not sure if something like this exists as an actual hierarchy of needs in the marketing literature, but I found it very interesting in how I communicate with my prospects and with my paying users.

When they ask me to help them set up functional alerts, more often than not, I find it works well to get a glimpse of where they currently are on this journey – which needs are already met and what the next unmet need is that I can focus my attention on. This helps me share with them what they could be doing, what they should be doing in the short term, and what the strategy for the long term should be.

Your Turn

Think about your own customers and the data they need from you. What’s their hierarchy of needs? What do they need to know first before they can care about the next level? Understanding this progression isn’t just about better onboarding or sales – it’s about truly understanding the journey your customers are on and meeting them exactly where they are.

Because just like Maslow’s hierarchy, you can’t skip levels. You can’t ask someone to care about industry thought leadership when they don’t even know if people are talking about their product. You can’t get them excited about sentiment analysis when they haven’t figured out who their competitors are yet.

Build your product, your onboarding, and your sales process with this in mind. Start at the bottom of the hierarchy and work your way up. Your customers will thank you for it – and more importantly, they’ll stick around because you’re giving them exactly what they need, exactly when they need it.

That’s what I’ve learned building Podscan, and I hope it helps you build something meaningful too.

Alright, people paying for your product, that’s the general entrepreneurial idea, right? But along the way, you’ll realize that this starting point isn’t actually the whole story. Along the way, there are so many things that you care about that other people simply don’t.

Today, we’re diving into a couple of things that might be contentious, maybe polarizing in their ways, but are definitely things that you’re over-indexing on that other people do not care about. This is going to be different for every project and every founder, but let me share what I’ve learned from my own experience building Podscan.

The User Interface Obsession

Let’s start with the user interface. I thought, if I don’t spend hours, days, and weeks tweaking this interface, people aren’t going to use my product.

And lo and behold, people still use it, even though a lot of the things that I want to change – things I feel deserve weeks worth of refactoring – are still sitting in my feature backlog.

People are instead very much focused on using the product to serve their needs. As clunky as it might be, extremely rarely do I ever get any feedback on the user interface. This might be because it’s further along, or because it’s good enough, or whatever it might be, but nobody’s telling me, “Hey, you should really refactor this.”

I had one customer – just one – tell me: “In your product, there’s a certain kind of behavior that exists in this location, and that location, and that location, and it’s slightly different in the fourth location. Could you streamline this? We’re getting confused whenever we use this.”

That’s good feedback, and it’s something I still have on the pile. But here’s the thing – they’re using all four locations! It still works for them, even though it’s slightly confusing.

So my focus isn’t on rebuilding my interface components. My focus – and this has been my focus with Podscan from very early on, but more now than ever – is making the data that flows into the system as reliable and as usable as possible. Because in the end, that’s all that matters: what data comes in, and what of that data is useful.

People care about accurate transcriptions. They care about accurate results for their alerts. They care about reliable API access. Nothing about what it looks like is relevant. People would probably be able to use the very first version of Podscan if the data quality was high enough.

The API Design Trap

Which brings us to API design. As founders, we have this idea that we need to have exactly the finest API. We want an API that people at Stripe would look at and say, “Wow, this is well designed.” That’s what we want.

People really don’t care.

I have hundreds of people who use the Podscan API to power their businesses at this point. One person ever reached out and said, “Oh, I’m trying this API endpoint, and it’s weirdly named.” And that person? Never converted into a paying customer.

So do I care about this? No. I designed my API well – at least I think so, I hope so – but I do not go overboard in making it the most beautiful thing I’ve ever seen. Over-engineering is my enemy when I run a software as a service business.

Here’s the reality: the first version that is deployed of anything will eventually be depended upon. There’s Hyrum’s Law – that with a sufficient number of users of an API, it doesn’t matter what you promise in the contract. All observable behaviors of your system will be depended on by somebody. Even if I don’t explicitly build something into the API, somebody will find it, use it, and then I can’t change it.

So I’m not going to go overboard to make this a beautiful thing. The important part is to document it well.

Documentation: Fancy vs. Functional

And even that documentation doesn’t have to be great. It doesn’t have to be fancy. It doesn’t have to be flashy. It needs to be text that you can copy and paste and throw into an AI. That’s pretty much what it is, honestly.

If you build anything and you build documentation, just make it accessible. Make it so that people can copy it, can copy and paste it, can run it, throw it into Claude or ChatGPT to get the gist of it or a code example. Make it easily accessible. Don’t make it a JavaScript single-page app that can’t be scraped or parsed by OpenAI or Anthropic.

You want something that people can pull very easily into their development chain, so they can use your documentation – your source of truth – as a data foundation for their agentic or real coders.

When it comes to user-facing documentation, people don’t really care what your documentation looks like either. It can be a standalone help desk software like Intercom’s knowledge base, or what I use, Crisp. There’s also Knowledge Owl and many different systems that allow you to set up a help desk.

But initially? My help desk was a couple of Notion pages turned public and linked from my application. And still, in some parts, I have public Notion pages. I have a section in my Notion organization that’s called “Public – Do Not Delete,” and links to all the individual pages in there are littered across the application.

It makes it extremely easy to update. It makes it extremely easy to write. I even have a Notion proxy running on a Cloudflare Worker that pulls this data to a specific URL so it looks like it’s under my own domain. That’s an additional step that’s not really necessary, but it’s kind of cool.

The point is: have documentation that’s easy for you to write. Because people will read it if they really need a solution to their problem and they’ve already seen the value of the business. They’ll go through the step of reading a weird website or trying to find exactly what they need in a convoluted document.

You need to have an easy time writing it as a founder, and people will bite the bullet to search. Any documentation, any knowledge base, is better than none. And the one that you create and maintain for your customers is going to beat the one that your competitor doesn’t have, or that your competitor auto-generated but never updated since the last patch two years ago.

The Interoperability Illusion

Another thing – and this might be different between businesses depending on your audience’s professional expectations – is interoperability.

You’d think that people really care about being able to import Excel files or files in proprietary data formats used in their industry, and export the exact same file format or something else that goes directly into the machines that produce their merchandise or whatever.

But that’s really not what people expect from software as a service platforms. That’s what they expect from standalone, installed, hyper-specialized, super expensive, fully-fledged software suites.

From a SaaS, people have a minimal – almost maximum – expectation: Does it handle CSV or Excel sheets? Can I import a spreadsheet, select the things that I want, and it pulls it into the program? Can it export a spreadsheet that I can then take to my next software?

That’s all they want. The fancier you get, the more you have to support. But people have found ways to turn Excel files or the even simpler comma-separated value file – the CSV – and import that into anything they need and export it from anything they need. As long as you have that baseline of a CSV export in whatever is relevant to your customers, you’re pretty good for input/output.

It’s surprising because you think the more you support, the cooler it looks. But that’s really engineering you can do at a later point. It’s not required. People don’t care.

Customer Support Reality Check

Customer support is something I’ve changed my mind on over the past few years. In the beginning, I thought, “Hey, you need to have chat. You need to be there within seconds for your customers to delight them.”

And it’s still true – it’s really cool to see somebody go, “Wow, you responded within a minute to my customer service outreach! That’s amazing! That never happens to me. Are you a bot?” That’s what I get now more than ever: “Are you an AI?”

But honestly, I don’t think I need the chat thing to be real-time in the first place. People are fine with email, particularly the higher you go up the corporate customer ladder. When you work with enterprise, most communication between you and your prospects and customers is going to go through email anyway.

Having a customer service system that just goes to email – and maybe live action, but only when you initiate it – works perfectly fine for most software as a service businesses.

Here’s the truth: People who expect to be helped immediately for something that costs them 10 bucks a month are likely not good customers to serve anyway. But somebody who’s paying 200 bucks a month and is fine with a day or two of delay between emails? That’s suddenly a much easier, much less annoying, and much more gratifying customer to serve.

Consider that in the beginning, it’s useful to build that initial relationship with your customers. But the moment you have some kind of repeatable process, turn off the real-time chat – only use it when you need it – and have everything else go through email. It’s always good to have a paper trail anyway. You can bounce these emails up and down if you need to, delay them or have them come back to you in a couple days if it’s not pressing right now, and just delete them if they don’t work out.

The more professional your customers are, the more they know that you’re busy and won’t expect a sub-minute response time. It still delights. It’s still great. But it’s not a requirement.

The Bottom Line: What Actually Matters

So if you think about it, what people need is something that helps them get their jobs done without having to bend over backwards to make it happen.

Provide common and expected input/output formats. Have a reliable and well-documented system – both the user interface and any programmatic interfaces you might have. Have reliable and expectable response times with your customer service.

Do these things, and you’re pretty good with most industries and most people who will gladly pay for your service over time.

The lesson here isn’t to build bad software. It’s to recognize that as a solo software entrepreneur, you have to do the 80/20. And the 80/20 clearly is in “works well enough and is super well documented,” not in “beautiful, long-term, hyper-maintainable, hyper-scalable” perfection.

Your customers are using your product to solve their problems, not to admire your craftsmanship. They want reliability over refinement, functionality over fanciness, and results over architectural beauty.

Build something that works, document it so people can use it, be there when they need help – even if not instantly – and keep making the core value proposition better. That’s what matters. That’s what people pay for. Everything else? That’s just founder vanity.

And recognizing this difference between what we care about and what our customers care about – that’s one of the most important lessons in the journey from founder to successful entrepreneur.

And for founders who are already on that journey? I’m just going to share the little things I’ve realized along the way, so that maybe you can recognize them at an earlier stage.

So let me get into the mindset here. Why should you never start a software business as a solopreneur, as a bootstrap founder?

The Loneliness Nobody Warns You About

First off, it can get incredibly lonely. Software entrepreneurship means that you’re going to spend more time with your code, with your product, with making sure it runs, making sure it provides the value that people may or may not pay money for. You’re constantly going to be interfacing with computer systems, and when you rarely interface with your customers, it tends to be in a negative context.

Sure, you can have a nice conversation. You can turn a bug report into a very friendly interaction with a prospect or with a customer. A complaint or a help request – you can always turn that into something positive. But it starts out as a point of friction, as a point of challenge. So any human interaction that you’re likely going to have with your customers is going to be one of being challenged, seeking help, or – and this might be even worse when you come from a technical perspective – somebody who is not interested in your product. You try sales outreach, you try marketing. People come in. They see it. They don’t want it. They don’t even come in. You send emails. People say, “Stop sending me emails.”

That can make you feel fairly lonely, particularly if you’re not doing this with a group of people.

The way out for me is just being very active in my founder online community – being on Twitter, being in Slack groups, reading people’s blog posts, writing blog posts and interacting with my readers, having a podcast, having interviews on the podcast, talking to people. Just giving my brain the feeling that it’s real, that I’m not alone.

But there are different kinds of lonely. There’s the lonely that happens over time, where you just feel like another week went by and I only had like two real conversations with people during my work hours. This is a kind of sad, prolonged lonely.

But then there’s also the lonely in the moment. It’s two o’clock in the morning, for some reason your server has decided to run out of memory, and you are trying to restart it to make sure that the product comes back up, but then it fills up again within five minutes, and you need to restart it again. So you need to fix the problem while you’re also triaging the problem, while customers start emailing you that the stuff doesn’t work.

There’s a loneliness in that moment where you are the sole defender of the castle and you have to keep the invading hordes at bay, but also tell your inhabitants that things are going to be okay – while sharpening your swords and patching up your armor at the same time. It’s just a lot of pressure in moments where you don’t have many people around you to help you.

Becoming a Lightning Rod for Problems

Here’s another reason why you should never start a software as a service business: particularly in the early stages where you are the only person responsible for the business, you’re responsible for everything. And things will pull at you with unknown, previously unknown priorities.

At some point you thought you had figured it out. You’ve developed an outreach campaign that brings in new leads, and they eventually convert. And all of a sudden, one of the service providers that you use for your emailing starts experiencing outages every other day. It gets worse and it gets worse, and you suddenly have to completely rebuild your email infrastructure because that service needs to be replaced.

So not only do you need to replace a running system and run an outreach process that is mapped onto your email automations, you also need to find a comparably capable provider somewhere else that you can then integrate into your system to rebuild the exact same system. And that came out of the blue, took three days out of your week, and all of a sudden, everything else you wanted to do – the feature you promised your customers – none of that got done.

Lightning is going to strike all the time, and in a way, avoiding it makes it worse. So you have to become a lightning rod for problems. You have to go towards the problems any time they might appear.

As somebody who previously was a salaried engineer, when I started software development, I was taught to avoid problems – to avoid bugs, avoid complications, avoid challenges, make sure that they can never appear. And then when I became an entrepreneur, it was like, no, no, I have to get to the challenge before the challenge gets to me. I have to make sure that I preempt the chaotic explosion and make it happen early, so that I can see what parts of it get burned, so I can build a stronger, fireproof system around those systems.

You know that meme with the airplane with the bullet holes? It’s commonly used to say that people focus on the wrong things when they try to improve something. The US engineers thought that only the areas where planes that returned from fighting had a lot of bullet holes should be strengthened, forgetting that the areas that didn’t receive many bullet holes were likely representative of the fact that if a plane was shot in those areas, it wouldn’t even make it back home. Selection bias.

That’s kind of what this is. You want the plane to explode quickly so you can see where you need to strengthen your system more. Because if things keep working and keep working, they will blow up in your face anyway. Any sufficiently complicated system will eventually have some kind of explosion – either through latency accumulating, or external connections dropping, or some kind of dependency not working. There will be something at some point, and you will need to be there.

The 24/7 Reality Check

Which brings me to the third point: you are effectively working 24/7. You’re not putting all your efforts in 24/7 – you’re still going to go to sleep, and most nights, it’s going to be great. You wake up, you go to work, you keep working on it. You take care of all the customer service messages that came in overnight, and you send out emails the next morning. There will be some kind of structure to your day.

But then there will be days where this doesn’t matter. Where at three in the morning, you get a notification – an SMS or a push notification to your phone, which you hopefully have configured to ignore most things but let these things through – and it tells you your website is not reachable. Your external monitoring, the Pingdoms and Uptime Robots, they have tried to ping your website and it’s not responding. And you have customers that have an SLA – a service level agreement – with you that the maximum daily downtime is an hour or 30 minutes. You better get going.

This is the moment where you work 24/7, because you’re always on call building a software service business. Even if you use the best hosted application services, if you use the best hosted databases, there is going to be something. Something will happen. And even if it’s just the connective tissue between the services that sometimes breaks and you just need to restart your server, it’s enough at three in the morning to pull you out of your routine.

And that’s something that is unavoidable until you hire. And then you need to hire somebody who is going to be reliably there and knows exactly what to do, which is still a different challenge. Because likely what’s going to happen when you hire somebody to fix this for you is that they’re going to be woken by the alerts, they’ll spend five minutes trying to figure out what’s going on, they’re going to try and implement a fix, it doesn’t work, and they wake you up 10 minutes later. In the beginning, that is quite likely the kind of event chain that’s going to happen.

Running a software business is not going to make this easy for people with children or with other dependents that they need to take care of, or who want to have a solid distance from the work that they do. Obviously, there are still many parents, many caretakers, people with professional distance who end up building successful software businesses. But it’s certainly a higher investment of focus and attention.

The Inertia Mountain You Must Move

Here’s why you really shouldn’t build a software as a service business: it’s incredibly hard to convince people to change what they currently have. Most software as a service solutions are new versions or better versions of things that already exist, and the inertia that people have that prevents them from changing from their existing solution to a new solution – it’s incredibly hard to overcome.

People will go out of their way to not change anything about their work. And this might be different in certain audiences, but I can tell you, it takes a lot of effort to convince somebody not to just give you money – that is already hard – but to change their process in a non-trivial way.

This is particularly challenging because in the beginning, as you start your business, you have a lot of assumptions. Otherwise you would never get anything done. You have to assume a lot of things, and those assumptions – some of them are likely not correct. So you have to course-correct all the time. And a product that is in this path of the first couple years of course-correcting, of figuring out what exactly it needs to do, is even harder to sell, both as a solution and as an actual thing that costs something.

For you to learn how to talk to people in a way that you can actually assuage their fears, actually convince them that they’re missing out on something if they don’t use this – speaking the language, learning the language, learning how they prioritize, how they focus on their challenges – that takes a long, long time in any field. And it takes a lot of communication with customers, which, as I said earlier, sometimes is not happening that much because you’re so bogged down with the actual product that you want to be able to sell to people.

The Shifting Sands of Constant Change

Don’t build a software business if you want to feel secure in your choices and assumptions. Because not only does your product change to meet the job to be done of your customers, but the jobs that your customers have, the internal processes, the internal requirements – they change constantly as well. And this is true for smaller businesses just as much as it is for enterprise businesses.

Things are changing all the time. You will always have to keep up with things. You will always have to make sure that if somebody changes their process, you can still adequately map your process towards this. And then you have to think about the fact that the whole industry is changing – new people join the industry, some people drop off. New regulation hits the industry. New technologies get developed, new standards defined. New provisions are formulated. New laws are enacted for or against certain things. New perspectives are being integrated into people’s processes. New taboos come up. Old taboos break off.

It is a constant struggle to figure out what is going on and how you have to respond to things. So if you would like to feel like you know what you’re doing, choose an occupation that you can do for five years straight and not expect much change. I don’t know, become an oil painter. Oil paints have been chemically similar for the last couple hundred years. Of course, there are new developments in that technology as well, but the act of painting, the act of making art, does not constantly shift as much as the requirements and minuscule details and processes of people who use software tools might.

The Deprecation Treadmill

And then there’s the technology layer. Everything is getting deprecated and changed all of the time. If you choose the current version of Linux to install on a server, two and a half years from now, the long-term support for this is going to end. If you choose MySQL 8-point-something today, next year AWS will retire this version and charge you double if you want to keep it running. If you use an API, something is going to change, or you’re going to be asked to migrate to a new version because only that supports whatever new regulation – SOC 2, or some banking regulation in India, or something like that.

It is bizarre how often you have to chase changes and implement them so you can still do the exact same thing as you’ve done before. Things get deprecated and things have to be maintained. Because it’s turtles all the way down – you choose an infrastructure as a service provider that has to maintain a certain set of software, and then they have to upgrade it because of security concerns, and now you have to upgrade your integration, and the people using your product now have to upgrade because something works slightly different.

It’s this infinite chain of tiny changes bubbling up and down and making people change the things that are already running for them. Ideally, you start containerizing and isolating things, and you make sure that they are compatible, and you have alternative ways of doing it. But in the end, you’ll find that it’s always going to stop you left, right and center, because somebody changed a dependency somewhere.

The Ownership Paradox

And you have to own it. You have to both deal with it in the moment, and if it makes your software more unstable, if it makes your business wobble, you have to tell your customers, “We’re experiencing a problem.” You’re not supposed to say, “Hey, it’s AWS’s fault” or “Our email provider isn’t working.” You have to say, “We have a problem with our email. It’ll be back in a minute.” You have to own these things that are not your fault.

And that’s one big thing about running a software as a service business. Ownership is limited in many ways. It’s already hard to own a software business because you’re just building rented infrastructure on rented land. But you have to think of the fact that there are so many variables and so many externalities to running a software as a service business that it will never be something that you could just freeze and say, “This is it forever.” Things change all the time.

The Plot Twist: Why It’s Actually Worth It

I think these are sufficient reasons to consider maybe becoming a farmer or an oil painter. But realistically, none of these are problematic enough to not be worth it.

Because one of the things that building a software business allows you to do is to build a super high-leveraged, high-revenue company that is very, very interesting for PE companies, for other companies to acquire, and that might net you a couple million at the very least, if you run it well and bring a customer base that is worth an acquisition.

Building software businesses is a very interesting way to build financial stability and financial security. Unlike so many other things, it has such a massive upside that these downsides – as impactful as they might be – you’ll find versions of this in many other occupations that do not guarantee, or at least promise, an exit and an acquisition down the line.

So it’s absolutely worth it for me, even though I sometimes feel lonely when I just try to fix my code, even though I wake up to some kind of monitoring email and think, “Oh, come on, this again.” Hey, that’s just part of the arena. And you can build systems to automate this away, to make it easier, make it better, and you can build processes internally for yourself and the company that you’re building to make these things less likely and less impactful.

The Path Forward: Start Slowly

So if you’re still here, if you still want to build a software as a service business, go for it. The only thing I would recommend is do it slowly. Do it on the side. Build a software business one hour a day for the first couple weeks. See if you can handle this. See if this fits into your existing lifestyle. And then slowly up it to the point where you’re spending most of your time on it.

Get into it easy. I think that’s the best way of seeing if this is for you. Don’t throw yourself into it – that’s just going to freak you out. You have to learn how to deal with these things over time.

Because here’s the truth: every challenge I’ve described, every late-night server crash, every customer rejection, every deprecated dependency – they’re not bugs in the system. They’re features. They’re what make you resilient. They’re what make your business defensible. They’re what separate the people who build lasting companies from those who give up when things get hard.

The loneliness teaches you self-reliance and drives you to build meaningful connections. The constant fires teach you to build robust systems. The 24/7 responsibility teaches you what truly matters. The resistance to change teaches you empathy and communication. The shifting sands teach you adaptability. The deprecation treadmill keeps you sharp. And owning problems that aren’t your fault? That teaches you true leadership.

So yes, never start a software business – unless you’re ready to become the kind of person who can handle all of this and still wake up excited about what you’re building. Because if you are, there’s nothing quite like it.

This one’s for you.

Okay, here’s the thing – even if you’re in the AI-embracing camp, happily letting robots write your Redux boilerplate, what I’m about to share will be equally valuable. Because today, I’m going to show you all the ways you can leverage AI in your software projects without having it write a single line of production code.

The Coding Companion You Never Knew You Needed

The biggest breakthrough – and likely what some of you have already tried but can be done in a very particular and intentional way – is having AI systems as a coding companion. Not a code writer, but an investigator. Someone you can task with research, and who reports back insights that you can then tackle as projects on your timeline.

This is exactly how I got into using AI tools as coding helpers. Back in late 2023 and early 2024, when I was first building Podscan, AI systems just weren’t capable of producing reliable code. They couldn’t. So what was I using these tools for? I was tasking them with individual problems and challenges, asking them to give me insights that would allow me to write the solution myself.

Here’s the kind of thing I’d ask: “This function gives me the wrong result, even though I implemented it correctly. It worked for a bit, then I made a couple changes, and now it doesn’t. What could be the case?” This kind of impromptu investigation is where AI tools really shine. And if you tell these tools – either in the system prompt or in your request – to not create any code but only guide you through a solution, they become the pair programming partner who never touches the keyboard. The code reviewer who’s giving you insights and opinions on the code you’re writing.

Your Always-On Bug Hunter

AI is incredibly capable of building a theory of your program internally just from reading the code base. It’s not executing the code, but it seems to parse and trace through it to understand where bugs might come from.

Here’s how I use it: “Hey, I’m experiencing a bug when this happens. I think it’s in this module, or at least this class is involved. Can you investigate how, when I call this function with this kind of data, erroneous output like this could potentially emerge?”

Now, you have to understand that LLMs suffer from what I call “sycophantic exuberance” – they want to tell you everything is great. So if you just ask it to find bugs, it’ll say your code is perfect. You need to actively tell it to maintain a very nuanced, professional, detached perspective when investigating your code base.

Some bugs of certain complexity just won’t be reproducible by an LLM. You’ll need to give it precise input data, precise output data, and every step along the way. Traditional static code analysis tools might be better for some cases, but I have a strong feeling that people are working on MCP systems that AI bug-hunting agents will soon be able to use in their own analysis.

Think of it as your always-on, always-available bug-hunting colleague that can look at code in ways you might not. It brings a completely different perspective, and sometimes that fresh set of eyes is exactly what’s needed to find the bug.

The Cross-Language Optimization Expert

Here’s where things get really interesting – trans-language or multi-language code optimization. How often have you had an ORM query or some SQL embedded in your JavaScript or PHP that’s running slow, not getting the right data, or could just be faster?

An AI agent is quite capable of taking an existing query – both the actual SQL and the way it’s composed in your programming language and framework – and investigating how it could be better. When it comes to SQL queries, and this is something I do constantly with AI help, here’s my process:

Run the query, note the execution time. Run an EXPLAIN ANALYZE with the exact same query. Take that output along with either the full database schema or at least the table schema you’re working with – copy and paste the fields and existing indices. Then let the AI look for ways to optimize.

If you provide a full EXPLAIN ANALYZE output for a particular query, in nine out of ten cases, I get an immediate optimization and speed improvement. And here’s the beautiful part – it’s not necessarily writing code. It might just suggest a new index to add, or point out that your indices are in the wrong order.

This happens to me all the time. I create an index thinking it’s exactly what I need. Then a few queries later, it turns out it shouldn’t have been an index on the ID, foreign key, and created_at field in that order. It should have been ID, created_at, then the foreign key, because that’s the order most queries access the data. I would forget, but an agentic system can figure this out.

Your Personal Security Reviewer

One of the latest features I’ve been experimenting with in Claude Code is security review. It looks at recent changes and checks them for security implications. This is another incredibly useful behind-the-scenes use case that can eclipse traditional tests in terms of impact on code quality.

Imagine creating a very specific security-related prompt where you express all your preferences for application security, all the commonly used best practices you want to establish in your code base. Then have Claude check the code base and recent commits for adherence to your security preferences, for semantic correctness, and for potential vulnerabilities.

Suddenly, you have a very capable – not perfect, but highly capable – security reviewing tool that you can run every time you commit something. Or before you commit. Or when you merge commits back into your main branch. Or when you’re experimenting with new technology and want to see if it has implications in other parts of the code base.

Claude is quite capable of understanding security requirements that exist in our community – more than you might know, because it was trained on all security-related software, not just the vulnerabilities you’ve personally noticed or worried about. It’s a great tool to run before a major release to ensure you’re not facilitating a massive backdoor into your system. These get caught quite reliably by agentic AI systems.

The Code Reviewer You Can’t Afford to Hire

Security vulnerabilities notwithstanding, agentic code systems are spectacular at reviewing code. And this is particularly valuable when you’re the only one in your company. If you’re a solopreneur building a solo business, there’s literally no reason why you wouldn’t want to have a capable agentic system review your code.

It can tell you when something doesn’t do what it appears to do, when something is unexpected, misconfigured, when you’re using the wrong version of a library. These are the kinds of things that a second pair of eyes would catch, but as a solo founder, you don’t have that luxury. Until now.

If you have a ChatGPT subscription or a Claude subscription for 20 bucks a month, run it before you merge a commit. Run it when you’re done with a new feature implementation. Create a prompt, or look online for code reviewing prompts – there are so many now. There are Claude Code prompt libraries that can help you scan a code base for accessibility issues, circular dependencies, memory leaks, test coverage validation. There are prompts for finding where tests are missing or where disambiguation in documentation would be helpful.

It’s this process of telling you where the gaps are, because it has full access to your whole code base. By a mere command, you can have an expert review your code. It would be quite a waste not to do it.

Building Value Through AI-Assisted Documentation

When you’re building a software business as a solopreneur or small team, there’s always the chance you might want to sell the business. And an acquisition-ready, well-maintained, well-documented, and well-tested code base is valuable. It’s worth actual money.

If you have 50% test coverage in your code base, that’s great. But what if you could get to 95%? What if you could tell your acquirer, “This code base is highly tested. Any breaking change will be immediately caught by our testing system.” That’s money on the table, because they know the value of that code base.

You can ask an AI system: “What kinds of tests should I implement that would have the highest potential coverage?” or “What documentation would I need to write to make this business more sellable?” These are actual prompts you can use to get pretty good answers without the system writing any line of code.

The Bottom Line

I highly recommend using a standalone AI coding agent like Claude Code – that’s what I use. You can express all your preferences in the claude.md system prompt file that gets loaded whenever Claude starts. For every prompt, you can specify: “I don’t want you to actually write my code. I only want you to help me figure things out, analyze them, optimize them, and give me suggestions in the shape of markdown files in a ‘fix-me’ folder.”

It’s also helpful to have a claude.md file that you populate where Claude scans your whole code base, figures out the internal structure, and documents it. Review that, rewrite it if it’s wrong, add things that are important to you. This helps Claude understand the internal logic of your code base every time it runs.

Let me be very clear: Claude Code can be run completely without having it inject any line of code into your system. But having it there, able to understand your system, is incredibly valuable.

Now, obviously, what I’m trying to tell you is to prompt for these things and then maybe – just maybe – let the thing also write some code. But that’s a step that only works if you have trust in the AI system, trust in the underlying documentation, trust in your prompting, and trust in your ability to review changes that these code-generating tools have made.

But you don’t need a single line of code to be written by AI for it to be useful. And I hope these examples give you ideas of how you can use it in your handcrafted code base. For everybody else who’s already embracing AI code generation, this gives you ideas of what else you could have AI build instead of just features.

Your code base is yours. You own every line, every semicolon, every clever hack. But that doesn’t mean you can’t have the world’s most knowledgeable coding companion sitting right there with you, ready to investigate, optimize, secure, and review everything you build. That’s not surrendering control – that’s augmenting your capabilities while maintaining your craft.

Don’t let pride keep you from using tools that can make your code better, your business more valuable, and your life as a developer easier. The AI isn’t here to replace your coding – it’s here to make you a better coder. And that’s something even the most ardent code purist can get behind.

A lot of early-stage founders have understood—mostly because more and more people are talking about their early-stage strategies—that you need to validate your ideas. You need to make an effort to figure out if the thing you’re planning to do is actually reasonable to attempt. Validation is important and absolutely worth doing prior to building.

That much, many people have understood.

But here’s where things get interesting. Often enough, validation looks like checking if people have the problem—checking if people have the challenge that your idea solves. And if you find people complaining about it, if you find people mentioning that they struggle with this, to some founders, that’s a sufficient reason to build a software-as-a-service solution.

Then they bring it to market and realize something frustrating: even if they directly engage people in their market, even if they directly show this and onboard people into the product, they still don’t get a sale.

People stick with what they’re currently doing, even though it is something that, from your perspective as a founder, is much worse, much more expensive, much more complicated, much less scalable.

Why is that?

The Critical Missing Step

What I have seen—and do see a lot when I talk to my consulting clients who show me a view into their business and strategy—is that validation is missing a central and critical step.

They look for challenges. They look for proof of pain. But they do not investigate alternative solutions.

They might look for existing software-as-a-service solutions in the field and see those either as potential competitors or as inspiration for solving problems. But what they absolutely don’t do is investigate non-SaaS alternative solutions.

Let me walk you through the alternative solutions I’ve found in the past for my own projects and the projects my consulting clients have built. Because when you go through your idea validation stage, when you try to validate that there is a solid market and a solid group of prospects for your business, you don’t just need to understand what they lack. You also need to understand what they make do with.

The Most Overlooked Competitor: The Spreadsheet

The most commonly overlooked alternative solution to your product—and the alternative solution to the challenge that your prospects face—is the extreme DIY. The pen and paper. The custom, handcrafted Excel sheet.

You would be surprised how far people get with just a single Excel sheet that tracks everything they need to know and does all the math, all the data massaging. Excel is one of the most flexible tools when it comes to handling data, and people, through sheer necessity, have figured out how to use that particular tool.

It’s not a sexy tool. It’s not a fun tool. But it is likely your biggest competitor in most fields and industries that you can imagine.

I’ve seen Excel—or a spreadsheet tool just like it, could be Google Sheets, could be Airtable, something like this—being used in the construction industry, by medical professionals, by authors, hairdressers, lifeguards. The nature of data that needs to be segmented, sorted, collated, and graphed makes Excel the tool for almost anybody. And it’s so flexible that most business processes can at least partially be mapped into a spreadsheet.

Understanding the Job to Be Done

There’s something we don’t really think about much when we talk about product: the job to be done that your customer has. Everybody has a job. Everybody has some input data that needs to be transformed into output data.

People get a request for a proposal as input, and the output is either the project itself or some other kind of artifact. In between, they do their job. Some people get a list of invoices, and the output is bookkeeping. People get a script, and the output is a fully realized podcast episode. That’s how products work. That’s what a job to be done is and does.

To be able to do a job, people have to have a mental model of the process. They have to know exactly which steps to take to get from input to output. And in almost all cases, that model has to exist fully established in the mind of the person executing the work.

This means that when an organization uses software tools, they try to map as much of that mental model into the software tool as possible. The Excel sheet that contains all this data doesn’t just contain data. It contains an attempt at mapping an internal model of a process and the flow of data into a very flexible but not very customizable tool.

The Hidden Moat Around Spreadsheets

And here’s the thing: the act of mapping that model into a spreadsheet is extremely costly.

A spreadsheet that has been in a company, that has been tracking the internal process of that company, is extremely hard to replace. Not only does it contain all the historical data that’s relevant for internal analysis and that kind of stuff, but it contains the probably very painfully learned lessons of trying to both establish a process and map that process into a software tool.

It is the best they could do, and it is the result of a long journey of tiny experiments to make it work. We tend to forget the complexity that goes into configuring a simple spreadsheet.

And that’s what you’re competing with. You’re not competing with the spreadsheet. You’re competing with the months and years it took to get that spreadsheet to where it is. Unless your solution is significantly more maintainable and even more apt at mirroring the process that your prospect, your customer, has than what they already have, the cost of switching and setting up again a mapping of the internal process into your tool is likely going to be too high.

That’s always a big competitor. The spreadsheet, the homegrown DIY solution, is a big competitor with a big moat around it that is just time and pain that people spent to create it.

Learning from Failed Attempts

Which is why, when you look for alternative solutions, you very much have to investigate if people have actually attempted this transition prior—if people have attempted to solve the transition from homegrown tool to software project. And if that’s the case, why they failed.

This really differs between industries. In some industries, this spreadsheet, as complicated as it might be, is still replaceable with a software business. There’s still a chance that whatever you build is worth building because it does effectively improve on the existing solution for people.

But if existing DIY solutions are very complex due to the complexity of the underlying process that they map, then a lot of businesses likely thought they could have solved it in the past and failed.

So when I look for competing solutions, for alternative solutions in a space, I first look for the amount and intensity of DIY solutions. Then I look for attempts at solving this problem by building a business that have failed. I try to find the founders for whom this failure occurred and learn from them about the failure and the specific reasons they failed.

It’s a pretty significant thing to do when you’re building, or trying to verify the potential future existence of a business—to look for people who have failed and then investigate why that’s the case.

Sometimes there are websites like failory.com where you can find interviews of people in this field. You can ask experts in the field if there were any attempts, if they ever tried a solution for this and what that was called, so you can figure out the name of the founder and maybe reach out to them.

Most importantly, don’t assume that just because there is no current solution, you will find success with yours. A lot of people may have tried and failed because they assumed that their solution would be enough, where the resistance to moving from DIY to a hosted or software solution is too high.

Other Alternative Solutions to Investigate

Let me walk through the other alternatives you need to research.

Legacy Software: People may have had some software built in the early 2000s that had their business process mapped custom for them. It’s installed on their Windows XP machines, and they are and have and will keep using it for the foreseeable future. That’s just the way they’re going to run their business. Only once that software breaks will they ever think about finding a new solution.

Since you don’t control when that happens, these customers are not actually prospects of your business, at least not at this point. There’s a strong external reason for them to either opt into or out of your sales process, and you have no control over that.

Direct SaaS Competitors: Of course, you actively need to research the software-as-a-service space for actual competitors. When you do this, one of the most important things I would look at is not the specific feature set or UI or workflow. You obviously still have to look at that, but what I think is even more important is understanding what their positioning is and who they’re aiming at.

Successful companies will have understood that they’re best at serving a particular part of the market—a niche within the niche—with their software product. Look at how they talk and who they talk to, and how that reflects on the product they offer. What is the input data they work with? What is the output? What is the result that the product facilitates? What do they not offer?

How well or how hard is it to integrate this product with other solutions in the space? Is it easy or hard to export and import data? Do they have integrations into workflow systems, or do they try to keep all data internally? That gives you a lot of insight about what the expectations of the market are, and maybe also how expectations in this market differ from subgroup to subgroup.

Open Source Solutions: You’re building software. It’s likely that somebody in the late ’90s has built a maybe less functional but still pretty well-working version of that software before. Or currently, the thing that you want to build exists in seven different varieties for JavaScript as an example project that people build upon.

As much as operating them and maintaining them is costly in terms of time, they are free. And for a lot of people who struggle financially or who are not yet in the wonderful position to have a lot of budget, these free solutions are much preferable to a paid solution, even if the paid solution has a better workflow or integrations or interface. People will struggle through the weird, completely arbitrary interfaces of somebody’s pet software if that is freely available to them.

Agencies and Services: This one’s not very obvious, particularly because we think, in the software-as-a-service world, in terms of products. But there’s an actual agency or service or consultant that is tasked with the job, and that’s somebody you would replace.

If you think about your product in terms of a job to be done, you’re replacing a full job that somebody is executing with your software. And that might already be somewhat outsourced to an agency. An agency gets the input data, they’re expected to provide the output data, and how they do it is up to them.

Let me give you an example. In the writing world, people are wildly creative and vision-led. They’re very focused on the vision of the book, the stories, the narratives, the characters. But somebody needs to proofread that, somebody needs to edit that and make sure that consistency exists and spelling errors are removed. Usually that person is not the author themselves because they don’t concern themselves with that—it’s too technical. They also might not be capable of looking at their prose from a neutral, professional distance.

There are probably tools that do this, and you could likely build one that’s much faster and probably just as reliable as a person or agency. But that’s who you’re competing with. It’s going to be the “pay 100 bucks and you get it in two days” kind of agency. You’ll have to have an offering that is much faster, much cheaper, and more reliable to compete with the already pretty optimized processes that these agencies have.

The Status Quo: Finally, let me bring up the most painful alternative to a problem that we as founders have to live with, and that is doing nothing.

Some people will just keep doing what they’re doing and not buy any solution to their problem because, to them, living the pain is not a problem. Some people cannot handle the pain and will look for a solution. But a lot of people will say, “Yep, that’s just par for the course. That’s just part of the experience. You have to suffer through this so you can get to the final result.”

People will do nothing as an alternative solution to a problem. They’re just going to suffer through it, and that’s something you can’t really deal with. No amount of customer education will move people who have chosen to just deal with the pain and not deal with the problem.

What You Can Actually Deal With

So which of these can you work with?

I think the best ones to deal with are people who are using legacy or incumbent solutions, where you can build something better for them if you understand that process perfectly and map it directly into your product.

You can deal well with people who are using direct competitors—you just have to find the right niche that is currently underserved or unserved.

You can also deal well with people who are using general tools like spreadsheets for mapping processes that are not extremely complicated. The more complicated it gets, the harder it will be to get people to move away from their DIY solutions.

The Insights You’ll Gain

Ultimately, understanding all of these alternative solutions gives you a lot of insight into who your actual competitor is, and that’s often not who you think it is.

You’ll see a lot about price anchors and willingness to pay or unwillingness to pay. If everybody in your field uses an open-source solution and there is no SaaS that could ever exist in this field even though people tried, that might not be a good industry to be in.

You’ll see switching costs and friction, maybe even from stories of people who’ve done this in the past. And in investigating all of this, you’ll find things like feature gaps and market gaps. A feature gap is something you can exploit to serve a market that’s underserved. A market gap is something where, even with an existing feature set that other tools have, you can replicate and serve them better than anybody else.

Most importantly, you will understand why people stick with worse solutions. Why do they stick with something that doesn’t work as well as something that could?

There are probably underlying reasons that you might not be aware of, and you’ll figure this out by looking.

The biggest mistake? Only looking at direct SaaS competitors while ignoring the 60% of your market that might just be using spreadsheets and Slack.

Don’t make that mistake. Investigate the alternatives, understand what you’re really competing against, and you’ll have a much clearer picture of whether your idea can actually succeed in the market.

But there’s something we need to talk about. Something that’s quietly accumulating in our projects while we marvel at how quickly we can ship features.

This is called comprehension debt.

A New Kind of Technical Debt

Comprehension debt is like technical debt, but fundamentally different. Technical debt is about choices developers consciously make to defer work until a later stage of the business. You know you’re taking a shortcut. You know you’ll have to come back and fix it. That’s traditional technical debt.

Comprehension debt is different. It’s when we don’t comprehend what the system does anymore. We don’t understand it because we never built the understanding in the first place. And this is happening more and more with AI-generated code.

The Theory of Your Codebase

There’s this concept I came across from Peter Naur, the mathematician behind the Backus-Naur form. He calls it “theory building.” The idea is that code implodes when the team that has the theory—the mental model—of that particular piece of code is dissolved.

The code will keep running and producing results, sure. But the moment you try to modify it, you’re in trouble. You don’t have the theory to actually work with it. Naur says you have to rebuild not just the program, but also its underlying theory by a new team.

This has always been a challenge in software projects. But AI makes it exponentially more complex.

How AI Builds and Destroys Understanding

Here’s what happens when you use AI coding tools. You give it a prompt for a feature. The AI actually assembles an internal mental model of what needs to be done and what needs to be changed. You see this in all these wonderful coding tools—they pull together things from different parts of the codebase. They figure it out. They know what to change. They even see connections that you as a developer might have missed because they can scan through the whole codebase and see all the little moving parts.

So the AI assembles this theory—probably inadequate in some ways, but sufficiently adequate for this particular task. It builds a theory of the codebase, of the product. Then it implements the feature.

And if you’re lucky, if it’s in your system prompt, you tell it to write tests or document the behavior in some way.

But here’s the problem: the actual model that it created, the mental model, the theory of the product, is never persisted. It’s immediately lost. Once the prompt is run through and the context of that conversation is done, the model is gone. Nobody knows it.

So constantly, by adding more and more features to your product, you’re facilitating the creation of new models every single time you prompt. Models that are built up, implemented through, and then torn down.

And if you don’t read the code, if you don’t understand what is added and why, you will not develop this model as a developer. You will never comprehend the underlying theory of the product.

The Maintenance Problem

This creates a real problem. Eventually, if the AI for some reason is unable to rebuild the underlying understanding or model of the codebase as it had in the past, then it will not be able to adequately and correctly modify and change the system.

I think one solution being developed right now is context persistence in our agentic coding systems. Not just about the prompt you’re currently giving, but a deep understanding of the codebase maintained over time. A document, if you want to call it that, in which you work.

But if you are a developer who is already capable of building mental models from reading code, then you really have to do code review. If you just want to build something quickly and you don’t care about this, then using AI agentic systems to create code for you is fine. But you will find that eventually, the ownership of the theory of the codebase needs to lie with you.

The Business Transfer Problem

This becomes especially critical if you want your business to be acquired or if you want to hire.

You have to be able to transfer not just the raw codebase over to somebody. You have to be able to transfer the internal knowledge of the codebase to this person. Usually this happens through training—training somebody to replace you in a business, or as you grow, hiring your CTO, your lead developers, junior developers.

Everybody who gets to work on the codebase is trained into it. You transfer parts of, or the whole of, your mental model to those people. You transfer it over so that they can eventually integrate the model into their own brain and keep the theory alive.

But what happens when you don’t have that theory yourself?

Before, it was impossible to build a functional software business without deeply understanding the software of your product. Now, there’s a chance that someone could buy a product that nobody understands. Nobody.

The Acquisition Risk

This adds a very real layer of risk. You have time bombs unintentionally built into the product that, once someone buys the business, will quickly surface. Because people want to make changes to underlying systems and structures that the previous owner—the person that prompted this into existence—never thought about.

When you integrate a new software as a service business into your portfolio as a private equity company, or you integrate it into your existing system as a strategic buyer, there are things you will touch that the person who built this never considered. That’s inevitable. You buy a business because it has components that your current system lacks, and your current system has features that this new system lacks.

So the chance of quickly finding a hidden time bomb is quite high.

This is likely going to be priced into the acquisition—the money they pay for it. If you cannot show them that either the code is well documented, that these time bombs are avoidable, manageable, or non-existent, or that you are still in complete control of the codebase and have the theory of that codebase, of the product, you’ll see it reflected in the valuation.

I think buyers will become very, very intimately aware of this in the future, to the point that they will be demanding not just a codebase, but a kind of documentation system, a traceable and trackable history of the projects and the choices that were made within it. They will need some way to train their developers or the agentic systems that they have established internally on the correct functionality of your codebase and how to best work with it.

At some point, you will not be available to them anymore. And maybe even if you sell your business, if it was all AI-generated, you might not even know how it works yourself.

Fighting Comprehension Debt

So what do we do about this?

Right now, to deal with this kind of comprehension debt, I highly recommend making part of your system prompt for all these agentic tools that you use to very deliberately comment. Put comments into the system that facilitate a theory and a mental model of your codebase. Make it maintainable. Add code that helps the thing be maintainable.

Document choices that were made along the way. Document, maybe even the prompts that went into the codebase. Keep your prompts documented. Keep them logged, so you can step through historically and see what changes were made and what choices were made for and through these changes.

A Tool Idea

This is also an interesting field to build a tool in. It would be very interesting to offer a service or tool that constantly checks the internal theory as much as it can read from the codebase and deduce from reading through it using AI tooling.

This tool would constantly keep this theory both available to AI systems—kind of as an MCP, a description of code examples or code locations—and over time, track when the theory changes.

For example, let’s say you’ve determined, as the program’s designer, that in every list you create, people can sort the list, filter the list, and export the list as a CSV file. That’s just a choice you made. That’s the theory of your product—it does this. In every list, you have shared components, shared views, shared design patterns.

Over time, you’re prompting and prompting, and all of a sudden, the AI chooses to build a list that is sortable and filterable but doesn’t have an export. At that point, the theory of your system changes from “every list has these features” to “some lists have this feature.”

At that point, you should either be alerted—that would be an interesting business to build—or your agentic system is told that there is a discrepancy, and it should recreate the actual theory that it had prior to this.

I think that would be an interesting tool. Kind of an internal error tool, like a code quality maintenance tool. We don’t really have many tools right now that deal with code quality before errors happen. But I think this would be one of them.

The Founder’s Responsibility

So maybe comprehension debt can be fought by a deeper and more obvious understanding of the underlying theory in software businesses. As founders, we have to think about the fact that this is an additional risk if we add this comprehension debt. It’s something that an acquirer or us in the future will have to pay at some point.

Really be careful with how much of the theory building you allow your AI to do and control. Or at least be intentional about how much of this theory you retain.

Because at the end of the day, your business isn’t just the code. It’s the understanding of what that code does, why it does it, and how it all fits together.

That understanding is becoming more valuable than ever.

Recently, a peer of mine asked an interesting question that adds a layer to this idea. They suggested that at this point, the best tech stack is probably the one that the AI tool you use for coding knows the most about.

That’s a fascinating thought, and it’s partially true. For many people who don’t do their own coding anymore, the best tech stack might not just be the one they know best, but the one that the coding AI handles pretty well.

But here’s what I believe: the original statement still holds true, even in its inverted form. It doesn’t matter if the AI model knows a coding language or framework the best. The quality of code the AI produces, and the quality of code that ends up in your software product, is still directly connected to your capacity of understanding and judging, reviewing and debugging that code.

Let me explain why.

Understanding How AI Knows Code

To make sense of this, it’s really helpful to understand how these AI models are being built. An AI model is effectively a token guesser that builds upon existing examples of the written word. It has ingested hundreds of millions of documents: code bases, Stack Overflow conversations, blog posts, chat transcripts from IRC and forums. From there, it builds this internal model that makes it very capable of guessing what the next token should be in a series of tokens, which ends up being text itself.

The data that flows into these models, at least for the first couple generations, was what people had publicly provided. Open code bases on GitHub, GitLab, SourceForge, and other places where people deploy code. The AI was trained on this data, which makes it obvious that the AI has had the most exposure to the programming languages that were the most popular at the point of its training.

From a quantitative view, the AI is trained best on code that in aggregate has been most often used and most often written up until the point where the AI was trained.

So it’s only logical that the AI has had the most exposure to things like JavaScript, which over the last decade has had this massive renaissance. It works pretty well both in the front end and on the server, thanks to Next.js and hosted solutions like Vercel. JavaScript became one of the most popular languages, and a lot of people wrote code and published it, making it available for the AI to ingest.

Languages like PHP, Ruby, C#, and Java—equally popular frameworks with a lot of history in deployed code—are also best represented internally in these AI systems.

If you look for more esoteric code, more niche programming languages like Nim, Erlang, or Smalltalk, there’s still ample history of these languages being written. It might just not be as prevalent as the other languages, assuming all of this data made it into the training corpus.

The model can only know what it was fed. It can only assume things from the data it has been trained on.

So when it comes to making a technology choice based on what the AI understands, the answer is actually surprising: you could probably use everything that has existed in the past where there’s a written record of code for an AI to have been trained on.

If you go with JavaScript, PHP, Ruby, or Python, you’ll get very good results because the training data has been so plentiful. But even if you go with languages like Elixir, Scala, or Bash, you still have a massive data set for the AI to draw on.

The problem comes with languages or framework versions that have been created since the AI was baseline trained. The AI only remembers what it was trained on. Until we have AI systems that create their own training data without human intervention, you have to wait for a new version to be released that may or may not incorporate new features.

Now, obviously, the Model Context Protocol and the integration of tool calling in AI systems makes this somewhat moot. These tools are able to ingest the full documentation of any version of any framework and allow an AI system to update its knowledge on the fly as it’s working on a coding problem.

This means that if you have a proper MCP system that pulls documentation for any programming language you might want to use, any sufficiently capable AI coding system will be able to code in the language you choose.

So it really doesn’t matter which framework you choose for your coding projects. The AI system, with proper default choices or with proper instrumentation around non-default choices, will be capable of building this tool for you.

Why You Still Need to Know Your Stack

For some people, this might mean they think, “Hey, cool. If that’s the case, then I’m just going to build this project in whatever language I think is perfect for it.”

Maybe you’re a JavaScript developer and you’ve heard that you should really write everything in Rust because of memory safety and performance. You could probably instruct your coding AI system to build a backend server in Rust, and it very likely would be able to build code.

But this is going to be code that you don’t innately understand.

You’re going to be presented with code that your AI system will build for you, and you’ll have to say, “Okay, yeah, cool, sure, let’s run this,” or, “Hey, this doesn’t look right.”

If you’re not able to tell one from the other, then you are effectively building a black box—something so opaque that you just don’t understand how it works. You only see that it does or it doesn’t.

And if it doesn’t work, you can only tell the AI to fix it. But you can’t tell it why it should fix it, what it should fix, and to what end that fix should be better or different than the current implementation.

Obviously, all of these activities—debugging, expanding, and manipulating code—will be done by automation systems for many people in the future. For most developers in the future, and for many already. But your capacity to see errors and to understand the infrastructure of a coding project is still responsible for the maintainability and the functional capabilities of your coding projects today.

I strongly, strongly recommend that even though we have this magical tool that can build anything in any language, you should still learn and deeply understand a particular programming language.

Choose one that has a vivid ecosystem that an AI can pull a lot of documentation from. Choose one with a vivid community that an AI can pull conversations from and learn what the best practices are and why they are like that. Choose one with a strong historical backlog of existing projects—the Lindy effect, right? Things that have stuck around for a long time are likely to stick around for a long time.

AI systems are going to amplify this. The AI systems themselves are going to create artifacts in particular frameworks and languages by creating new projects that people then upload to GitHub, which then goes into the next generation of AI models as training data.

You want to choose a technology that you are versed in, that you understand, so that with every potential commit that the AI suggests to you, you know exactly what happens.

Because if you don’t, the AI will build what people who wrote code in that language thought in the past is going to be best—not what you think is best, not what you would build in another language, but what the collective implementation strategy of people in the past who used this technology looks like.

The AI is effectively going to build somebody else’s code with your instruction. And you don’t want that. You want it to build your code with your instruction.

For that, you need to still know and understand the language.

Making the Right Choice

If you’re on the fence right now about whether you should use another framework or tech stack that you know an AI understands but you don’t, go back to what you understand and slowly learn new technology.

Do not throw completely new tech on new projects and hope that the AI will save you. I don’t think that’s the case.

You need to be able to understand every single piece of code. You need to develop experience in potential scaling challenges, in esoteric edge cases, in handling small and frequent or large and infrequent data. You need experience integrating this technology with others and getting other people onboarded into this technology as your business grows and you’re hiring.

All of this requires you to have a solid, foundational understanding of the technology that you’re using.

Do not outsource this to the AI.

The AI is only going to be as good as the other people who used it in the past, and it does not necessarily map onto what you need. If you can’t reliably instruct your AI with these things, it will build something that somebody else would build, not something that you would build.

AI’s impact on tech stack choices is massive because you can do everything. But you should be highly restrictive with new technology choices that you outsource to AI, because that is outsourcing control. And that ultimately is outsourcing ownership.

If you can’t fix it, you have to hire somebody who can, and you pay money for this. If you can’t fix it, you’re going to have to rewrite it, and that’s going to cause financial damage to your business. You’re going to have to rebuild it in a way that you understand in the end, or you just have to sell it, or you have to stop using it and put the project away because it just spirals out of control.

You definitely don’t want that.

So do not make AI-centric tech choices. Make you-centric tech choices.

The best tech stack is still the one you already know—even in the age of AI.

“What do I actually own” is a question that becomes particularly urgent when you realize that modern software businesses exist in this fascinating paradox. We’re building increasingly valuable assets—businesses that generate revenue, grow in value, and can potentially be sold for significant sums—yet we have less direct control over the infrastructure than ever before. We’re essentially building castles on rented land, and the implications of this go far deeper than most founders realize.

The Dual Nature of Business Value

Let me start with why this matters so much. A business is not just a place where you work. It’s both something that generates this constant stream—maybe a salary or dividends, or you reinvest the money that the business makes into itself. But in the end, the business itself grows in value. And if you own that value, and if that value is capturable by you, then you effectively get value twice. You get value along the way through operational income, and then you get the expected value over the course of the business running—that’s something that people could buy from you.

I’m always thinking: How can I balance how much value the business creates for me today and how much will it potentially create for me or somebody else in the future? And here’s the thing that’s funny enough to be able to sell something—you have to actually own the asset.

This becomes a particular problem for building software businesses in this world of vibe coding and hosted everything. If you manage to build a profitable business on Lovable or on v0, or on any of these other easy-to-deploy, easy-to-prompt vibe coding platforms, then one of the interesting questions becomes: How much control, how much ownership do you actually have? Not just over the business as an entity—that’s a legal question—but how much control do you have over the operational durability of your business?

The Infrastructure Dependency Chain

We live in a world where almost everything you could potentially run as software, or as an underlying foundation for a software business, also exists as a rentable version—a much more affordable, rentable version that somebody else is running for you. I’m thinking about Platform as a Service stuff like Heroku, or even Infrastructure as a Service like AWS or Google Cloud. Or platforms like Vercel, where you just ship some code and then everything magically runs for you.

Even for my more recent side projects for Podscan, I’ve started to run things on Laravel Cloud, which is effectively a Platform as a Service provider for Laravel. I just deploy my code there, and they automatically spin up the services that are needed. They spin up the database, they spin up the Redis caching layer, they spin up file systems—and none of this I need to manage anymore.

With Podscan, I still have some control over the infrastructure, but that infrastructure is also, at least in parts, hosted with Infrastructure as a Service providers. I have a couple of bare metal machines that are mostly running my transcription and my search engine, but the main application is, for reliability and scalability reasons, hosted not on a VPS, but with an Infrastructure as a Service provider.

We are becoming more and more dependent on externalized services that are deep at the core of our businesses. And this dependency creates both opportunities and vulnerabilities that we need to carefully consider.

The Technology Choice That Haunted My Exit

Let me tell you a story that really drove this home for me. I had this technology choice problem with my previous business that I sold, Feedback Panda, which was built on top of a rather rarely seen web server called Phoenix in the Elixir programming language. And that, in many ways, quite limited who would be able to buy our company or buy our product, because they would have to have an Elixir engineer.

Whereas everybody has access to many, many PHP and Ruby and JavaScript engineers, Elixir engineers are still in high demand, and the engineers that can work with this technology have spent many years figuring it out—they are more expensive than others. So in a way, that choice probably precluded us from several buyers, potential buyers, just by the mere tech choice that we made.

Even though we had this wonderful application that we thought we owned, when somebody asked, “Well, can I buy it from you? What tech do you use?”—your ownership, not just in terms of the software, the code itself, but also the decision of which code to write, matters tremendously.

For me, scalability and sellability are essentially the same thing. Either I scale the business or somebody else scales it. The question becomes: Do my technology and ownership choices work for that? Did I make the right choice at the right time, and do I control enough of it for somebody to either build more out of it or take it and build something bigger from it?

The GitHub Dependency We All Pretend Doesn’t Exist

This affects not just what code I write and where it’s running, but also where my code is stored and how I deploy it—from where I control it in version control to the actual servers that need a new version or need a fix or need a rollback.

Many a day on Twitter, I see people saying, “Well, GitHub is down. Can’t work today.” As funny as it is to see people posting memes about that old XKCD comic about code compiling and people fencing on their office chairs because they have nothing else to do, an outage of one of these infrastructure systems—not of the running code, but of the deployment and development of code—that’s pretty critical to a business that has to deal with bugs and new developments every single day.

Being able to deploy code, not just through a pipeline that involves a third-party service, but from your local development system in a pinch—particularly for bootstrapped founders, for people with small software as a service businesses that do not have massive checking and balance of power requirements—that’s something you need to still own. You need to still own a way to deploy in a pinch to a server, even if part of your code deployment infrastructure is not working.

Building Resilience Through Strategic Redundancy

I’ve figured out how to turn off and on particular parts of my deployment procedure that may or may not require external servers. I lean heavily into caching of these things so once I have them, I can always reinstall the exact same thing on the exact same server, and I lean into just being able to skip the installation process and copy over old data when I need to.

Fortunately—and you may have opinions about this—I’m working with PHP as my programming language. So I have, ultimately, the capacity to just SSH into my production server, go to the folder where the PHP file that has a bug is located, and manually adjust that file if needed. If everything broke down, if GitHub didn’t work anymore, if my installation system would fail every single time, I could still manually correct code like it’s the 90s. And that, to me, is also ownership.

Let me give you a concrete example of how I think about this layered approach. For authentication, I use an authentication library that allows me to connect to an external service. I have an authentication system that works locally in my PHP Laravel application, but I could also allow people to click a button and log in through Auth0. This is a layered, abstracted approach where there’s always a local fallback.

I have the same thing with my AI usage in the backend. Whenever I do an AI analysis of a transcribed podcast episode that came into my system, I run the best available local language model that I have. If that is busy, I try to go to OpenAI. And if OpenAI is throwing errors because somebody plugged in the coffee machine next to the server at OpenAI again, then it falls back into a queue so a local system can take care of it.

You have to think about what could break and what are your alternatives. What can you fall back on? Fallback systems for every single thing you have might be very interesting, and they need to be tested.

The Customer Relationship Paradox

Here’s where it gets really interesting. I use Paddle as my payment provider, and they are merchant of record, so they kind of own the customer relationship. But because of this—because it makes so many things easier—I’m fine with that. I’m actually quite happy about this, because they take care of so many things that would add extra complexity to my business. That is their business to solve.

But being aware of them owning the customer relationship, or at least the payment relationship with the customer, I regularly export every single thing from the Paddle platform through API calls and through reporting exports. I have a list of all my customers and all their subscriptions on my Dropbox somewhere, and on my local computer, so that even though that service may own the relationship or might experience problems on occasion, I always still have control of the data, and I can connect with the people that are my customers.

Think about it: You’re renting on rented land. You’re renting out something to your software as a service customers, and you yourself are a software as a service customer to somebody else. In this relationship, you need to make sure you try to own as much of the relationship with your customer in terms of actual business interaction, and to own, as much as possible, the circumstances and the data of your software product on the other side of things.

The Ownership Framework for Modern Founders

So here’s what I’ve learned about navigating this ownership paradox:

First, always ask yourself: Who would not want to buy your business because of the choices that you made? Because of the technological choices, the infrastructure choices you’re constantly making, and because of the presence or lack of documentation of these processes?

Second, think about ownership almost as decentralization of data. Do I have a full copy of all my customers with their emails and their payment information, if needed, or at least a way to reach them to set up an alternative should my payment provider fail?

Third, for every external dependency, build a fallback. This doesn’t mean you need to rebuild everything from scratch. It means having a plan B that you’ve tested and know works. Whether it’s being able to deploy code manually when your CI/CD pipeline fails, or having local authentication when your auth provider is down, or maintaining regular exports of critical data.

Fourth, consider the transferability of your choices. When you make these initial decisions—do I build my own authentication system? Do I use a library that everybody uses? Do I use a service like Auth0?—think about how easy it would be to hand over these components to a potential buyer or even to a team member taking over your work as the business grows.

The Path Forward

The option to sell always exists with a successful business, but the option to grow and to invest in new team members taking on work—delegating—that means somebody else will have to take care of it as well. Even though my ownership is retained, access needs to be shared. And access needs to be shared to the point where I don’t have to touch anything at all anymore.

This is the reality of building software businesses in 2025. We’re more dependent on external services than ever before, but that doesn’t mean we have to sacrifice ownership entirely. It means we need to be more intentional about what we choose to own, what we choose to rent, and how we maintain optionality in between.

The businesses we’re building today are incredible feats of leverage—we can create million-dollar companies with tiny teams precisely because we don’t have to own and operate every piece of infrastructure. But with that leverage comes responsibility: the responsibility to understand our dependencies, to build resilience into our systems, and to maintain enough ownership that we can still capture the value we’re creating.

As bootstrapped founders, we’re not just building products. We’re building assets. And an asset you don’t truly own is just a job with extra steps. The key is finding that balance—leveraging the incredible tools and services available to us while maintaining enough control that when opportunity knocks—whether that’s scaling or selling—we’re actually in a position to answer the door.

This is something I’ve been wrestling with at Podscan, and I know many of you face the same challenge: you’re building a product that could serve two, three, maybe even five different ideal customer profiles. And you’re trying to figure out how to keep them all balanced—or whether you should even try.

I run a small software as a service business that has several ideal customer profiles just by the nature of the business. And as somebody with limited time and limited capacity to make a product appealing to particular groups, I’ve had to learn how to juggle trying to sell to several different potential audiences at the same time.

The Universal Challenge

No matter how much we try to niche down, we often find that the software we’re building is so flexible that different kinds of people can use it.

Look at Peter Levels’ PhotoAI, for example. This is ostensibly a B2C product, so it serves pretty much everybody. But he’s trying to serve people who need passport photos, while also serving people who are using AI-generated photos for marketing purposes, for social media posting, or for their dating app profiles. So many different audiences, and he has to serve all of them at the same time.

This gets worse when you’re going into the world of B2B, into the world of bigger companies or enterprise companies that you’re trying to serve with your products. In an enterprise situation, customers expect to be very clearly spoken to. If you’re trying to speak from the same location to many different people, you are effectively diluting your own messaging just by trying to reach multiple people at the same time.

Yet there is a lot of value in trying to reach different customer profiles, because you are still in this phase of trying to find product-market fit. You don’t want to set your sights on one particular customer too early.

My Podscan Journey

That’s been my personal experience with Podscan as well. If you’ve been listening to past episodes of my podcast over the last year and a half—almost two years at this point—you’ll find that not only did I set out to serve multiple customer types at the same time, I even went back and forth between which one I prioritized at any given time.

For me, these customer groups were marketers, public relations agencies, founders in the media and podcasting world—these three-ish groups, depending on if you put the first two in a bucket or if they are independent from each other. I recently added a couple more. I found that news agencies are a wonderful customer type, even SEO professionals. So maybe there’s four or five different groups of people, and all of them, I try to reach in particular ways.

The Time-Boxing Strategy

Unless you really clearly know who you’re going to focus all of your efforts on, you have to spread out your efforts for all these different groups. But here’s what I learned: you can’t really target everyone at the same time. That just spreads out your efforts too much, and you don’t really get clear results.

If you have two or three different customer types and you run three experiments and sign-ups go up—well, which one worked? If you don’t really track where those people come from, or if you track it but you’re not really sure which of your efforts they actually saw, then it’s not that meaningful. You can’t really learn anything from that process.

So personally, for somebody who has limited time and limited attention—and that’s really what this is about—I would focus very much one effort at a time. That looked like improving particular parts of the product or having conversations with particular kinds of people at any given time.

Often, I would attempt to really focus in on the Podscan API, which is something that is more intensely used by founders. So I would make sure that all my trialing founders get exactly what they need on the API, which often meant that I would need to reach out to them explicitly and maybe ignore what the non-founder trial users were telling me, just to make sure that I could serve that one particular vertical in my prospect base.

Then other times, I would think we’ve worked enough on the API, and we need to get back to people who actually use the platform. And I would see what these PR and marketing people needed.

The Demo Discovery Method

Demos became incredibly valuable for classification. I offer a demo button in the application where people mostly self-selected by just how ambitious they were with what they were going to build. Those were usually the people who were trying to get a good demo from me.

During that demo, I could figure out which bucket they would fall into. It was often clear before, but sometimes it became more apparent during the demo. Then I could ask really precise questions about what their job to be done was, what they needed from me, what they didn’t even know they might need but were looking for in products, what alternatives they were using—all that kind of stuff was very evident during these demo sessions.

Creating Dedicated Landing Pages

I have created a landing page for each of my ideal customer profiles. Each ICP has a landing page dedicated to them that highlights particular values for the platform that are relevant for their group.

You have in your footer or in your header navigation, a link to solutions. And in those solutions, you have solutions for media businesses, solutions for PR agencies, for founders, for podcast owners, for SEO, and so on. That’s what my homepage has, both in the header navigation and in the footer.

On those pages, I highlight mostly very goal-oriented solutions that the platform offers. If you’re a news agency, you’ll find that the news agency landing page says you’ll get real-time information about breaking topics. You’ll be able to see trends and how certain topics are getting more and more traction before they become mainstream. That’s the kind of stuff that news agencies care about, because I know that their mission is to report things before others report them.

Whereas on the page for PR agencies, I highlight that it makes it very easy to find wherever one of their clients might have reputation risk—where somebody is complaining about them, or there’s a public flogging of a certain company. Podscan makes it very easy to reliably be alerted when this happens.

In that way, they become very aware of how our product is meant for them. It was built for them. It is usable and useful to them and by them. That’s something that I feel I have to very clearly communicate, because it can be used by so many different kinds of people.

Smart Classification During Registration

When people register on Podscan, they can select between a couple of options: I’m here to look at data, I’m here to look at transcripts, I’m here to look at an API, and I’m here to search for stuff. It changes over time, just to see—because I’m experimenting with that as well.

People can self-select into: Am I an analyst, or more like a founder, or more like a podcast owner? Do I have my own show and want to see what the product says? That allows me to score and select customers into groups.

I don’t necessarily ask them specifically for the industry they’re from, but that happens in the next step through in-platform onboarding. During that, I take the email domain and maybe the project name they gave me, maybe their full name, and do a background AI agentic search to figure out who they are and how I can present data to them. How can I make the platform immediately useful? That’s one of the more elaborate onboarding AI automation systems that I’ve built.

With that, I very quickly figure out who people are, what they do, and what kind of customer group they belong to. I note this in the backend, in my own CRM system, trying to sort each of these customers into these brackets. And during onboarding, I try to make it as apparent as possible what people of their customer type find most useful.

Different Marketing for Different Groups

The way I market to these particular groups and the way I sell to them is wildly different. That’s something I realized very quickly—you cannot expect a single process to work for every single kind of customer that you have. It just doesn’t work.

My founder customers are almost exclusively coming to me through my founder network or through the larger founder communities in which I or the people who use my product are active. That means I don’t reach them via cold email. That makes no sense. Founders get cold emails all the time, and they don’t really respond to them well.

What helps is that people recommend me. People who are working with the API, who’ve used Podscan before, are recommending Podscan to somebody who they know might benefit from it. Which is why you will hear at the end of this podcast, and at the end of every single podcast that I’ve had for the last couple of years, a shout-out asking people to recommend me to their peers—which they do. This works.

Whenever somebody highlights Podscan or their use of Podscan on social media, I very strongly amplify it. I’m very grateful publicly, and I try to expose this to my own audience, so that this person will be further encouraged to share this stuff on Twitter.

Just a couple days ago, my dear founder friend Rob Walling shared publicly on Twitter how Podscan finds very interesting mentions of his name and the brands that he’s interested in and the conversation around them to his own audience of almost 40,000 followers. And on a meta level, I know that he’ll be notified of this mention on this podcast as well, and likely talk about it.

There’s value in having a strong network of amazing and successful founders that know about your product, that use your product, and then spread it among their peers. That’s my logic here, and that’s how it works for founders.

The Competition Factor

But this would never work for marketers or PR agencies, because that’s not my network. To reach these people, I have to find alternative ways. That is directed sales, cold outreach, social outreach, being present on LinkedIn and going into specific communities that I know these people frequent. Or at least listening to people’s complaints and trying to figure out how to interact with them to highlight the benefit of potentially using Podscan. That could be in specialist newsletters or anything like this.

But it has to be different for each of my ICPs, because these people communicate very differently between each of these groups. They hang out in wildly different locations, and they deal with cold emails and peer recommendations differently.

Also, for some of my customer types, using Podscan is a massive edge they will not share with their peers. Where a founder would immediately tell all the other founders they know if they’d found a really cool way to increase leads or reduce churn, for a financial analyst that has just found a new way to forecast good investment trends, they’re not going to share this with their peers. That’s who they’re competing with for forecasting and trend analysis. Having an edge is a big barrier to word-of-mouth marketing.

Speaking Different Languages

All the methods are very different between each of these groups, and I found that I have to have a different outreach, marketing, and sales approach for each of these ICPs. That’s one of the biggest learnings here—even though I’m doing all of this, I have to almost be a different persona for each of them.

When I talk to my founder peers, I can be colloquial. I can use memes. I can be funny. I can use references from the founder community. But I have to be much more professional when I talk to PR agencies, who themselves are often representatively formal to their clients.

You have to speak the local language of that community. You have to learn this or find somebody who knows it if you want to be able to build a strong base in each of these profile groups.

The Bottom Line

Between different onboarding systems, different internal feature presentations per customer group, and process isolation when it comes to how to reach out and convert your customers—that’s what I have so far learned with Podscan about having different ICPs.

This is one of the first businesses that I ever had that has wildly different customer profiles. And while it’s complex, while it requires me to context-switch and be different things to different people, it’s also incredibly valuable. It keeps me from getting too narrow too early. It helps me discover unexpected use cases. And ultimately, it makes the product stronger for everyone.

The key is not trying to be everything to everyone at once, but being very intentional about when and how you serve each group. Time-box your experiments. Create dedicated experiences. And most importantly, learn to speak each group’s language—not just in your marketing copy, but in how you think about their problems and present your solutions.

That’s the reality of building a flexible product in today’s market. The juggle is real, but with the right systems in place, it’s absolutely manageable—even as a solo founder.

That observation stopped me in my tracks.

Even the people portrayed as Britains best amateur bakers are, in a way, focused professionals competing on every level, through many stages of pre-competition trials to the eventual baking show finals, with all the self-presentation, ambitious dreams, and lucrative post-competition baking book deals.

It reminded me that we’re living in a world where everybody is on social media, where everybody is presenting themselves in their field. People like Nikita Bier tweet that the best way to stand out is to talk about one particular topic 100,000 times and present yourself as an expert in the field – advice that I’ve given to other people as well. If you want people to believe that you’re an expert, just keep talking about the topic and keep helping people who are on their own path to expertise.

But this reality in which we all get better at what we do is very different from the reality of craftsmen and artisans in the past. And understanding this shift isn’t just philosophical musing – it has real implications for how we build businesses, create products, and establish ourselves in the digital economy.

The Lost World of Pure Craftsmanship

Think about this for a moment: throughout most of human history, some people were just really good at some particular thing for most of their life, but the only people who knew about it were their closest family members, or the people who happened to live in proximity to them.

The local woodworker would occasionally bring over a really well-worked piece of woodworking. They were good at it. They did it for decades, for half a century, yet they never, ever posted a picture of it on Instagram or tried to turn it into a woodworking Etsy shop or a business.

They just were good at the thing because they enjoyed it.

Never did it feel like they had to present themselves as an expert in that particular activity, even though they were one. Had they had a chance to teach their knowledge to somebody else, they would have empowered somebody to become just as much of an expert as they were. But some people just didn’t. They just did the thing they liked, huddled away in their basements, huddled away in their shops, and that was that.

There was something pure about this. Something authentic. The work was the reward. The craft was the point. There was no audience to perform for, no metrics to chase, no engagement to optimize. Just the simple satisfaction of creating something with your own hands, of getting better at something you loved, of mastering a skill for its own sake.

But that world is largely gone now. And while we might feel nostalgic for it, we need to understand what has replaced it – because that’s the world we’re building businesses in today.

The Attention Competition

In a world of media – social media, or media of any kind – you can’t just be an amateur anymore. Bake Off is traditional media, but YouTube channels where people share their own journeys represent the more novel version of this transformation. You have to be a presenter, a self-presenter, or effectively, a salesman. You’re somebody who is competing with others for attention.

I think that’s the big difference that amateurs never had to cope with in the pre-social media world: attention is now part of the activity. If you want to be an amateur, if you want to pursue a hobby, you’re immediately thrust into this ecosystem where documentation and presentation are as important as the actual skill itself.

Let me give you a personal example from my particular hobby field: miniature painting. I really always enjoyed it – painting miniatures of all kinds for most of my life. It’s meditative, creative, and deeply satisfying. But the landscape of this hobby has completely transformed in the last decade.

The content that is being created for people in this field is now created by people who are both very, very good at what they do – maybe not professionally, they don’t paint miniatures on commission – they’re just really good at doing that. But here’s the thing: they are now looking for sponsors. They are looking for influencer marketing gigs. They’re building Patreons, selling courses, creating exclusive content tiers.

All of a sudden, it’s not about the quality of how well they can paint a tiny little dwarf or an orc, but how they present the process of that paint job. All of a sudden, they need to also be good at camera work and narrative for a 30-minute YouTube video. They need to understand lighting, audio quality, video editing, thumbnail design, SEO, community management, and social media algorithms.

The skillset has exploded. It means that they just cannot be the actual amateur enthusiast that they would be if they didn’t want to – or have to – present their work in the social media context. They’re not just painters anymore; they’re content creators, educators, entertainers, and entrepreneurs all rolled into one.

And this isn’t unique to miniature painting. Look at any hobby, any field, any area of expertise. The woodworkers are on YouTube. The knitters are on Instagram. The home cooks are on TikTok. Everyone is performing their expertise, not just practicing it.

The Pressure to Perform Excellence

What’s particularly interesting – and somewhat troubling – is how this has raised the bar for what constitutes acceptable amateur work. When you’re constantly exposed to the best of the best on social media, when algorithms surface only the most engaging, most polished content, your own humble efforts can feel inadequate by comparison.

The person who used to be perfectly happy with their Sunday painting sessions now feels pressure to document their process, to have good lighting, to create time-lapses, to explain their techniques. The joy of simple creation gets complicated by the anxiety of presentation.

And here’s where it gets really complex: very few people watch people who are worse than they are at the thing they want to be better at. So you have to reach a pretty high level of competence yet still feel relatable and approachable for people to start forging a relationship with you. You need to be aspirational but accessible, expert but empathetic, polished but personable.

It’s an impossible tightrope to walk, and yet thousands of people are attempting it every day across every conceivable niche and hobby.

Two Critical Lessons for Entrepreneurs

I’m sharing this for two reasons, and both are important for entrepreneurs and founders navigating this new landscape.

Lesson One: Building Your Personal Brand in the Performance Economy

If you’re going to build anything, if you want to build a personal brand in any field, you have to be aware that just being good at the thing is not sufficient anymore. Just being technically capable – be that a good painter, a good musician, a good software developer, a good writer, anything you can become better at – is not enough.

You also have to be capable of communicating this well to people who are on similar journeys. You have to be an empathetic and relatable person. You need to understand not just your craft, but how to teach it, how to inspire others, how to build community around it.

Think about the most successful people in any field today. They’re not necessarily the absolute best at their craft – they’re the ones who are very good at their craft AND excellent at communicating about it. They can break down complex ideas into digestible content. They can turn their process into compelling narratives. They can make their expertise accessible to others.

This is why you see so many founders building in public now. It’s not enough to build a great product; you need to document the journey. It’s not enough to have expertise; you need to share it constantly. The work itself has become inseparable from the performance of the work.

Lesson Two: Building Products for the Self-Documenting Semi-Professional

On the other side, if you look at this as a founder of a software as a service business, or any kind of software-enabled digital business, you need to understand that your users are living in this reality too. Not only are you going to have to help people become better at what they do, you also have to consider that if you are selling to a group of enthusiastic amateurs or semi-professionals, you don’t just have to solve their primary problem well.

You should think about how you can facilitate for them to communicate what they are doing and show what they are doing to others. This is something really new, and it’s something that I haven’t seen in many spaces other than community-centric businesses that have understood this already.

Your users don’t just want to accomplish tasks – they want to share their accomplishments. They don’t just want to improve – they want to document their improvement. They don’t just want to succeed – they want to celebrate their success publicly.

The Documentation Imperative: “Screenshot or It Didn’t Happen”

There was a meme when I was growing up around claims on the internet: “Screenshot or it didn’t happen.” In a way, that was an early version of proof being in the documentation, being in the visual representation of the thing you’re doing. It’s not just that people trust you to have done the thing – you have to be able to show it in memeable formats.

This has evolved into something much more sophisticated now. It’s not just about proof; it’s about narrative, about building your story in public, about creating a documented journey that others can follow and learn from.

A lot of the products that I see doing this really well have understood that if an accomplishment happens within a product, they need to facilitate sharing it. Let me give you a concrete example: One of the software tools I use is called DaisyDisk, which scans my hard drive for files and shows me which I can delete. Whenever I’ve deleted a certain number of gigabytes, it prompts me to post about it on Twitter. Now I don’t always do it, but I like the idea.

The idea is brilliant: hey, you’ve just accomplished something – you’ve cleaned up your disk, something that many people want to do but don’t find the time to. You can share this achievement. It’s getting people at the point where something that people aspire to do happens for you, and then it allows you to share it.

Think about all the successful products that have built-in sharing mechanisms:

• Strava for runners and cyclists
• Duolingo with its streak counters
• GitHub with its contribution graphs
• Spotify Wrapped at the end of each year

These aren’t just features; they’re recognition that users want to perform their progress, to make their private achievements public, to turn their personal development into social content.

Building for the Documentation Age

We have to think about the decline of the pure amateur and the increased presence of the self-documenting semi-professional in how we design our products and services. As entrepreneurs, we can help people navigate this new reality, because that is just what being a person in the times of social media is about. It’s doing things and talking about things, and talking about things and then doing them. It’s that constant cycle of self-documentation.

We can help facilitate that in many ways that we might not yet do. The products and the offerings and the services that help people self-document – either internally through journaling or reporting, or externally through posting and documenting on social media – are going to be increasingly valuable.

Think about it: the MRR screenshots that founders share, the customer service conversations with the names blurred out, the before-and-after transformations, the progress bars, the milestone celebrations – all of this is something we can facilitate, because it’s part of somebody’s journey that they would like to communicate.

Because that’s just how we do journeys now. We don’t just go on them; we document them. We don’t just learn; we teach what we’re learning. We don’t just improve; we inspire others to improve.

The Double-Edged Sword of Public Performance

Now, I want to be clear: this isn’t entirely negative. There are real benefits to this shift. The democratization of expertise means that knowledge that was once locked away in guilds or passed down through apprenticeships is now freely available to anyone with an internet connection. The barrier to learning almost any skill has never been lower.

The social pressure to document and share has also created accountability mechanisms that can actually help people improve faster. When you know you’re going to share your progress, you’re more likely to make progress. When you’re teaching others, you learn more deeply yourself.

But we also need to acknowledge what we’ve lost. The simple joy of doing something just because you enjoy it, without any thought of how it will look on Instagram. The freedom to be mediocre at something without feeling ashamed. The ability to have private hobbies, secret skills, personal satisfactions that aren’t performed for an audience.

Practical Implications for Founders

So what does this mean practically for those of us building businesses in this new reality?

First, we need to recognize that our users are not just users – they’re performers. They’re not just solving problems; they’re creating content about solving problems. They’re not just achieving goals; they’re documenting their achievements.

This means we should be thinking about:

• How can we make our users look good?
• How can we help them tell their story?
• How can we facilitate their self-presentation?
• How can we make their achievements shareable?
• How can we help them build their own audiences?

Second, we need to understand that the value we provide isn’t just functional – it’s social. People don’t just want tools that work; they want tools that make them look like they’re working. They don’t just want to be productive; they want to appear productive.

This isn’t about being cynical or manipulative. It’s about understanding the reality of how people live and work today. The performance is part of the job now, whether we like it or not.

The Future of Amateur Expertise

Looking forward, I don’t see this trend reversing. If anything, it’s accelerating. As more of our lives move online, as remote work becomes more common, as AI tools make content creation easier, the pressure to perform our expertise will only increase.

The pure amateur – the person who pursues a craft solely for personal satisfaction without any thought of audience or documentation – is becoming an endangered species. In their place, we have a new breed of practitioners: the performer-practitioner, the creator-craftsperson, the influencer-expert.

This isn’t necessarily better or worse than what came before – it’s just different. And as founders and entrepreneurs, we need to understand this shift if we want to build products and services that truly serve people’s needs in this new reality.

Conclusion: Embracing the Performance

I think we could definitely make this part of our mission: to not just empower our users to get their jobs done, but to also show – to whoever they want to show their progress to – just how much they get done.

The craftsman in the basement has been replaced by the creator with a camera. The amateur tinkering in the garage has become the YouTuber with a workshop studio. The hobbyist has become the content creator. And our job, as entrepreneurs, is to help them navigate this new reality.

We can mourn the loss of the pure amateur, the person who did things just for the joy of doing them. But we also need to recognize and serve the new reality: a world where doing and showing are inseparable, where practice and performance are one and the same, where every amateur is also an influencer in waiting.

The question isn’t whether this is good or bad – it’s how we can build products and services that help people thrive in this new reality. How can we make the performance easier? How can we make the documentation seamless? How can we help people share their journeys in ways that feel authentic and sustainable?

Because at the end of the day, that’s what being a person in the age of social media is about. It’s not just about being good at something – it’s about being good at sharing that you’re good at something. And if we can help people do both, we’re creating real value in this new economy of performed expertise.

The pure amateur may be dead, but in their place, we have millions of people sharing their knowledge, documenting their journeys, and inspiring others to follow in their footsteps. And maybe, just maybe, that’s not such a bad trade-off after all.

Over the last couple of months, my way of building product has significantly changed. A lot of the skill of coding solutions effectively has been pretty much surpassed by the AI agents that I use. Don’t get me wrong – it still has a lot to do with the fact that I’m very capable of specifying extremely correctly what I want and having a system build out code that is well specified, well commented, and that makes it easy for an agent to implement the things that I wanted to implement. But the speed at which this is being built? It removes one of the biggest moats for indie hackers and software entrepreneurs.

We used to be really good at building stuff and creating code that works. That advantage doesn’t exist anymore when everyone has access to Claude, or ChatGPT, or whatever the latest model is for building applications. So that’s gone.

And at the same time, we’re looking at subscription fatigue. People don’t want to buy software as a service businesses anymore. That used to be the one big thing that indie hackers had – reliable and anticipatable revenue from monthly subscriptions.

So what are the things that we still have? What are the things that are moats that we as entrepreneurs can use to protect ourselves from competition when our traditional advantages are disappearing?

The Expertise-Relationship Advantage

I believe – and we should probably expand a bit on this here – that the moats we do have are deep expertise in the field and the willingness to collaborate with our customers where bigger companies just see them as a transaction. We see them as a relationship. Relational engagement with customers is the ultimate opportunity builder for software founders.

This creates something interesting. We’re not looking at our businesses as these stand-alone services anymore that just generate value for our customers. It becomes much more of a collaborative approach to building services and building value for them.

Think about it this way: when you have deep domain expertise – really understanding the pain points, the workflows, the unspoken needs of your market – that becomes your first competitive advantage. But here’s where it gets interesting: you position yourself as the expert who codes, not just a coder who happens to work in your domain.

This is what I call the “Expertise-as-a-Service” model. You’re not just selling software; you’re selling your understanding of the problem space, backed by the ability to rapidly prototype and iterate solutions. Your customers aren’t just buying a tool – they’re getting access to someone who understands their world and can build exactly what they need.

The Integration-Heavy Future

We’re very integration heavy. If we are heavily collaborating, we build integrations into existing systems. We maintain those integrations and make them work better, make them work with even more things. And all of a sudden our moat is not about lock-in. In our universe, our customers are kept and engaged not because they’re locked in, but because our moat is that we are flexible and capable of interfacing with other systems.

We’re providing data to other systems, providing reliable, important, relevant, critical data that comes from somewhere else. And we just make it work. We make it attainable. We make it manageable. We make it accessible.

Here’s what I’ve started doing: instead of just building integrations myself, I’m creating what I call “Integration Marketplaces” around my core products. Think of it as turning your product into a platform where customers or even third-party developers can build their own integrations. You take a percentage of revenue or charge connection fees. Suddenly, your product isn’t just a tool – it’s an ecosystem.

This approach transforms switching costs entirely. Instead of technical lock-in, you create relationship depth. When your product becomes the hub that connects to everything else in their workflow, leaving becomes exponentially more difficult – not because they can’t, but because they lose all those valuable connections and relationships.

The Communication Revolution

From that relational approach to customer success stems a very different business model, a very different product design philosophy. Not one of locking people in, but one of unlocking things for people.

And where this happens is in the collaborative conversation with our customers. It’s in the feedback that we get. It’s in the back and forth and the ideas that our customers bring into our product. Like, “Hey, I would like this.” Or, “Hey, I see a competitor offers this. I don’t like that, but I want something like it, but better.” Those kinds of things come from conversations with customers.

But here’s where AI becomes your secret weapon for customer discovery. I’ve been experimenting with what I call “AI-Powered Customer Discovery Loops.” Instead of manually sifting through support tickets and feature requests, I deploy AI agents to analyze patterns across all customer interactions. These agents identify trends I’d miss manually, spot emerging needs before they become widespread, and even help me understand which customers are most likely to churn based on their communication patterns.

This gives you faster feedback loops and helps you stay ahead of customer needs. While your competitors are still manually analyzing quarterly surveys, you’re responding to customer needs in real-time. Customer development becomes your competitive advantage.

The scripts have to be rewritten. The whole idea of the software business that was impossible to build for anybody without extensive coding experience – that is gone. The software part may not even be as relevant anymore.

The important part, if you are a software entrepreneur, is not the software. It’s the wetware. It’s the communication with human minds. It’s the flow – I don’t know what else to call it. There’s something that is outside of all the automations that are ever easier and easier to build. The automation becomes a consequence rather than the product.

The New Business Models

The product, in many ways, is our capacity and willingness to engage and build solutions for the people that we’re serving. Not build a solution and then sell it to people, but sell our capacity to build the thing that people want.

This is leading me toward what I’m calling “The Solution Concierge” business model. Instead of traditional subscriptions, you offer solution packages where customers pay for outcomes rather than just access. You use AI to rapidly prototype and iterate solutions with customers, charging per problem solved or per integration implemented, rather than relying solely on monthly recurring revenue.

Last week on the podcast I talked about how we can onboard people using AI, where we don’t even know what people need, but AI will figure it out with them and for them. Or we figure out who our customers are by having AI sift through a system, then write the perfect follow-up email for us, knowing what the capacities of our system are and what this user should be doing.

But there’s another layer here that I’ve been experimenting with: building async collaboration tools directly into your product. Since human communication is becoming the differentiator, why not make that communication part of your platform? Think shared workspaces, commentary systems, or workflow documentation that keeps customers engaged with your platform daily.

Instead of trying to increase engagement through notifications or gamification, you increase it through genuine collaboration. Your customers aren’t just using your tool – they’re working with you inside your tool. The switching cost becomes the loss of that collaborative relationship, not the technical difficulty of moving data.

The AI Facilitation Layer

The AI systems are facilitators here. They’re kind of like agentic organic compounds in this wetware that we’re building.

The more I see people struggle with the fact that AI isn’t replacing them as software engineers just yet, the more I think these people are looking at it from the wrong perspective. Because it’s not about the quality of code that comes out of AI agents today – it’s the expectable increase in quality that agentic AI coding systems are going to bring to the business in the next few years.

Just like email became a thing that every business is using, the idea of custom software to solve your problem – or software that is highly customizable to the point that it will really adequately solve your problem – that’s the magic that’s coming.

When AI handles the implementation details, your job becomes solution architecture and customer relationship management. You become the translator between customer needs and technical possibilities. You become the curator of solutions.

This is where the relationship advantage really shines. A big company might have better AI agents, but they can’t have the same depth of relationship with each customer that you can. They can’t have the same willingness to customize, to iterate, to build something that’s exactly right for one specific use case.

What This Means for Your Business

So what does this mean practically for bootstrapped founders?

First, start positioning yourself as the domain expert who codes, not just someone who codes in a domain. Write about your industry. Speak at industry conferences. Become known for understanding the problem space deeply, not just for your technical skills.

Second, make integration your strategy, not just a feature. Look for ways to turn your product into a hub that connects to everything else your customers use. Consider building marketplace models around those integrations.

Third, use AI for customer discovery, not just product development. Set up systems that help you understand your customers better and faster than anyone else in your space.

Fourth, build collaboration into your product from the ground up. Make working with you and your team part of the value proposition, not just using your software.

And finally, experiment with outcome-based pricing models alongside or instead of traditional subscriptions. Sell your capacity to solve problems, not just access to a tool.

The Wetware Advantage

The businesses that will thrive in this new landscape are the ones that understand that software is becoming a commodity, but solutions are becoming more valuable than ever. The relationship becomes the product. The expertise becomes the service. The willingness to collaborate becomes the moat.

This isn’t about building defensive moats the way we used to think about them. This is about building generative moats – advantages that actually create more value for everyone involved, including your customers and even your competitors in some ways.

When you’re integration-heavy and collaboration-focused, you’re not trying to lock anyone in. You’re trying to unlock value for them. And when you do that consistently, with expertise and genuine care for their success, that creates a kind of loyalty that’s much stronger than any technical switching cost.

Looking Forward

The future belongs to founders who understand that in a world where code is commoditized, relationships become premium. Where solutions matter more than software. Where being able to rapidly prototype and iterate with customers beats having the most polished initial product.

AI systems make this much easier, but they don’t make the human element less important – they make it more important. The AI handles the implementation details, freeing you up to focus on understanding problems deeply and building relationships authentically.

The entrepreneurs who are struggling right now are often the ones still trying to compete on technical implementation quality or trying to build traditional SaaS businesses in a market suffering from subscription fatigue. The ones who are thriving are embracing this shift toward collaboration, expertise, and relationship-driven business models.

Your coding skills aren’t obsolete – they’re just moving up the stack. Instead of writing functions, you’re architecting solutions. Instead of debugging code, you’re debugging customer problems. Instead of optimizing algorithms, you’re optimizing relationships.

And that, I think, is a much more interesting and sustainable way to build a business anyway.

The question isn’t whether AI will replace software entrepreneurs. The question is whether software entrepreneurs will evolve fast enough to stay relevant in this new landscape. The tools are there. The opportunities are there. The only question is whether we’re willing to change our approach to match the new reality.

That’s what I’ve been thinking about lately as I watch this industry transform around us. What are you seeing in your own business? How are you adapting to this shift? I’d love to hear your thoughts – this conversation is just getting started.

You know, it took me a long while to realize this: AI isn’t just something like a chatbot for my customers. AI can work behind the scenes to facilitate getting the right stuff in front of the right people for me, even just to figure out who people are and how I should talk to them. And today, I want to share exactly what I’m doing, how expensive this is to run, and how I believe this can be part of every single software as a service business out there—even if you don’t have any touchpoint with artificial intelligence in that business at all. Even if you don’t think you should be offering AI features to your customers.

The Six-Hour Score That Changed Everything

Let me start with the internal use of generative AI that has been absolutely transformative for Podscan. Six hours after a customer signs up for their trial—exactly six hours—something magical happens. But they don’t see it. It happens completely behind the scenes.

I let them explore the platform first. But at that six-hour mark, I score them. Or rather, I have an LLM that is fed with a lot of information score that customer for me on a scale from zero to 10. I take everything that I know about this person up until that point and have the AI come up with a number following a rather complicated prompt on how to score them.

Here’s what I collect: the domain of their email address, their name, the name of the team they created. I track what and how often people search and the general themes of the topics they search for. I collect all the activities they have on the page—if they navigate to the dashboard, if they navigate to a search window, if they navigate to the API documentation, or just which podcasts they checked out along the way. I take all of these activities that I track very meticulously in a database that at this point has over 500,000 activities in it.

I condense all of this into a prompt—I think at this point it’s GPT-4o still—to come up with a JSON object, a data object that contains a score and an explanation for why that score was given. I set up the prompt so that it gives me the explanation first and then gives me the score. Usually, that’s generally a good idea for these LLM systems that generate one token after the other—to always give them reasoning ability first and then any summary, any scoring, any reduction of granularity of information should come after they actually argued the case.

And if they have a score of five and above, they should then answer not just with the score, but with a full data object containing information about this customer, this potential customer, and how I should interact with them in the future.

The prompt is incredibly specific. I instruct it: “We’re trying to talk mostly to these kinds of customers—PR agencies, marketing customers, and founders. So score them higher if they’re a founder. And if they are a founder, figure out what projects they’re currently working on, so we can talk to them about these projects. Suggest particular things on how to use the platform with their specific problems and targets in mind.”

If it’s a business domain—not just Gmail—I instruct the prompt to look up that website and figure out what kind of business they are. I very intensely instruct the AI to actually check who is signing up, if they know this email address, if they know the name, and can give me more social feeds to reach out to them or to look for their work.

I send this message to my Slack if it’s a high-scoring prospect, so I can start reaching out manually to them. And I persist this score, the reason for the score, and the additional data to the user object, so I can use it later.

The Magic of the Generate Email Button

In my administrative interface, I have a view that lists every single prospect over the last 10 days—which is the length of a trial—showing their score, what activities they’ve taken up until now, their email, all of that. And then at any point when I feel like reaching out to them, I have a generate email button.

That generate email button takes all of the activities into account. It takes their score, their previous extraction, who they are, what we know about them, what they’ve said about themselves in the profile, what teams they are on, what alerts they’ve already created, what searches they have done. It takes all that into account and creates a follow-up email that looks at the things they have done and tries to find the next best thing that they should be doing on Podscan to see the value of the platform.

I’ve instructed that particular email-generating prompt to come up with the best possible keywords for an alert, or the best search terms for a search if they haven’t searched before, and suggest that one thing to them in an email. The email introduces me as the founder. It says, “Hey, this is the next step you could take. Any questions? Just respond to this email.” And then I send that manually by taking that content and putting it into my email window.

This has been extremely helpful in getting people who have done little on the platform to actually set up their first alert, and getting people who’ve already seen a lot of value by searching to persist that search into an alert. Because that’s my main goal with Podscan—to get people to set up an alert. Because an alert generates value memory, like value-nurturing notifications. If somebody puts their brand in there and they get one or two mentions on a podcast every single day, that’s great. They get an email from me every single day with something interesting. That is valuable, value-nurturing that just happens through the platform itself.

This has been running for a couple months at this point. It’s extremely helpful. It has led to a lot of interesting conversions and even conversations with people who were just checking it out, not doing much. But a day or two later, I reached out to them with a suggestion. They set up the alert, and now all of a sudden, they are extremely happy with the product, and they’re paying for it.

The Onboarding Wizard That Reads Minds

There’s a second step, one that comes much earlier, one that I only recently implemented because I realized I’ve been missing this all along. And that is during the first onboarding wizard that new signups have on Podscan.

I had onboarding for over a year—whenever you come to the dashboard for the first time, a fullscreen overlay comes up that says, “Hey, what do you want to do? Do you want to look for mentions? Do you want to search? Or do you want to just check out the product?” Click any of these, and it takes you to that section.

If you clicked on monitoring—and that was the default up until a couple of days ago—you would then be able to write a couple of filters or keywords that you might find interesting, put them into a little list and click “Create my first alert.” But it still involved a lot of manual work from people who just came to this product. They want to see what it can do.

So instead of having people write their own keywords, I implemented an automated background process that would fetch or generate the right keywords for this person while they are going through the onboarding process.

During registration, I have a step where I ask people to self-classify. They can classify as a founder, as somebody who owns a podcast, as somebody who analyzes data for a living in PR or marketing, or alternatively, “I just want to check it out.” Between these four groups, the ones I’m most interested in are obviously the data analyst and the founder, but the others might also just be on their first step into becoming a customer.

I also have a text field during registration where they can say what their project is, why they come to Podscan. Some people tell me, “Oh, I’m looking for this particular transcript,” or “I work for a PR agency, and we’re trying to track what people say about our clients.” People put that in there, maybe in 20% of cases. But the people who do help a lot with the system.

I take this information, I take the domain from the email they just signed up with and their full name, and I throw this into a very fast model—I think this is GPT-4o mini. And I task it to create three good keywords or keyword groups that might be good alert keywords that will be potentially useful to this person.

The selection is incredibly effective. If you sign up from a Google domain and you say you’re just looking for a transcript, it suggests an alert that has to do with the podcast you might be interested in. If you come from an educational domain, you work at a university, and you say you’re a data analyst, then it suggests some keywords, maybe even some key personnel names from your university to track. If you come from a marketing company that the AI is aware of, an agency that has certain clients, the AI will check their website, figure out who their biggest clients are, and suggest tracking their clients.

That is the magic in this moment. That is what the LLM can do with tool calling and with scraping websites—it can actually fetch meaningful information that helps onboard the customer to their specific use case. All from just a self-classifier, maybe a project description, and their email domain.

The Dashboard AI Builders

The third way I use generative AI is in the dashboard itself. Some people just don’t like onboarding. They say, “No, I’m going to do this myself.” But I still wanted that magic of having the system create an alert for you to be part of the dashboard experience, to be a repeatable thing that people can do. It’s not just their first alert that they get to create via AI—it’s also every other one they do in the future.

So I implemented an alert builder. You can just free-form write about whatever you want. You can say, “Hey, I want an alert that tracks keywords from this industry. I’m using it to create a newsletter,” and whatever. And then an AI tasked with a lot of information about the platform creates the best possible keywords and other specific information, like the context-aware question filter that I offer.

This is an AI-assisted check that runs on every single transcript that gets certain keywords mentioned, just to make sure the context is exactly what the user wants. Because if John Smith is looking for a mention, then a lot of John Smiths that that guy might not be interested in might be mentioned too. So having a specific keyword filter—things like “Is this episode talking about John Smith, the professional basketball player?”—will get a lot of false positives out of the way. And that can also be pre-suggested by AI.

I’ve trained this AI through prompting to give really good, solid results that work really well for Podscan data. The alert builders are available in the dashboard for everybody. The list builder, which creates lists of podcasts, has several features where you can just say, “I want all podcasts that talk about Star Trek: The Next Generation, like rewatch podcasts or humor comedy podcasts that have a sci-fi angle,” whatever it might be. You say what you want, and then the list gets generated.

It pulls all of these podcasts from our own API. It searches for keywords. It pulls those in. It looks for similar podcasts, because we have podcast similarity—I built that over the last year as well. And it just explores the whole system, scores them, and returns the list of the best 50 or 100 items, which is all also powered by an AI system that gets the best search terms and finds the best scoring criteria for that process.

The Philosophy: AI as a Translation Layer

For me, generative AI means not having a chatbot in there. I don’t need that. It doesn’t mean any kind of overly agentic behavior. Using generative AI in Podscan, in the way I communicate with the user, is about making it magical for them to be understood. For them to see that Podscan gets why they are using it. It understands that for their business, they might be looking for this, so I’m going to suggest that. So they see, “Oh, this is what I should look for.”

And in a moment like this, where they already get a good suggestion, they also understand how they should be searching for things, how they should be phrasing things to make Podscan be used more optimally and most effectively.

To be able to do this, I did a painful walkthrough of the system where I recorded myself just explaining every single feature on the platform into a transcription software. Then had that transcription thrown into Claude, and had that boiled down to a markdown document describing the structure and function of the platform. That markdown document is a couple thousand lines long. That was then condensed into the prompts that generate all these helpful steps.

The prompts are not small. They’re quite huge, because they have a lot of context about what Podscan is and how Podscan can best be used. Particularly the prompt that tells people what their next best step is—the one that I manually trigger via email—that needs to know what all the potential steps are. So I had to go through the whole platform, had to describe it from start to finish, and that becomes part of the prompt.

The Economics of Magic

Looking into this, to whatever kind of software business you might be running, I think this is a very, very useful and quite cheap thing to do. Because it only ever runs once, right? My scoring happens per customer—it’s only one request that comes back with a score and a little bit of text. It doesn’t really have too much context other than the name of the customer, the email, maybe a couple things they searched for, maybe a couple locations they’ve been in the product. It’s not big. This costs me less than a couple cents, maybe not even a cent in fees.

Same goes for the email generated to the customer. That also may be a cent or two just in cost to pull in all the information and the prompt cycle. So that might be more expensive, but it’s still like per customer, let’s say five cents. I think that’s very manageable per prospect, and I do it only for certain prospects that score fairly high. So on a daily basis, I spend maybe 20 cents on this. It’s negligible.

At the same time, AI in the product can be quite expensive if people use it a lot, so I’m very, very cautious with anything that allows a customer to trigger an AI API request. It’s heavily rate-limited within Podscan’s infrastructure. If I see somebody using AI requests of any kind—they all go through the same middleware—more than a couple times an hour, then I can manually decide if I should block this for this customer or deactivate the account if they’re starting to abuse it.

You have to be careful with that. With backend processes, it’s always good to make sure that you don’t overuse AI API calls just for your own sanity. I would track them all and see if you go over a certain threshold per hour, you should get an alarm.

The Universal Application

I think tracking who your users are, understanding what their needs are, and suggesting initial configuration for their dashboards or for their use of your software—that can work in every single niche. That can work in every single industry. I see a lot of cutting-edge founders building this into every single product they create, because it is always valuable to meet the customer immediately where they’re at.

And this is easiest to do if you investigate where they’re coming from. What information do I have about this person? How can I make it easiest for them to see where the value is?

Inside your product, you can also make AI a kind of transmission system between what the customer knows they want and how you need it presented to your database or your algorithms or your backend system. AI can communicate between these two because you can put in the effort to completely and correctly describe your system, and then task AI to translate between user requirements and your platform requirements.

That is another magical moment. It’s the AI doing work for the user. It’s almost an agentic thing. You have this little transmission process that an AI does for you as a user, and all you see is the data you want to get, and you just describe it with natural language.

This is the one way that I think every business can benefit from AI, and I highly recommend you implement it. This might even be a business idea, for that matter. So, you know, take a look at it.

The goal isn’t to wow people with AI. The goal is to use AI to help people reach their own wow moments with your product. And when you do that invisibly, behind the scenes, creating those magical moments where everything just works exactly as they hoped—that’s when AI becomes truly powerful for bootstrapped founders.

That’s it. That’s what entrepreneurship is.

We’re constantly encountering currents that either facilitate what we want to accomplish—the businesses we want to build, the lives we want to create—or they oppose us, trying to sweep us into dangerous waters. These currents change all the time. They vary in strength depending on where you are in your journey. And here’s the thing: they’re mostly invisible until you learn to feel them.

Someone on Twitter asked me what my top three currents were after I shared this thought. It turned out to be a revealing exercise—assessing what I’m exposed to, what I’m dealing with, and how I’m navigating these forces. So let me share what I’ve discovered about the currents pulling at me as I build Podscan.

The Technology Rapids

The biggest current I’ve felt over the last year and a half is the rapidly changing technological landscape. As a software entrepreneur, you’re permanently exposed to new technologies. There’s always something you might want to learn, something that could give you an advantage if you figure it out—or leave you behind if you don’t.

When I was a salaried software engineer, it was so much easier to get really good at the craft. All day long, I was dealing with one particular technology stack, optimizing it, understanding it, implementing everything that needed to be done. But as a founder? The fleeting nature of projects and the volatile nature of early-stage software businesses means that pivoting from one stack to another is not just easy—it’s often necessary.

Think about it: right now, you might need time series data, or some kind of vector database that may not be as established but is perfect for building with new technology—particularly embeddings and vector stores. You need to learn a new language for communicating with your database, new ways of interacting with data that, prior to this, you would have never cared about. You would have just used a regular old database and a regular old approach to building software. But that’s just not happening anymore.

And that prevents mastery. When you’re constantly incentivized to switch tech, to learn new tech, to implement new technology into your business immediately—because you need to stay on top of what the early adopter crowd is interested in, and that’s often new technology, new ways of dealing with technology, new ways of presenting data, new ways of accumulating data—it makes it very hard to become really good at any one thing.

This is particularly hard when you’re in the early stages of building a business. You’re not only exposed to all the potential fancy technology—and I don’t just mean software stacks, I also mean things like AI agentic coding or vibe coding, things that build software for you—but you just don’t know. You don’t know what this technology is really like, how exactly it works, how you can use it in an optimized, high-efficiency way.

How do I resist this current? By choosing solid fundamentals for my own business adventures. When I built the Podscan Ideas Vault—the software that I recently started on top of Podscan’s webhook API, which constantly extracts business ideas from podcasts all over the world—I needed to build a new data storage system. And there I was, thinking: I’m just gonna go with what I know. I’m gonna open up a PostgreSQL database. There’s gonna be a Redis cache, and that’s it. I’m not gonna go into document-based databases or even vector storage. I’m gonna choose Postgres, because it offers these things built in. But in the end, it’s always going to be a relational database.

That was a pretty good choice, because it allows me to just build the thing I want to build and not feel compelled to constantly learn new things all the time.

My recommendation: go with technology that hasn’t changed based on hype. It should always be based on the effect. If it’s been around, it’s a safe choice to make. If you’re a Rails developer and you want to build a new business, just default to Rails. Even though you could go into PHP, you could go into JavaScript and have fancy new automated build systems that are highly complicated—great that exists, and that could well be a thing, but you don’t have to choose this technology because it’s there. You should choose the one that you already understand.

This makes it easier, particularly if you look at how AI coding is such a normal thing for most people now. Even though people don’t always use agentic tools, they will use autocomplete—that’s always been a thing, IntelliSense and that kind of stuff. But knowing if an autocomplete suggestion is good, if it’s something that’s going to benefit your project or not—well, that’s only possible if you have an understanding of the underlying framework and system. For that, you should always go with the thing you know.

And if you don’t know anything, if you’re just going to start learning the technology, learning to code while building a business—well, then going with a widely adopted and wildly popular system like Laravel PHP or Ruby on Rails is probably a good idea. The reverse Lindy effect is real here: technology that hasn’t been around for a while has a high risk of not sticking around for longer. The Lindy effect says that technology that’s been around for a while will likely stick around for a while. So the inverse would be that new technology is volatile. You might run into software that just stops working after a while because it didn’t get the traction people thought it needed.

The Commoditization Wave

The second current is both a blessing and a curse: software engineering is being heavily commoditized. It’s so much easier to build software now, so much faster to create working, monetizable prototypes. This has been a boon to the indie hacking community—solo founders can start small, niche businesses like never before.

But here’s the undertow: it’s just as easy for anybody working at a larger company with deeper pockets to build the same thing. Your idea can be copied, duplicated, and out-executed by someone with more time or resources. The red flags in B2B software building are still there—people still need clearance for projects, specifications, integrations—but the barrier to entry has dropped dramatically.

This makes bootstrapping a software business less of a solid defensive moat than it used to be. Unless—and this is crucial—unless you build distribution and a public brand around it. Which leads me directly to the third current.

The Attention Undertow

The ever-growing need for attention in this increasingly crowded ocean—that’s a current that both pulls me along and holds me back, depending on where I look.

The biggest problem for any founder is distribution. It’s hard to find customers for your projects if you don’t have the marketing dollars to just spend on paid advertising or influencer marketing. Once you have that kind of money, it’s great. It works. It really works. You get solid leads from spending money. But if you don’t have that money, you kind of have to do it organically. You have to build a brand in public, share your business journey in public. Building in public is still the cheapest way of getting attention on yourself and your business, finding your customers, finding partnerships, and all that kind of stuff.

But it’s marketing. And here’s the strongest tension for me: I want to stay authentically myself as a founder. I want to communicate very authentically what my journey is as I build it in public. But I know that every single post I make has a marketing angle.

Now, let me share how this attention current plays out in my daily routine. Every day before my newsletter goes out, I share one or two ideas from it with commentary. I’ve been doing this for the last couple of days—if you follow me on Twitter, you’ve probably seen it. I want people to know that first off, there is a newsletter that might be interesting for them, and this is what they might get. It is a marketing activity to share what the newsletter does every day. I’m quite aware of this.

So it feels performative on occasion to post about this. Every day at 8 AM, my newsletter goes out. I check: okay, what’s in there? What’s interesting? What could I say about this? And as much as I actually like to see all these ideas and to get some kind of insight into what’s being talked about in the world, it’s still marketing. Being a creator on social media while trying to remain an authentic person—it’s a current that sometimes pulls me toward my goals and sometimes away from them.

The Social Media Mirage

Another current I feel strongly, particularly in our community of founders online, is being a consumer of social media. I suffer a hard time maintaining a firm grasp on my own journey when everybody else’s journey seems to be flashing more brightly around me.

Social media is highly selective, right? You share the good stuff, and people rarely share the bad stuff. So what you see is an echo chamber of positivity—not necessarily toxic positivity, but it’s selective positivity. People share, “Oh my, MRR went up!” That’s wonderful. Here’s the screenshot. I don’t really see too many people sharing when their MRR goes down with the screenshots that come from that. I don’t really get to see them often, because people don’t share them.

So what you see is everybody’s doing well, and you just don’t get to see the struggles. My own reality, where every day the MRR graph goes up and sometimes down—that is not represented in the social media network around me. If it’s not represented, I can’t perceive it accurately. And if I can’t perceive it accurately, my journey is colored by this distortion.

It doesn’t even have to be envy or jealousy for this kind of fabricated reality to affect you. It’s like Plato’s cave—we’re looking at shadows on the wall. What we see are mirrors or silhouettes on the wall, and the reality is something behind us that we don’t necessarily get to see, because we only get to see the wall—quite literally, the Facebook wall and the Twitter feed.

This is a strong current I feel that often can motivate me, because I see other people doing well and I think, “I want to get that too. What do I need to do?” But it can be disheartening in moments of doubt and moments of failure, moments of perceived lack of success. It’s a strong feeling when it seems like everybody else is doing so well.

The Work-Life Whirlpool

The final current—and this is particularly hard—is the pull of work-life balance. I try not to spend all day working. I’ve been focusing more on balancing my own mental stability, which I derive from being with friends and family, from reading, from having hobbies.

Yet combining the lack of technological stability with the pressure for social media presence makes me want to spend more time working to reach my goals and less time away from work—which is also a goal, but one that isn’t as directly perceived.

When I don’t work, there’s always this nagging thought: you could be spending time working. Even though it wouldn’t necessarily be productive or helpful. It might even be distracting—just working for the sake of working.

We all understand now that you don’t measure the quality of a software engineer by lines of code written. You measure features implemented, bugs fixed, efficiency gains, maybe sales made. You don’t measure output—you measure impact. Yet there’s still this output-centric mindset, this current that says more time working equals better results. That’s the current I’m trying to swim against.

After 25 years of sitting in front of a computer, it’s so easy to check things, try to improve things a little. It’s so hard to step outside and not do that.

Navigating, Not Drowning

Your currents are probably going to look different. You might feel pulled in different directions. You might view these forces more benevolently or more malevolently. But here’s what I think is important: realizing that these currents exist.

They’re often internally validated, but they’re mostly external forces acting upon you. People will share their stories with or without you. The rapid developments in AI and frameworks—that’s not your fault. The fact that this causes more competition—not your fault. The fact that you picked an industry that now sees so many people trying to build in it—not your fault either.

These are external forces, but we make them internal when we allow them to sweep us away without even knowing we’re moving.

The important part is to understand that these currents exist. To make them visible, make them present, so that we recognize them as currents and not as our own failings. We shouldn’t despair when we get pulled in a direction a little bit too much. That’s just what entrepreneurship is. You’re constantly torn from one side to the other, and you have to make different strokes to stay where you want to be.

A stronger current does make for stronger fish. But only if you know you’re swimming. Only if you’re aware of the water you’re in. Once you recognize the currents, you can choose: swim against them, swim with them, or find the calm eddies where you can rest and reassess.

The currents will always be there. They change with the tides of technology, market forces, and social dynamics. But awareness—that’s your compass. And deliberate action—that’s your stroke.

So take a moment. Feel the currents pulling at you. Name them. Understand them. Then decide how you want to navigate them. Because in the end, you’re not just trying to survive these waters. You’re trying to get somewhere. And knowing the currents is the first step to charting your course.

The Evolution of Software Consumers

There used to be a time where websites were mostly for people. People were browsing websites, reading websites, handwriting websites in HTML in text editors. The late 90s, early 2000s were pretty much that.

Then there was a time where APIs became all the rage and applications became programmable with each other. Applications would exchange information and orchestrate each other to get data from one point to the other. First, software was made for people, and then software was made for machines to consume.

Now we have this weird hybrid of man and machine – the agentic AI. The AI that follows human logic and human approaches to process and discovery and exploration, but is effectively a machine that can do it much faster, much more targeted, and maybe also much more dangerously than what most humans could do.

We’re looking at the age of building interfaces for AI systems.

The Progression of Concerns

It’s always a progression, right? When you look at user interfaces – browsers or desktop applications – there was a progression towards making these things computer accessible. Browsers deployed things as HTML documents or JavaScript applications, where the backend would make available an API with a more structured approach – maybe a JSON API, or a GraphQL API, or some kind of remote procedure call system. It would be more technical, more focused on what machines would like to consume.

But I think there was a migration of concerns from “this is what a human wants to accomplish” towards “this is what a human wants a machine to accomplish.”

And now there’s this part of the interface that isn’t consumed by humans, but it’s also not consumed by repeatably expectable or reliable machine systems anymore. Now we have agentic systems that try stuff, just like a human explorer would try to see if they can get some information. If they can’t, they try alternative approaches. They might have different ways of solving a problem. They might try to fabricate new solutions to previously unencountered and undiscovered challenges.

The agentic system will require its own user interface in a way. What the website or the rendered DOM was for a browser that allowed us to visualize information, and what the API endpoint was for machines – we have to think about how we will make this available to AI systems right now and in the future.

Current Solutions and Future Needs

Right now, we will likely have these AI systems use API systems. The MCP – the Model Context Protocol – is an idea. It’s kind of an API of sorts, an API that translates certain things into API calls on the backend. It’s like a wrapper around an API system, around a service to make it accessible to LLMs.

But there might be a future where this wrapper is not flexible enough. We want systems to be able to quickly integrate with the capacities of our services, of the businesses that we run, the platforms that we run, the data that we make available to our customers and users. We want systems that are flexible enough for new ideas to not be reliant on us having to implement some kind of endpoint.

Funny enough, the GraphQL idea was more aimed at this – make available an endpoint and allow the consumer to configure exactly what data they want. I see similar things in the DSL for the Elasticsearch engine, which I’m using quite a lot for PodScan. It’s something that frightened me when I was first encountering it a couple decades ago, and has been something frightening in the back of my head ever since. It’s just such a complicated way of expressing highly complex queries, but AI has really helped me dig into it and build working queries for me, so that now I actually understand the DSL better.

The DSL is so flexible that I don’t think you could enumerate the full possible spectrum of all possible search queries. I think it’s infinitely flexible, which is something that we will need with AI systems in the future.

The Security Challenge

At the same time, that flexibility is also a security risk. When we allow a lot of flexibility to the systems, then all of a sudden we have this transmission system – the border where our data ends and our system ends and where the consumption starts of this external agentic AI system, however intensely and however maliciously it may try to access our system. Now we have to defend it at that point, while still making most of our data available to everybody else who uses the system benevolently.

It feels problematic in a way that we have very established security systems for API systems and for browsers. We have cookies in browsers. We have sessions in browsers and for APIs. We have tokens, we have authentication systems, we have OAuth, we have secrets like HTTP header properties that reliably and secretly communicate and have encryption and all of that.

It’s going to be problematic to do this with agentic systems. Agentic systems will obviously need some kind of permission and authorization and authentication systems. The authentication system is very similar to what we currently have – that won’t change much. But in a world of flexible data use, permission settings for using a data node or using some kind of interactive system might not just be a binary choice.

Real-World Complexity: The Calendar Booking Example

Let’s imagine we’re integrating with somebody else’s calendar booking system. We run a company that offers, I don’t know, virtual meeting rooms, and we want to integrate not just with somebody else’s calendar system, but somebody else’s booking agentic systems where software is trying to mediate booking an event between any number of parties.

Now if we give access to that system, how do we reliably structure it so that these agentic systems that might get into novel situations work properly? Somebody might say, “Well, I have time, but only for one hour on that day, depending on if somebody books something else on the day before, or the time slot before. If that is booked by Friday, then I’m available here.”

People have very imprecise ways of determining their availability, and an agentic system, compared to an API where you would have a very rigid, very strict system of “tell me exactly when you will be available,” an AI system might be more flexible, or try to be more flexible with that.

How do we build systems that allow for this without causing errors, without causing maybe mis-bookings, over-bookings, maybe overloading the system? Because all of a sudden there’s a recursive loop in the agentic system, and it just tries to check everything and then book something and check something else, and then unbooks because it doesn’t fit anymore, but now it fits again, and then it books again.

Situations like this – that is not just a rate limiting issue. That is an issue of protecting yourself against novel situations that your system has not yet discovered because you haven’t encoded it in the logic of it. You haven’t encoded it in the expected situations that consumption patterns or consumers might run into.

The Version Management Problem

There are many other problems. If an LLM system has been trained on an old version of an interface, and it’s not instructed to fetch and work with a new version – some kind of updated version of the interface – it is going to try and use the old one, which might require some kind of translation layer or a rerouting system.

These are not really novel problems, but they have a different taste this time around, a different connotation, because we’re now working with much less precise inputs that are not as typed and not as binary – not as right or wrong as they used to be. The moment we interact with systems that supposedly draw discrete information from a non-discrete description or a non-discrete system, it’s going to be an interesting challenge.

The New Consumer: Neither Human nor Machine

Besides the human user and the machine user – the API-centric, very well-defined information exchange kind of consumer of our software – we now might have to deal with a consumer that is much faster, much more capable of experimenting in a very short amount of time, and therefore potentially overloading our services or creating junk data in our services, or misusing and misappropriating services than we ever were before.

This makes it very complicated to even communicate clearly what a software product can and cannot do. Because we’ll effectively try to open as much surface as possible to these agentic tools and rely on them to appropriately use the platforms. This is particularly complicated when we’re used to either human speed or machine speed.

When a human uses a product, you have an understanding of how long they will wait, what should be synchronous and what should be asynchronous, what data to present and what data not to present. The same goes for an API when you have a clearly defined contract between service and consumer – a transactional exchange of sorts.

Then all of a sudden we have agentic users who act like a human in one way and act like a machine in others. A lot of the tools that we see out there have human-in-the-loop features where the execution of workflow is paused until the human interacts. So now, what is a session with these kinds of consumers? Is it a connection? A request? Is it a series of requests within a certain timeframe, or is it a certain order of requests that includes – or maybe doesn’t include – a human in the loop?

It becomes hard to explain and communicate how exactly the borders of the service work when it’s not even clear how much machine and how much human is in the consumer.

The Economic Risks

I know this might all sound a little bit solvable. Obviously, we’ve had rate limits before, we’ve had the concept of well-defined inputs and outputs before. We had patterns like “be precise in what you output and be flexible in what you allow into a system.” All of this existed before.

But particularly with the technology that is developing as crassly and as quickly as agentic consumer systems and the technology on top of which they sit, I don’t really know anymore. It feels like we are looking at a world, an industry reality where product consumption has become less expectable, less plannable, and less reliable.

On top of that, AI-centric products are really prone to being disastrous when maliciously abused. If we open up our APIs to flexible systems and they overconsume, and that requires us to send API call after API call to a system that charges us for each of these calls, but we want to be flexible and we want to allow agentic systems to do their work on us, then all of a sudden we have to be able to incur a massive potential cost that we may not want to.

And the cost may appear even though it wasn’t intended to be produced or caused because the system just went haywire and was stuck in a loop or was effectively launching an unintentional denial of service attack due to its own internal parallelized architecture.

There are so many interesting new problems that face us as we open up our applications to AI systems.

The Path Forward

I think it’s generally a good idea at this point to look into the Model Context Protocol because it’s the first attempt at understanding how products and systems can be used by and through large language models and the applications that are based on them.

I personally have been attempting to experiment with that kind of stuff for PodScan because I know that it’s interesting for my customers to be able to use PodScan from inside their agentic loops and their conversational AIs. It hasn’t really resulted in a public thing just yet, but I know that within a couple of years, we’ll have systems like this built into every single platform and product out there.

It’s just unavoidably required for these interfaces to exist, just like Laravel – the tool that I use – has a web-based component that allows people to use it, and an API component with Sanctum, which is an internal plugin that allows API-based call-based authentication. There will be something built into the framework quite soon, probably because Laravel has been really intensifying their AI efforts, both in how to build Laravel and what Laravel can support.

There will soon be something that will be the third option that will allow LLMs programmatic access to any application through a normalized interface internally. I find this fascinating.

Conclusion: Embracing the Unknown

So, who knows where we’re going? We have to think about this as a consumer – as a qualified consumer of our applications – and protect ourselves from the potential downsides of allowing machines to think and act like humans but still be machines.

We’re entering uncharted territory here. The age of AI consumers is upon us, and as founders and developers, we need to start thinking about how our products will serve not just humans, not just traditional APIs, but these new hybrid entities that combine human-like reasoning with machine-like speed and scale.

The challenges are real – from security to cost management to simply understanding what a session means anymore. But so are the opportunities. Those who figure out how to build robust, flexible, and secure interfaces for AI agents will be at the forefront of the next wave of software innovation.

It’s time to start experimenting, learning, and preparing for a world where our biggest users might not be human at all.