Key takeaways
- Write a two-page brief and name the person on your side who will make decisions every week before you contact any vendor.
- Shortlist three to five firms, and weight experience with your type of system above experience in your exact industry.
- Walk away from firm prices given after one short call, code kept in the vendor’s repository and pressure to sign quickly.
- Your contract should give you ownership of the code and accounts, termination on 15–30 days notice and a warranty, often 30–90 days.
- Run a paid discovery phase or small first project, typically 2–6 weeks long, before committing to the full build.
Knowing how to choose a software development company is mostly about managing risk. Nearly every firm's website makes the same promises, so the website won't help you much. The differences show up in how a vendor scopes work, how they communicate when things go sideways, and what the contract says about who owns the code. This is the checklist we'd use if we were sitting on your side of the table.
Do your own homework first
Vendors can only respond to what you give them. A vague request gets you vague proposals that are impossible to compare. Before you talk to anyone, write down:
- The business problem in plain terms. “Our dispatchers re-key every order into three systems” is better than “we need a logistics platform”.
- Who will use the software and roughly how many people.
- The systems it has to connect to, such as your ERP, CRM, accounting package or payment provider.
- Your budget range, your deadline, and which of the two is actually fixed.
- The person on your side who will make decisions and answer questions every week.
If you can't name that last person, sort it out before hiring anyone. More projects stall on the client side than people like to admit, and no vendor can fix a missing product owner.
Building a shortlist
Three to five firms is plenty. More than that and you'll spend weeks in sales calls. Good sources are referrals from peers who have shipped something similar, review sites (read the detailed reviews, then verify with your own reference calls), and partner directories for platform work such as Microsoft Dynamics 365.
Filter on experience with your type of system more than your exact industry. A team that has built three scheduling apps will understand your scheduling app faster than a team that has worked in your industry but never built scheduling. Industry knowledge still helps, especially in regulated fields like healthcare and finance, but the technical pattern matters more.
Get the size fit right
A very large consultancy may staff your $150,000 project with whoever is free that month. A two-person shop may stall if one developer leaves. For most mid-sized projects, the sweet spot is a firm big enough to cover vacations and turnover and small enough that a senior person knows your project by name. You want to be a meaningful client, not a rounding error.
Questions to ask in the first calls
Pay attention to how specific the answers are. Good vendors answer with examples and trade-offs. Weak vendors answer with adjectives.
- Who exactly will work on my project, and can I talk to them before we sign? You want names, roles and a call with the lead developer. Watch for a senior team in the sales meeting and a junior team on the actual work.
- What does a normal week look like? Look for a shared backlog you can see, a demo of working software every one or two weeks, and a single named lead you can call.
- What happens when you find out an estimate was wrong? A good answer is that they tell you early, explain why, and offer options: cut scope, extend the timeline or add budget. “That doesn't happen” is a bad answer.
- How do you test? Look for automated tests, code review on every change and a staging environment that mirrors production. “Our developers test their own work” is not enough by itself.
- Can you show me something similar you built? Ask for a live walkthrough rather than screenshots, and ask what they would do differently today.
- How do you deploy and host? You want to hear about automated pipelines, infrastructure defined in code, and cloud accounts that belong to you.
- What happens after launch? Get the support terms, response times and warranty period in writing.
- Can I talk to two past clients, including one where the project hit trouble? How a firm handled a bad month tells you more than any success story.
Red flags worth walking away from
- A firm fixed price after one short call. Either they are guessing or they have padded it heavily.
- No questions about your business. If they only ask about features and never about your users or how you make money, they'll build what you said rather than what you need.
- They want the code in their own repository and will hand it over “at the end”.
- Everything is described as easy. Experienced engineers name the risks early, because they have been burned by them.
- Pressure to sign quickly, like a discount that expires Friday.
- References that never call back, or no references at all.
- One developer who knows everything, and no documentation anyone else could use.
- Unclear answers about who writes the code. Subcontracting isn't automatically bad, but you should know who the subcontractor is and where they work.
- Rates far below the market with no clear explanation of how quality is managed.
Contract terms that protect you
Always have a lawyer review a development agreement. What follows is general guidance on what to look for, not legal advice. These are the terms we'd read first.
| Term | What good looks like | Watch out for |
|---|---|---|
| IP ownership | You own the custom code, designs and documentation, assigned to you on payment | Vendor keeps ownership and licenses your own app back to you |
| Pre-existing tools | Vendor keeps its reusable libraries but grants you a perpetual, royalty-free license | Ongoing fees to keep using components built into your product |
| Code and accounts | Repository, cloud, domains and app store accounts owned by your company from day one | Everything in the vendor’s accounts until final payment |
| Termination | You can end the contract with 15–30 days notice and pay for work done | Long minimum terms or large exit fees on a first engagement |
| Warranty | Defects in delivered work fixed at no charge for a set period, often 30–90 days | No warranty, or one that starts before you have actually used the software |
| Data protection | NDA, data processing terms, and a Business Associate Agreement if they will touch health data | Production data copied to developer laptops with no written rules |
| Liability and insurance | A reasonable liability cap plus professional liability and cyber insurance | Liability capped at a tiny amount, or no insurance at all |
A note on non-solicitation clauses: most vendors will ask that you not hire their developers directly for a period. That's normal and fair. Make sure the period and any fee are reasonable, and that the clause runs both ways.
Run a paid trial before the big commitment
The best way to judge a firm is to work with it. Before signing a six-month contract, run a paid discovery phase or a small first project, typically 2–6 weeks long. A good discovery produces a clickable prototype, an architecture outline and an estimated backlog. A good small project delivers one self-contained feature into production.
During the trial, watch the behavior more than the output. Did they ask sharp questions about your business? Did they flag risks without being asked? Were demos on time? Is the code already in your repository? How did they handle the first disagreement? If the trial goes badly, you've lost a few weeks and a small budget, not a year.
Everything produced in a discovery phase should be yours and usable by another vendor. If the deliverables only make sense if you hire the same firm for the build, it was a sales exercise, not discovery.
Onshore, nearshore or offshore
Rate differences between regions are real, and so are the costs of distance. The biggest practical factor is time-zone overlap. Software projects run on hundreds of small decisions, and each one waits if your team and the vendor aren't awake at the same time. Offshore teams can work well for clearly specified work with a strong technical lead on your side. For projects where requirements will evolve, overlap during your business day is worth paying for.
Canadian firms are one nearshore option for US companies. Most of Ontario and Quebec runs on Eastern Time, contract and business norms are close to what US companies expect, and travel for a workshop is a short flight. We have offices in Toronto as well as New York, Chicago and Dallas, so weigh the point accordingly, but the underlying logic applies to any vendor you consider.
Scoring the finalists
Once you have two or three proposals, score them the same way so the cheapest or the most polished one does not win by default. A simple weighted scorecard works:
- Understanding of your problem. Did the proposal reflect what you told them, or could it have been sent to anyone?
- Team quality. Based on the people you actually spoke to, not the company bio.
- Process and transparency. Backlog visibility, demo cadence, how estimates are tracked.
- Contract terms. IP, access, termination and warranty as covered above.
- Price, compared on equal scope. Normalize the proposals so you are comparing the same work.
Give price real weight, but not the most. The cheapest proposal is often the one with the most exclusions, and you find out what was excluded after you sign.
The short version
- Write a two-page brief and name your decision-maker.
- Shortlist three to five firms with experience in your type of system.
- Interview the people who will do the work, not only the sales team.
- Walk away from firm prices without discovery, vendor-owned repositories and pressure tactics.
- Get IP ownership, account ownership, termination rights and a warranty in the contract.
- Start with a paid discovery or small project before committing to the full build.
If you'd like to put us through this checklist, we're happy to answer every question on it. Email sales@tag4tech.com or reach us through our contact page.