410: Building for the Age of AI Consumers

I think we're at the precipice of a pretty significant change in how we build software products. Obviously, the recent ascent of vibe coding and all the agentic coding tools that we find very useful and highly effective shows a difference in how we approach building products. But there's another change - not just in how we build, but in who these products are for.

This episode of The Bootstraped Founder is sponsored by Paddle.com

The blog post: https://thebootstrappedfounder.com/building-for-the-age-of-ai-consumers/
The podcast episode: https://tbf.fm/episodes/410-building-for-the-age-of-ai-consumers

Check out Podscan, the Podcast database that transcribes every podcast episode out there minutes after it gets released: https://podscan.fm
Send me a voicemail on Podline: https://podline.fm/arvid

You'll find my weekly article on my blog: https://thebootstrappedfounder.com

Podcast: https://thebootstrappedfounder.com/podcast

Newsletter: https://thebootstrappedfounder.com/newsletter

My book Zero to Sold: https://zerotosold.com/

My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/

My course Find Your Following: https://findyourfollowing.com

Here are a few tools I use. Using my affiliate links will support my work at no additional cost to you.
- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx
- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid
- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid
- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60
- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ
- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q
- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

Creators and Guests

Host

Arvid Kahl

Empowering founders with kindness. Building in Public. Sold my SaaS FeedbackPanda for life-changing $ in 2019, now sharing my journey & what I learned.

What is The Bootstrapped Founder?

Arvid Kahl talks about starting and bootstrapping businesses, how to build an audience, and how to build in public.

Arvid: 00:00

Hey. I'm Arvid, and this is the Bootstrap founder. I think we're at the precipice of a pretty significant change in how we build software products. And I know I say this a lot, and I've said this every year, but this time, I think it's weird in a way. Obviously, the recent ascent of vibe coding and all the agentic coding tools that we all find super useful and highly effective, well, shows a difference in how we approach building products.

Arvid: 00:30

Sure. But there's another change, not just in how we build, but in who we build these products for. This episode is sponsored by paddle.com, my merchant of record payment provider of choice who's been helping me focus on PodScan and my other projects. They have been taking care of all things related to money so that founders like you and me can focus on building the things that only we can build for all the audiences we might want to serve with that. Paddle handles all the rest sales tax and credit cards failing all of that.

Arvid: 00:59

I highly recommend it. So please check out paddle.com. Now there used to be a time where websites were mostly for people and people were browsing websites, they were reading websites, they were handwriting websites in HTML and text editors. If you did this in school or at any point, I commend you. It was a great time to learn how to be on the web and how to produce something meaningful.

Arvid: 01:22

The late 90s early 2000s were pretty much that and then of course technology evolved around it and it made it easier to build things but that's kind of what websites were right they were crafted HTML for people by people. And then there was a time where APIs became all the rage and applications became these programmable things that could work with each other. They would exchange information and orchestrate each other to get data from one point to the other. And first, software was made for people and then software was made for machines to consume. Of course, I know that software was always for machines to consume.

Arvid: 01:58

Even an HTML website technically was consumed by the browser before the person used it. But you know what I mean. Right? It was meant for active consumption by other machines in a scaled way. And now we have this weird hybrid of man and machine and that's the new thing that's agentic AI.

Arvid: 02:16

The AI that follows human logic and has human approaches to process and discovery and exploration but is effectively a machine that can do things much faster and much more targeted maybe also much more dangerously than what most humans alone could do. So we are looking at the age of building software and interfaces most importantly for AI systems. And it's always a progression right when you look at user interfaces browsers or desktop applications there was this progression towards making these things computer accessible. Browsers deployed things as HTML documents, JavaScript applications where the back end would be then later made available as an API with a more structured approach, maybe a JSON API, a GraphQL API or some kind of remote procedure call. It would be more technical, focused on the API side of things, more focused on things what machines would like to consume and browser renderings were kind of for people.

Arvid: 03:19

But I think there was a migration of concerns here from this is what a human wants to accomplish with this piece of software towards this is what a human wants a machine to accomplish with this piece of software. And now there's an interface. It's part of the interface that isn't even consumed by humans but it's also not consumed the same way like repeatably expectably or reliably as machines would consume APIs as they used to at least. Now we have agentic systems that try stuff. It's the best way I can phrase it.

Arvid: 03:51

Right? If you have an API, if you have a contract with an API client and an API server somewhere, you know exactly what's gonna happen. And anything that's kinda out of the ordinary produces errors or at worst causes an IP ban or something but now you don't really know these machines these agentic systems they try they explore just like a human explorer would and would try to see if they can get some kind of information from somewhere. Just dig around a little bit. See what happens.

