The annual software roadmap is quietly losing its authority. Demand for software has not slowed down, but the window in which technology leaders can commit to a plan has shrunk to six months at most. Work now arrives in bursts: a short, intense push to deliver one thing that matters, followed by a fresh decision about what comes next.
We heard this clearly during a recent round of visits with several of our clients in Boston. Across lunches and dinners with CTOs and chief product and technology officers, at companies of very different sizes, two themes kept coming back. Every one of them was building something hands-on with AI in their own time, and every one of them described a planning horizon that has collapsed to a maximum of six months.
At Ballast Lane Applications, we have been seeing the same pattern in the requests that reach us. The question is rarely "can you give us a team for the next two years?" It is "can you get us more capacity, quickly, for this specific push?" That shift changes how engineering capacity should be planned, bought, and staffed.
Demand Is Tied to a Specific Business Outcome
The bursts are not random. Almost every one we see is attached to a concrete business event with a date on it. A large retail integration that has to go live before a partner's deadline. A deal that will only close if one specific feature ships. A launch that the next funding conversation depends on.
When the work is tied to revenue in the next six months, the priority is obvious, and the urgency is real. Leaders are no longer funding a standing development organization for its own sake. They fund delivery when it is directly linked to revenue, adoption, or a critical launch, and they want that capacity in place now rather than after a two-month hiring cycle.
The end of the year tends to concentrate these commitments. Several clients have come to us with essentially the same request: more people, on a specific outcome, starting as soon as possible.
Budgets Are Released in Stages
The way money is released has changed with it. Instead of one annual allocation, budgets increasingly arrive in tranches. A leadership team approves enough spend to prove the next phase, and only once that phase lands is the following tranche released. A plan scoped as nine months of work can be pulled forward into three when a deal or an investor raises the stakes.
For an engineering leader, this means a signed plan is a hypothesis rather than a commitment. Teams are scaled up quickly, with funding committed one quarter at a time. What happens after that depends on what gets sold, and everyone involved expects the plan to look different by then.
Hiring permanently into that kind of uncertainty is risky in both directions. Hire too slowly and the moment passes. Hire too much and the company carries fixed cost into a quarter that may not need it.
AI Makes Output Faster and Estimates Less Reliable
AI adds a second source of uncertainty, and the leaders we met know it firsthand from what they build in their own time. With today's tools, a team can build a large part of a new product in a couple of weeks. The first 80% looks remarkable. The remaining 20% still takes months: the edge cases, integrations, security and performance work, migrations, and usability details that decide whether a product succeeds.
That uneven curve makes traditional estimation unreliable. Historical velocity no longer predicts the next sprint, and a priority that looked stable can be overtaken within two months by something new. We increasingly see requests for proposals that arrive with a hundred pages of specification generated over a weekend, along with the expectation that the build will take two weeks. It will be faster than it used to be, but it is not free, and it needs more senior people to get it right.
The result is a planning environment where leaders reasonably refuse to commit beyond the next six months, because they genuinely cannot see further than that with confidence.
Staffing for the Push, Not the Year
If the plan only holds for six months at most, the team behind it should be shaped the same way. The teams that deliver well in this environment share a few characteristics:
- They start within weeks, not after a months-long hiring process.
- They are sized to the push, with a clear duration and a clear exit.
- They work inside the client's own tools, ceremonies, and codebase, managed by the client's product and technical leadership.
- They can be extended, scaled up, or scaled down as the roadmap changes, without renegotiating the whole relationship.
- They are made up of people who own outcomes, not just tickets, because the bottleneck has moved from writing code to deciding what to build next.
That last point matters more than it used to. When engineers finish in two days what was estimated at a week, the limiting factor becomes judgment: knowing what to pick up next, challenging a weak requirement, and making sure work actually reaches production. Capacity without that judgment produces more output faster, not more results.
This is the model behind our nearshore development teams. Teams typically start within weeks, engagements usually run for a few months and are often extended, and at the end of each stretch there is a clear choice to extend, scale, or wrap up with a handover.
Why Same Time Zone Matters More in a Burst
Short pushes leave no room for slow feedback loops. A push of a few months cannot afford a day lost to every question that waits overnight for an answer. That is one of the reasons nearshore teams fit this pattern well.
Our team works across Latin America, from Mexico to Argentina, and most team members work in or close to U.S. Eastern time. Working days overlap, decisions happen in the same meeting rather than the next morning, and the team can sit in the same stand-ups as the client's own engineers. For a burst with a fixed commercial deadline, that overlap is worth more than any rate difference.
Planning Capacity on the Same Horizon as the Business
The companies we spoke with are not planning less because they are disorganized. They are planning on a shorter horizon because that is the horizon on which the market, their funding, and their tools now let them see clearly. Pretending otherwise produces annual plans that are rewritten every quarter anyway.
The more useful response is to match capacity to the horizon the business actually has: a team that can start quickly, deliver one meaningful push, and then be extended or released based on what that push achieved. Roadmaps now run in bursts. The teams that succeed are the ones staffed for the push, not the year.