Just because you can, doesn't mean you should.

...or does it?

The phrase has done twenty years of honest work. Someone reaches for it whenever AI comes up. Nobody argues back, because nobody ever does — which should probably have been the first clue.

Just because you can, doesn't mean you should.

Sage. Unassailable. The conversational equivalent of folding your arms and looking pensively out of a window. And quietly, because the ground under it has moved, doing the opposite of what it was meant to do.

One old question, three new ones

The line got popular when new tech came in one flavour: expensive, slow, consequential. "Just because you can" was shorthand for hold on, this'll cost six figures and break something. Useful brake. Fair call.

That single question has since split into three. Most people are still driving the one brake.

Capability expanded, caution unchanged. Bad ideas in 2015, still bad ideas now. Pointing an unknown model at client data. Auto-drafting a safeguarding decision. Letting a chatbot answer for a regulated service with nobody on the other end. "Can" got cheap. "Should" didn't. The exposure here is larger than most teams think, but the principle hasn't moved an inch.

Capability expanded, caution collapsed. This is the big one, and the one the phrase is actively ruining. The small, annoying asks — the form, the internal tool, the bit of glue between two systems — used to mean a developer, months, thousands of pounds. So they got filed under "not worth it." That filing cabinet is now mostly full of stuff that's a day's work. The shackles are off; the phrase is being used to keep them on.

Capability expanded, caution expanded. The genuinely new territory. Agents taking actions in your systems. Voice that holds a conversation. Vision on a camera feed. The capability is new, the failure modes are new, and the old caution doesn't map. You need a fresh one. Most teams haven't built it yet.

Most meeting-room disagreements right now are two people arguing across those three categories without realising. One's thinking about data leakage. One's thinking about a form. Neither says which. The phrase floats overhead, looking wise, doing damage.

The test has moved

"Can we build it?" is mostly yes now. A startling amount of yes.

"Should we build it?" is too blunt to be useful. The question the phrase used to smuggle in is harder:

What does this look like in eighteen months?

Who owns it when the person who built it has left. Who notices when it starts drifting. What happens when the model provider deprecates the API, or triples the price, or ships a safety update that changes the output shape. Who gets the call when it's wrong at 11pm on a Sunday.

Operational-sustainability test, not a technical one. And a harder test — can we? you can answer in an afternoon. Who owns this in eighteen months? you mostly can't.

Two ways to get this wrong

Both are common. Both are the same mistake in opposite trousers.

Paralysed by the old logic. Teams still treating a bespoke internal tool as a six-figure decision. A month spent deciding whether to automate a form that's two hours' work. The boring-bit wins sitting in full view while the strategy meeting enters its fourth quarter.

Emboldened by the new logic. "We can!" is a feeling, not a plan. These are the projects that work beautifully for six months and then quietly become the thing nobody wants to touch. Built by someone who's moved on. Running against a model that's been superseded. No dashboards, no owner, no exit. A liability in a cardigan.

Both look like decisions. Both are reflexes with a straight face.

What to say instead

Three questions. Say them out loud about whatever's on the table:

• Would we still be glad we built this in eighteen months?
• Who owns it when I'm on holiday and it's wrong?
• What's the exit if the vendor under it changes the rules?

If any answer is "we don't know" — and honestly, it usually is — the "should we?" is "not yet." Not "no." Not forever. Just not yet, because we haven't worked this bit out.

That's the thing the old phrase was doing for us, quietly, and isn't any more. It made us ask the harder question without having to name it. Can we? is cheap enough now that the hard question has to be on the agenda in its own right. You can't smuggle it in the back any more.

A note on our own bias

We build this kind of thing for a living. Read the rest accordingly.

That said — the three questions above aren't marketing ones. They're the ones that separate a project that keeps working from one that quietly becomes a liability. If you've got an internal team that can genuinely hold them over an eighteen-month horizon, go. Build it yourselves. That's a real answer.

If you haven't, this is one of the moves where the cost of going solo tends to show up two quarters in, not on day one. It almost never arrives as "we couldn't build it." It arrives as "we built it and now nobody's quite sure who's looking after it" — which is a different problem, and a much more expensive one to unwind. The shape of the work that holds those questions is here. Worth a look either way.

Close

The rule hasn't been retired. It's been sharpened.

"Just because you can, doesn't mean you should" still holds. What's moved is which side of the line most ideas actually sit on now. Twenty years ago most things landed on the "don't" side, because the cost was real, the upside was speculative, and the reversal path was expensive. Now most of what lands on a normal team's desk is on the "yes, but work out who owns it" side.

The brake isn't broken. It just needs the question underneath it put back on.