Arvid: 04:19

And if they can't, they try alternative approaches. They might try different ways of solving a problem that are not codified in an API documentation or in a browser how to walk through video they might try to fabricate completely new solutions to previously unencountered and undiscovered challenges that you might have or pose with the API so the agentic system of today and the future will kind of require its own user interface in a way. What the website the rendered DOM was for the browser that allowed people to visualize information and what the API endpoint was for machines we kind of have to think about how we will make this available to AI systems right now and in the future. And if you think well just just going to use APIs right? Well yeah maybe right now I think we will likely have these AI systems use APIs because that's what we have.

Arvid: 05:13

And if you look at the technology that is being developed, the MCP, the model context protocol, that is an idea that kind of fits there. It's kind of an API of sorts, an API that translates certain things into API calls on the back end. This kind of a magical wrapper around an API system, around a service that makes the whole thing accessible to agents, LLMs. But I think there might be a future where this wrapper is not flexible enough. We want systems to be able to quickly integrate with the capabilities and capacities of our platforms, of our offerings.

Arvid: 05:47

Right? The businesses that we run, the platforms that we run, the data that we make available, and the transactional nature of our system that we make available to our customer and users. We want systems that are flexible enough for new ideas, like new agentic approaches, to not be reliant on us having to implement some kind of endpoint whenever somebody wants to use it in a different way. And when I think about APIs of the past and present, I guess, I think the GraphQL idea was more aimed at this compared to the REST idea, the idea of a RESTful system. It was all well defined.

Arvid: 06:20

But GraphQL was more like, we'll make available an endpoint and allow the consumer to configure exactly what data they want. Just tell me the things, the properties you want and that's what you will get. It's kind of nice. It's flexible, more flexible than what REST used to offer at least through the spec and I see similar things in the DSLs the domain specific languages for things like the Elasticsearch engine a tool that I use quite a lot for Podscan it is something that used to frighten me decades ago when I was first encountering it and has been something frightening in the back of my head ever since. It's complicated.

Arvid: 06:54

It's such a complicated way of expressing what I have to admit are highly complex queries to search for stuff and rank it and sort it and, you know, do a lot of magic. But AI, surprisingly has really helped me dig into this and built working starter queries for me so that I now actually understand the DSL better and like to implement it more of course mostly AI does it for me but I can see how it works. It's kinda nice. Like, the AI actually pulls out the complexity and makes it a thing that I can accomplish, a thing that I can understand. And that DSL is so flexible that I don't think you could even enumerate the full possible spectrum of all possible search queries or even search query configurations you can always nest one more search query and make it more specific or rank it differently I think it's infinitely flexible which is something that I think we will need with AI systems in the future and it's not just going to be Elasticsearch with this wonderful query system that needs this we all will need this the AI systems that will consume our products they want that flexibility because they themselves don't really know what task they're going to be trying to accomplish and at the same time the flexibility that that would offer is also a massive security risk to the product, to our customers, to a whole business.

Arvid: 08:15

Because when we allow a lot of flexibility to the systems that interact with us, then all of a sudden we have this transmission system that the border where our data ends and our system ends and where this consumption starts of this external agentic AI system however intensely and however maliciously it may try to access our system and that's going be a problem. Now we have to defend it our system 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 these very established security systems for APIs and for browsers, right? Cookies in browsers, sessions in browsers and for APIs we have tokens, we have authentication systems like OAuth, we have secrets and headers and things that reliably and secretly communicate between a server and a client what can be done. We have encryption all of this kind of stuff and this is going be problematic to do this with agentic systems.

Arvid: 09:13

Right now probably not the systems try and if they fail when that's just what it is but these agents will obviously need some kind of permission and authorization and authentication system too that is still flexible. The authentication system is likely going to be similar to what we currently have. That won't change much but in a world of flexible data use expectations permission settings for using one certain data node or some kind of interactive system, that might not just be a binary choice anymore, not a yes, you can or no, you can't. We see this already in the web scraping world. Cloudflare did something, must have been a month or two ago, where they were trying to implement like a web payments API where certain AI scrapers like the OpenAI's and the Anthropics of this world only get to access your Cloudflare page if they pay like a micro amount per scrape.

Arvid: 10:03

It becomes a not a yes or a no, which you can still say. You can say you can scrape everything or you can scrape nothing, but you can also say, well, you can scrape some things depending on an action that you take. I think that's cool but it's also adding a lot of complexity and if you give access to a system how do we reliable structure it so that these agentic systems that might get into novel situations work properly. It's not just about abusing the system it's just about not using the system right. Somebody might say to their agent well I'm booking an appointment here I have time but only for one hour on that day and that depends and if somebody else books something on my calendar the day before or the time slot before and if that is booked by this Friday then I'll be available for the next week.

