The Future of Build vs. Buy: Throwaway Software, Dark Factories, and Liquid Code

“If agents can build software on demand, why would you buy software at all?” That question used to sound theoretical. It doesn’t anymore — and the answer is reshaping every software investment decision being made right now.

What is throwaway software and why does it matter for the build vs. buy decision?

The idea is simple: instead of building software that lasts, you build software that does what you need right now and then disappears.

An AI agent receives a request. It writes the code, runs it, delivers the output, and the code is discarded. No maintenance. No technical debt. No versioning. The software exists only for as long as it’s useful.

This isn’t hypothetical. It’s already happening in specific use cases. In the wealthtech and fintech space, platforms are using this pattern today. A user asks for a custom chart comparing three data sets over 36 months. Rather than generating a static visualization, the AI agent writes actual code, fetches the data, renders the chart, and executes it. The user gets exactly what they asked for. The code served its purpose and is gone.

The implications are large. If software can be generated on demand for a specific task, a huge category of one-off tooling — internal dashboards, data transformations, report generators — stops being something you build or buy. It becomes something you prompt for.

What this means for build vs. buy: The “buy” side has always included lightweight tools that companies purchase because building them isn’t worth the effort. Scheduling scripts. Data formatters. Simple integrations. As our build vs. buy AI framework shows, the threshold for when building makes sense is already shifting — and throwaway software is accelerating that shift for the lowest-complexity tier of tools.

The limitation is predictability. When you run the same throwaway code twice, you want the same result. Agents still have reliability concerns around hallucination and inconsistency, which is why throwaway software works best today for analysis and visualization tasks where a human reviews the output. For anything mission-critical or repeatable, persistent tested software remains the right answer.

What is the dark software factory and how close are we to it?

The concept borrows from manufacturing. A “dark factory” is a production facility that runs autonomously — no humans on the floor, no lights needed. The dark software factory applies the same idea to code.

The premise: you start with a prompt or a specification. A team of AI agents takes that input, builds the software, tests it against defined criteria, deploys it, and delivers a finished product. Humans define what to build. Agents handle the how.

As of early 2026, this is no longer speculative. BCG Platinion published a detailed framework describing autonomous software delivery as an emerging reality. StrongDM, an infrastructure access company, has operated a dark factory internally since mid-2025 with three engineers and a strict rule: no human-written code and no human code review. Spotify reportedly has engineers who haven’t written a line of code since December 2025, using an internal AI platform called Honk to trigger and merge autonomous code changes.

Dan Shapiro, CEO of Glowforge, developed a five-level framework for AI autonomy in software development. Level zero is fully manual. Level five is the dark factory, where specs go in and software comes out. Most organizations today sit between levels one and three. But the gap between leaders and laggards is widening fast.

Is there hype? Yes. Some firms claim to be fully at level five today. The reality is more nuanced. But the trajectory is clear, and the distance between “AI assists the developer” and “AI builds the software” is shrinking with each model generation.

What would software as a managed service actually look like?

This is the most speculative of the three concepts, but it may also be the most consequential.

Today, most non-technical companies engage a managed service provider (MSP) for their IT infrastructure. That’s the firm that sets up your Wi-Fi, maintains your email, manages your basic network services. It’s a well-established model.

Now extend that model to software. What if a provider could deliver custom software on demand and maintain it for you? Not software as a service in the traditional SaaS sense, where you’re one of thousands of tenants using the same product. More like instantaneous, real-time, bespoke software built for your specific needs, with a user base of one.

This would satisfy the need for custom software while keeping the distraction of building it off your plate. For non-technical companies, software could become liquid: something you consume as needed rather than something you own and maintain. The $100K threshold analysis for non-technical companies assumes a world where custom development has a certain cost floor — liquid code could push that floor significantly lower.

We’re not there yet. But the building blocks are falling into place. Throwaway software proves that code can be generated on demand. Dark factories prove that the full build-test-deploy cycle can be automated. Combine those two capabilities with a service layer, and you get something that looks a lot like software-as-a-managed-service.

How do throwaway software and dark factories change the classic build vs. buy tradeoffs?

The traditional tradeoff — buy is faster and cheaper, build is slower but more customized — assumed that human engineers were the bottleneck and that software had to be maintained by someone on your team. Both assumptions are being weakened simultaneously.

If a dark factory pipeline can produce tested, deployable software from a spec in days instead of months, the “buy is faster” advantage shrinks. If throwaway patterns can replace lightweight purchased tools entirely, the volume of software you need to buy decreases. And if software-as-a-managed-service matures, the three-way decision becomes: build it (full ownership, maximum control), buy SaaS (shared product, lower cost), or subscribe to managed custom software (bespoke but outsourced). For companies whose core business has nothing to do with technology, that third option could be the most compelling path — custom software without the overhead of custom development.

What should you actually do differently right now?

These concepts are at different stages of maturity. Throwaway software is real and happening in production today, though limited in scope. The dark software factory is operational at a handful of pioneering organizations and quickly moving toward broader adoption. Software-as-managed-service is the logical extension, but it’s still early.

What hasn’t changed is the core decision framework. If a mature SaaS tool solves your problem, buy it. If your competitive advantage depends on proprietary data or custom logic, build it. If you need the power of frontier AI models without building your own, use the hybrid approach for tech companies where the math already favors that path. These principles hold regardless of where autonomous software delivery lands.

What’s changing is the cost and speed of the “build” option. As AI agents get better at writing, testing, and deploying code autonomously, the timeline and price tag for custom software will compress. Features that once took months will take weeks. Projects that once required a 10-person team may require three people and a well-written spec.

At Fraction, this is already shaping how we work. We build the application layer on top of existing AI infrastructure. As the tooling for autonomous software delivery improves, our ability to ship faster and more cost-effectively improves with it. The pricing model stays the same: $149 per story point, scoped upfront, with a structured breakdown before you commit. What changes is how much more value fits inside each sprint.

The companies that will benefit most from these shifts are the ones paying attention to the mechanics now — not the hype. Understanding what throwaway software can and can’t do. Knowing when a dark factory pattern applies and when it doesn’t. The goal isn’t to predict the future perfectly. It’s to make sure you’re not making a five-year software investment based on assumptions that won’t survive the next 18 months.

Frequently asked questions

Sources