Building software is faster now than it was two years ago. That is not a claim, it is something we notice in every delivery. But the pace has moved the bottleneck, not removed it, and the problems we are called out to now are not the ones we used to see.
1. The prototype was never thrown away
Somebody built something in an afternoon to show an idea. It worked. Then people started using it. Now it is in production with no tests, no environments, and nobody sure who owns it.
This is the most common one, and it is not an AI problem, AI just made getting there cheaper. The fix is deciding in advance what a prototype is: something you look at and then make a decision about, not something that slides into production because nobody said stop.
2. Nobody can explain why the code looks like that
Code written fast and approved lightly becomes expensive the moment something has to change. The question is not whether a human typed every line. It is whether somebody understood it well enough to answer for it.
That is why we review everything going into production, whoever or whatever wrote it. An agent that writes code quickly is an advantage. An agent that writes code nobody reads is a debt.
3. Permissions were never tidied
This bites hardest when AI arrives in an environment that has grown for ten years. Copilot and agents surface what the user has access to, and suddenly people discover what that actually is. The tool does not cause the problem, it reveals it.
Tidy permissions before you roll out, not after.
4. Nobody owns the solution
Speed makes it easy to build many things. It does not make them easier to run. Five applications with no named owner become five surprises in eighteen months, when something stops working and nobody knows where the source code lives.
5. The cost per run was never measured
Anything running in production that calls a model has a recurring cost. If you do not measure it before going live, you discover it on the invoice. It is a solvable problem, we set ceilings per run and per month, but only if somebody thinks of it first.
What has not changed
Speed moves where the work sits. It does not remove the need for environments, review, ownership and operations. Those four are exactly as necessary now as before, the difference is that you can build a great deal more before you notice they are missing.
Where Breathe AI Launchpad fits
Launchpad is our answer to precisely this ordering. We build with AI coding agents, but around them sits what makes the result hold: environments kept apart, review before anything reaches production, documentation you own, and operations that come with it.
You describe the need, we build a working prototype quickly, and you look at it before anyone commits budget. What gets approved goes into production in your own environment. What does not gets thrown away, and saying no to a prototype is cheaper than saying no to a half-finished project.
The pricing model follows the same logic: a fixed part for the development environment and governance, a flat fee per application we run in production. The cost follows how many applications you run, not how many people use them.
Is it right for you? That depends on whether you need something bespoke or something standard. We have written how we tell those apart, and we say so when the answer is Dynamics 365. More about Launchpad.
Common questions
Is code written with AI worse?
Not in itself. The problem arises when it is not read. We review everything going into production whoever or whatever wrote it, the question is whether somebody understood it well enough to answer for it.
What is the most common problem you see now?
Prototypes that ended up in production without anyone deciding they should. AI made building something quickly cheaper, and so made sliding into production without environments, tests or ownership easier.
Why do AI solutions cost more to run than people expect?
Because anything calling a model has a recurring cost that follows usage. If it is not measured before go-live, it is discovered on the invoice. We set ceilings per run and per month before anything goes live.
What is the difference between Launchpad and an ordinary development project?
The pricing model and the ordering. You see a working prototype before committing budget, and the cost follows how many applications we run, not how many users there are.