Vibe Coding Is Not the Problem

Every few weeks another post explains that AI-generated MVPs are quietly killing startups. The story is always the same. A founder builds a full-stack SaaS in a weekend with Cursor, launches, watches the database lock up, and discovers nobody on the team can read the code well enough to fix it. The lesson offered at the end is usually that you should have hired a real engineer in the first place.

We build software for a living, and we use those same tools every day. Cursor, Copilot, agents running inside our pipelines. Our engineers ship more in a week than they did two years ago, and the code that comes out the other end is not worse. So I think the lesson in those articles is wrong.

The prototype is not the trap. The trap is believing the prototype was the hard part.

What the weekend build actually bought you

A working demo answers a question that used to cost six months and a seed round to answer. Does anyone want this.

You can put it in front of ten real customers on Monday. You can watch where they get confused. You can find out that the feature you were most proud of is the one nobody uses. That is worth a great deal, and anybody telling you to skip it is spending your runway for you.

What the demo does not tell you is whether the thing underneath it can carry a business. Those are two different questions, and the demo is completely silent on the second one. Silence is easy to read as a yes.

The part that does not demo

Here is the pattern we see when somebody brings us a prototype that stopped working.

The application opens a database connection for every incoming request and never hands it back. With one person clicking around, nothing happens. With sixty, the pool is exhausted, and every request after that sits and waits. The code is not wrong, exactly. Nobody told the model there would be sixty people.

Or a page loads a list of records, then runs one additional query per row to fill in a name. Fifty rows, fifty-one queries, loads fine. Five million rows and the page never finishes. The query plan never changed. The data did.

Or the file upload works beautifully because files land on the container's own disk. The container gets replaced on the next deploy. The files are gone, and there is no backup, because nothing was ever written down saying that disk mattered.

Or every user's data sits in one table with a customer ID column, and nothing in the system enforces that you only ever see your own rows. It works because the frontend always sends the right ID. Until someone changes the ID in the browser.

Each of these takes a few hours to fix when you know to look for it. Each one is invisible until the precise moment it becomes expensive. That is the actual shape of the problem, and it has very little to do with AI. We saw all four of these long before anyone was generating code with a model. The models made them cheaper to produce, which means more of them reach production.

Scale is a design decision, not a feature you turn on

"Will it scale" is the wrong question, because the honest answer is always "to what."

The useful version is more specific. How many users at once, a year from now, on the worst day. How much data total, and how fast does it arrive. What is the slowest acceptable response, and for which screen. What happens when one piece goes down, and what is allowed to stop working alongside it.

We ask those questions early because the answers change the architecture, and architecture is the expensive thing to change later. A system expecting a hundred concurrent users and one expecting a hundred thousand are not the same system with different server sizes. They partition data differently. They cache differently. They fail differently.

Most of our work runs in environments with hard constraints that do not negotiate. Bandwidth-constrained networks. Disconnected sites that go dark for days and have to catch up when they reconnect. Deployments where "just push a hotfix" is not available, because the system sits inside a network we cannot reach from here. We spend a lot of our engineering effort on the question of what the software does when conditions are bad, because for our customers bad conditions are the normal case.

That discipline transfers. A commercial product built that way degrades instead of collapsing.

Security is not a phase near the end

The common plan is to get traction first and bring in security before the enterprise deal. That plan fails on contact with the first enterprise buyer, because by then the decisions that matter were made months ago and are buried in the code.

Identity is the clearest example. Who is this person, what are they allowed to see, and who decided. If that logic is scattered across forty endpoints, each one checking a little differently, you do not have an authorization model. You have forty chances to get it wrong, and the one you miss is the breach. Pulling that into one place after the fact touches every file in the project. Deciding it on day one costs a week.

The same goes for what is actually in your software. A modern application pulls in hundreds of third-party packages, most of which you never chose directly. When a vulnerability lands in one of them, the only question that matters is whether you are running it, and most teams cannot answer that in under a day. We ship a software bill of materials with every release, because our customers require one, and because it turns a week of panicked grep into a database query.

Secrets, encryption at rest and in transit, audit logging, dependency provenance, static analysis gates in the pipeline. We build to NIST 800-218 practices because defense work demands it. I think commercial products should be built that way too, and most of the cost people imagine is front-loaded discipline rather than ongoing tax.

