How to Choose an IT Consulting Firm: The 12 Questions Every SMB Should Ask

Most small business owners approach hiring an IT consulting firm the same way they approach hiring a contractor to renovate their kitchen: they ask for a portfolio, check reviews, and compare bids. That process works fine when you're choosing between tile samples. It tends to fail spectacularly when you're choosing the company that will touch your operations, your data, and the software your business runs on.

The problem is not that SMB owners ask bad questions. It's that the questions most people ask - "How long have you been in business?" "Do you have experience in my industry?" "What does your pricing look like?" - are table-stakes queries that any firm worth its retainer can answer smoothly. They tell you very little about whether this particular firm will act as your technology partner or simply your technology vendor.

There is a meaningful difference between those two things, and that difference is worth understanding before you sign anything.

This guide gives you 12 questions to bring into every IT consulting conversation. These are not "gotcha" questions. They are diagnostic ones - the kind a practitioner asks when they want to understand how another firm actually operates, not how they present themselves in a pitch deck. Some questions will surface red flags. Others will help you recognize a firm that has genuinely earned your trust.

Use them all.

Table of Contents

1. Before the Questions: Understand What You're Actually Buying
2. The 12 Questions
   • Do you start with the business problem or the technology?
   • How do you handle a project that starts going wrong?
   • Who actually does the work - and where are they?
   • How do you handle budget tracking during a project?
   • What happens if the project needs to be rescued mid-stream?
   • Can you tell me about a project you turned down - and why?
   • What does your discovery process look like before you write a single line of code?
   • How do you approach AI consulting, and how do you know when AI is the wrong answer?
   • Do your clients own everything when you're done?
   • What does your client communication look like on a week-to-week basis?
   • Can you give me references from clients who had a difficult engagement - not just a successful one?
   • What is your honest assessment of whether we're ready to work together right now?
3. How to Use These Questions Together
4. What This Looks Like at Tizbi
5. Checklist You Can Bring to Your Next Conversation
6. FAQ

Before the Questions: Understand What You're Actually Buying

Custom IT consulting is not a commodity. You are not buying a service with fixed inputs and predictable outputs. You are buying judgment - the judgment of people who will help you decide what to build, what to skip, what to fix, and what to leave alone. That judgment is shaped by the firm's values, methodology, and honest assessment of your situation.

The best IT consulting firms will tell you things you do not want to hear. They will tell you when a project is underfunded, when your timeline is unrealistic, when a shiny new technology is the wrong answer for your particular business problem. The firms that win your business by telling you only what you want to hear are the same firms you'll be complaining about in eighteen months.

Keep that in mind as you work through the questions below.

The 12 Questions

1. Do you start with the business problem or the technology?

This is the single most revealing question on this list, and you should listen carefully to how it's answered - not just what is said.

A firm that leads with its technology stack, its platform partnerships, or its preferred tools is telling you something important: they have a hammer, and they are going to look for nails. Their job, as they see it, is to deploy the technology they already know. Your job is to have a problem that fits it.

A firm that starts by asking what problem you're trying to solve - what's breaking in your operation, what the business looks like today versus where you're trying to take it - is approaching the engagement differently. They are treating your business as the starting point, not the technology.

At Tizbi, we call this discovery-before-code. Every engagement begins with a structured discovery process: we ask questions before we recommend solutions. That occasionally means telling a prospective client that what they think they need is not what will actually help them. It's an uncomfortable conversation to have in a sales meeting. We have it anyway.

Red flag: The firm skips directly to capability demonstrations or platform walkthroughs without first asking about your business operations.

2. How do you handle a project that starts going wrong?

Every project of meaningful scope runs into problems. Technology projects, especially custom development work, have more variables than most business engagements - shifting requirements, integration surprises, key personnel changes, scope discoveries mid-build. The question is not whether problems will arise. The question is what the firm does when they do.

A transparent firm has a defined answer to this question. They communicate early when something is off track. They surface budget concerns before they become overruns, not after. They have a mechanism for raising issues without it becoming an adversarial conversation.

