Blueprint Software
Introduction
I have been thinking a lot about vibe coding, partly because I use AI to build software every day and partly because it’s becoming difficult to have a conversation about software without somebody claiming that the whole job has been automated.
The tools are impressive. Someone without much development experience can describe an idea and end up with an application that has user accounts, forms, a database, reports, and an interface that looks professional. It may only take a few hours. That’s a useful thing that did not really exist before, at least not in a form this accessible.
I think this is mostly good. A person can test an idea without spending a bunch of money. An employee can make a small tool that saves them time. A business can learn whether a workflow makes sense before committing to a larger project. I’m not interested in telling people they need a professional software team every time they want to put a form in front of a database.
The problem is that an application can look finished much earlier than it is ready for a business to depend on. The interface works, the demo goes well, and everyone starts treating it like the hard work must be over. In my experience, that is usually when the harder work is starting.
A Prototype Can Be a Prototype
There is nothing wrong with building a rough application. If it’s a personal tool, a short-term experiment, a calculator, or something with no sensitive data and very little consequence when it fails, go build it. Sometimes refreshing the page and trying again is a perfectly reasonable recovery plan.
I would be more careful once employees are planning their day around it, customers are entering personal information, money is passing through it, or the business no longer has another way to perform the work. At that point the application has become part of the operation whether anyone deliberately made that decision or not.
A demo normally proves one path. Enter the expected information, click the button once, and get the expected result. Actual users do all kinds of reasonable and unreasonable things. They click twice, enter incomplete information, lose their connection, open the same record in multiple tabs, and come back six months later asking why a number changed.
Payments are a good example. A payment provider may accept a charge while the application times out waiting for the response. Retrying could charge the customer twice, but assuming the payment failed could leave the order unpaid. The application needs to understand that weird middle state and recover from it. A generated checkout screen can look completely done without handling any of this.
Of course, software written by professional developers can fail too. I’ve written plenty of bugs myself. The difference I care about is whether someone has thought about the failure, limited what it can damage, tested the behavior, and made it possible to figure out what happened afterward.
The Security Problem
Security is one of the easiest things to underestimate because most of it isn’t visible during a demo. A login page does not prove that permissions work. An application can require every user to sign in and still let one customer view another customer’s data by changing an ID in the URL. Hiding an admin button is also not the same as preventing someone from calling the operation behind it. “Security through obscurity is absurdity” so I’ve heard it go.
Personally identifiable information tends to spread once a system has it. Names and email addresses show up in logs. Uploaded documents get copied into test environments. Employees export spreadsheets. Backups exist somewhere, although nobody is completely sure where or whether they can be restored. Encryption is important, but it cannot help when the application decrypts a record and gives it to the wrong authenticated user.
There are already some fairly awful public examples. Researchers reviewing Moltbook, a vibe-coded social network, found roughly 4.75 million exposed records including authentication tokens, email addresses, and private messages. The database configuration also allowed account impersonation and changes to the live site. It wasn’t an obscure cryptography problem. A database access policy was missing.
The other example I keep coming back to is Replit’s agent deleting a production database during a code freeze. The agent had been explicitly told not to make changes and deleted thousands of live records anyway. Replit responded by separating development databases from production, which is the correct boundary, but it would obviously have been better for that boundary to exist before the incident.
I don’t think these examples mean vibe-coded software is automatically insecure. They mean the person building it still needs to understand database permissions, production access, backups, logging, dependencies, and all of the other things the generated interface does not explain. If nobody involved knows to ask about those things, the application can move into production with everyone assuming the tool handled them.
Sometimes it did. Sometimes it absolutely did not.
What Are You Paying For?
Clients aren’t paying a software company because developers can type code. That was already a weak explanation of the job before AI, and it’s a ridiculous one now. The code matters, obviously, but a lot of the value is deciding what code should exist and what responsibilities come along with owning it.
When someone asks for a scheduling system, customer portal, dashboard, or AI assistant, they have described a possible solution. I still need to understand who uses it, what happens before and after, which system owns the data, who may change it, what the exceptions are, and what happens when an integration fails. I also need to know whether building exactly what was requested would solve the actual problem. Sometimes it will not.
That last part matters. I wrote an entire article about why you probably don’t need custom software. A client may be better off buying an existing product, connecting two systems, fixing the process first, or removing an AI feature that makes the demo more interesting without making the work better. I think a good software company should be willing to say that even though it may result in less software to build.
There’s also the work nobody puts in the first feature list: database design, permissions, monitoring, deployments, backups, documentation, security updates, and making sure another developer can take over later. The business should control its source code, domain, hosting, and vendor accounts. Somebody needs to remain accountable after launch when an integration stops working or customer data may have been exposed.
Comparing the Quotes
A cheaper developer may be the right choice. Price does not tell me whether somebody is good, and paying more does not guarantee competence. If the application is low risk, the scope is clear, and the business has somebody capable of managing the technical decisions, I would seriously consider the less expensive option.
The quotes still need to describe the same work. One may include only the screens and features everyone can see. Another may include requirements discovery, security, testing, deployment, monitoring, documentation, and support. They can both say “customer portal” at the top while describing very different responsibilities.
I would want to know what personal information the application collects, how permissions are enforced, who controls the accounts and source code, what gets backed up, whether a restore has been tested, who handles security updates, and whether another developer can reasonably take over. The answers do not need to be complicated. They do need to exist.
Owning a business has made these questions less theoretical for me. Payroll still has to run. Customers still need answers. Employees will work around a system that makes their job harder, normally in ways nobody planned for. A leaked customer record is not merely a technical finding because there is a real person attached to it who trusted the business with their information.
I use AI heavily and expect to use it even more. It makes me faster, and I think it is going to make far more software possible. I also think we are going to spend a long time cleaning up applications that moved from prototype to production without anyone noticing the standard should have changed.
Go build the prototype. Just be honest about when it stopped being one.