The Work You've Been Putting Off
Your killed-project list just became a planning document.
The cost of building software dropped. The backlog that got killed because it couldn’t justify the engineering budget is back on the table. I wrote about that last month.
What I didn’t write about: which project to pull off the shelf first.
Building custom software used to mean six engineers for six months. At that cost per unit of output, only the top-two or top-three priorities ever penciled. Everything else went on the list. The list got long. The list became a monument to what the company knew it wanted but couldn’t justify. Internal tools someone wanted but couldn’t get prioritized. Integrations that would have saved a department an hour a day. Automations that got killed in planning because the engineering cost was three times the annual benefit.
Those kills were right at the old price. They aren’t right anymore.
Where the actual wins hide
The loudest pitch in the room right now is “rip out your SaaS and rebuild it custom.” That story is real. It’s just not usually the biggest unlock, and it’s not what most operators should do first.
Three categories pay off faster and carry less risk.
Manual processes that need a human in the loop, not a human doing the work. The AP team reviewing invoices. The ops manager classifying support tickets. The analyst assembling a weekly report by hand. Judgment is part of the job, so full automation is wrong. The mechanical eighty percent of those jobs is not. McKinsey measured processes run by humans and AI together at fifty to one hundred twenty percent more efficient than either alone. One enterprise swapped fifteen manual data-collection workflows for an AI-plus-human-oversight system. Costs went from four million dollars to two hundred seventy thousand. Accuracy went from seventy-one percent to ninety-six. The humans didn’t disappear. They moved from typing to reviewing.
Legacy systems and data flows too expensive to optimize at the old cost. The billing system nobody wants to touch. The internal tool that started as a spreadsheet and ended as a load-bearing wall. The ETL that runs for six hours every night because it was written once and never revisited. At the old cost of custom engineering, these stayed broken. IDC reports that over eighty percent of large enterprises will be using AI-assisted tools to modernize legacy systems by 2026. Modernization programs that needed twenty-four months and ten million dollars manually now complete in fourteen months at four. You don’t rip the legacy system out. You wrap it, optimize the expensive parts, and bridge the parts that were never connected.
Existing cloud and SaaS running more efficiently without ripping anything out. Most cloud waste is not “wrong tool.” It is “right tool running inefficiently.” The inference pipeline that calls the expensive model for every query when most queries could route to a cheaper one. The queue worker pool sized three years ago. The daily full-table scan that could have been incremental. AI-assisted development makes this kind of re-architecting affordable for the first time. Two-tier LLM architectures on production agent workloads cut cost by roughly seventy-five percent without changing vendor relationships.
Replacing your stack is a thing you can do. It is not usually the thing to do first.
The projects that come off the shelf first are predictable. Workflow automation where the judgment stays with a human and the mechanical steps leave. Document processing for PDFs, invoices, scanned forms, and the email threads that land in a shared inbox. Internal tools that consolidate what was living in three places into one, without signing off on another SaaS contract. Data pipelines connecting systems that should have been connected years ago. Reporting that runs itself on the cadence you actually need. If your backlog has items in those categories, they are probably viable now.
How to triage the list
Not every killed project is worth reviving. The framework that actually works is boring and specific. Score each candidate on four criteria:
Clear, documentable decision rules. If a human employee can write down how they handle it in a page or two, a system can do it. If the rules are “it depends” and “you just kind of know”, leave it on the shelf.
Judgment is rule-shaped, or bounded with a human in the loop. Some workflows can be fully automated because the decisions are rules. Others should not be, because the judgment carries relationship context or high stakes. Both are viable if the humans stay in the loop on the judgment calls and the AI does the mechanical work around them. What does not work is pure open-ended judgment on unstructured input at low volume. Leave those on the shelf.
Structured data in and out. Rows, fields, forms, JSON. Unstructured video, hand-written notes, and unknown legacy formats are a longer road.
Process stability. If this workflow is going to get rewritten in six months, wait. If it has been the same for two years and will be the same two years from now, it is a real target.
Score each item one to three on each criterion. Add them up. Start with the highest.
One more threshold worth enforcing: volume. If the process fires fewer than fifty to a hundred times a month, the payback window gets long. Automate rare events last.
Pick one. Pilot it. Prove it. Then expand. Operators who try to do five in parallel tend to finish zero.
The Cursor-license trap
The trap most teams fall into is believing the bottleneck was tooling. If you just give every developer a Claude Code or Cursor subscription, surely the backlog starts draining itself.
That is not what happens.
Developers spend only twenty to forty percent of their time typing code. The rest is analysis, scoping, stakeholder conversations, reading legacy systems, deciding what “done” means, and the endless back-and-forth of getting a requirement clear enough to implement. AI tools accelerate the smallest slice of the job.
The harder skill is judgment. Knowing when an AI-generated solution is merely functional versus actually right. Knowing which edge case the test suite is not going to catch. Knowing whether to rewrite the upstream data contract or patch around it for now. That skill does not come in a subscription. It comes from having built these kinds of systems before, shipped them, maintained them, and seen which shortcuts turn into nightmares in six months.
The signal is already in the data. Stack Overflow surveys in early 2026 found that nearly half of engineers say their company is not meaningfully using AI, even while their executives believe it is. The tools are installed. The gap is elsewhere.
Be honest about what still takes time
The code part got fast. Everything around the code did not.
Scoping a new workflow for real-world inputs still takes real time. Aligning stakeholders on what “correct” means still takes real time. Designing the handoff between the new system and the people using it still takes real time. If a vendor is pitching “ships in days” for something that touches live operations, they are either cutting one of those corners or they are lying about the timeline.
This is why the old projects coming back to life are still projects, not button-clicks. They are just projects a good team can actually finish now instead of starting and abandoning.
What to do with your list
Pull it out. It probably exists as a Trello board nobody has touched, a Notion page with a “Someday” tag, or a tab in a spreadsheet called Roadmap v4. Go through it with the framework above. Most items will still not pencil. Some will. Those are the ones you were right to want and wrong to kill.
The framework is easier to read than to run. If no one on the team has worked AI-first before, the questions are hard to answer with confidence. Which workflows really need an LLM in the loop and which are just traditional software built fast. Which legacy system is worth wrapping and which should be re-architected. Which line item on the cloud bill is right-sized and which is waste. Making these calls wrong is how AI projects stall. Making them right takes someone who has already made them.
We do this work two ways. For teams that need the judgment side, what to build, in what order, with what tradeoffs, we embed as AI leadership on retainer. For teams that already know what they want built, we scope it, build it, document it, and hand it off. Not as a slide deck. Working systems. You decide what goes on the list. We build it. You own it.
You already know what you want. The list has been sitting there for years. The part that changed is what it costs to finish, and whether you have someone in the room who can tell you which items are real.