Over the past year, I have spent a significant amount of time developing custom software for my business using AI-assisted coding tools. 

What started as an effort to solve a few operational problems has evolved into a platform that now handles customer information, online orders, inventory, dispatch, payments, recurring subscriptions, phone records, automated emails, mapping and an AI voice agent. 

The experience has reinforced how much AI has lowered the barrier to building custom business software. But it has also taught me something equally important: being able to build something quickly is very different from being able to build it reliably. 

Most of the difficult lessons have not come from writing the software itself. They have come from choosing technologies, connecting systems, controlling costs, testing critical functions and figuring out what happens when something inevitably goes wrong. 

Here are a few lessons I wish I had known when I started. 

Choose Your Building Blocks Carefully 

Building custom software does not mean building everything from scratch. 

Our application uses existing technologies including Supabase for backend infrastructure, Stripe for payments, Postmark for transactional email, Quo for our phone system, ElevenLabs for our AI voice agent, Twilio for communications infrastructure and Google Maps for location-based services. 

The custom part is how those technologies communicate with one another and how they fit into our specific business workflows. 

That makes choosing the right underlying technologies extremely important. 

One of the first things I now look for is whether a technology has a well-documented and open API, or application programming interface. In simple terms, an API allows one piece of software to communicate with another. 

You also need to understand whether API access is included in your service plan, what limitations exist and what usage could cost as your application grows. 

Something that costs almost nothing during development can become considerably more expensive once thousands of automated requests begin occurring. 

I learned that lesson the hard way. 

My $1,000 Lesson in Guardrails 

While developing our application, we were using the Google Maps API for several location-related functions. 

During testing, I noticed a charge of approximately $100 from Google. I thought it was unusual because I had not expected to substantially exceed the included usage, but I had also been doing significant testing. 

I didn’t think too much about it. 

Then, while I was out to dinner, Google charged my credit card $5,000. 

I immediately knew something was seriously wrong. 

A software bug had generated millions of Google Maps API requests in a relatively short period. Compounding the problem, Google’s billing system had automatically increased my payment threshold from approximately $100 to $5,000. 

Eventually, I discovered that additional quotas and usage restrictions could have been configured to help prevent the problem. 

After weeks of disputing the charges, much of the amount was refunded, but I still ultimately paid approximately $1,000 for API usage resulting from the bug. 

It was an expensive lesson. 

Today, I approach consumption-based services differently. Set billing alerts. Establish quotas. Configure rate limits. Add safeguards inside the application. Start with limits that are overly restrictive and expand them only when necessary. 

When software can automatically generate expenses, assume that something will eventually behave differently than expected and plan accordingly. 

Hopefully, my $1,000 lesson saves someone else from learning the same one. 

Know When to Pivot 

Another lesson I learned is that just because an integration should work does not mean it is worth continuing to fight with it. 

At one point, I spent approximately a week trying to configure automated email functionality through a particular service. Both the coding platform I was using and multiple AI searches suggested it was a good solution. 

Every time something failed, AI confidently provided another troubleshooting step. 

Then another. 

And another. 

Eventually, I decided I had spent enough time trying to force the solution to work and switched to Postmark. 

Within approximately 30 minutes, the functionality I had spent nearly a week troubleshooting was working correctly. It has operated reliably ever since. 

Sometimes the best technical decision is simply knowing when to pivot. 

That experience also reinforced an important limitation of AI-assisted development. AI is an incredibly powerful tool, but it does not replace judgment. 

It can continue providing technically plausible solutions indefinitely. At some point, a person still needs to decide whether continuing down a particular path is worth the time being invested. 

Easy to Build Does Not Mean Ready to Deploy 

Not every software integration carries the same level of risk. 

Stripe is a good example. 

Stripe has excellent technology and a powerful API, but our implementation required much more than simply processing a credit card. 

Our system needed to generate invoices correctly, apply sales tax appropriately to different products and services, establish recurring subscriptions, identify failed or late payments and create reconciliation functions so important payment issues were not overlooked. 

When software begins handling money, the margin for error becomes much smaller. 

That portion of the system received substantially more testing before we were comfortable relying on it operationally. 

The ease with which AI can generate software creates a potential trap: just because something was easy to create does not mean it is ready to deploy. 

The more consequential the function, the more rigorous the testing should be. 

Building an AI Employee Is Different From Building an AI Demo 

Our AI voice agent provided another lesson in the difference between making technology work and making it work reliably in the real world. 

We use ElevenLabs as the foundation of an AI agent that interacts with customers over the phone. 

Creating an AI agent that can hold a basic conversation is now remarkably easy. 

Creating one that can reliably represent a real business is considerably more complicated. 

Our implementation required numerous function calls allowing the agent to interact with our software and approximately 60 pages of instructions explaining how it should handle different customer questions, situations and scenarios. 

Even after that work, the system continues to evolve. 

We review calls, identify situations we did not anticipate and continually refine how the agent responds. 

It works reasonably well today, but I would not consider it finished. In reality, I am not sure business software is ever truly finished. As employees and customers use it, you continually discover opportunities to improve it. 

The Bigger Lesson 

I don’t believe every small business should start replacing its existing software with something custom. Plenty of excellent products already exist, and buying an established solution will often remain the easiest answer. 

But there are increasingly situations where a business has a unique workflow, pays for several disconnected systems or spends significant employee time working around the limitations of its software. 

Those problems have become much more realistic for small businesses to solve. 

The potential cost savings can be meaningful, but I believe customization is the larger opportunity. 

When you control the software layer of your business, you can identify an operational problem and build a solution around it. You can connect information that previously lived in separate systems and automate repetitive processes that once required someone to manually move information from one place to another. 

That has been the most interesting part of this experience for me. 

I initially approached software development simply as a way to solve problems within my own company. As the system has grown, I have become increasingly interested in the process itself: understanding how a business operates, identifying friction and figuring out how technology can eliminate it. 

AI is also creating an interesting bridge between people who understand business problems and the people traditionally responsible for building software. Someone with deep knowledge of an industry can now participate much more directly in creating the technology that solves those problems. 

AI has made the actual building considerably more accessible, but it has not eliminated the need for judgment, testing or problem-solving. 

Read more at badgerboxstorage.com.