How to choose the right software developer.

Most growing businesses run on software, and the developer you pick to build it shapes how much pain you take over the next two years. The wrong choice costs you twice: once on the failed build, again on the rebuild. If you’re hiring a custom software developer and don’t know what to look for, this is the short list.

Know your needs before you start calling

Before you hire anyone, you need a clear read on the problem you’re solving. Look at what comparable businesses (competitors or not) are already using. That tells you what your real needs are and what already works in your space.

You’re looking for how they solve their problems and what you can borrow. This saves you weeks of arguing about scope and points you at the right kind of vendor.

Look for industry-relevant developers

Software development is a broad field. Plenty of firms can technically solve your problem, but a vendor with no exposure to your industry will burn weeks ramping up on the basics. After you know the type of software you need, filter by industry experience.

Custom software lives or dies on how well the developer understands your business. A team that already serves companies like yours starts at speed. A team that doesn’t will spend your money learning. If your industry has specific rules (financial, healthcare, government), the risk multiplies.

Freelancer, agency, or in-house studio

The kind of vendor you hire matters as much as the specific company. Each fits a different size of job.

• Freelancer. Cheapest, fast for a small and well-defined task. You carry the risk: one person gets sick, takes another contract, or disappears, and the project stalls. Fine for a script or a single feature. Risky for anything your business runs on.
• Large agency. Full team, formal process, account managers. Good for a serious platform with budget to match. The catch is layers between you and the people writing code, and juniors doing the work that the senior names in the pitch implied.
• Boutique studio with an in-house team. Senior people you talk to directly, no offshore handoff, one team that owns the project end to end. This is where Calibre sits. It suits a real build that still needs close contact and accountability.

Match the team to the risk. The more your business depends on the software, the less you want a single point of failure.

The offshore handoff problem

Plenty of firms sell you a local salesperson and a senior lead, then route the actual build to a subcontracted team in another timezone. The pitch and the code come from different people. You notice when a simple change takes a week, the answers get vague, and nobody on the call wrote the line you’re asking about. Ask one direct question early: who writes the code, and are they employees or subcontractors? An in-house team answers without hedging.

Ask for references

The best way to find a reliable vendor is through people who’ve already worked with them. Start with your network:

• Customers
• Suppliers
• Business partners
• Personal contacts

Search online and on social. Industry forums help, but discount reviews from sources you don’t trust. Be critical with both praise and complaints, looking for the concrete details under the noise. A developer with no online footprint is a red flag.

Check their reputation

This is the step that protects you. Check their client list, read online reviews, and (better) talk to a past client by email or phone. A two-minute call usually tells you what a hundred testimonials won’t.

Check how long they’ve been in business

Years in business correlate with problems already solved. A team that’s shipped for a decade has seen most of the edge cases yours will hit. A team a year out of stealth has not.

Ask how past implementations went

The best preview of your project is somebody else’s project. Talk to previous clients and ask how the engagement ran. Ask about communication style too, so you know whether their cadence works for your team.

Watch the contract

Even with a great vendor, this is still a business relationship. Get it in writing. The clauses that protect you later are the ones people skip in the excitement of starting:

• Scope and deliverables. What gets built, in plain terms, with a change process for anything beyond it.
• IP ownership. You own the software and the code. Say it explicitly.
• Source code access. You get the full repository, not a compiled black box you can’t maintain.
• Hosting and credentials. Accounts and domains live in your name, not the vendor’s.
• Handover. A defined way to transfer everything if you part ways.

The cost of getting these wrong shows up six months after launch, when the relationship sours or you want to move on and find the code sitting on someone else’s server.

Questions to ask before you sign

Run this list on your shortlist. The answers separate a partner from a pitch:

1. Who writes the code, and are they employees or subcontractors?
2. Who owns the source code and IP when we’re done?
3. How do you handle a change in scope mid-project?
4. What does support look like after launch, and what does it cost?
5. Can I talk to two clients you’ve shipped for?
6. What happens if we decide to move the project elsewhere?

Still weighing whether to build custom at all? Start with custom vs off-the-shelf and why custom software matters before you brief a single vendor. When you’re ready to see real work, our case studies show how projects ran end to end.

Common questions

How much should custom software cost?

It depends on scope, not on the hourly rate alone. A small internal tool runs in the low five figures. A platform with multiple user types and integrations runs much higher. Be wary of a quote far below the others: it usually means the vendor missed the scope and will come back for more once you’re committed.

Should I hire a freelancer, an agency, or an in-house team?

A freelancer is cheapest and fits a small, well-defined job, but you carry the risk if they vanish. An agency brings a full team and process, which suits a real platform. A boutique studio with an in-house team sits between the two: senior people, direct contact, no offshore handoff. Match the size of the team to the size and risk of the project.

Who owns the source code when the project is done?

You should, and the contract should say so in plain terms. Make sure IP ownership, full source code access, hosting credentials, and handover are written into the agreement before work starts. If a vendor resists putting code ownership in writing, walk away.

What questions should I ask before hiring?

Ask who does the actual coding, whether work is in-house or subcontracted, who owns the code, how they handle changes to scope, what support looks like after launch, and for two references you can call.