Firms that become evasive when you ask this question - who answer with generic reassurances about "project management methodologies" without describing any specific accountability structure - are often the ones that let problems compound in silence until they become your emergency.

Ask for a specific example. What went wrong on a past project? How did they tell the client? What happened next? The quality of that story will tell you more than any case study.

Red flag: The answer describes processes, not behavior. "We have weekly check-ins" is a process. "Here's a time we caught a scope issue in week two and here's how we communicated it" is behavior.

3. Who actually does the work - and where are they?

This question matters for reasons beyond staffing logistics.

Many IT consulting firms operate as intermediaries: they sell the engagement, then staff it with contractors or offshore teams whose quality they do not directly control. There is nothing inherently wrong with distributed or international development - Tizbi has development centers across Europe, South America, and elsewhere, and our international teams are skilled and deeply integrated into how we work. But there is a meaningful difference between a firm that has built and managed its own international teams over many years versus a firm that is subcontracting your project to whoever is available on a platform marketplace.

Ask directly: Are the people who will work on my project employed by your firm or contracted externally? Who manages them? How long have they worked with you?

The answer will either show you a team with continuity, established culture, and institutional knowledge - or it will show you a staffing arrangement where "quality" is a marketing promise with little operational substance behind it.

Red flag: Vague answers about "a global network of talent" with no specifics about who manages that network or how quality is maintained.

4. How do you handle budget tracking during a project?

Small and mid-size businesses are spending real money on these engagements. A $150,000 custom software project is a material investment for most SMBs - one that deserves the same fiscal discipline the client applies to every other line of their budget.

Ask the firm: How often do I see budget status? What does that reporting look like? At what point do you flag that we're approaching a budget ceiling?

Firms that give you a monthly summary at the end of a billing cycle are giving you a historical record, not an operational tool. By the time you see that number, the spend has already happened.

Firms with serious fiscal discipline build budget visibility into the daily rhythm of the project. You know where you stand - not because you asked, but because the reporting structure ensures you always know. That kind of transparency is not an administrative nicety. It is a respect for the client's financial reality.

Red flag: Budget is discussed at kickoff and again at billing. There's no structure for visibility in between.

5. What happens if the project needs to be rescued mid-stream?

This question serves two purposes. First, it tells you whether the firm has experience with distressed projects - projects that were started by someone else, stalled, built poorly, or handed off in a broken state. Second, it tells you something about the firm's self-awareness: do they understand the dynamics that cause projects to fail, or do they only work with clean slates?

Project rescue is a real discipline, and it's more common than the industry likes to admit. Plenty of businesses arrive at a new IT consulting firm carrying technical debt, incomplete code, or a partially built system that a previous team abandoned. A firm that has never done rescue work - or that dismisses it as something they don't touch - is giving you useful information about the limits of their experience.

Ask whether they've ever taken over a project mid-stream. What was broken? How did they assess it? What did it cost to stabilize versus rebuild? How long did it take?

Red flag: No experience with distressed projects, or dismissiveness about the category. It's a signal the firm has only ever worked in favorable conditions.

6. Can you tell me about a project you turned down - and why?

This question tends to surprise people. Most prospective clients ask about what a firm can do; few ask about what a firm has chosen not to do. But the answer is extraordinarily revealing.

Firms with integrity turn down work. They turn it down when the client's budget does not match the actual scope of what's needed. They turn it down when the right solution is something they don't build. They turn it down when a client is not ready - not organizationally, not financially, not in terms of what they're asking for. A firm that has never declined a project either has not been honest with its clients, or it has never been in a situation where honesty required saying no.

Tizbi's honest position on this is straightforward: we will tell you if you are not ready for AI. We will tell you if your project is better served by an off-the-shelf solution than by custom development. We will tell you if the scope you've described cannot be built for the budget you have. That is not a sales strategy - it is the only kind of consulting that actually produces good outcomes.

Red flag: The firm cannot recall a meaningful example of turning down or redirecting a client engagement.

