Five Questions Every Buyer Should Ask Before Hiring a Software Development Firm

If you are evaluating software firms right now, you already know how much is riding on getting this right. 

Real budget on the line, a timeline that has to hold, and a team that has been promised this build will fix something they have been working around for too long. 

Underneath all of it, the worry that the firm in the proposal will look very different from the firm doing the work eight months in.

That worry is not paranoid. 

McDonald's and IBM spent five years building an AI voice ordering system across more than 100 drive-through locations before McDonald's ended the partnership in June 2024. The viral wrong orders made headlines. 

The real story was a buyer-vendor relationship that did not survive contact with real users. The largest restaurant brand in the world hired one of the largest enterprise vendors on earth and still ended up with a system not worth keeping.

We have spent over a decade on the other side of these conversations, watching projects go well and watching projects go sideways. 

The five questions below are the ones we tell our own prospects to ask any firm they are considering, including us. 

They are not designed to make us look good. 

They are designed to surface how a firm actually operates when the work gets hard, which is the only thing that matters once the contract is signed.

‍

What These Questions Are Actually For

Vendor RFPs are designed to compare deliverables. 

These five questions are designed to surface the truth about how a firm operates under pressure. 

‍

1. What happens after launch?

Launch day is the milestone everyone shows up for. The two years after launch are what determine whether the build was worth it.

Most firms deliver and step back. The contract closes, the team that learned your business moves on, and six months later you are paying someone else to relearn what the last firm already knew or you are stuck inside a system nobody wants to maintain.

A strong answer comes with structure:

• A defined post-launch warranty period, with the firm fixing real bugs at no cost
• Hosting and maintenance the firm actually runs, with named team members who stay available
• A partnership model designed to evolve the software as the business changes
• A track record of clients who have stayed for years, not single-project relationships

A weak answer sounds like "we are available if you have questions." 

That sentence has no edge to it. It commits to nothing, because the firm does not plan to be there.

‍

2. Have you ever talked a client out of a feature, or out of a project entirely?

This is the question that separates a vendor from a partner. A firm paid by the hour or by the deliverable will build whatever the client asks for. A firm trying to keep a relationship for the long term will sometimes argue against the build.

A real answer to this question comes with a real story. The feature, the conversation, what happened next. If the firm cannot remember an example, they have either never said no or they are not used to thinking of those conversations as part of the job. Both are worth paying attention to.

We have walked clients out of AI features they came in asking for. The most common version of the conversation goes something like this: the client wants an AI assistant in a part of the product where the workflow already works, and the assistant would only create a second place for the user to look without giving them anything new. 

Saying that out loud to a client is uncomfortable. Every relationship that has come out of one of those conversations is stronger for it.

‍

3. How is the work priced, and what happens when scope changes mid-project?

Pricing is where most projects start to slip, and where most buyers feel the pressure first. Time and materials billing has a meter that never stops. Change orders, in the wrong firm's hands, are a profit center. The pattern plays out every quarter inside companies that never end up in court but still write off significant chunks of their software budget.

A strong answer is fixed-fee pricing with a scoping process rigorous enough to make the fixed fee real. Look for:

• A free or low-cost scoping engagement before any contract gets signed
• A written estimate that ties cost to specific deliverables, not blanket hours
• A clear process for handling real scope changes when the business evolves mid-project, separate from the initial scope creep firms create on purpose
• A willingness to walk away from the work if scope cannot be defined

A weak answer is hourly rates and a promise to communicate proactively. 

That is the answer that ends in the lawsuit, or in the quiet budget overrun the team will spend a year trying to explain.

‍

4. Who is actually writing the code, and where are they sitting?

You are about to share something close to the center of your business with a team you have not met. Most buyers do not realize how much of that team gets swapped out after the contract is signed. 

The senior architects in the sales meeting are rarely the developers writing the code, and the buyer often ends up with junior contractors in three time zones, none of whom were on the original call.

A strong answer specifies the team. Where they are, what level of experience they have, how long they have been at the firm, and what the firm does to keep the same people on the project from start to finish.

We believe that business is built on transparency and trust, and that good software is built the same way. 

The team writing the code is where that trust either lives or does not. If a firm cannot tell you who that team is, the firm is not in a position to back the work.

The geography conversation also matters more in 2026 than it did five years ago. AI tooling has eliminated some of the cost differential that drove software work offshore. 

What it has not eliminated is the friction of a team that does not understand the business it is writing code for.

‍

5. What does your AI integration approach look like, and where have you said no?

AI is what your board is asking about. It is also where the most expensive bad decisions are happening right now. 

Almost every firm in our industry claims some version of AI-driven, and the McDonald's drive-through is the kind of outcome that happens when AI gets bolted onto the wrong workflow.

A strong answer goes into how the firm decides where AI belongs in a product. Look for:

• A workflow-mapping process before any AI tool gets selected
• Specific examples of AI features the firm has declined to build for clients, and why
• A clear position on cost-at-scale, since the inference costs that work at demo usage rarely work at production usage
• A view on where AI does not belong in your specific product, not just where it does

A weak answer is the phrase AI-driven repeated until the meeting ends. The firm cannot describe the line because they have not drawn one.

‍

What to Do With the Answers

You do not need to ask these questions perfectly. You just need to ask them, and listen for whether the answer comes with specifics or with deflection. 

The buyer who runs this checklist before signing tends to find the firm worth hiring within three meetings, even when that firm is not us.

We have spent over a decade trying to be the firm that answers these questions well. We tell our prospective clients to ask them of every firm they evaluate, including us, because the truth about how a firm operates is more useful than any pitch deck.

The firm that earns the work is the one that holds up under the questions.

Whether you hire us or someone else, run the list before the contract gets signed. 

Two to three years of your software roadmap depend on it.