Arvid: 10:51

You know these are situations that happen in real life and people have very imprecise ways of determining their own availability. So for an agentic system compared to like an API that you would use that would have a very rigid, strict system of tell me exactly when you are available, the agent might need some more flexibility or try to be more flexible with that. So how do we build systems that allow for this kind of flexibility without causing errors all the time, without causing maybe miss bookings or over bookings or overloading our system, completely irrelevant what we actually are building. Right? Because all of a sudden, there might be a recursive loop in the agent because the agent itself can be faulty or it can just try different things really quickly just to check everything book something and then check again that it unbooks the thing because it doesn't fit anymore but now it fits again and then it books again that kind of stuff situations like this it's not just a rate limiting issue that's not how we solve this this is how we prevent abuse.

Arvid: 11:47

This is an issue of protecting yourself against novel situations that your system and their system has not ever experienced because you haven't encoded it in the logic of the system because you don't know. You haven't encoded it in those expected situations that consumption patterns or consumers might run into because you can't expect it just yet. It's just one of those infinite possibilities of how your system could be used. And there are other many many other problems with this if an LLM system has been trained on an old version of an interface even if it's an API or a website or whatever the new thing is gonna be whether it be like UI AI, AUI, like something like that. But if it's not instructed to fetch and work with a new version, some kind of updated version of the interface or its documentation, it's gonna try and use the old one and that might break things or it might require some kind of translation layer or a routing system between versions, and that gets complex again.

Arvid: 12:45

And I know these are not really novel problems. Like Stripe is the best example for having an API that has versions that go up and down and depending on what version a consumer uses their requests get like rewritten to fit any version of the system. They've written about this on their engineering blog at length Highly recommend it if you're into API stuff. It's really, really interesting. But it has a different taste this time around with this infinite level of complexity.

Arvid: 13:12

It's not just one axis. It's not just a version that goes up in small increments over time, and they have to kinda deal with this one linear thing goes in both directions, maybe that makes it complicated, but AI agents that could do anything and everything with all kinds of data, that all of a sudden is a four d situation, not a two d one. So it has different connotations for me 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. And the moment we interact with systems that supposedly draw discrete information from a non discrete description or a non discrete system like a prompt, it's going to be an interesting challenge. Besides this human user and machine user, the API centric very well defined information kind of exchange of consumers in our software, we might now have to deal with a consumer that is much faster and much more capable of experimenting with our system in a very short amount of time and therefore potentially overloading our systems or creating junk data on our services, misusing, misappropriating services faster than we ever have experienced before.

Arvid: 14:21

Denial of service is a thing we know but stupid denial of service because some agent is in a loop it's not going to be fun but it's going to be real And 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 because this is going to be paying customers for us, right? We rely on them to appropriately use the platforms. And this is particularly complicated when we're used to either human speed or machine speed. When a human use is a product and I think this is an important distinction to make you have an understanding of how long they will wait, how long a click takes, how they look at a website, they scroll, they click on things and something should be synchronous, right, because it happens immediately.

Arvid: 15:08

Other things can be asynchronous. They get a notification. What data do we need to present? What data doesn't need to be there? The same goes for APIs where you have this clearly defined contract between servers and consumer a transactional exchange really and you know that if you do this more than five times a minute our rate limiting kicks in or if you try to get more than five items they're going to be paginated right you have these kind of contracts these kind of expectations and 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 even where the execution of a workflow is paused until the human interacts with this thing like an approval, a verification system or just something where a human needs to do something.

Arvid: 15:53

So now what even is a session here with these kind of consumers? Is a session a single request? A connection? Is it a series of requests within a certain time frame? Or is it a certain order of requests that includes or maybe doesn't include this human in the loop?

Arvid: 16:08

It becomes so hard to explain and communicate even the basic ideas of what we knew until now what a session is, what a request is, what a workflow is and to communicate exactly the borders of the service and the work within it when it's not even clear how much machine and how much human is in the consumer. I know this might all sound a little bit solvable to be honest. I think this is just about setting expectations and obviously we've had things like rate limits before, we've had the concept of well defined inputs and outputs before, we had patterns even like be precise in what you output and be flexible in what you allow into a system right 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 LLMs I don't really know anymore. It feels like we're looking at a world an industry reality where product consumption has become less expectable less planable, less reliable, and therefore also less easily scalable or maintainable or financeable because we just don't know. And on top of this, AI centric products are really prone to being disastrous when maliciously abused or even non intentionally.

