Building got fast. A working prototype that used to take a quarter and a team now takes a day or two and a well-written brief. That’s one of the best things to happen to software in a decade, and the teams that have learned to move at that speed are pulling ahead because of it.
But speed just moves the hard part somewhere else. For twenty years, the cost of building forced the questions: Is this worth it? Who is it for? What happens if we’re wrong? Nobody had to assign that review, because the budget did it. Now the budget is gone, and so is the review. The result is an organization shipping the wrong thing on time and under budget.
So the question worth asking isn’t whether we can build a thing. It’s whether we should.
Summary
Four questions screen any AI initiative before it reaches the business: who gets hurt if it’s wrong, whether you could show it to the people it touches, whether you can verify it yourself, and how fast you could undo it. Most ideas clear all four in minutes. The ones that stall expose the commitment hiding behind the build, the process change and the vendor contract and the role that no longer exists, which is the part that was never cheap.
The question nobody is assigned to ask
The shift sounds subtle. In practice, it changes who has to think.
By the time anyone asks whether you should build it, the work already feels done. You’ve defined the problem, ruled out a few approaches, and written the brief describing what you want to build. The idea is documented, and the momentum is real, which is exactly when most organizations stop asking questions.
“You have an idea, and need to commit to it. But before we do, let’s look at it from two angles,” says Sarah Bhatia, Director of AI Product Innovation at Slingshot. “This is where we start to shift from ‘can we build a thing’ to ‘should we build a thing.’ Is the solution we’re creating something sustainable? Does it fit in my business? Is it something that we actually want?”
Those two angles are readiness and gaps. Is the business ready, and where is the idea weak? The four questions that follow help you test both.
What speed doesn’t buy you
Fast building makes that screening more valuable, not less. When a build took six months, the business case got written, argued over, and defended. When a build only takes days, it can skip straight to rollout, and the first serious review happens after people are already using it. The commitment isn’t the development spend anymore. It’s the process change, the customer touchpoint, the report an executive now reads every Monday, and the team that reorganized around all three.
Speed obscures this, because speed feels like progress. “While we can do stuff fast, it doesn’t actually mean that we’re getting any quality out of it,” Sarah says. She points to the fifteen-page document generated in thirty seconds and then handed to someone else to make usable. The generation was free; the cleanup wasn’t, and it fell to someone who didn’t choose it.
The same confusion runs the other way too, in companies that buy the tool before they name the problem. “I hear companies all the time starting with a tool and saying, ‘We turned on ChatGPT. We have AI now. We did it.’ And then a few months in, they get frustrated because they’re not seeing an impact,” Sarah says.
The fix isn’t more governance theater. It’s four questions to ask before the organization commits: stakes, defensibility, verification, and reversibility. “If all four of these are feeling fine, if the gut check is passing, keep moving. If they don’t, then stop and re-evaluate,” Sarah says.
1. Who’s affected if this is wrong?
Stakes come first, because the other three checks only matter in proportion to the answer. “Whatever AI hands back to you, run it through a gut check before it goes anywhere,” Sarah says.
The question is about people, not systems. A misclassified row in an internal dashboard is an annoyance. The same error inside a pricing recommendation, a candidate screen, a credit decision, or a customer communication is a different category of problem, and the difference has nothing to do with the model and everything to do with who sits downstream.
Executives already run this calculation on other risks. Nobody signs off on a new financial control without knowing whose numbers it touches. AI initiatives often skip it because the output arrives looking finished, and finished-looking work elicits less scrutiny than a draft does.
It helps to answer in specifics. Not “customers,” but which customers, how many, in what moment, and with what recourse. Not “the ops team,” but the three people whose Monday changes. When the blast radius is small and internal, move fast and learn. When it reaches a customer, a regulator, or an employee’s livelihood, the remaining three checks aren’t optional.
Stakes also set the right level of review. A low-stakes internal tool doesn’t need a steering committee. A high-pressure one shouldn’t get a pilot that quietly becomes permanent because no one scheduled a decision to stop.
2. Could you show it to the people it touches?
The second check turns an abstract concern into something a CEO can actually evaluate.
“Would I be comfortable, from a bias perspective, showing this to the group that it impacts?” Sarah asks.
That reframes fairness as defensibility, which is the version executives already know how to reason about. The test isn’t whether the model is biased in a technical sense. It’s whether the logic survives contact with the people living with the result. If the answer needs a disclaimer, a carve-out, or a hope that nobody asks, the answer is no.
That discomfort is useful data. It usually points to a gap in the inputs rather than a flaw in the output, and the gap is almost always context the business knows, but the system doesn’t.
“AI doesn’t know the context of what you do, why you do it, how you do it,” Sarah says. “That context is your edge. That is where your human brain comes into play.”
The system won’t object to you, because it’s built to please rather than push back. “AI really wants to make you proud; it wants you to be so proud of what a good job it did,” Sarah says. “So it will close those gaps on its own, and it makes those assumptions independently and often incorrectly.”
Sarah’s countermeasure takes one line: tell it to pose clarifying questions before it starts, because otherwise it assumes, and assumptions are where hallucinations begin.
The same move works on the idea itself. Ask the system to argue against the plan instead of just building it, and it will. Most organizations never ask, so the first real objection comes from the group the decision lands on. That version costs considerably more to hear.
3. Can you verify it yourself?
The third check is about what you can defend later, which means you have to design it in before launch, not inspect it afterward.
“Can you verify the output yourself?” Sarah says. “If not, you need to think hard about whether that’s something you want to bring out into the business.”
Verification is a design requirement, not a review step. A recommendation you can’t trace back to a source, a number, or a rule isn’t an insight. It’s a claim, and claims accumulate.
The practical form of this question is simple: if a customer, an auditor, or a board member challenges this output six months from now, what does the organization point at? If the honest answer is “the system said so,” the initiative needs a different design before it needs a launch date.
That applies to the easy cases too. Outputs that look obviously right are the ones that nobody traces, and they sit in reports for quarters before anyone asks where the number came from.
4. Can you undo it quickly?
The fourth check asks what it costs to be wrong: not whether the solution works, but how fast you can pull it back out if it doesn’t.
“If I implement this process and it’s terrible, how quickly can I roll that back?” Sarah says.
Reversibility is where speed gets tested. The build itself is easy to undo, but the commitment around it usually isn’t. Data gets migrated, a vendor gets a two-year contract, a role gets eliminated, customers learn a new workflow, and the week-long build now has a twelve-month exit.
Knowing the rollback cost before launch is what turns an AI initiative from an expense into an investment, because an investment is something you can size, stage, and stop. It also changes how you sequence the work. A reversible version first buys you the information to commit properly, and it costs much less now that building is the fast part.
A decision you can undo is one you’re allowed to get wrong, and that’s the only kind worth making at speed.
Where judgment stays
None of this slows the building down; building is the fast part now, and it will stay fast. The four checkpoints protect the commitment that follows the build, where the real cost has quietly moved.
Stakes tell you how much rigor the idea deserves. Defensibility tells you whether the logic holds up in front of the people it touches. Verification tells you what you can stand behind later. Reversibility tells you what it costs to be wrong. Together they turn a build decision back into what it always was: a business decision.
And the judgment stays human throughout, because the context does. “You’re bringing your context, you’re bringing your problem. That is your unique individual judgment. That’s what keeps us valuable,” Sarah says. “If AI starts to push you one way too far, it’s your job to provide that judgment and bring it back on track. It’s your job to course correct.”
The upside isn’t just a faster organization. As Sarah puts it, AI offers a real opportunity: “You get not just to go faster, but to go better. Build better, be better.”
Run your next AI initiative through the four checkpoints before you fund the first sprint. Anything can be built now; that’s exactly why what gets built should still have to earn it.
What Else AI Made Cheap
Written by: Savannah Cherry
Savannah leads marketing and new business at Slingshot. She writes, posts, and creates all things Slingshot, and helps companies navigate working with a tech partner for the first time. While she isn’t developing software, her CIS minor and a tendency to tinker with AI tools to streamline her own work keep her up to speed on the team’s work. She co-organizes and hosts the Louisville AI Exchange, and she can’t rest until all her work is done.
Expert: Sarah Bhatia
Sarah Bhatia brings people together. In her decade plus of product and product-adjacent experience, her focus has been on cross-functional collaboration, asking lots of questions, and getting big results. She excels at strategy development, and getting the right brains in the room to solve big problems. Sarah would describe herself as a daredevil, because she’s not afraid to ask “dumb“ questions, get smart answers, and take (calculated) risks.
Frequently Asked Questions
Four questions, asked before the organization commits: Who is affected if this is wrong? Would you be comfortable showing the output to the group it impacts? Can you verify the result yourself? If you are wrong, can you undo it quickly? Sarah Bhatia, Director of AI Product Innovation at Slingshot, describes these as a gut check rather than a process. If all four pass, keep moving. If one stalls, stop and re-evaluate before funding the work.
For two decades, the expense of building forced a business case to be written, argued over, and defended before anything shipped. Nobody had to assign that review because the budget did it automatically. Now that a working prototype takes days instead of a quarter, the budget no longer triggers the review, and the real commitment has moved downstream to the process change, the vendor contract, the customer touchpoint, and the team that reorganized around them.
An output is verifiable when you can trace it back to a source, a number, or a rule without relying on the system's say-so. Verification is a design requirement rather than a review step, because it has to be built in before launch instead of inspected afterward. The practical test: if a customer, an auditor, or a board member challenges this output six months from now, what does the organization point at? If the answer is that the system said so, the initiative needs a different design.
Reversibility is how quickly and cheaply the organization can undo a decision after it has been implemented. The build itself is easy to undo. The commitment around it usually is not, because data gets migrated, vendors get multi-year contracts, roles get eliminated, and customers learn new workflows. Knowing the rollback cost before launch is what turns an AI initiative from an expense into an investment, since an investment is something you can size, stage, and stop.
Turning on a tool does not identify which problem it should solve, so adoption spreads without producing measurable impact. Bhatia hears the pattern constantly from companies that announce they have AI now and then grow frustrated a few months later when results do not appear. Starting from a named business problem, then asking whether AI is the right fit for it, produces outcomes that a tool-first rollout rarely reaches.
No. These systems are built to please rather than push back, so they close gaps independently and often incorrectly rather than surfacing what is missing. Two habits counter this: tell the system to ask clarifying questions before it starts, since otherwise it assumes and assumptions are where hallucinations begin, and ask it to argue against the plan rather than only build it. Most organizations never ask, so the first real objection arrives from the group the decision lands on.