7. What does your discovery process look like before you write a single line of code?

This question is the technical complement to Question 1. Where Question 1 reveals philosophy, this question reveals process.

Good IT consulting firms treat discovery as a distinct phase - structured, time-bounded, and output-driven. A proper discovery process produces something tangible: a documented understanding of your current state, your desired future state, the gaps between them, the technical constraints involved, and a recommended path forward. That document becomes the foundation for everything that follows.

Firms that skip or abbreviate discovery - who move from "let's talk about your needs" to a statement of work in the same week - are often doing so because discovery takes time and time costs money. What they save in upfront cost they more than spend in misaligned expectations, scope creep, and rework downstream.

Ask specifically: What does your discovery deliverable look like? How long does it take? Who is involved on your side? What decisions does it help us make before any development begins?

Red flag: Discovery is described as a few calls and a kickoff meeting rather than a structured phase with defined outputs.

8. How do you approach AI consulting, and how do you know when AI is the wrong answer?

If a firm cannot answer the second half of this question, be cautious about the first half.

AI has been attached to an enormous amount of vendor marketing over the past several years. There are legitimate, high-value applications of AI for SMBs - workflow automation, intelligent data processing, predictive analytics, custom language models trained on proprietary business data. There are also many situations where AI adds cost and complexity without adding proportionate value, where a well-designed integration or a simpler software solution would produce better outcomes for less money.

A trustworthy AI consulting firm knows the difference. They can describe specific scenarios where they've recommended against an AI solution and explain what they recommended instead. They can tell you what the realistic timeline and investment looks like for AI implementation rather than making it sound effortless. They understand that the businesses that will actually benefit from AI are the ones that first own their data - and they can explain what that means in operational terms.

Red flag: Every client problem seems to have an AI solution. No examples of "we looked at this and AI was not the right answer."

9. Do your clients own everything when you're done?

This question is not a technicality. It is existential for any business that plans to operate for more than a few years.

When a firm builds custom software and the client does not own the intellectual property, the source code, and the infrastructure configuration outright, the client is dependent on that firm indefinitely - not because the work was done well, but because the work was done in a way that creates lock-in. Access is not ownership. Access can be revoked, repriced, or held hostage in a contract dispute.

Ask directly: When you build something for me, who owns the code? Do I receive full source code with documentation? Can I walk away with everything and hand it to a different development team if I choose to? What does the offboarding process look like?

Firms that hedge on this question - who describe licensing arrangements, proprietary platforms, or "access to your system through our portal" rather than outright code ownership - are telling you something about how the relationship will be structured. It is not structured in your favor.

Red flag: Anything other than a clear, unequivocal answer that the client owns all work product.

10. What does your client communication look like on a week-to-week basis?

Not on the first week. Not during a crisis. On a regular, unremarkable week six months into an engagement.

This question exposes the difference between firms that are attentive and firms that are present. Attentive firms respond when you reach out. Present firms are actively communicating what is happening, what is coming, and what decisions they need from you - without waiting for you to ask.

Ask for specifics: What format does the weekly update take? How long does it typically take a team member to respond to a message? Who is your primary point of contact - a project manager, an account manager, or one of the people actually building the system? What happens when that person is out?

The answer will show you what it feels like to be a client of this firm a year from now.

Red flag: Communication is described in terms of availability ("you can always reach us") rather than structure ("here is what you will hear from us and when").

11. Can you give me references from clients who had a difficult engagement - not just a successful one?

Most firms offer references from their happiest clients. That is useful, but it is not the full picture. The clients worth talking to are the ones who went through something hard - a project that ran long, a scope that needed to be renegotiated, a technical obstacle that took longer to solve than expected - and came out the other side still working with the firm.

Those clients can tell you what the firm is actually like when the pressure is on. What did the firm do when they delivered bad news? Did they disappear when things got uncomfortable? Did they take accountability or route blame toward the client's requirements? Did the relationship survive honest conversation?

A firm that can only produce happy-path references either has not done difficult work or has not kept clients through difficult periods. Both are worth knowing.

