Years before I was Director of Operations and then Director of Product Discovery at Designli, I started my tech career as a freelance programmer. I got my first true technology job right around the time the shift to the cloud was in full force and had completely reached the corporate world that had resisted it for years. It was already clear there was a new way of doing things, one that had upended how solutions were provisioned and built.
The Hardware Era
Historically, hardware was the main cost driver. We call these cost drivers the variables in a pricing equation with the biggest impact on the final result. Every solution is different, but a few factors matter disproportionately.
Servers mattered. Where they lived physically, whether you bought them or depreciated them, and whether they counted as capital or operational expense, all of that went into the CTO's cost matrix. This held whether your code came off the shelf (SAP, Oracle EBS) or you built it custom (C#, Java, Ruby). Infrastructure costs were as important as development hours, sometimes more so.
When cloud providers started charging per hour, everything changed. Infrastructure stopped being capital you committed to upfront and became a variable expense you could scale as you needed it. One click to spin up a server meant hardware was no longer a primary cost driver. It didn't disappear, but its weight in the total cost equation shifted dramatically.
A resource that was fixed and finite became dynamic and a la carte, and the costs per unit at the time were also greatly reduced. Ten years later, something similar happened to the other traditionally important cost driver: software engineering hours.
The Writing Code Era
To understand the cost landscape, you can follow the trend of the last few decades. We software engineers have been trying to disrupt ourselves since the beginning. The history of our craft is one long chain of changing cost drivers: factors that, all else equal, disproportionately affect what you spend to build something.
After the hardware era came the 'writing code era,' where the cost of engineering time in the past dwarfed all other categories for software cost drivers, making it THE most important factor that affected the cost of building a solution.
Now AI tools can do 10x the output per engineer. Work that took months takes weeks. Engineer hours as a share of total cost drop significantly.
| Era | Primary Cost Driver | Key Constraint |
|---|---|---|
| Hardware | Hardware (servers, infrastructure) | Capital expenditure, physical space |
| Code Writing | Engineering hours | Time to develop, developer salary |
| Curation | Human validation and taste | Attention, expertise, quality judgment |
The Problem: AI Slop at Industrial Scale
AI accelerated code creation, but business always moves at the speed of the slowest bottleneck. This acceleration is different from past shifts. I want to highlight why some bottlenecks are actually more important now, not less: they are the new cost drivers.
I would expect that almost a year into a world where "writing code is a solved problem," we would be seeing a world with perfect, bug-free, feature-rich software. But what I see is an enormous increase of low-quality "slop" software and software that used to be close to bulletproof, like Amazon's marketplace, having more time offline than in any period I can remember. Every platform I use is clogged with tasteless "AI slop" content.
Mediocre has always existed. SEO-optimized grandma recipes. Greeting card copy. Email templates. All of LinkedIn. In software engineering, you could build an API by TABing through VisualStudio or copy-pasting StackOverflow. AI just made it possible to generate garbage at scale without trying.
What Actually Defines Slop
I think slop is easier to define by its process rather than by its output. My definition of AI slop would be an output created in a process that didn't have a good/careful human curator. Something doesn't become slop just because it was generated by AI. It is the process of a human that gives a damn carefully validating the outputs that makes the resulting output non-slop. You can have an essay that was entirely written by generative AI but that had every line validated by a human, and I wouldn't call it slop.
Everything we make has a thousand decisions baked in. When AI generates something with even a detailed prompt, it makes hundreds of decisions. Some are right, some miss, and some (about 10%) are straight hallucinations. The difference between slop and value is simple: a human read every word and understood and corrected every decision in the final output.
Given the cost of generation being close to zero, this deslopping process is the scarce resource. This process of human curation is the difference between a sea of worthless words/bytes and outputs that have value. In the curation era, the cost drivers are verification time and curator taste.
The Taste/Curation Era
Having said all that, in the last 12 months there has been a shift in the distribution of the bottlenecks. By far, writing code used to be the biggest one. Now that it has been reduced, other parts that didn't feel like one before are now the actual bottlenecks. Tasks that turn the firehose of code and decisions into something that doesn't suck. You move at the speed of human verification.
The conversation shifts from "engineering hours" to "attention and taste." Things need to be verified by someone who knows what good looks like. Curation tasks:
- Discovery: Figuring out what to build and why it matters
- Design feedback loops: Evaluating design decisions against actual user needs
- Validation: Testing assumptions before you commit to them
- Acceptance testing: Making sure it works in the real world, not just in your test cases
- Defining software architecture: Decisions that compound over time
- Designing and optimizing databases for scale: Building systems that don't collapse when they work
- Reviewing code: Catching things before they reach production
- QA: Real testing across scenarios that matter
- Edge cases: Anticipating what will actually break
- Security: Protecting data and systems from attack
These are verification tasks, not execution tasks. Better done by an expert.
Lean Teams Need Taste
AI pushes teams to get leaner. When you amplify what each person can do and let them cover multiple roles, you need fewer people. A build that used to need developers, DevOps, and QA can happen with one dev and one PO. At Designli, we still surround that core with senior design, architecture and engineering review, because that's where the taste lives. You save money on headcount and all the friction and context loss from bigger teams.
Some people think this means non-technical people can now build platforms themselves. For very simple, very standard stuff, maybe. For anything real, no.
You still need thousands of hours of scar tissue. The kind that teaches you what will break when it matters.
Why Designli Exists in 2026
That's the whole point of Designli. Our value is the experience, processes, and taste to build something that won't shatter the second you have more than 30 users. Lean teams are great, but only when someone steering them knows what good actually looks like.
Taste is real work:
- User empathy: Knowing what real users actually need
- Real-world experience: Having shipped things that scaled
- Architectural thinking: Making decisions that compound
- Technical debt evaluation: Knowing which shortcuts cost you later
- Edge case prevention: Seeing problems before users find them
When you hire Designli, you're paying for experience, curation, technical knowledge, and taste to keep your MVP focused and prevent it breaking in production.
One more thing: AI costs are heavily subsidized right now. We're not paying the real price of computing. That's temporary. When subsidies end and the cost gets expensive, cost dynamics change again.
True MVPs: The Art of Ruthless Prioritization
Project cost depends on how much you build, whether by hand or AI. It's always easier and more certain to cut features than add them.
Most MVPs are overbuilt. Even when adding features cost six figures and killed time-to-market, founders still pushed for nice-to-have features that didn't move the needle. Now that code is nearly free to generate, discipline matters more, not less.
Set strict limits. Define MVP as the minimum that delivers value without overwhelming users with more features than they can validate in a month. With real product discipline, a Designli team can ship a true MVP in 60 days: 30 to build and friends & family test, 30 to adjust based on feedback.
| Timeframe | Phase | Focus |
|---|---|---|
| Days 1-30 | Build & Friends & Family Launch | Core features, friends, and family releases |
| Days 31-60 | Feedback & Iterate | Adjust based on real feedback, and refine core value |
If it can't be built in 30 days, it's probably overbuilt. Your mileage varies depending on what you're building.
At Designli, a 3-month MVP team costs $60,000–90,000. The first 60 days get the MVP built and refined with real feedback; the third month goes to launching it and finding your first paying customers. For reference, we used to quote traditional MVPs at 6 months and $120,000 for not much better results.
AI Can't Substitute for Scar Tissue
AI is a huge boost for code creation, but it's not the end of professional development. It just changes what matters. You don't need a massive engineering team anymore, but expert human curation is more critical than ever.
Some founders try to muscle through and build it themselves. They pay an invisible price for not being experts. You end up with brittle, unfocused products that break in real scenarios. AI can't replace hard-earned experience in architecture, databases, scaling, or security.
That's Designli's value: the experience and taste that act like insurance. Things don't break. If they do, we fix them fast. More importantly, taste in the form of product discipline means your MVP isn't a mess of features; it's a focused product built to scale and built to sell.
The hidden cost of going solo isn't the broken product. It's the months you lose figuring out what doesn't work.
Want the numbers? Here's what an MVP costs. Want to start building? Talk to us.
