0:02 Hey, it's Arvid and this is the I really want to clean up a little bit
0:14 when it comes to VIP coding and software as a service businesses because I think
0:18 there's a lot of confusion, just a lot of hype and a lot of complaints about
0:24 the imminent demise of software as a service businesses and solutions. I
0:29 think it's time that we have a voice out here that's not a doomer. And I know
0:32 there are some people who are more pragmatic about this, but a lot of it
0:38 out there right now is just so apocalyptical. It's crazy. I'm certainly
0:43 not an apologist for the software as a service movement either. Like not all
0:47 about it is great. But giving some realistic expectations of where we are
0:52 and where the field is headed is probably a good idea at this point. A
0:57 quick word from our sponsor, paddle.com. I use Paddle as my merchant of record
1:01 for all my software projects and they take care of all the taxes, currencies,
1:05 all the transactions when they're declined and credit cards when they have
1:08 to be updated so I can just focus on my own customers. If you would rather build
1:13 your product instead of dealing with all of these banks and regulators, check out
1:17 paddle.com as your payment provider and I believe that while software as a
1:27 service may struggle with things like subscription fatigue right now, there's
1:30 a lot of people who don't want to pay one more thing a month or even some
1:35 vibecoded slop solutions are replacing certain purchases that some people might
1:39 have been making in the past. I don't think it's the end and I don't think
1:43 it's necessarily a bad thing for our industry to be where we are right now.
1:48 There are a couple of things that I feel are significantly undervalued when
1:52 people look at AI and what threat it might pose to the software development
1:56 field and the SAS field in particular. So let's talk about that. Most
2:00 importantly, I think people who believe that just because you can go to bolt.new
2:05 or to vzero lovable whatever the tool might be explain what you want and then
2:09 have a vibe coding tool pretty much build whatever its you've just
2:13 explained. I don't think this is the end of all software as a service. But before
2:18 we dive into why this is a false interpretation, maybe we should
2:22 determine what exactly VIP coding is because a lot of software developers see
2:28 AI and they think like vibe coding it's the same thing mostly because the
2:33 consensus in our community is that this is what it means and I don't believe so.
2:39 VIP coding is a version a subset of AI assisted software engineering. let's
2:44 call it an extreme version of it. But not all software created through AI
2:49 assisted engineering is vipcoded. VIP coding is when you really don't care
2:52 about the underlying code at all. You just say what you want, the thing builds
2:56 and it deploys in the background and then it runs, that to me is a vibe coded
3:02 app. But the moment you dive into the code, the moment you understand it, the
3:05 moment you know what the components are underneath the UI or the API, it's not a
3:12 vioded project anymore. It is at most a strongly AI assisted software
3:17 engineering project. So here is my definitatory exercise. The general
3:21 consensus, let's call it the thinkfluencer community on Twitter and
3:27 other social media seems to be that VIP coding is taking our jobs that it's
3:31 making it harder to build simple SAS businesses and monetize them and that
3:34 people can just build these things internally and be perfectly happy with
3:39 those solutions. I believe that that is completely false because it's easy to
3:45 vibe code a project to some degree maybe but it's incredibly hard to v code a
3:51 business if not impossible and I think people who have never built a business
3:54 but who have strong opinions about software engineering mistake one for the
3:59 other here you can build a product with all kinds of features that is not a
4:03 problem but a business and that is the main part of what software as a service
4:08 is service part has significantly different requirements than just
4:12 building a software tool. In fact, I think people are so focused on the
4:16 software aspect of the whole software as a service terminology that they
4:20 completely forget that it was never really about the software. Software as a
4:25 service was always about the service part, always about operating the
4:29 software, the implementation of changes, the adaptation of software to new
4:34 things. The actual value of a software as a service business and being a
4:38 customer of one is that somebody is running and supplying the software, not
4:43 that the software itself contains the value. If you understand that that the
4:48 value of a SAS is in the service, not in the software, then you know that AI
4:52 tooling will only ever, at least in this current situation that we're in, which
4:56 is likely going to be true for another couple years, be good at creating
5:01 software, but it will be very limited at creating and more so maintaining
5:06 businesses. You can vip code a product no problem and it can look and feel like
5:11 an actual human-built software business. But the moment your first customer
5:14 service request comes in or the moment your first integration request comes in
5:19 or somebody has a problem with that data that you might need to adjust in a
5:22 database or built a particular feature. They need a certain file format
5:25 supported and they make that a requirement for their purchase. you're
5:29 going to end up in vibe coding hell because the vibe coded solution operates
5:34 under certain assumptions that come with that system on which it is built. And
5:38 every single feature request that you get will have to change these
5:43 assumptions, but it won't be able to. And everything that your customers do or
5:47 want it to be will have to lead to a re-evaluation of your initial
5:51 assumptions. And these VIP coding systems are not good at this. And that's
5:55 the whole trick here. That's the whole basic truth that a lot of people with
5:59 strong opinions seem to be intentionally forgetting. A software product is the
6:06 outcome of a business effort. A SAS is a way of solving a business problem, a
6:10 challenge. And to be able to comprehend not just how to solve that problem, but
6:14 what that problem is in the first place. Who struggles with it? Who should be
6:18 approached to purchase the solution? Who they should be talking to? How those
6:22 people can be convinced? what alternative solutions they are currently
6:26 using and what they think about the field and certain integrations,
6:31 implementations, features, ideas. All of this takes a lot of founder experience.
6:36 It takes nuance and industry insight. Most software products exist in and come
6:42 from a niche from a very specific subset of all the potential problems and
6:47 solutions in an industry. And if we have learned one thing about the LLM AI
6:50 systems that we use to prompt our way into products now, it's that these tools
6:56 are built for consensus purposes. An LLM can act like it knows a lot about a
7:00 specific thing or it can act as a niche persona, but in the end it will always
7:05 be the consensus engine that we created it to be, right? Any LLM that you task
7:11 with something is trying to be the best for everybody at this particular thing.
7:16 And that just doesn't work in the niche setting. It is very significant that we
7:20 understand this as founders. For a product to be built well, the problem
7:24 and the solution have to be deeply understood and then implemented and then
7:29 permanently adjusted all the time. All these VIP coding tools seem to be like a
7:34 flicker in time. Some of them are great and some of them will fulfill a purpose,
7:38 but they all come with an extremely heavy maintenance burden that they
7:41 themselves cannot solve, that they cannot deliver. And that burden is
7:47 surprisingly bearable when it is created as a consequence of a human project
7:51 because when people build something, they have the strong internal
7:55 understanding of what their codebase and their product is about and what it's
7:59 doing and how it works. But it is extremely frustrating to deal with this
8:03 in a vipcoded project. If you've ever vipcoded anything or even heavily AI
8:08 assisted something that doesn't have proper documentation, then the AI will
8:13 struggle. and not just struggle but fail to remember what it was thinking when it
8:16 was building the thing in the first place while stuff is being built while
8:21 the context window exists you will find that AI tools are very very capable of
8:26 maintaining internal cohesion right they have this understanding of what they're
8:30 doing but the moment that window is gone either by compression or when you end
8:34 your session with lovable or whatever the internal understanding this
8:38 fullyfledged representation of what the vip coded tool was meant to build is
8:43 gone on forever. It literally vanishes into this unreoverable state because
8:47 it's not meant to be understood or persisted or maintained. It is just
8:51 meant to exist for the moment that things are being built and then it's
8:55 gone. And maybe in the future we will have ways to create this fully
8:59 comprehensive internal understanding of a codebase like that I have in my mind
9:03 about my own codebase right now. Maybe an AI can recall it or persist it plus
9:08 everything in the business around it. But right now with the tools we're
9:12 talking about today, we're not there. And I talked about this recently on the
9:15 podcast when I was discussing comprehension debt, a new version of
9:20 technical debt. It's different than technical debt because it's not really
9:25 code related. It is representation related. It's that internal
9:29 understanding that is still for us as a founder, as a developer to maintain. So
9:34 if we use AI tools, we need to persist that kind of into text files that then
9:39 can be read by AI tools and by other humans either using comments or strong
9:44 architectural documentation, whatever it needs. We need to kind of make it more
9:48 accessible to the AI system. And traditionally software engineering used
9:52 to work like this, right? Somebody architects the thing, they write up
9:55 docs, they write up specs, and then they implement it. Doesn't necessarily have
9:59 to be waterfall. It could also be, you know, scrum and you repeat it and you
10:03 have sprints and whatnot. But there's a thinking step, a documentation step, a
10:07 discussion step, and an implementation step. And people fully understood what
10:11 they built. At least you would hope so. And they would write tests because they
10:14 had an understanding of what it should be doing and then implemented it. So you
10:18 could test if a thing is doing what it should be because we have this
10:21 expectation of what things are going to be like. The test is written to see if
10:26 that expectation holds true. But if nobody has that knowledge anymore, if it
10:31 is just vanishing after you use the tool, how can you know if your codebase
10:35 is working or doing what it's supposed to do? If it's small, sure, you can kind
10:40 of test your way through it manually or even have an AI kind of comprehend it on
10:44 the fly by reading it all. But if it's not, if it's bigger, if it's more
10:48 complicated, then all of a sudden you have a problem. a really really big
10:51 problem because you won't be able to know at all what your product actually
10:56 is. Not just what it does but also what it is. You just don't know. And a
11:01 product that is that unreliable because nobody knows what they have created.
11:06 Well, that just makes a business that has high churn, low retention, and
11:10 ultimately it turns into a business that fails. So the phrase isn't SAS is dying
11:16 because of AI. It's more like certain kinds of software engineering are
11:20 changing because of AI, but it has so little to do with the actual potential
11:25 of a software as a service business as a dying concept because people can now
11:29 tell lovable or some other tool that they want a certain thing done in a
11:32 certain way. That's definitely not the case. Think about why people buy
11:36 software as a service products because often it's not that they couldn't build
11:41 something like that themselves. There are people out there who are amazing
11:45 developers buying software for developers that they could have written.
11:49 We often think about buy versus build and a lot of companies have let's call
11:54 it a sales challenge, right? They would rather build it themselves. In many ways
11:59 during sales, it's the conversation where you try to convince people that
12:03 their build cost would be significantly higher than their buy cost. And that's
12:07 definitely true in most cases for most SAS. But people are very well aware that
12:11 they could build any software product, your software product very likely
12:17 because of the mode that you have. That really is just time and energy spent.
12:21 It's really not much more than that for most software as a service businesses.
12:25 At least that's the perception out there, right? And yet they still choose
12:29 to buy it. I think the reason here is the Parto principle. 80% of the way
12:33 there takes 20% of the time, but the remaining 20% of the work takes like 80%
12:39 of the time. And most people who are in successful businesses themselves, you
12:42 know, your buyers hopefully, they understand very well that they don't see
12:48 the 20% that you have figured out over the last couple years that would turn
12:53 into the 80 plus% of work for them. This is why people buy SAS businesses
12:57 products that have been around for a while. They kind of want to see that you
13:01 struggle for a bit, that you did the leg work, and you've truly understood all
13:05 your customer needs. Smart people will buy your product because they're
13:08 perfectly aware of the fact that you've covered all the edge cases, that you've
13:12 encountered every single little thing along the way. You've discovered
13:15 specific, really hard to maintain integrations into systems that they
13:18 don't even know exist yet because they didn't have to dive in as deep as you
13:22 did. That's why people buy your SAS ultimately, not because it's 10% cheaper
13:26 than if they were to build it themselves. People who think like this,
13:30 they are not successful founders or successful builders or they work for
13:34 companies that are so hilariously over capitalized that they can think it and
13:40 still turn a profit. Of course, a lot of people think that they have to build
13:43 everything in-house or otherwise it's a dependency risk that often comes up as
13:47 an argument against it. But building a software tool that other people employ
13:53 half a dozen staff to maintain as a SAS business all in itself clearly has
13:57 opportunity costs that will likely outpace the $200 a month that you might
14:01 be paying for a subscription. I often wonder why people don't seem to be able
14:06 to take that particular leap. Either they pay 200 bucks a month for my tool
14:12 or they pay $20,000 a month to keep the team working on their version of my
14:16 tool. People will always have these weird issues and weird understandings
14:19 when they make their purchasing decisions. But I certainly feel that
14:25 your ideal customer, not the customer that has too much money or too little
14:28 money, your ideal customer, the middle, they understand that they buy your SAS
14:34 for the last 20%. Like your 80%. But they're 20%. Which brings me to the
14:38 whole point of this. If SAS is not dying, but VIP coded internal solutions
14:43 are much easier for people to build. Well, how can we make sure that these
14:48 last 20% the invisible stuff becomes visible? Not so that people can copy it
14:52 more easily into their own internal solutions, but so that it becomes an
14:56 argument for why people should buy our solution instead of building their own.
14:59 And I think this is going to be the ongoing struggle over the next decade or
15:03 so in this particular realm of technology. We've understood that in
15:07 software as a service. We understood that customers aren't buying our
15:10 software. they're buying like peace of mind or they're buying having the thing
15:14 figured out and that having the problem solved. That's big thing we put on our
15:18 landing pages. Now, this might actually swing back into the direction of them
15:21 buying something that even they could kind of make themselves, but it's still
15:25 better because it is built from experience or it's something that would
15:29 be very hard for them to get right, very hard to even approach correctly. So, in
15:34 our self-escription, maybe we don't sell the solution to problems as much
15:38 anymore. or when we do, we show that there's so much complexity to this and
15:43 an interdependency to all of those components that they might not have
15:48 expected. Maybe we are upfront with our buy versus build equations, too. I think
15:51 it's generally a good idea. I've had a couple conversations with people who are
15:55 interested in buying a POTSCAN subscription and they were like, "Yeah,
15:58 we were trying to build this in house, but then we figured out this was super
16:01 expensive." So, I've kind of learned what people have figured out the cost of
16:07 this might be. So instead, next time you talk to one of your customers in a in a
16:11 call or something, instead of waiting for customer to ask you about this,
16:15 well, maybe tell them this would probably cost like $50,000 to $100,000
16:20 to build and at least $10,000 a month to maintain with a service level agreement
16:26 worth of reliability. Or here is the same thing for $2,000 a month as a
16:31 subscription with the same SLA. We have integrations with like 56 different data
16:35 providers to get the data that you need. You just need one login. If you were to
16:40 build this yourself, you would have to make those arrangements with over 50
16:44 different people. That is the stuff we now need to bring to the table. The
16:49 conversation will be shifting. We're now talking to people who are technically
16:53 capable of building their own systems. And maybe we always have, but now it's
16:58 much much easier even for the people who don't have the extreme technical talent
17:02 that the larger companies had in the past. Every company now has someone who
17:07 at least understands AI a little bit and people would try to consider that they
17:12 could possibly build everything. Maybe we just give them a clear background. We
17:16 give insight into how complex it would be to build this and they will benefit
17:20 from us having it already built for them because we have built the last 20%
17:24 already. That's what we're selling to them. But I think it's time to make this
17:29 more apparent, right? It needs to be communicated more clearly. So by coding
17:33 is not killing SAS. It's changing how we need to communicate our value. The value
17:38 prop and the service in software as a service has always been the point. the
17:42 edge cases, integrations, the accumulated wisdom from serving real
17:47 people with their real problems. That's what people are paying for and that's
17:51 what they'll continue to pay for. And if you're building SAS, lean into this.
17:55 Show your work. Make visible what was always invisible before. Because the
17:59 person who can vip code a clone of your product in an afternoon, they still
18:03 cannot vibe code the years of customer conversations and all these hard one
18:08 insights that made your product actually work for people. And that's it for
18:11 today. Thank you for listening to the Boots Founder. You can find me on
18:15 Twitter at Avit Khl. If you're a founder, a PR expert, or marketing
18:19 professional wondering what people are saying about your brand, well, you might
18:23 be missing these conversations. Podscan.fm monitors over 4 million
18:27 podcasts in real time and will alert you when people talk about you. And if you
18:32 are a founder still searching for your next venture, you can go to
18:36 ideas.padscan.fm FM where we identify startup opportunities from hundreds of
18:41 hours of expert conversations every day so you can build what people are asking
18:45 for. Please share this with anybody who needs to turn conversations into their
18:48 competitive advantage because it would really help. Thank you so much for
18:52 listening. Have a wonderful day and