Somebody has to answer the phone at 2am

This is the part founders think about last and customers think about first.

A product is a promise that the thing will keep working. That promise has machinery behind it. Monitoring that tells you something broke before your customer does. Logs detailed enough to reconstruct what happened without the user on the phone guessing. A release process that lets you ship a fix on Tuesday afternoon without holding your breath. A rollback that actually rolls back, tested, not assumed. A patch path for the critical vulnerability that drops on a Friday.

None of this shows up in a demo. All of it shows up in your churn rate.

Our product work runs on a quarterly release cadence with immediate patching for high and critical vulnerabilities, support windows we are held to, and administrator documentation that ships with the release instead of trailing it by a quarter. That is not a sales feature. It is the minimum required to tell a customer with a straight face that they can depend on you.

Usable is a different skill than functional

A demo gets used by its creator, who knows exactly what to click. A product gets used by somebody tired, on a bad screen, during the worst hour of their week.

Most of our users are operators and analysts working real missions, and they taught us a few things that apply everywhere. The screen that gets stared at for eight hours cannot be the screen that looked best in a screenshot. Information density beats whitespace when the user has a job to do. Every click you remove from the common path is worth more than every feature you add to the rare one. And people need to know whether what they are looking at is current, because a stale number presented confidently is worse than no number.

That last one matters more than it sounds. A lot of software quietly shows you old data and never says so. In an operational setting that gets people hurt. In a commercial setting it gets you fired by your customer.

What we actually do with your prototype

The reflex move is to throw it away and start over. We usually do not, and I think the instinct to rewrite is mostly engineers wanting a clean canvas rather than a judgment about what serves the customer.

What we do first is read it. All of it. The prototype encodes months of product thinking, including decisions you made for good reasons and may not remember making. Most of that is worth keeping. What needs to go is usually narrower than it looks, and the pieces that need to go are specific: the data model, the authorization layer, anything touching money, anything touching personal data.

Then we work out what the thing actually has to survive. Load, data volume, failure modes, compliance obligations, who the real users are and what they do all day. That shapes the plan, and it is why we ask uncomfortable questions early instead of agreeing with everything and sending an invoice.

Then we rebuild in layers, with the product staying usable the whole time, because you have customers now and cannot go dark for a quarter.

And we hand it back in a condition where somebody other than us can own it. Documentation, a working build and deploy pipeline, tests that mean something, and a code base organized the way the rest of the industry organizes code. I think any firm that leaves you unable to leave them has done bad work, however good the software is.

Why a geospatial defense company

Fair question. We build secure geospatial and mission systems for defense, intelligence, and health customers, and have for over fifteen years. That sounds narrow if you are building something commercial.

It is actually the reason to call us. Our systems run across multiple classified domains, over links that drop, on hardware at the edge of a network, for users who cannot afford to wait and cannot tolerate a wrong answer. We have been doing continuous DoD delivery for more than a decade, which means we have lived with our own architectural decisions for years instead of moving on after the launch party. Nothing teaches you about durability like being required to support the thing you built in 2016.

We also build heavily on open source and open standards, and we contribute back to the projects we depend on. Practically, that means we do not have a proprietary platform we need to sell you, and you are not locked into us. I consider that a feature. It is also the posture that lets us drop into somebody else's codebase without making it a religious argument.

So we build fast, with the same AI tooling everyone else has. The difference is what we do in the weeks after the demo works.

If you are sitting on a prototype

Use the AI. Build the thing. Get it in front of people. That part of the current moment is real and it is a gift.

Then, before you sell it to somebody who is counting on it, get an engineer who builds production systems for a living to spend a few days reading what you have. Not to tell you it is garbage. To tell you specifically which four things will break, in what order, and what each one costs to fix now instead of later.

That conversation is usually short, and it is almost always cheaper than the alternative. We are happy to have it.

Frequently Asked Questions

NGS is a geospatial engineering and software company that delivers secure, scalable, and interoperable solutions for government, defense, and commercial customers. Our team specializes in geospatial systems, full-stack software engineering, DevSecOps, and open architecture integration.