You know, Herman, I was looking at my bank statement the other day, and the sheer number of monthly subscriptions I have for software is actually starting to get a little ridiculous. It feels like every time I want to solve a minor problem, I have to sign up for a new service, give them my credit card, and hope I remember to cancel it in three months when I realize I only used it twice. It is a digital graveyard of forgotten passwords and fifteen dollar charges. But today, we are diving into a topic that suggests this entire model might be on its way out. Today's prompt from Daniel is about the shift from using Software as a Service to building your own bespoke tools using artificial intelligence agents. It is about the transition from being a consumer to being a creator, even if you do not know a lick of Python.
Herman Poppleberry here. And Corn, that is exactly what is on my mind lately too. We are sitting here in February of twenty twenty six, and the landscape has shifted so fast. Daniel mentioned something that I think a lot of our technically literate listeners will resonate with, which is that lightbulb moment. For him, it was using artificial intelligence to generate code for Home Assistant to control his lights at sunset. It sounds like a small thing, but once you realize that the artificial intelligence isn't just a better search engine, but a partner that can actually build functional technology for you, the entire world changes. Daniel is originally from Ireland, but he has been in Jerusalem for years now, and his background in technology communications really shines through here because he is looking at the systems level of this. He is currently using custom-coded tools for sixty to seventy percent of his daily workflow. That is a staggering number when you think about where we were just two years ago.
It really is. And it makes me think about how we have spent the last fifteen years being told that we should not build things ourselves. The mantra of the modern developer was always, do not reinvent the wheel, just use an existing Application Programming Interface or a Software as a Service platform. We were told that bespoke was a dirty word because it meant unscalable and hard to maintain. But if Daniel is right, and if the barrier to entry for coding has dropped so low that a systems thinker who does not even want to be a developer can create an entire repository manager or an inventory system, then the old rules might be breaking. We are moving from the era of the generic platform to the era of the personal stack.
They definitely are breaking. We actually touched on this evolution a bit in episode six hundred and sixty seven when we talked about the shift from artificial intelligence washing to truly artificial intelligence first organizations. But what Daniel is describing is even more personal. It is the democratization of development at the individual level. He is paying two hundred dollars a month for his Claude Code Max plan, and while that sounds like a lot for one subscription, he is arguing that it is actually incredible value because it allows him to cancel five or six other subscriptions that were costing him just as much but giving him less control. He is essentially hiring a junior developer for two hundred dollars a month who works twenty four hours a day and never complains about documentation.
That control factor is huge. Daniel mentioned the issue of data ownership and how many Software as a Service vendors make it difficult to export or back up your own data. It is a form of vendor lock-in that we have just accepted as the cost of doing business. We have all been there—trying to export a Customer Relationship Management database only to find it is trapped in a proprietary format that requires a specialized script to decode. But if you build your own tool, you own the database. You own the logic. You own the interface. There is no one to tell you that a feature you rely on is being deprecated or that the price is doubling next month because the company got acquired by a private equity firm.
But here is the friction point that Daniel raised, and I think this is where the discussion gets really deep. If everyone starts building their own bespoke versions of common tools like Customer Relationship Management systems or inventory trackers, are we not just wasting a massive amount of collective energy? Think of it like a custom-tailored suit versus something off the rack. The tailored suit fits you perfectly, but it took a lot of individual effort to create. If millions of people are all building their own slightly different versions of the same thing, we lose the benefit of standardized best practices. We lose the shared language of how business is done.
That is the paradox, right? If I build my own Customer Relationship Management system, I might be missing out on twenty years of collective wisdom about how sales funnels should actually work. I am building a tool that fits my current mental model, but my mental model might be flawed. Established software companies have the benefit of seeing how thousands of different customers use their product, which allows them to build in features and safeguards that an individual might never think of until it is too late. They have handled the edge cases, the security vulnerabilities, and the weird browser bugs that I would never even consider.
And let us not forget the maintenance burden. This is something we discussed back in episode eight hundred and eight when we talked about the deprecation trap. Even if an artificial intelligence agent writes the code for you today, that code exists in an ecosystem that is constantly changing. Libraries get updated, security vulnerabilities are discovered, and browsers change how they handle certain scripts. If you own the code, you are the chief technology officer, the lead developer, and the security auditor for that tool. If you have twenty custom tools running your life, you have twenty separate codebases that might need a tweak six months from now when a new version of the underlying language is released. You have traded a subscription fee for a cognitive load.
That is a great point. But I wonder if the agentic nature of modern artificial intelligence solves for that. If I have a sub-agent whose entire job is to monitor my custom tools and update them as needed, does the maintenance burden actually stay with me, or does it stay with the agent? We explored that idea of sub-agent delegation in episode seven hundred and ninety five. If the agents are good enough to build the tool, they should be good enough to maintain it, right? I can imagine a world where my personal artificial intelligence just pings me once a week and says, hey Corn, I updated your inventory manager to fix a security flaw in the database driver, and I also added that feature you mentioned in passing yesterday.
In theory, yes. But we are still in that messy middle phase. Right now, the human still has to be the one to realize something is broken and prompt the agent to fix it. We are not quite at the point of autonomous self-healing software for the average user yet. But let us look at the solution Daniel proposed, because I think it is brilliant. He suggested the idea of open-source starters. Instead of starting from a blank page and asking an agent to build a Customer Relationship Management system from scratch, you start with a high-quality, standardized, open-source foundation. Then, you bring in your agent to customize the last twenty percent to fit your specific needs. It is the eighty twenty rule applied to software development.
It is like having a solid foundation and a frame for a house, and then you get to decide exactly where the walls go and what the kitchen looks like. You are not reinventing the physics of how a roof stays up, but you are also not forced to live in a house that was designed for someone else. This feels like the middle ground between the rigid silos of Software as a Service and the chaotic wild west of completely bespoke code. It allows for standardization where it matters—like security and data structures—and customization where it adds value—like the user interface and specific business logic.
I love that direction. Imagine a world where the most successful software projects are not finished products, but highly malleable frameworks designed specifically to be manipulated by large language models. We are already seeing the beginning of this with things like shadcn UI components in web development. They are not a library you install; they are code you copy into your project and then own. It is perfectly positioned for an artificial intelligence to come in and say, okay, I see this button component, let me change the padding, the color, and the behavior to match exactly what Daniel wants for his inventory system. We are moving from a world of black boxes to a world of glass boxes.
This also changes the role of the developer. If the future is about building these starters, then the best developers will be the ones who can create the most flexible, understandable, and agent-friendly architectures. It is less about building a specific feature and more about building a playground where an artificial intelligence can safely and effectively build features for the end user. The developer becomes an architect of possibilities rather than a builder of constraints.
And that brings up a really interesting point about User Interface and User Experience. In episode eight hundred and thirty five, we talked about red-teaming your User Interface using agents as model users. If everyone is building their own custom tools, the traditional rules of User Interface design might start to melt away. If I am the only person using my custom repository manager, I do not need it to be intuitive for a general audience. I just need it to work for me. The interface could be incredibly idiosyncratic, or it could even be entirely voice-driven or text-driven, with no traditional graphical interface at all. Why build a dashboard when you can just ask your agent, what is the status of my inventory?
That is a bit of a double-edged sword, though. One of the benefits of standard software is that if I hire someone to help me with my business, they probably already know how to use common tools like Salesforce or Trello. If I have a completely bespoke stack of sixty custom programs, the onboarding process for a new employee would be a nightmare. They would have to learn an entirely unique digital language just to do their job. We would be creating these tiny, isolated digital islands where only the creator knows how to navigate.
That is true, but maybe the agent solves that too? If the agent built the software, the agent can also be the interface for the new employee. The employee does not need to learn where the buttons are; they just tell the agent what they want to accomplish, and the agent handles the bespoke backend. We are moving toward a world where the underlying code matters less than the intent of the user. The agent becomes the universal translator between the human's desire and the machine's execution.
I want to go back to the economics of this for a second. Daniel mentioned that he is saving money by paying for a high-end artificial intelligence subscription instead of multiple Software as a Service tools. But as we discussed in episode seven hundred and ninety one, we have to look at the Gartner Hype Cycle here. Right now, these artificial intelligence companies are heavily subsidizing the cost of compute to gain market share. Two hundred dollars a month for a tool that can write thousands of lines of functional code is an absolute steal. But what happens when the venture capital money runs out and the true cost of that compute is passed on to the consumer? Will it still be cheaper to build bespoke tools, or will the efficiency of scale that Software as a Service providers have allow them to under-price the DIY approach again?
That is the billion-dollar question. Software as a Service companies have the advantage of running one codebase for millions of users. That is incredibly efficient from a compute perspective. If every user is running their own custom inference to generate and run their own custom code, the total energy and compute requirements are much higher. However, we are also seeing the rise of smaller, more efficient models that can run locally. If Daniel can run a coding-specific model on his own hardware in Jerusalem, the marginal cost of building and maintaining his tools drops to almost zero. The decentralization of compute might be the final nail in the coffin for the centralized Software as a Service model.
So we might see a bifurcation. The mass market stays with Software as a Service because it is easy and cheap, but the power users, the systems thinkers like Daniel, move to this bespoke, local-first model. It is almost like the difference between people who buy pre-made meals at the grocery store and people who maintain a high-end kitchen and grow their own herbs. One is about convenience, the other is about craft and control. And just like cooking, the barrier to entry for the craft is getting lower every day.
And the craft is becoming so much more accessible. Daniel mentioned that he has been building computers and installing Linux since he was eighteen, but he never wanted to be a developer. That is a crucial distinction. There is a huge segment of the population that is technically literate and understands how systems should work, but they find the actual syntax of coding tedious or frustrating. Artificial intelligence is the bridge for those people. It allows them to express their systems thinking directly into functional code. It is the ultimate power-up for the person who knows what they want but doesn't want to spend ten years learning how to tell a computer to do it.
I love that phrase, systems thinking. It is about understanding the inputs, the processes, and the outputs, rather than worrying about where the semicolon goes. If we can empower the systems thinkers of the world to build their own tools, we might see a massive explosion of innovation in niche areas that were too small for traditional Software as a Service companies to care about. Think about a very specific type of artisan or a small non-profit with unique needs. They could never afford a custom developer, and no Software as a Service company would build a product just for them. But now, they can build it themselves. We are talking about the long tail of software.
It is the long tail of software. Just like the internet allowed for the long tail of content, artificial intelligence is allowing for the long tail of applications. But we have to address the reinventing the wheel problem one more time. If I am an artisan building a custom tool for my pottery business, and there is another potter in Ireland doing the same thing, how do we share our innovations? In the Software as a Service world, the provider sees what works for both of us and incorporates it into the product. In the bespoke world, we are isolated. We lose that collective intelligence that comes from shared platforms.
That is where the open-source starters and community-driven prompt libraries come in. Maybe the future of collaboration isn't sharing a finished product, but sharing the recipes and the blueprints. Instead of a pottery Software as a Service, there is a pottery starter kit on GitHub that includes a basic database schema and a set of specialized prompts that help an agent understand the nuances of kiln temperatures and clay types. You take the recipe, and you cook it to your own taste.
It is a shift from a product economy to a knowledge economy. You are not selling the software; you are selling the expertise on how to guide an artificial intelligence to build the software. I can imagine a marketplace for these starters where you pay a one-time fee for a high-quality foundation that has been vetted for security and best practices, and then you take it from there. It is the democratization of intellectual property.
That sounds a lot like the early days of the web, actually. People would share snippets of code and templates, and everyone would customize their own Geocities page or their own WordPress blog. We moved away from that toward the centralized platforms of the twenty tens, but now the pendulum is swinging back. The difference is that this time, we have a super-intelligent assistant to help us with the heavy lifting. We are moving from the era of the profile page to the era of the personal application.
It is a more sophisticated version of the personal home page. It is the personal home application. And for someone like Daniel, who is clearly deep into the automation ecosystem with Home Assistant, this is just a natural extension of his environment. He is not just a consumer of technology; he is the architect of his own digital space. I think about his son Ezra, who was born just last year in July of twenty twenty five. By the time Ezra is old enough to use a computer, the idea of signing up for a fixed, rigid Software as a Service might seem as archaic as buying a physical CD to listen to music. He will just describe the tool he needs, and it will exist. He will grow up in a world where software is fluid, not fixed.
That is a wild thought. The concept of a software feature might become obsolete. Instead of waiting for a company to release a new version with the features you want, you just manifest the features yourself. But we have to talk about the risks, too. When you build your own tools, you are responsible for the security. If Daniel builds a custom inventory system that he uses for his work in technology communications, and that system has a vulnerability, there is no security team at a big Software as a Service company looking out for him. He is on his own in a very dangerous digital neighborhood.
That is where the agentic red-teaming comes in. You have to use the artificial intelligence not just to build the code, but to try and break it. You have to ask it, find the security flaws in the code you just wrote, and fix them. It is a constant cycle of creation and verification. And again, this is why the starter model is so important. If the foundation is built by experts and is open-source, it can be audited by the community. You are only responsible for the security of the customizations you add on top. It is a shared responsibility model, similar to how cloud providers work today.
So, if we are looking for the middle ground that Daniel asked about, it seems to be this three-layered cake. At the bottom, you have standardized, open-source foundations. In the middle, you have high-powered artificial intelligence agents that understand those foundations. And at the top, you have the individual user providing the specific intent and context. This structure prevents us from reinventing the wheel because the foundation is shared, but it still allows for the bespoke flexibility that Daniel finds so valuable. It is the best of both worlds.
I think that is exactly right. And it also suggests a new business model for software companies. Instead of selling a subscription to a closed platform, they could sell premium starters, expert-level prompt libraries, and specialized agents that are trained on their specific domain knowledge. You are paying for the expertise, not the hosting. It is a move toward a more consultative model of software development, where the company provides the ingredients and the instructions, and the user does the cooking.
It is a much more honest relationship, in a way. You are paying for value delivered upfront rather than being locked into a recurring fee that you might not be fully utilizing. I am curious, Herman, if you were going to build one bespoke tool for yourself right now, something that you currently pay for but would rather own, what would it be?
Oh, definitely a research manager. I use several different tools to track papers, take notes, and organize my thoughts, but none of them work exactly the way my brain does. They all have their own opinions about how information should be structured. I would love to build a tool that can ingest a PDF, extract the key data points, link it to my existing notes, and then allow me to query my entire library using a custom-tuned agent. I have tried to do this with existing tools, but there is always some limitation in the Application Programming Interface or the way they handle data that gets in the way. If I could build it from scratch on top of a solid open-source foundation, it would be a game-changer for my workflow. I would call it the Herman-Brain.
For me, it would be a project management tool that actually understands the context of my work. Most tools are just glorified to-do lists. I want something that can look at my emails, my calendar, and my code repositories, and then automatically prioritize my tasks based on actual deadlines and progress. That is a very personal thing that depends on my specific habits and priorities. A generic Software as a Service can never truly get that right because it doesn't know me. It only knows its own data structures.
And that is the beauty of Daniel's prompt. It is about moving from the generic to the specific. It is about making technology serve the individual, rather than forcing the individual to adapt to the technology. It is a powerful shift, and I think we are only at the very beginning of it. As the models get better and the starters get more robust, the coding gap is going to disappear for almost everyone. We are entering the era of the sovereign user.
It is going to be a fascinating few years. I think we should wrap this up with some practical takeaways for our listeners who might be inspired by Daniel's experience. If you are feeling that Software as a Service fatigue, where do you start? How do you move from being a subscriber to being an architect?
First, I would say, look for the lightbulb moment. Find a small, annoying problem in your life that can be solved with a bit of code. Whether it is a Home Assistant automation like Daniel's or a simple script to organize your files, start small. Use a high-quality model like Claude four or GPT five, and just start a conversation. You do not need to know how to code; you just need to know how to describe your problem in detail. Be precise about what you want the machine to do.
Second, lean on the community. Do not actually start from a blank page. Go to GitHub and search for starters or templates for the type of tool you want to build. There is almost certainly someone who has built a foundation that you can use. Look for projects that are designed to be artificial intelligence friendly—projects that have clear documentation and modular code.
Third, be mindful of the maintenance. If you build it, you own it. Make sure you are using your artificial intelligence agent to document the code and explain how it works, so that when you need to fix it six months from now, you are not starting from scratch. And use the agent to write tests for your code. It is the best way to ensure that a small change today doesn't break everything tomorrow. Think of it as insurance for your bespoke tools.
And finally, think about your data. One of the biggest advantages of this approach is data sovereignty. Design your custom tools to use simple, open data formats like JSON or SQLite databases that you can easily back up and move. The goal is to eliminate vendor lock-in, so don't create your own personal version of it by using obscure formats. Keep your data portable and your logic transparent.
This has been such a great discussion. Daniel, thank you for sending this in. It really pushed us to think about the long-term implications of what we are all seeing in the headlines every day. It is one thing to talk about artificial intelligence in the abstract, but seeing how it is actually changing the daily lives of our friends and listeners is where the real insight happens. It makes the future feel a lot more tangible.
And if you are out there listening and you have had your own lightbulb moment with artificial intelligence, or if you have built something bespoke that changed your workflow, we want to hear about it. Send us a note at show at myweirdprompts dot com. We love hearing about how you are using these tools in the real world to reclaim your digital agency.
And if you are enjoying the show, we would really appreciate it if you could leave us a quick review on your podcast app or on Spotify. It genuinely helps other people find the show and allows us to keep having these deep dives into the weird and wonderful world of artificial intelligence and technology. We are building this community one listener at a time.
You can find all of our past episodes, including the ones we mentioned today about agentic delegation and the deprecation trap, at myweirdprompts dot com. We have a full archive there with show notes and transcripts. You can also subscribe to our RSS feed there if you want to make sure you never miss an episode. We are committed to staying on the cutting edge of these discussions.
We are available on Spotify, Apple Podcasts, and pretty much everywhere else you listen to podcasts. Our music is generated with Suno, which is another great example of the kind of generative tools we have been talking about today. It is a bespoke soundtrack for a bespoke podcast.
Well, I think that is it for this one. I am going to go see if I can use an agent to build a custom tool to manage my podcast research. I think Herman might be onto something there with the Herman-Brain idea. I might call mine the Corn-Kernel.
I will race you to it, Corn. Let's see whose agent is faster. Thanks for listening, everyone. We will see you in the next one.
This has been My Weird Prompts. Thanks for joining us, and we will talk to you soon. Goodbye!
Goodbye!
