Agile Isn’t Fast Enough Anymore - Software Delivery in Rapid Development Mode

The Industry Has Changed, So Must We

Since 2023, I’ve watched the percentage of rejected or heavily negotiated offers skyrocket. I realized sometimes more time was being spent on meetings, negotiating, and explaining the work behind the requirement than I would have spent actually building at least “something” less abstract than these discussions. Yes, it wasn’t something entirely new, but the volume of it was.

In 2025, the winning deliverable is no longer a perfect spec or a polished two-week sprint demo. It’s running software in production that the client can click today and decide tomorrow whether it’s worth investing more in.

Why Traditional Agile Suddenly Felt Like Bureaucracy

I realized the issue wasn’t just cost; it was perceived value and speed, which translated into time-to-market with limited budgets. The industry has accelerated again. Exponentially. Traditional Agile, with its sprint planning, reviews, and retrospectives, created a buffer that felt like bureaucracy to clients hungry for quick wins. It became the new waterfall.

The New Reality: AI + Tight Budgets + Overnight Competitors

Hard economic times and the arrival of AI have drastically impacted software development. The combination of less money to spend and competitors demoing MVPs conjured seemingly overnight, leveraging AI for code generation, was destroying traditional (more structured) workflow.

The New Workflow: Feature-Based Short Loops

I thought every functional requirement could be broken into smaller chunks. Almost always, we can deploy “something” very quickly. Let’s always try creating a PoC for the idea. Then plan upcoming iterations. The goal was to publish something for a client as soon as possible, with minimal resources, and, in the end, enrich the functionality for end users.

Sometimes the idea stalled after PoC because it wasn’t the right fit for the product or market. Sometimes, PoC was marked as production-ready, the client was satisfied, and planned iterations were put on hold because they were no longer needed. Resources were saved for something else that will bring more business value.

The 1.5-Day Integration That’s Still Running in Production

In one system integration design, I handled all edge cases and details as they were requested and provided an estimated development time of 2 weeks. The reply was that it’s too much, again. I said, "Ok, I can provide a minimalist version in 1–2 days." Forget the details, expect unhandled edge cases, data discrepancies, maybe glitchy behavior, but you will have at least something, for a fraction of the cost. To my surprise, it was approved. It took 1.5 days to develop and deploy, and it’s already been running in production for half a year, unchanged. The feature has imperfections, but it was used multiple times to generate valuable leads and customers despite very limited budgets.

How I Changed My Architect Proposal Template

As a software architect, I have an impact from the very beginning. Today, when I present my proposal, I always break it down into phases, with a very strong focus on the first one or two. It’s important to have some vision, but I would keep it at that level. I try to save the client’s resources for meaningful things. Details often cost a fortune and deliver near-zero value (at least at first). 80/20 rule applies. After all these years, from my experience, statistically, discussing what can or should be implemented half a year later is a complete waste of time. The feature almost never looks or behaves as everyone expected. Pushing it also means unnecessarily complicating the architecture design, resulting in (often) wasted costs. It’s important to start as soon as possible with something, and we will adapt and adjust as we go. Good architecture allows that, but a throwaway prototype is also an option, sometimes the most cost-effective one.

Overpriced Solutions

The majority of apps originally planned as “MVP” don’t end up as MVP on the first production release. Especially in Europe’s market, clients often fear releasing imperfection. We’ve seen projects delayed by 6+ months for “just one more feature”. Most such projects are doomed to fail nowadays. Then the architect/lead developer is asked why the solution was so expensive. Well, as 6 months of development have now passed instead of the originally planned 1, the cost follows.

I say that most features can be implemented in 2 days, 2 weeks, or 2 months. I like to start with basic logic and basic UI, then iterate and improve. Estimates shift to days at most, with immediate deployments to test environments for test group feedback. Approved? Straight to production if it can bring at least some business value.

The Wins Achieved

Time-to-Market: Features hit production in days, not weeks/months. Multiple releases a day are now possible.

Cost Efficiency: Many features were overly complicated from the beginning. After the change, the product team and test group could try it and get a feel for it before wasting the budget. Adjustments were made instantly, or feature development was completely stopped. Over the course of a project, this often totaled less than the original estimates, as over-engineering of unused features was avoided.

Team Strain: Maybe the opposite of what one would expect happened - less stress. Large features, or even worse, grouped in large versions waiting to be deployed for weeks, often led to long code freezes and QA testing sessions. Developers feared releasing, often waiting for what would break because it was forgotten somewhere in the last month. Both sides, devs and the client, have more peace now.

The Caveats and Non-Compatibilities

Quality Compromises: Rushing minimal versions may sometimes mean skimping on tests or docs. Mitigate by not skipping it, even for PoCs, or by being very strict about mandatory to-be-done tasks when moving forward with the feature iterations.

Not for Every Project: Regulated industries (e.g., healthcare) demand audits and compliance for some parts that don’t fit “days-only” timelines.

Git Merging & Unwanted Production Features: Some parts of the codebase are easier to work with that way, some not. Advanced Git experience for merging/rebasing is sometimes needed, as with every other parallel work. Feature flags can help enable and disable features when something should not go live yet in today’s deployment pipelines.

Converting All Projects? No

This quick-loop model isn’t “better” than traditional Agile; it’s different, tailored to an era of AI acceleration and economic impatience. While it boosted competitiveness, it reminds us that no methodology is one-size-fits-all. Both sides, the development and product teams (sometimes the client directly), have to be compatible with it. For some, the old approach works just fine - sticking to it is enough.

The irony? We’re finally doing what the Agile Manifesto actually asked for in 2001. Sadly, we needed AI and near-recession budgets to force us to take it seriously.