Red flag: References are uniformly enthusiastic, uniformly recent, and uniformly from completed engagements with clean outcomes.

12. What is your honest assessment of whether we're ready to work together right now?

Ask this last. Ask it in those words.

A firm that is genuinely invested in your success rather than your contract will answer honestly. If your requirements are not fully defined, they will say so. If your budget is not aligned with what you're describing, they will say so. If there is organizational groundwork you need to do before a technology engagement can succeed - data governance, internal alignment, process documentation - a good firm will tell you what that looks like and help you understand what comes first.

This question is partly a test of intellectual honesty. But it is also a genuinely useful question to ask, because the answer - whatever it is - will save you from making an expensive mistake.

If the answer is some version of "yes, you're ready, let's talk about scope," and the firm has not pushed back on anything, asked any hard questions of their own, or identified any gaps in what you've described: that is a data point worth weighing carefully.

Red flag: The firm has an enthusiastic, frictionless answer to this question every single time.

How to Use These Questions Together

No single question here is a silver bullet. The value of this list is in the pattern it reveals across an entire conversation. A firm that handles ten of these well but deflects on Question 9 (who owns the code) has told you something important. A firm that handles all twelve honestly - including the ones where the honest answer is "we've made that mistake before" - has shown you something even more important.

What you are listening for, underneath all twelve questions, is whether this firm leads with your interests or their own. That distinction is not revealed in a single answer. It is revealed in the cumulative texture of how they talk about their work, their clients, and their failures.

The firms that have been doing this long enough - who have seen what happens when a client owns nothing at the end of a two-year engagement, when a budget surprise blows up a relationship, when a technology solution gets deployed before the business problem is fully understood - those firms talk about their work differently. Carefully. With a kind of earned humility that does not sound like modesty and does not sound like marketing.

That is the voice you are listening for.

What This Looks Like at Tizbi

We built these twelve questions from the inside out - not as an external vetting framework but as a reflection of how we have always believed this work should be done. After more than two decades and hundreds of completed projects across industries, we have seen most of the ways a technology engagement can go wrong, and most of them trace back to the same root causes: misaligned expectations, absent transparency, solutions in search of problems, and clients who do not own what they paid to build.

Our approach to every new engagement starts with discovery. Our budgets are tracked and visible. Our clients own everything we build for them. We turn down work when it's not the right fit - including AI projects where the business is not ready, and custom development projects where an off-the-shelf solution would genuinely serve better. And when things get hard, as they sometimes do, we have the conversations that need to be had rather than the ones that are comfortable.

We do not think this is exceptional. We think it is what responsible technology consulting looks like. But we are aware that not everyone in this industry operates this way - which is exactly why this list of questions exists.

Checklist You Can Bring to Your Next Conversation

Print this out or open it on your phone. Run through it in your first substantive conversation with any firm you are seriously considering.

• Does the firm start with the business problem or the technology?
• How do they handle a project that goes wrong? (Ask for a specific example.)
• Who does the actual work - employees or external contractors?
• How is budget tracked and communicated during a project?
• Do they have experience rescuing distressed projects?
• Can they describe work they've turned down and why?
• What does their discovery process produce, and how long does it take?
• Can they explain when AI is the wrong answer?
• Does the client own all code and IP at project close?
• What does routine, mid-engagement communication look like?
• Can they provide a reference from a client who went through something difficult?
• What is their honest read on whether you're ready to engage right now?

If you are at the stage of evaluating IT consulting partners and want to see how Tizbi answers these questions, we are happy to have that conversation - the questions included. You can reach us through the contact page, or read more about what a complete IT team partnership looks like in practice before you decide whether it's worth a call.

FAQ

What does an IT consultant actually do for a small business?

That depends heavily on what the firm does and what your business needs. An IT consultant might assess your current technology setup, recommend tools or systems, manage a software project, integrate disconnected platforms, or help you figure out whether AI is a smart investment right now or a distraction. What a good IT consultant should always do: start with your business problem, not a product they want to sell you. If someone walks in with a solution before they understand your operation, that's not consulting — that's pitching.

