Questions to Ask Before Hiring a Custom Software Development Company: What I Wish I'd Known

The first custom software development company I hired had a polished pitch, a beautiful portfolio, and references who said glowing things. Six months later, the project was over budget, behind schedule, and the software didn't solve the problem I'd hired them to fix. The company wasn't dishonest. I had simply asked the wrong questions.

The questions you ask during evaluation determine the quality of what gets built. Ask surface-level questions, and you'll get surface-level answers that sound reassuring but reveal nothing. Ask specific, challenging questions, and you'll see how a company thinks, communicates, and handles pressure before you've committed a single dollar.

Here are the questions I now ask every custom software development company before signing a contract—and what their answers reveal.

Questions About How They Work

Who will actually write the code, and how much time will they spend on my project?

This is the question that saved me from repeating my worst hiring mistake. During the sales process, I met senior engineers who were articulate, experienced, and impressive. After the contract was signed, those senior engineers disappeared. The actual work was done by junior developers I'd never met, supervised by a senior engineer who spent a few hours a week on my project.

Now I ask directly: who will write the code? What percentage of their time will be dedicated to my project? Will I have direct access to them, or will communication go through a project manager? Companies that hesitate to answer this question are revealing something important about how they staff projects.

Good companies are transparent about team composition. They tell you that a senior engineer will design the architecture and review code while junior developers handle implementation. They explain the ratio and the oversight process. Poor companies give vague answers about "our talented team" without specifics.

What happens when something goes wrong?

Every software project encounters problems. The question isn't whether problems will occur—it's how the company handles them. I ask for specific examples: tell me about a project where something went seriously wrong and how you handled it.

Companies that answer this question well describe specific failures, the steps they took to address them, and what they changed afterward. They demonstrate accountability and learning. Companies that answer poorly claim nothing ever goes wrong—which means they're either lying or they've never done enough work to encounter problems.

I also ask about their escalation process. If I'm unhappy with progress, who do I talk to? What happens if the project manager and I disagree about priorities? How are disputes resolved? The answers reveal whether the company has mature processes or relies on ad hoc approaches that break down under stress.

Questions About Communication

How will you handle it when I change my mind?

Requirements change. It's not a sign of bad planning—it's a sign of learning. The question isn't whether changes will occur but how the company handles them.

Good companies have a clear change management process. They explain how change requests are evaluated, how they're priced, and how they affect timelines. They don't pretend changes are free, but they don't treat them as betrayals either. Poor companies either promise to accommodate any change at no cost—which means they're either lying or cutting corners—or they resist changes entirely, which means you're locked into decisions made when you knew the least.

I also ask how they document decisions made during development. When we decide to change direction, how is that decision recorded and communicated? Who needs to approve it? The answers reveal whether the company has processes for managing complexity or whether they rely on verbal agreements that will be disputed later.

What will you need from me that I'm not expecting?

This question reveals more than any other about a company's experience. Inexperienced companies assume the client just provides requirements and reviews deliverables. Experienced companies know the client needs to provide domain expertise, make timely decisions, review work promptly, and be available for questions.

When a company gives me a specific, honest answer about what they'll need from me—time commitments, decision turnaround expectations, access to internal systems or subject matter experts—I know they've done this before. When they say "just tell us what you want and we'll handle everything," I know they're either inexperienced or dishonest.

Questions About the Project

What would you do differently from what I've described?

This is my favorite evaluation question. I describe what I want to build, then ask the company how they'd approach it differently. The answer reveals whether they think critically or just take requirements at face value.

The best companies push back. They identify assumptions I've made that might be wrong. They suggest alternative approaches I haven't considered. They explain trade-offs I didn't know existed. They demonstrate that they're thinking about my problem, not just taking my money.

Companies that say "that sounds great, we'll build exactly that" without any questions or suggestions are telling me they won't add value beyond writing code. I can hire developers anywhere. I'm looking for a partner who improves my thinking.

This kind of critical thinking is especially important when deciding between custom and off-the-shelf solutions—a decision I've learned to make before I even start evaluating vendors.

What's the smallest useful thing you can deliver first?

I no longer hire companies that want to spend months building before showing me anything. The best companies think in terms of incremental delivery—what's the smallest piece that provides real value and can be delivered quickly?

This question reveals whether a company understands iterative development or just pays lip service to it. Good answers include specific features, timelines, and criteria for what "useful" means. Poor answers involve hand-waving about "sprints" and "milestones" without concrete deliverables.

The smallest useful deliverable also serves as a test of the relationship. If the first increment goes well, we continue. If it doesn't, we've learned something valuable without committing to a year-long engagement. Companies that resist this approach are often companies that benefit from commitments that outlast problems.

Questions About After Launch

What happens after you deliver the software?

Software isn't finished when it launches. It needs maintenance, updates, and occasional fixes. I ask specific questions about post-launch support because I've been stranded by companies that delivered working software and then disappeared.

What's included in the initial engagement? How are bugs handled after launch? What's the warranty period, and what does it cover? How are ongoing maintenance and new feature development priced? What happens if the developers who built the software leave the company?

Good companies have clear answers to all of these questions. They've thought about the entire lifecycle, not just the initial build. Poor companies wave off these concerns with reassurances that "we stand behind our work" without specifics. Reassurance without detail is just words.

If we part ways, how do I get my code?

This question is uncomfortable to ask, which is exactly why you should ask it. The answer reveals whether you're truly the owner of the software you're paying to build or whether the company retains leverage over you.

I now require explicit answers about code ownership, documentation handoff, and transition support before signing any contract. The code should belong to me. The documentation should be sufficient for another developer to understand and maintain the system. There should be a defined process for transitioning the codebase if the relationship ends.

Companies that resist clear answers to this question are telling you something important about the relationship they envision—one where you're dependent on them indefinitely.

Conclusion

The questions I've listed here aren't theoretical. They're the product of projects that succeeded and projects that failed, of companies I'd hire again and companies I'd warn others away from. The common thread is that good answers are specific, honest, and sometimes uncomfortable. Bad answers are vague, reassuring, and designed to close the deal rather than set expectations.

A custom software development company that answers these questions well is a company that understands what they're committing to. One that answers them poorly is revealing something important—and you should listen.