How to Choose a Custom Software Developer: A 12-Question Checklist for Small Business Owners

Most small business owners only hire a software developer once or twice in their career. By the time they figure out what they should have asked, the money is already spent and the project is either built or stuck. That is a terrible learning curve to be on, especially for something that is going to run a meaningful part of the business for the next ten years.

This guide is not about which programming language to ask for or what cloud provider to use. It is about the small set of questions that, if you ask them up front and pay attention to the answers, separate the developers worth hiring from the ones who will quietly burn through your budget. Most of these do not require any technical background. They require a willingness to slow the conversation down and insist on real answers.

The four kinds of developers you will meet

Before the questions, the categories. Every developer you talk to falls into one of four buckets, and each one comes with a different set of trade-offs:

• Solo freelancer. One person, often very good, sometimes very fast, almost always overcommitted. The risk is concentration: if they get sick, get a bigger client, or burn out, your project stops. Best for a small, contained build that does not need to be supported for years.
• Offshore agency. Lower hourly rates, larger teams, often introduced through a referral. The risk is communication latency, time zone gaps, and vague accountability when something goes wrong. Best when you have an experienced in-house product owner who can manage the work day to day.
• Domestic boutique agency. A small team — usually under ten people — with a project owner who stays involved end to end. The risk is bandwidth: a small shop can only run so many projects at once, so the timing has to work. Best for SMB owners who want a fixed scope and a single point of contact.
• Full-time hire. A developer on payroll. The risk is that you have to keep them busy for years to justify the cost, and a single hire is also a single point of failure. Best once your roadmap is genuinely large enough to support an in-house team.

None of these are wrong. They are different tools. The mistake is treating them as if they were the same and picking on price alone. A cheaper hourly rate from an offshore team is not actually cheaper if the project takes three times as long and you spend your nights writing requirement documents at midnight.

The 12 questions to ask before you sign anything

Read these out loud in the first or second meeting. Take notes. The answers will tell you more than any portfolio piece.

1. Will you give me a fixed price for a defined scope?

This is the single highest-signal question in the whole list. A developer who cannot give a fixed price for a defined scope is telling you, politely, that they do not know what it will take to build what you are asking for — or that they are not willing to take any of the risk of being wrong about it. Hourly billing transfers all of the schedule and budget risk onto you, and almost every horror story you hear about runaway software projects starts with an hourly contract.

Fixed price is not a magic bullet. It only works when there is a real scoping conversation up front and a written scope that both parties sign off on. But if the developer is unwilling to do that work or unwilling to commit to a number when it is done, you are paying for the privilege of being their R&D project.

2. Who, by name, will be writing the code?

The senior developer in the sales meeting is not always the developer who shows up on the project. Ask who specifically will be on the build. Ask how many other projects they are on at the same time. Ask whether you will have a single project owner or a rotating set of account managers. Then ask to meet the person who will actually be doing the work before you sign.

3. Who owns the code when you are done?

You do. Or at least, you should. The contract should say in plain language that all source code, design files, and documentation produced under the agreement become your property on payment. If the developer wants to keep ownership and license it back to you, walk away. You are paying for the asset. You should own the asset.

4. Where will the code live, and what happens if we part ways?

Your code should live in a repository on a major hosting service — GitHub, GitLab, Bitbucket — under your account, with the developer added as a collaborator. Your application should run on infrastructure you can access and own (your AWS, your Vercel, your Supabase, your Azure). Hosting under the developer's account is fine for early prototyping, but before launch, the production environment should be in your name with the developer granted access — not the other way around.

The reason is simple. If the relationship ends — for any reason, friendly or not — you should be able to revoke access in five minutes and have a working system that another developer can pick up. If your only path to the code is through the current vendor, you do not have an asset. You have a hostage situation.

5. How do you handle scope changes?

Scope creep is the most common reason custom software projects miss budgets and deadlines. A serious developer has a written change-order process. They will tell you, before you sign, exactly how a request to add or change a feature gets reviewed, priced, and approved. Vague answers here — “we handle that as it comes up” — are how three-month projects become twelve-month projects.

6. What is your testing and QA process?

You do not need to understand the technical details. You need to hear that there is a process. Are there automated tests? Is there a staging environment where you can review work before it goes live? Who tests the build before the developer says it is done? If the only quality control is you finding bugs after launch, the developer is using your business as their QA team — and your customers will eventually find the bugs you do not.

7. How do you handle data security and credentials?

This is a soft check on professionalism. Ask how they handle passwords, API keys, and customer data during development. The right answer involves a secrets manager (AWS Secrets Manager, GitHub Secrets, 1Password Business, Doppler — anything purpose-built) and an explicit policy about never storing credentials in code or in chat. The wrong answer is anything that includes the words “we just email them.” A developer who is sloppy with secrets in 2026 is going to be sloppy with your customers' data, too.

8. Can I see code or systems you have built for other small businesses?

