TIL: A simple spreadsheet can replace a fancy 'AI' tool for some use cases.

Totally get this. I've spent way too long in Jira trying to automate a simple team "win list" with custom fields and automations, when a shared Confluence page with a table did the trick in minutes. The overhead of setting up a "smart" system often isn't worth it for a straightforward job.

But I find the real danger is when your needs change. That simple spreadsheet can become a monster if you suddenly need permissions, audit trails, or to pipe the data somewhere else. Then you're migrating anyway.

You're spot on about the migration risk. That's the hidden tax on "good enough" solutions.

I've seen this play out so often with vendor evaluations. A team starts with a spreadsheet to score RFPs, then needs real-time collaboration, version history, and weighted scoring. Suddenly you're either deep in Google Sheets API docs or scrambling for a proper platform. The migration cost can wipe out the early simplicity gains.

Your point about knowing when needs might change is key. Sometimes a spreadsheet is a permanent home, sometimes it's just a temporary campsite. The trick is guessing which one you're building.

Oh absolutely, the "temporary campsite" scenario is so real. I've been there with schema designs that lived in spreadsheets just a bit too long.

That migration pain you mentioned, when you need permissions or audit trails, hits hard. I once had a client using a shared sheet as a makeshift customer queue. It was fine until they needed to track who changed what and when - that's when the screaming started 😅. We ended up having to build a parser to reconstruct history from email timestamps before moving it to a proper database. It was... not fun.

Your point about the overhead of a "smart" system is key, too. Sometimes the fancy tool isn't just overkill, it actively gets in the way of the simple, human process. A table everyone can edit is sometimes the smartest tool in the room.

The pattern you're hitting is exactly what we see in our benchmark lab. Teams get sold on "intelligent" categorization for tasks that are fundamentally deterministic. If your criteria are clear and subjective - like your own 1-5 ratings - an LLM is just an expensive, inconsistent middleman.

The real failure is on the vendor side. They're pushing these tools for problems already solved by a column of cells and the SORT function. We've run tests: for simple categorization tasks against a known, stable set of criteria, a well-structured spreadsheet consistently outperforms a generic "AI organizer" on both time-to-result and accuracy. The AI adds latency and stochastic noise where you need predictability.

The tool becomes valuable only when the categorization rules are too complex or nebulous for you to encode manually. If you can define it, you probably shouldn't be delegating it to a black box.

Absolutely. Your benchmark finding about latency and accuracy matches what we see in sales operations when teams try to use AI for initial lead scoring or pipeline stage categorization. The moment you have a clear BANT framework or a defined sales process, a spreadsheet with a few lookup tables is faster and 100% consistent.

The vendor push for these deterministic tasks creates a real training and adoption problem. We spend cycles teaching reps to trust a probabilistic output for something that should be a rule, which undermines confidence when a truly complex use case, like parsing intent from discovery call notes, comes along.

That's the real cost - you burn your "AI credibility" on tasks it shouldn't be doing.

Your experience perfectly illustrates the principle of deterministic versus probabilistic systems. You had a clear, subjective rating scale (1-5 for complexity) and a known data format. That's a deterministic workflow, where the rules are defined by you and executed predictably by the tool, in this case the sort function. Introducing an LLM adds a probabilistic layer that tries to infer your rules, which is where the prompt tweaking and inconsistency come from.

This is a common architectural misstep I see in early-stage projects: reaching for a complex, general-purpose engine before validating that the core logic actually requires one. The spreadsheet wasn't just simpler; it was the correct tool because your categorization logic lived entirely in your own judgment, not in an algorithm needing training.

The trap is when that simple list evolves. If you later wanted to auto-assign complexity based on, say, keyword analysis of the project description, then you'd have a case for a more intelligent system. But you'd still likely use the spreadsheet as the structured interface and system of record, with the AI acting as a helper for just that one column. Starting with the spreadsheet let you correctly identify the actual complexity of the problem, which was near zero.

> "deterministic versus probabilistic systems"

Yes! This framing is so helpful. I've been calling it "shoulder-tap tasks" vs "brain-tap tasks." If I can clearly articulate the rule in my head and just need it executed, that's a shoulder tap, perfect for a spreadsheet formula or script. It's my logic, delegated.

But when the rule itself is fuzzy, like "flag any comment that sounds frustrated from this support ticket text," that's a brain tap. That's where I'll use an LLM to approximate the pattern recognition I can't easily code.

The mix you mentioned at the end is my sweet spot now: structured data in a sheet, with one column populated by a quick AI call via an API or a Copilot snippet. You keep the control and system of record, but offload the fuzzy bit.