Summary
Stop overpaying for rigid software. Learn how to build AI internal tools for your ecommerce business to save money and increase efficiency.
Stephen Brown and Stacy Walker from Ledger Gurus join The Ecommerce Finance Podcast to break down why expensive, off-the-shelf software is often the wrong choice for growing brands. Instead of relying on limited platforms that force you to adapt your workflow, they explain how custom AI internal tools can provide the exact functionality your team needs to scale.
This conversation focuses on the hidden costs associated with choosing the wrong ecommerce software solutions. You will learn how to evaluate when it makes sense to build versus buy, and how simple AI integrations can solve specific accounting or operational bottlenecks without the massive expense of enterprise-level subscriptions.
Subscribe for weekly ecommerce finance breakdowns, and comment below if you want to see a walkthrough of specific AI tools for your accounting stack.
Takeaways
- Is It Cheaper to Build Software or Buy SaaS?
- The Hidden Maintenance Costs of Custom Software
- What Is the Builder Conundrum and Why It Matters
- Security Risks Every Vibe Coder Ignores
- Compliance Rules That Can Trigger a Lawsuit
- When Building Your Own Software Actually Makes Sense
- The Build vs. Buy Decision Framework
- How Critical Software Failures Impact Your Business
- Why AI-Native Vendors Are the Next Generation of Software
What We Cover:
- 00:00 The Rise of AI and Vibe Coding
- 02:38 The Hidden Costs of Building Software
- 05:12 The Builder Conundrum
- 08:03 Security and Compliance Considerations
- 11:06 When to Build vs. Buy Software
- 13:43 The Pros and Cons of Vibe Coding
- 16:17 The Future of Software Development
- 19:20 Final Thoughts on Building Software
Guest Information
Stacy Walker is the Director of Growth at LedgerGurus, where she leads the sales and growth strategy for one of the ecommerce industry’s most specialized accounting firms. With a background that spans business development, sales, and marketing, Stacy brings a front-line perspective on what ecommerce brands are actually dealing with, having spent years talking directly with seven and eight-figure sellers navigating everything from scaling challenges to profitability gaps.
Work with LedgerGurus
Building your own tools versus sticking with SaaS is a tough call, and this episode gives you a framework to decide with confidence. If you need help with ecommerce accounting, LedgerGurus can help.
Transcript
Stephen Brown (00:00) AI has made it possible for a non-developer to spin up a functional internal tool in an afternoon. So why pay hundreds of dollars a month for software that only does 80% of what you need? It can really mess up an ecommerce business. Welcome to The Ecommerce Finance Podcast. I’m Stephen Brown with LedgerGurus. Today I have Stacy Walker, Director of Growth here at LedgerGurus, and we’re going to discuss build or buy: is it cheaper to vibe code with AI or use SaaS? Stacy, welcome back.
Stacy Walker (00:35) Thanks for having me, Stephen.
Stephen Brown (00:37) In our previous episode, we talked a little bit about AI costs. And along that line, I want to talk about vibe coding, because it seems like everybody’s talking about it, and there’s all this conversation around the death of software. We’re all just going to build our own tools, and all the SaaS companies can go away, and we’ll just send all that money to OpenAI and Anthropic. Problem solved.
Stacy Walker (00:58) Yeah, I wanna see how that works out.
Stephen Brown (01:02) Me too. So I want to explore this, because I think ecommerce businesses are very technically savvy. They’re using a lot of technology. And I’m hearing about a lot of operators who are vibe coding apps and believing that it’s the answer to all their problems. What do you think, Stacy? Are you gonna go vibe code all your stack? Get rid of your CRM and just build your own?
Stacy Walker (01:24) No. I just don’t see a world where it’s gonna work. I just don’t. There’s too many things that change too often. I don’t see how it’s gonna happen. Talk me out of it, though. Maybe I’m wrong.
Stephen Brown (01:41) Well, let’s talk to the implications of building software, and maybe end up on where it might make sense and where it doesn’t. As a little background, I spent 20 years in enterprise software, so I feel like I can talk about this from experience. I worked for software companies from 1997 to 2016, including a Fortune 500 and a couple of publicly traded companies.
Stacy Walker (01:51) Okay, I like it.
Stephen Brown (02:10) So I’ve been around building software for a long time. And obviously this changes in the age of AI. I was not a great software developer. I got into other aspects of the software industry. But I look at AI tools and I’m like, hey, I might have been a half-decent software developer, because I’m pretty good with the logic and how things should work. But I always struggled with the syntax, and which function do I use for this, and how to use it. It was not my forte. And so I can see why people are like, “I can do it.” And I’ve built some stuff now with AI tools, and I’m like, man, I can build things, and it’s awesome. But it’s easier said than done.
Stacy Walker (02:53) Yeah, for real. Totally. So tell me what you see the most with people vibe coding. I’m curious what you’re seeing in your role, and then I’ll tell you what I’m seeing in mine.
Stephen Brown (03:06) I’m hearing a lot of stuff. I’m hearing people say, “I’m gonna build my own inventory management system.” Or they’re saying, “I’m gonna go replace that Shopify plugin.” And that’s mostly the ecommerce space. I haven’t heard anybody say they’re gonna replace Shopify or a Klaviyo, one of these big systems. But I would consider an inventory management system a pretty serious system. And I know in the accounting space,
Stacy Walker (03:12) That’s what I’m saying.
Stephen Brown (03:35) there are conversations around, “Could I vibe code my own accounting software, because all these accounting software vendors are terrible, and I’m just gonna build my own?” And that’s what caused me to want to have this conversation, because I’m like, be careful. You might not know what you’re getting into.
Stacy Walker (03:52) Yeah. So what do you think the implications are? I’m thinking about the inventory management systems that people are trying to vibe code. But you brought up something I’m curious about. You said they’re dropping plugins on Shopify and building their own. So are there security issues with that?
Stephen Brown (04:12) You know, there are a number of issues, and maybe we should walk through those. Security is one of them.
Stacy Walker (04:16) Okay, let’s do it.
Stephen Brown (04:18) So I would do a callback to our previous episode first. Depending on what you’re building and how much you’re using AI in your software, one of the things you gotta think about is tokens and subscriptions and how much consumption that is. What is the cost of building that software? As you and I talked about previously, there are hard costs going into AI software that you and I believe are going to become a bigger issue. So first, how much is it going to cost to build that software? Right now it’s not too expensive, but I think as you’re getting into Claude Code and the other tools, those costs are starting to become usage-based. And so you’ve got to think about how much it’s gonna actually cost to build that.
Stacy Walker (05:06) Yeah. And how much is it gonna cost to keep it running, right? What happens when your process changes?
Stephen Brown (05:12) That’s the second point, right? A lot of times, people think about software and they’re like, “I built this cool app.” But software is not a one-and-done thing. It’s a living, breathing thing that you’re constantly changing. You’ll be like, “I need to fix this,” or, “I need this new feature.” It’s constantly evolving. So it’s more than that upfront cost. There’s the ongoing maintenance cost of software, which is why there are subscription fees. Even before that, you had maintenance fees on software, because the vendors were constantly fixing and updating it. You need to think about the ongoing costs of updating that software.
Stacy Walker (05:55) So I think about some of the software we know our clients are using. Think about a sales tax software, where people say, “I just set it and forget it. I don’t think about it again.” But we know that things break. There are very few things — I can’t think of anything in our ecosystem — that you can set and forget as far as software’s concerned. So who is so confident with their vibe coding that they feel like they can set it and forget it?
Stephen Brown (06:28) Yeah, I don’t know. I would hope people aren’t. And that’s the first consideration. APIs change if you’re connecting to Shopify or Amazon or whatever platform. Most software doesn’t live in isolation anymore; it’s usually connecting to other systems. So you’ve got to consider that APIs are gonna change. There are gonna be features you’re gonna wanna add to your tool. And so I think you have to think a little bit about how much you’re willing to invest to maintain this software.
Stacy Walker (06:43) Yeah, I agree.
Stephen Brown (06:59) Along that line, I think there’s another thing, and that’s the builder conundrum.
Stacy Walker (07:04) What is the builder conundrum?
Stephen Brown (07:06) Not everybody’s gonna vibe code. Have you vibe coded anything, Stacy? Shame on you. How do you even wake up in the morning and look at yourself in the mirror?
Stacy Walker (07:09) No, definitely not. I have other people that do it. I don’t have to.
Stephen Brown (07:19) But I don’t know, when you go to conferences or listen to any podcast, you feel like, “My gosh, I should be vibe coding.” Everybody seems to be talking about this.
Stacy Walker (07:27) No, because I don’t feel like it can be successful long term. And so I’m not putting my efforts there.
Stephen Brown (07:34) Maybe as a builder, somebody who’s built software, I feel this guilt, like I’m not vibe coding enough. I have the skills. Okay, I have vibe coding guilt. I’m like, “I should be building more software. This is what I did for twenty years. Why am I not building more software?” Not everybody’s gonna build. There’s a skill set to building software, whether you’re using old-school integrated development environments, no-code applications — there’s an understanding of underlying logic and architectures that you have to develop for yourself. And so I think this idea that everybody’s going to be a software builder is a little bit extreme. Now, I think it’ll be easier to create no-code applications. But full-blown applications that are integrating with an API, have a back-end database, a system of record — that’s not going to be everybody.
So let’s say you go out and decide to build one of those things, or you have somebody on your team who is the builder. That person is now the maintainer of the software. What happens if that person decides to leave? Who’s going to maintain that critical software you built? Or if you’re the owner, like, “I’m just going to do it myself,” are you now a slave to that software? You’ve got to constantly update it. And so the builder conundrum is something where — custom software’s been around forever. It’s not like companies couldn’t build their own software; it’s just gotten a lot easier. But the builder conundrum doesn’t go away. You’re still gonna need the person, the expert who understands that software, to maintain it, or bring in other people to maintain it. So that’s something people have to consider.
Stacy Walker (09:26) Does the vibe coded software always work?
Stephen Brown (09:28) Software breaks. It breaks all the time. When I was building software, we were constantly updating it. You’d find bugs. Like I said, things would change. Software is never static. And so you’ve got to be constantly updating it. Even if you’re not adding features, there’s something you’ve got to do to keep it maintained and up to date.
Stacy Walker (09:50) And does the builder always even know what they need to do? Can they always tell, if something’s not working, why it’s not working?
Stephen Brown (09:57) Hopefully. I mean, in the age of AI, I’m hopeful that troubleshooting is easier. I know when I’ve built some stuff, it’s way easier, and you can be like, “Hey, this isn’t working.” But I find that because I have a software background, I know how to talk using software terms. I can very much say, “Hey, do this thing.” I think with no-code software,
Stacy Walker (10:04) Okay.
Stephen Brown (10:25) that’s a little bit different, because you’re building on top of no-code platforms. Obviously, you can do things in Claude, and it’s probably gonna get better. But again, you’re gonna have to understand how to build things in Claude, and how those artifacts work, and whatnot — or whatever your AI tool of choice is. So that’s problem number one: the builder conundrum. You’re gonna have to have somebody maintain it, and what happens if that somebody leaves?
Stacy Walker (10:29) Yeah. Okay, that’s interesting.
Stephen Brown (10:55) Versus a SaaS tool, where that’s their problem to solve. To me, it’s the analogy of outsourced accounting, which we do, versus in-house, right? With outsourced, if somebody leaves us, it’s our problem to solve. They’re paying us to solve a problem. And if the person who was supporting our customer leaves, we have to figure out a solution. Same thing with custom-grown software. You have to figure out how to maintain that.
Stacy Walker (10:55) Right.
Stephen Brown (11:24) The software vendors will do that for you.
Stacy Walker (11:27) And if you’re building your own, you have to be able to know exactly what you want the software to do, and you have to document exactly what the requirements are, right? Whereas if it’s a SaaS product, they’re doing all of that. So a lot of the heavy lifting, I would say, falls on them. Something breaks, you’re going to them.
Stephen Brown (11:50) Yeah. Now, the pro to vibe coding is you can do whatever you want. You don’t have to wait for the software vendor to build something, because there are always gaps. You’re always like, “I really would like it to do this.” Maybe you build a relationship with the vendor, and you’re able to get your request onto their backlog and onto their roadmap, and they’ll build it for you. The upside of vibe coding is you get to build whatever you want, whenever you want. You can just go ahead and build. So that’s a pro to building your own: you get to control what’s in the product, and if you need something, you can go build it.
Stacy Walker (12:27) And if you go build it, hopefully you have your process so well aligned that you don’t miss any steps in the building.
Stephen Brown (12:34) Yeah. I mean, ideally, you’re either gonna be good at building vibe coded software or you’re not, and you’ll know that pretty quickly. I think where it’s gonna get tricky is those who can build something but aren’t thinking about some of the other issues that go into software.
Stacy Walker (12:51) So, like security.
Stephen Brown (12:52) Let’s talk about security, right? I actually worked on not just software, but information security software. There are a lot of vulnerabilities in software. There’s a thesis that vibe coded software, that AI, is gonna build perfect software. I don’t know if I believe that. I think it’ll build better, but I still think there are gonna be potential bugs and security vulnerabilities that get created and need to be remediated. So, how do you know that your software is secure? The other thing is, when you’re interacting with other systems, you have to think about authentication, you have to think about how you’re using API keys, and you have to think about what type of data is in your system. Is it secure? Is this information that contains customer data, or is it software that’s just solving a generic problem where the data’s not really sensitive? Where is that software hosted? How exposed is it? Can other people get to it? I highly doubt people are gonna vibe code desktop software; they’re probably gonna be vibe coding SaaS software. So what are the
Stacy Walker (14:08) Yeah.
Stephen Brown (14:10) controls and the security around that software? These are all things we had to think about in enterprise software. Are you gonna think about it? Or are you just gonna chase features?
Stacy Walker (14:23) Yeah, exactly. So, Stephen, what about compliance? If I’m vibe coding something, what should I be considering?
Stephen Brown (14:30) There are a lot of regulations around sensitive information. This is hand in hand with security, but if you’re handling credit cards or customer records, there are all sorts of things you’re supposed to be compliant with, and you may not even realize those things. A good software company — hopefully your vendors are good — they’re gonna think about those things. But you could find yourself, especially if your software was not handling that information correctly, with a big lawsuit, or regulators that come down and cause all sorts of nightmares for you. So that’s the other thing around compliance: there are all sorts of laws around the handling of information that you need to be considering. So that’s a big flag: what’s in your software? Are you handling any sort of customer information or payment information? Huge flag. That stuff has to be really handled right.
Stacy Walker (15:37) Must be locked down, for sure. So do you feel like there’s ever a time when vibe coding, building your own system, makes sense?
Stephen Brown (15:46) I think so. Let’s take the example of Shopify plugins. Some of these plugins are just basic features that nobody else is solving. Really, they should just be part of a bigger piece of software, but they haven’t been absorbed into a bigger piece of software, or the bigger software suites haven’t done that. So that could be a good example. Another example could be, “I’ve got a problem that nobody’s solving.” We have built some software here at LedgerGurus where we just couldn’t find an answer. I spent literally some years trying to find solutions, and I just couldn’t find it. So finally we just decided to build our own.
Stacy Walker (16:27) Yeah.
Stephen Brown (16:29) I think if the scope is narrow and somewhat stable, it makes sense. If you’re building something complex, something like a system of record, I would be cautious, because you may not realize what you’re getting into. The other thing I think about is: are you a software company, or are you a seller of widgets, right?
Stacy Walker (16:55) Yeah.
Stephen Brown (16:56) And I do think you’re gonna see some people have success building their own software. But I’ll give you a good example. You and I were at a conference a little while ago, and one of the vendors was on a panel about AI software. He had a lot of developers. He was talking about how they decided to replace a tool with something they built internally, and he was like, “It ended up being more expensive.”
Stacy Walker (17:09) Oh wow, really?
Stephen Brown (17:24) He’s like, “Yeah.” Because I think when you get into tokens, and the cost of building, and the cost of maintaining — he didn’t really get into the details, but I think it’s all those things that I’m talking about. That stuff adds up. And so I think you have to be really thoughtful, especially when you’re trying to replace software: is it really cheaper?
Stacy Walker (17:25) Yeah.
Stephen Brown (17:51) Now, if nobody’s solving that problem, the answer might be that it makes sense. But if you’re like, “Hey, I’m gonna do it better than that XYZ Shopify plugin,” maybe you will. Or maybe that was a really good price that you didn’t realize. And heaven forbid, don’t go try to build your own Shopify or your own Klaviyo. You’re asking for trouble.
Stacy Walker (18:05) Yeah, without a doubt. I was talking to somebody a couple of days ago at another conference, and he mentioned that he had vibe coded a whole program for his firm, and he did it solely to think through every single piece of the process. Then he handed that over to his developer and said, “This is exactly what I need it to do.” Because then they could think of everything he hadn’t thought of, right? The security, the compliance, all of those things. And he felt like it was a great use of his time, because he knew exactly what he wanted once he had gone through that process. What are your thoughts on that?
Stephen Brown (18:50) Again, I think it could make sense, if there’s nothing out there. So part of what I think about is: is the tool internal? Does no solution exist? Do you have that technical continuity — so whoever’s building it is gonna be around, or you can easily replace them? Is the scope somewhat narrow? And the cost differential — all the costs. This is where we think, as accountants and CFOs,
Stacy Walker (18:56) Yeah.
Stephen Brown (19:21) not just about that subscription cost. You’re like, “Well, I don’t have to pay that subscription.” Yeah, but maybe you’re paying a dude that’s way more per month to maintain that software. Or a dudette, right? You don’t want to be gender biased. Anybody could build that. On the other side, there are some flags where I would just be like, you really should consider a SaaS tool.
Stacy Walker (19:30) Okay, so let’s talk about that. I am naturally a DIYer. I enjoy the process. But there are things where I’m like, it’s not worth the opportunity cost, it’s not worth my time, it’s not worth my money to try and figure this out. This is a job for a professional. So when do you think that’s the case with this?
Stephen Brown (19:50) So, coming from our world, I would say, number one, is it touching anything money — any sort of credit card records? I’d probably say don’t do that. If it’s customer-facing, you’d better be darn sure about its reliability and its usability. If there are any sort of compliance things related to the software — data privacy, payments, going back to that earlier point — and if you don’t have confidence in its maintainability, either by you or the person that’s building it, then be cautious. And again, if you’re just trying to replace a SaaS software, I’d really look closely and be like, who’s likely to be here in five years? Them, or me, or the builder who’s building this software? Can I build as quickly as they can build? And as you go down the path of adding more capabilities, who’s gonna do a better job?
Stacy Walker (21:15) That’s a really good thing to think about. I like that. So if you had to build a framework for deciding pros and cons, walk us through what that would look like. What would the matrix look like for that?
Stephen Brown (21:29) Okay, this will kind of be a recap of what I just talked about. Does it touch sensitive data? Buy. Is there SaaS software that’s cheaper than what you’re going to do? Buy. What is the technical continuity? Now, that can be an interesting thing, because a lot of startups might not be here in five years. So if you have a lot of confidence in your builder being around, maybe build. How much is it going to change? How much support is it gonna need? Is it a simple tool that’s not gonna need a lot of support? I could argue build. If there’s a ton of complexity, if I’m building on APIs that are constantly changing, you may want to buy. How core is this to your operation? Now here’s the other one, and this is a really good one: if this software goes down, what does that do to your business? And
Stacy Walker (22:24) No, that’s a really good point.
Stephen Brown (22:26) who’s picking up the call from the team? That should give some pause about how critical it is. Now, this is something you can consider as you’re working with software vendors. Like, how good is their support? This is something I’d always look at with a software vendor: what’s their reputation for support? How do you get support? Because if it’s really critical to your business, you want to be able to connect with them. Now, unfortunately, the software industry has moved away from phone-based support, because it’s expensive, toward a lot of chat agents. But still, is there some way to get a hold of somebody and escalate? And the more critical the software, the more timely the support that’s needed. So that’s what I’d think about: what is the criticality of this software? If it stops working, how does that impact the business? If this stops orders and sales,
Stacy Walker (22:58) Yeah.
Stephen Brown (23:23) and let’s say you’ve got Joe Developer. He’s on board, you’ve locked him up, you’ve got a really good salary. Joe’s on vacation. Maybe he’s on a backpacking trip. Nobody can reach him. What happens then? So I don’t know, I might be coming off as a little bit pessimistic toward vibe coding solutions, probably because I’ve built a crapload of software and I’ve dealt with all these issues. That said, we have built tools internally here at LedgerGurus. There’s this nervousness that I have, but a lot of those tools I’m building because nobody else is building those things. I’ve seen a need that
Stacy Walker (23:51) Yeah.
Stephen Brown (24:07) nobody else is solving. And so I’ve been okay going down that path. So as people are going down the path of build versus buy, I think they need to think about all these considerations, because you can easily make a bad decision. Now, do you wanna hear what I think’s gonna happen in the next few years?
Stacy Walker (24:30) I always wanna hear what you think’s gonna happen.
Stephen Brown (24:33) I think you’re gonna see a lot of people that vibe code apps and will probably reverse course and go back to paid software.
Stacy Walker (24:43) I agree.
Stephen Brown (24:44) Now, the bigger thing I think people should be thinking about is not, “Should I be building my own or buying?” I think the question now is, “What am I buying?” I think the vendors we’re using today are either gonna have to level up, or you’re gonna see a new class of software vendors emerge that are AI-native, that are able to build faster, that are able to use AI features more effectively. And that’s probably the next generation of software. In my career, I’ve seen software evolution. When I started — if I go way back, before I even got into working in software — you and I started on DOS and command-line software. Then it moved to Windows, then we moved to internet-based software, and then
Stacy Walker (25:30) Yeah.
Stephen Brown (25:41) I just had a brain fart. And then we moved to mobile, right? Now I not only need to be able to do my software from a browser, but I also want to be able to do it from a mobile app. And I need to build it — the software’s the same. And now we’re in this age of AI, where it’s AI features and capabilities. And each evolution, you’ll see a lot of changes in who the dominant players are. It’s often the newer players of software that overtake the older ones. It’s the classic innovator’s dilemma. Occasionally you’ll see legacy vendors that are able to make the leap. That’s super hard to do. So in my mind, I would be advising: don’t spend as much time thinking about what you can build by yourself, and think about what vendors are building —
Stacy Walker (26:20) Yeah.
Stephen Brown (26:40) the next generation of software — and look at them.
Stacy Walker (26:44) That’s great. I love that. So, Stephen, what are your final words of advice?
Stephen Brown (26:48) I would just go through that framework. I’d be cautious about what you’re building. I would be very much looking at next-generation software, keeping a close eye on that, building where there are gaps, making sure that it’s supportable and sustainable. Go ahead and hate me — I know all the talking heads are telling you to build your own software. I would just say, as somebody who spent two decades in software, who lived through the web, the mobile, and the cloud revolution: there’s a lot to consider. I won’t say don’t do it. Just do it wisely.
Stacy Walker (27:27) All right. You heard it here, folks.
Stephen Brown (27:30) All right, we’ll call that a wrap. Thanks for joining me again, Stacy.
Stacy Walker (27:33) Thanks, Stephen.