How is an IT consultant different from an IT vendor?

A vendor sells you something. A consultant helps you figure out what you actually need - and sometimes that answer is "not what we sell." The distinction sounds simple, but it matters enormously when you're trying to solve a real operational problem. Vendors optimize for the sale. Partners optimize for your outcome. Ask any firm you're evaluating this directly: "Have you ever told a client they didn't need what they came to you for?" The answer tells you a lot.

Do I need an IT consultant or a managed service provider (MSP)?

These serve different purposes. An MSP keeps your existing infrastructure running — networks, devices, security patches, help desk. An IT consulting firm helps you make strategic technology decisions and often builds or integrates custom solutions. If your problem is "our systems go down too much," you probably need an MSP. If your problem is "our systems can't talk to each other and we're losing hours every week to manual data entry," you need a consulting partner who can diagnose and build. Some firms do both. Many do not.

How much does IT consulting cost for a small business?

There is no universal number, and anyone who quotes you a figure before understanding your situation is guessing. Project-based work for a small business might run anywhere from $15,000 for a focused integration to well over $200,000 for a custom application built from the ground up. Hourly consulting engagements vary by region, team seniority, and scope. What matters more than the opening number: does the firm track budget daily and flag overruns before they happen, or do you find out at invoice time? Fiscal transparency is not a bonus feature - it should be standard.

Should I pay for a discovery phase before any development starts?

Yes. Almost always. A discovery phase - where the consulting firm digs into your business, your workflows, your data, and your goals before writing a line of code or drawing an architecture diagram - is how you avoid spending $80,000 on something that solves the wrong problem. Firms that skip discovery and jump straight to proposals are optimizing for their sales cycle, not your outcome. Discovery costs money. So does building the wrong thing.

What contract terms should I watch out for?

Watch for: proprietary platforms or tools that lock your data inside their ecosystem; vague deliverable definitions that give the firm wiggle room on scope; intellectual property clauses that leave ownership of your custom software ambiguous; and annual contracts for services that should scale with your actual usage. You should own what gets built for you. If that isn't explicit in the contract, ask why.

What questions should I ask during the sales process?

A few that cut through quickly: "Walk me through how you handle a project that's going sideways." "What's a situation where you told a client their idea wasn't ready?" "How do we see budget and progress - what does your reporting actually look like?" The answers to these questions reveal how a firm operates when things are not going perfectly, which is the only time the relationship really gets tested.

What are the red flags I should watch for?

Generic proposals written before they understood your business. Promises of speed without a clear methodology for quality control. Reluctance to show you how the work will be tracked or reported. Enthusiasm for the latest technology trend before hearing your problem. A firm that cannot explain why they're recommending a particular approach - only what they're recommending - is a firm operating on habit, not judgment.

Does the consulting firm need to know my industry?

Industry familiarity helps, but it is not always the deciding factor. What matters more: do they ask good questions about your business? Can they translate your operational reality into a technical architecture that actually reflects how your people work? A firm that has built solutions across many industries often brings perspective that a narrow specialist misses. Ask for relevant case examples. Judge by the quality of their questions, not just their résumé.

How do I know if a firm is genuinely prepared to help with AI?

Ask them what they built with AI in the last twelve months and what it actually did for the client. Ask them when they've told a client that AI was not the right tool for a given problem. AI consulting that is worth paying for starts with a sober assessment of your data, your readiness, and the realistic return - not a deck full of use cases that look good in a conference room. If they cannot describe a situation where they talked someone out of an AI project, keep asking questions.

What should a first engagement look like?

Ideally: a defined discovery or assessment phase before any significant commitment. A clear statement of what will be delivered, by when, and how you'll know it's done. Budget milestones, not just a final invoice. And a firm that treats the first project as the beginning of a relationship - not a transaction they're trying to close. The goal of a first engagement is to learn whether you can work well together. A good consulting partner understands that.