12 Questions to Ask Before Hiring a Software Development Partner

Hiring someone to build custom software is a big bet, and most owners only do it a few times. The proposals all look polished, the demos all look good, and it's hard to tell who will still be answering the phone six months after launch. These twelve questions help you see past the pitch.

For each one, we've included what a good answer tends to sound like. You're listening less for specific words and more for clarity, honesty and a willingness to say "it depends, and here's on what."

Scope and discovery

1. How will you figure out what we actually need?

A good partner wants to talk to the people who do the work, not just the owner. Expect them to ask to sit with your dispatcher, your warehouse lead or your billing person and watch how things happen today.

A good answer sounds like: "We'll spend time with your team, map the current process, and show you a design or clickable prototype before we write production code."

A paid discovery or blueprint phase is a healthy sign. It means the firm wants to understand the problem before committing to a price, and it gives you a usable plan even if you decide not to continue with them.

2. What would you leave out of the first version?

Anyone can say yes to everything. A thoughtful partner helps you decide what to build first and what can wait.

A good answer sounds like: "Here's the smallest version that solves the main problem. These other items are worth doing, but they can come in a second phase once you've used it."

Ownership and access

3. Who owns the code, the accounts and the data?

This is the question owners most often forget. You should own the source code, the hosting and cloud accounts, the app store accounts and every bit of your data.

A good answer sounds like: "You do. Accounts are set up in your name, and we're added as users. If we part ways, you remove our access and keep everything."

Be wary of a firm that hosts everything under its own accounts with no plan to hand them over. Contract terms around ownership matter, so have a lawyer review the agreement before you sign; this article isn't legal advice.

4. What happens if we want to switch developers later?

You're not planning to leave, but the answer tells you a lot.

A good answer sounds like: "The code lives in a repository you own, it's documented, and another competent team could pick it up."

Quality and testing

5. How do you test before something goes live?

Bugs in a quoting tool or an inventory sync cost real money. You want to know there's a process, not just good intentions.

A good answer sounds like: "We test as we build, we have a separate test environment, and your team tries each feature with real scenarios before it goes to production."

6. Who will actually do the work?

The people on the sales call aren't always the people who build your project. Ask who writes the code, who reviews it, and what happens if someone leaves partway through.

A good answer sounds like: "The engineers you're meeting are the ones building it. A senior engineer reviews every change, and you'll know ahead of time if anyone on the team changes."

Communication

7. How often will we hear from you, and from whom?

Silence is where projects go sideways. Ask who your day-to-day contact is and how updates arrive.

A good answer sounds like: "You'll have one main contact, a short check-in every week, and you'll see working progress regularly, not just status reports."

8. What happens when something goes wrong or runs late?

Every project hits surprises. What matters is how fast you hear about them.

A good answer sounds like: "We tell you as soon as we know, explain the options and the trade-offs, and let you decide."

The best partners bring you bad news early. If a firm has never had a project run into trouble, they either haven't done many or aren't being straight with you.

Launch and support

9. How will our team learn to use it?

Software nobody uses is a sunk cost. Training and adoption should be part of the plan, not an afterthought.

A good answer sounds like: "We'll train your team, provide simple how-to guides, and be hands-on for the first weeks after launch while people settle in."

10. What does support look like after launch?

Systems change. Your CRM updates its API, a carrier changes its label format, or your team asks for a new report. Ask what ongoing help looks like.

A good answer sounds like: "After the launch support period, we offer an ongoing plan for updates, fixes and monthly improvements, and you get a regular report on what we did."

Pricing structure

11. Is this fixed-price or hourly, and why?

Both models can work. A fixed price gives you a known cost for a clearly defined scope. Hourly or time-and-materials gives flexibility when the scope is still moving, but the total is less predictable.

A good answer sounds like: "Once discovery is done and scope is clear, we can give you a fixed quote and timeline. If you want to keep things open-ended, here's how we'd track hours and keep you informed."

A fixed price before anyone understands the problem is a warning sign. Either the scope is vague, or the estimate is padded to cover the unknowns.

12. How do changes to scope get handled?

You'll think of new ideas mid-project. That's normal. What matters is how they're priced and approved.

A good answer sounds like: "We write up the change, explain the effect on cost and timeline, and only proceed once you approve it in writing."

Red flags to listen for

A few answers should make you pause:

• They quote a firm price after a single short call.
• They're vague about who owns the code or accounts.
• They can't name who you'd talk to each week.
• Support after launch is "we'll figure it out."
• Every question gets a confident yes with no trade-offs.

Where to start

You can get ready before talking to anyone:

1. Write a one-page summary of the problem: what's slow, what breaks and who it affects.
2. List the tools you already use, such as Shopify, HubSpot, QuickBooks or your carrier portals.
3. Pick one or two people on your team who know the process best and can join early conversations.
4. Put these twelve questions in a doc and take notes on each firm's answers so you can compare them side by side.

If repetitive work is the main issue, our Run the numbers calculator gives you a rough sense of what it costs you each year. You can also see how we structure projects on our approach page, or browse what we build in custom software. If you'd like to put these questions to us, start with a short intro call.

General information only, not legal, tax or financial advice. Examples and figures are illustrative.