Last month, a client asked me to evaluate six different CRM platforms for their 4-person landscaping company. The sales demos were impressive. The pricing pages were confusing. And none of them answered the one question that actually mattered: would their team actually use it?

After building software for small businesses and consulting on tech decisions for the past few years, I've landed on a simple framework. Five questions that cut through the marketing and get to what matters.

Does This Solve a Problem We Have Today?

This sounds obvious, but most bad tech decisions start here. Someone sees a demo, gets excited about a feature, and buys software for a problem they might have someday.

The landscaping company didn't need a CRM with email marketing automation and lead scoring. They needed to stop losing customer phone numbers written on Post-it notes. That's it. We ended up going with a shared Google Sheet and a simple form. Total cost: $0. Time to implement: 45 minutes.

Before any tool evaluation, I write down the specific problem in one sentence. "We lose customer contact info" is a real problem. "We need better customer relationship management" is marketing language pretending to be a problem.

What's the Real Weekly Time Cost?

Every tool has two time costs: the time it saves and the time it demands. Most demos only show you the first one.

I worked with a bakery that adopted a inventory management system promising to save 3 hours per week. It did save that time on inventory counts. But it also required 4 hours of weekly data entry that their previous napkin-math system didn't need. Net result: they lost an hour per week and paid $89/month for the privilege.

When I evaluate software now, I map out every touchpoint for a typical week. Not the ideal week the sales team describes. The real week where someone's out sick and orders spike on Thursday.

Who Actually Has to Use This?

The person buying software is rarely the person using it daily. This gap kills more implementations than bad software ever could.

For AshTag, the cigar lounge platform I'm building, this shapes every feature decision. The owner might love detailed analytics dashboards, but the floor staff needs to check members in with two taps while holding a conversation. If the daily users hate the tool, it doesn't matter how powerful it is.

I now require the actual daily users to be part of any software evaluation. Not just informed about it. Present in the demos, clicking through trial accounts, giving honest feedback. A tool the owner loves and the team ignores is worse than no tool at all.

What Happens When It Breaks?

Every tool breaks eventually. Server goes down. Integration stops syncing. Update changes how something works. The question isn't if, it's how bad.

For critical operations, I look at three things: Can the business function manually for a day if this tool disappears? How fast does this company respond to support tickets? Is there a way to export our data if we need to switch?

A scheduling tool that goes down means confused customers and missed appointments. A tool for tracking employee birthdays can break for a week and nobody notices. Match your redundancy planning to the actual stakes.

What's the 90-Day Checkpoint?

The best defense against bad software decisions is admitting you might be wrong. Before adopting anything, I set a specific 90-day checkpoint with clear criteria.

Not "let's see how it goes." Something measurable: "By June 15th, we should see customer response time under 4 hours and the team should rate this tool 7/10 or higher for ease of use."

If those numbers aren't hit, we re-evaluate. No sunk cost fallacy. No "well, we already paid for the year." The 90-day checkpoint isn't about finding reasons to quit. It's about creating space to be honest about whether something is actually working.

The Real Takeaway

Most small businesses don't have bad technology. They have technology that doesn't match their actual constraints: small teams, tight budgets, no dedicated IT person, staff who need to do three jobs at once.

The next time someone pitches you software, skip the feature comparison and ask these five questions instead. The answers will tell you more than any demo ever could.