Arvid: 17:24

If we open up our APIs, our systems to flexible systems and they over consume and that requires us to send API call after API call to a system that charges us for each of these calls, like OpenAI and Anthropic, these platforms. Right? But we wanna be flexible and we wanna allow agentic systems to do their work on us so people can pull the value of our product into their systems then all of a sudden we have to be able to incur a massive potential cost and that cost may appear even though it wasn't intended to be produced or caused because the system just went haywire and was stuck in the loop was effectively launching this unintentional denial of service attack because its own internal paralyzed architecture that didn't expect to connect to the same site 400 times per second on 20 different servers, right? It's just okay, now I have to deal with this. There are so many interesting new problems that face us as we open up our applications to AI systems.

Arvid: 18:21

So biggest learning for me over the last year was on the inside, do rate limiting for anything that costs you money per request. Like for PodScan, I offer some kind of AI features and I have a lot of AI stuff in the background. But if there is anything coming in from a user that might potentially abuse this, I have an internal rate limit that no matter how many users are using this technology, is there anything AI related, you know, like automatic alternatives, finding alternatives for certain keywords, or I have an AI builder for alerts and an AI builder for lists. Like, if those things are used too much, a couple times per minute, it already says, hey, try again later. I will have to shift that number up and down, but at least right now, I prevent spending hundreds of dollars a day on AI.

Arvid: 19:08

This is something that I would build into any application where if the user clicks a button, AI is used because of this, because we don't know who's consuming our product. And I think it's generally a good idea at this point to look into things like MCP, into the model context protocol, just because it's the first attempt at understanding how products and systems can be used by and through these large language models and the applications that are based on them. I personally have been attempting to experiment with that kind of stuff for POTScan too because I know that it's interesting for my customers to be able to use POTScan 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 couple of years, we'll have systems like this built into not just every product, but every platform and every framework out there. I think it's unavoidable because it's required for these interfaces to eventually exist.

Arvid: 20:02

And Laravel, the tool that I use, the framework programming language that I use is PHP, and Laravel is the framework that sits on top of this. They have a lot of components in their system, like web components, obviously, the whole thing is a web framework, and they have API components that allow for authentication. It's called Sanctum. All of this is internal plug in stuff that allows these authentications and access ideas to work in a framework. And there will be something built into that framework quite soon, I think, probably because Laravel has been really intensifying their AI efforts both in how to build Laravel applications and also what Laravel internally can support in terms of AI tooling.

Arvid: 20:43

Right? Like how they can call AI and how AI can be used and leveraged in building Laravel apps. It's really cool. I think it's called Laravel Boost. It might actually already be out.

Arvid: 20:53

I think it adds an MCP that your code editor can plug into and test and get good information on how to build Laravel apps. It's really, really interesting. There'll soon be something that would be the third option here between regular web framework and, like, an API connector that will allow LLMs programmatic access to any application through this kind of normalized interface internally. And I think this is fascinating because we're part of a new movement here that has not existed for, I don't know, like twenty years. How new are APIs?

Arvid: 21:25

Yeah. 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 these consumers, these machines to think and act like humans but still be machines. That that is just something we need to take into account when we build software now. We're entering uncharted territory, I guess, we could call this.

Arvid: 21:48

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 people, not just traditional APIs, but these new hybrid entities that combine human like reasoning and human like process exploration with machine like speed and scale. And these challenges are real. Security, cost management, just simply understanding what a session means anymore but so are the opportunities here. Those who figure out how to build robust and flexible and secure interfaces for AI agents will be at, I guess, the forefront of the next wave of software innovation.

Arvid: 22:22

It's gonna be baked into frameworks, so I guess the people building the frameworks are there already and thinking about it. But you, at this point, should probably think about building this into your products if you wanna be able to sustain that wave and be part of this new generation of software tools. I think it's time to start experimenting and learning. So check out MCP. Check out whatever the newest AI developments in your programming languages are because this might actually be required reading in a couple years from now.

Arvid: 22:53

Prepare for a world where our biggest users might act like humans but not be human after all. Thank you so much for listening to the Bootstrap Founder today. You'll find me on Twitter abidkal, a r v I d k a h l. If you wanna know what everybody's saying about your brand on over 3,800,000 podcasts, well, podscan.fmtracks mentions with a very powerful API that is allowed to be consumed by LLFs as well that turns podcast conversations into actionable data. And if you're hunting your next business idea, get them delivered fresh from the podcast world at ideas.podscan.fm, where AI extracts the best startup opportunities from hundreds of hours of expert conversations every day.

Arvid: 23:33

Thank