Portfolio screenshots are easy to fake. Ask for a reference customer you can actually call. Ask what they built, when it shipped, and whether the customer is still using it. A developer who cannot produce a single small business client who will return your call has either never had one, lost them all, or is too new to be running your project. Any of those is worth knowing before you sign.

9. What does support look like after launch?

Software is not finished when it is launched. It is launched when it is ready for the next round of changes. Ask what happens the day after launch. Is there a support agreement? A monthly retainer? An hourly rate? A response-time commitment? Is there someone on call if the application goes down at 11 p.m. on a Saturday because a database certificate expired?

The point is not that you need a 24/7 SLA. Most small businesses do not. The point is that the developer should have an answer that is more specific than “just call me.”

10. What integrations have you built before?

Most small business software lives or dies on integrations — QuickBooks, Stripe, HubSpot, Google Workspace, the customer's industry-specific tools. Ask the developer about the specific integrations on your project. Have they built against that API before? Do they know the rate limits, the sandbox environments, the auth flows? An integration the developer has done three times is going to take a week. The same integration learned for the first time is going to take a month.

11. How will you communicate during the build?

Weekly demos are the gold standard. Every week, a working demo of the new features, even when they are unfinished. Slack or email check-ins are nice, but a weekly demo gives you something most software projects never have: a real, in-the-open look at progress, while there is still time to change direction. If the developer wants to disappear for six weeks and emerge with a finished product, they are protecting themselves, not you.

12. What are the warning signs in my own project?

A serious developer will push back on parts of your scope. Not because they are difficult, but because they have built a hundred of these and they know which features are going to cause problems. Watch for that. If the developer agrees with everything you say in the first call and never raises a single concern, they are selling, not consulting. The developer you want is the one who tells you, in the first meeting, that the way you have described feature X is going to be expensive and probably is not what you actually need — and then offers a better path.

Red flags that should send you running

Some patterns are signals that the engagement will go badly no matter what the contract says. If you see two or more of these in your conversations, keep shopping:

• They quote a price without ever asking what you are trying to build. The price is meaningless if it is not tied to a scope. A serious developer will not give you a number until they understand the work.
• They cannot explain what they will deliver in plain English. If every question gets answered with technical jargon, you are not going to be able to manage them once the project starts.
• They are vague about who owns the code. Or, worse, the contract draft includes a clause where the developer retains ownership and licenses it back to you. That is not standard. That is a trap.
• They want to host everything under their accounts. A short-term staging environment is fine. Long-term production hosting under a vendor account is how small businesses lose access to their own systems.
• They will not let you talk to a current client. Every developer with real customers can produce a reference call. Reluctance here is a tell.
• They lowball the price by promising a feature list that would take twice as long for an experienced team. They are either inexperienced, planning to run change orders to recover the margin, or both.
• They show up to every meeting with a sales rep but no developer. The relationship between you and the person actually building the software matters more than the contract. If you cannot meet that person before signing, you do not know what you are buying.

Green flags worth paying a premium for

On the other side, certain patterns are worth paying more for. The cheapest quote is rarely the cheapest project, and these are the things that tend to differentiate the work that goes well from the work that does not:

• They scope the project before quoting it. The first deliverable is a written scope document with screens, workflows, and acceptance criteria. The price is a result of the scope, not a number pulled out of thin air.
• They push back on the parts of your idea that do not make sense. Disagreement up front is a sign of experience. Total agreement up front is a sign of a sales call.
• They have a clear answer for what happens after launch. Whether it is a maintenance retainer, a fixed-price care plan, or hourly support, there is a model and it is in writing.
• They show working software every week or two. Long radio silence between contract signing and final delivery is the leading indicator of a project that is going to slip.
• They use modern, mainstream technologies. Not the bleeding edge, not legacy stacks. Whatever they pick should be something a different developer could pick up two years from now without retraining.
• They answer ownership and access questions before you ask. A developer who proactively explains where the code will live, who has access, and how to revoke it is a developer who has done this before.

What a healthy first conversation actually looks like

The right first call does not feel like a sales pitch. It feels like a doctor's appointment. The developer asks more questions than you do. They want to understand what is broken in the current system, who uses it, how often, and what the workaround costs you each week. They are not in a rush to close. They are in a rush to understand.

By the end of that call, the developer should be able to play back your problem in their own words. If they cannot, they have not heard you. If they can — and the playback includes things you said that you thought were throwaway details — that is the developer to keep talking to.

From there, a serious engagement looks like a written scope document, a fixed price, a defined timeline, weekly demos, a clear ownership and access model, and a stated support plan after launch. None of that is exotic. All of it is rare in the wild. Insisting on it is the single most reliable thing a small business owner can do to land in the small percentage of custom software projects that go well.

Frequently asked questions

If you are evaluating a developer right now and want a second set of eyes on the proposal, start with a conversation. We will scope your project before talking about a build, and we will tell you honestly if a different vendor is the better fit.