AI can help you build useful software much faster than it did two years ago. Before replacing a system your business depends on, though, it’s worth asking what you’re agreeing to. Generating an invoice is a feature. Generating the right invoice next month, after a tax rate changed, a customer upgraded mid-cycle, and your gateway retired the API you integrated against, is an ongoing job. The code working today is where that job starts, not where it ends.
A quick definition, because the term gets stretched. By vibe coding we mean accepting generated code because it appears to work, without understanding and verifying how it behaves. Using AI inside a disciplined development process, with review, tests, and someone who can explain the result, is a different thing. We do that every day, as do software engineers at companies of all sizes. The problem isn’t the tool. The problem is taking responsibility for software you can’t adequately evaluate or maintain.
What are you agreeing to?
The usual advice draws the line by size: vibe code the small stuff, be careful with the big stuff. That’s not a reliable boundary. A personal file renaming script can destroy files you cared about. A three person internal tool can expose every customer’s data. Rebuilding the code in an afternoon doesn’t undo what the previous version did.
A better test is about consequences and responsibility. Before you build something and put it in front of real users, ask:
- What can this software change, expose, or destroy?
- Can we detect mistakes before customers are affected?
- Can we reverse the consequences when we don’t?
- Who will maintain it and handle incidents, at 2 a.m., in three years?
- Does building it ourselves create an advantage for our business?
A todo list or a prototype answers those questions comfortably. A billing system does not. It touches every dollar and every customer record you have, mistakes are often invisible until a customer notices, some of them can’t be reversed, and billing is almost never the thing that makes your business different from the one next door.
Why billing is harder than it looks
Follow one scenario. A customer on a $10 monthly hosting plan, paid on the 1st, upgrades to the $25 plan on the 18th.
How much do you charge today? The unused days on the old plan are worth something, so you credit them. Divided by 30, or by the days in this month? February gives a different answer than March for the same plan. Then you charge for the remaining days on the new plan, using the same rule, or the customer notices the two don’t match. The original order used a 20% off coupon. Does it apply to the upgrade? For the first term only, or for the rest of the customer’s life?
Downgrades, upgrades, prorated invoices, credits. Tax rules. Invoice numbering. Fraud detection. Support. There are hundreds, if not thousands of considerations, and none of them are exotic.
The team at Lago, who build billing infrastructure for a living, call it “edge case hell”, and their point is that these cases overlap. Handling one changes the right answer for others.
An AI tool can write a plausible first draft of all of it. What it can’t give you is the list of things that actually happen, because that list is learned from customers, one ticket at a time. If you build your own, you’ll be learning it alone, and the lessons can be costly.
The security defaults AI tends to leave out
The generated code works, at first glance. That’s what makes the problem easy to miss. It works and quietly omits the thing a careful engineer would have added without being asked.
Veracode’s 2026 GenAI Code Security Report found that roughly 44% of tested AI code-generation tasks produced code with a known security vulnerability. That’s a benchmark result, not a claim that nearly half of all AI-written software is insecure. But it illustrates why working output still needs security review.
The consequences aren’t theoretical. In February 2026, Wiz reported that Moltbook, a platform its founder said was built entirely with AI, exposed authentication tokens, email addresses, and private messages through a misconfigured database. The application worked, but the access controls protecting its data were missing.
AI can help you build useful software. It doesn’t remove the responsibility to understand what that software can access, change, or expose, especially when it handles sensitive information, customer payments, and integrates with many other systems.
Day one is the cheap part
Getting the thing working is actually a small fraction of the total cost. The rest is keeping it working while everything around it moves:
- Your payment gateway deprecates an API version. Your registrar changes its EPP behavior. cPanel, Plesk, or Proxmox make breaking changes.
- PHP goes end-of-life, and the upgrade breaks a dependency you didn’t know you had.
- A payment comes through, but for some reason isn’t recorded internally.
- A customer reports that their total is off by a cent, but only in February on a leap year.
- Something fails at 2 a.m. on a Saturday, and only you can look at it.
If the code was accepted without being understood, each of these becomes a new round of prompting against a codebase nobody can explain. Quick fixes accumulate. Logic gets duplicated because the earlier version wasn’t found. Without tests, you can’t tell whether the fix for February broke March. That isn’t an inevitable property of using AI. It’s the predictable result of skipping the parts of engineering that make software maintainable, which is what vibe coding, by our definition, means.
You are the vendor
When commercial billing software breaks, you open a ticket, search the docs, ask the community, or read the advisory. When your own system breaks, you are the vendor. You are support, security response, software engineering, and the person on call. Those jobs don’t go away because the code was cheap to write.
And one day, someone else inherits it. A new hire, a business partner, or the company that buys yours. “Custom billing system, built from prompts, no documentation, no tests” is a line item in due diligence, and not one that raises your valuation.
The licensing cost you’d save is only one part of the calculation. Your time has a cost too, and one real incident can wipe out years of savings. The saving isn’t free. It’s a loan against your future attention, and the interest rate is terrible. We need to be selective with what we decide to build ourselves.
What to look for in a billing platform
None of this means buying is automatically right. Commercial software has bugs, some vendors have poor support, and a platform can carry its own maintenance burden. Buying makes sense when a suitable vendor takes on enough of the ongoing work to justify the cost.
That applies to people selling vibe-coded software too. If the seller doesn’t understand or verify the generated code, paying them doesn’t get you the engineering expertise you should expect. You may end up depending on someone whose only way to diagnose a billing error or fix a security flaw is another round of prompting. The same responsibility exists whether you generate the code yourself or buy it from someone else. Ask who understands it, how it’s tested, and who can maintain it when something goes wrong.
Whatever you evaluate, including Blesta, look for:
- The workflows and integrations you actually need, not a long feature list that lacks what’s most important to you.
- A visible maintenance history and a clear security response process. How often does it ship? What happens when a vulnerability is found, and do they tell you?
- Extendable code and open examples so you can customize without editing core files and your changes survive upgrades.
- Access to the data and a workable migration path, both in and out. You should be able to leave. Some vendors lock you in.
- Clear and reasonable costs for licensing, updates, and support.
Build on it, with your eyes open
Here’s where AI-assisted development genuinely earns its keep. A maintained platform handles the common work: invoicing, proration, taxes, gateways, dunning, orders, provisioning, the client area, the audit trail. What’s left is the part that’s actually specific to your business, and that part is usually small, well defined, and a good fit for building with AI help.
Still, you should apply the same consequence test to your extensions that you applied to the whole system. A custom report, a dashboard, or a notification to your team chat is a good place to start. If it’s wrong, you’ll notice, and nothing irreversible happens. An extension that charges cards, changes invoices, or provisions and suspends services needs review and testing proportional to those consequences, whoever or whatever wrote the first draft. Building on a maintained platform reduces how much you own, but it doesn’t make your custom code automatically safe.
Readable core code is a massive help here, because you and your AI assistant can inspect what a base class actually does instead of guessing from documentation. It still doesn’t replace verifying your assumptions against a test install before real customers hit the code.
How Blesta fits
This is how we’ve built Blesta. The core ships as readable PHP, all but six files, so you and your AI agent can see how things actually work. Every public model method is exposed through the REST API, an event system lets you react to things happening in the core without modifying it, and modules, gateways, and plugins have real base classes to build against. The point is that you shouldn’t have to fork the core to get the behavior you need.
Build an integration with your internal tools, a plugin for a workflow unique to your business, or a custom client template that matches your brand. These are ways to make Blesta your own without taking on development and maintenance of an entire billing system. We maintain the core. You build what makes it yours.
For AI-assisted work specifically, the free Extension Dev Kit on GitHub is a Claude Code skill (plain markdown, so it works in any AI tool) distilled from the v6 base classes. It teaches the model how a Blesta module, gateway, or plugin is structured, what to implement, and what the UI expects. It helps you build on top of Blesta the right way from the start.
Where to start
Write down what your current billing system cannot do. Separate those gaps from the billing functions it already handles correctly. Then look for a maintained platform that covers the common work and gives you room to build the missing pieces, rather than rebuilding the whole thing to fill the gaps. Future you will thank you.
If you want to run that exercise against Blesta, install the 30-day trial on a server of your own, import your data, and point your AI assistant at the Dev Kit. Build the missing pieces on top of the core, not underneath it.