Quick answer:
Choose a software development company by verifying five things before price: who actually writes the code, whether you’ll own it, how they handle scope changes, what happens after launch, and whether they can show revenue outcomes, not just shipped features. The 12-point checklist below turns those five into questions with verifiable answers.
The wrong development partner doesn’t just cost the budget. It costs the year. And most companies pick one using the two least predictive signals available: how polished the portfolio looks and what the hourly rate is.
The stakes compound quietly. We’ve written before about businesses that spend $20,000 to $100,000 building software their own teams avoid, and most of those stories trace back to this decision, made in a hurry, on the wrong signals.
The selection is hard because every vendor presents the same way. The demos are smooth, the screenshots are beautiful, and the proposals are written to be agreed with. The differences that decide whether your project ships or stalls are structural and contractual, and none of them are visible in a sales call unless you ask for them directly.
A custom software development company designs, builds, and maintains software the client owns: CRMs, ERPs, web and mobile applications, and the integrations between them, as opposed to configuring off-the-shelf products. The good ones run discovery before quoting, put code ownership in writing, and stay accountable after launch. The rest of this guide is how to tell them apart.
Aerosoft Global is a custom software development company, so read this knowing where we sit. The checklist still works if you never talk to us; every item on it is verifiable from a vendor’s own documents and answers.
Define the problem before the vendor
Vendor selection usually fails at the brief, not the shortlist. Before you request a single quote, write one page: the business problem, who will use the system daily, which existing tools it must talk to, and what success looks like in revenue or operational numbers. Vendors quote what you ask for. Ask for ‘an app’ and you will receive quotes for an app, priced with no reference to the outcome you actually need.
If the page feels hard to fill, that’s a finding in itself. The brief needs only four sections: the problem in operational terms (what happens today, and what it costs), the daily users and what they’ll stop doing manually, the systems the new software must read from or write to, and the number that defines success a year after launch. Two hours of writing here saves two months of building the wrong thing.
A one-page brief also gives you the first filter for free. Send it out and watch what comes back. Vendors who respond with questions are doing their job. Vendors who respond with a price are guessing, and you will pay for the guess later. It’s the same reason serious custom software development firms insist on a discovery phase before committing to numbers.
On assembling the shortlist itself: referrals from businesses your size beat directories, because they come attached to a two-year track record instead of a review score. Beyond referrals, look at the firms behind products you already admire, and treat review platforms as a source of candidates rather than a verdict. Three to five vendors is the right number; enough for signal, few enough to run the full checklist on each.
One more test worth running early: ask whether you should build at all. A vendor who will happily tell you that an off-the-shelf tool beats a custom CRM for your situation is a vendor whose advice you can trust when the answer is less convenient. A vendor for whom every problem needs custom software is selling inventory, not solutions.
The 12-point vetting checklist
Run every shortlisted vendor through all twelve. None of these require technical knowledge; they require asking and reading.
- Who writes the code. Ask whether the engineers are the vendor’s employees or subcontracted, and ask to meet the people who will actually build your project before you sign. If the answer involves a third company, the accountability chain just got longer than your contract, and every delay will happen somewhere you can’t see. A good answer names people; a bad answer names a ‘resourcing process.’
- Proof of outcomes, not screenshots. Screenshots prove design taste. Ask for case studies with numbers attached: adoption rates, hours saved, revenue moved, support tickets reduced. Then ask how they measured it, because the method tells you whether the number is real. A vendor who has never measured the business result of their own work will not start with yours.
- Discovery before quotes. A fixed price offered after one call is a guess with your name on it. Serious vendors scope first: they interview users, map the systems involved, and write down what’s in and out. Ask what discovery costs, what artifacts you receive, and whether you can take those artifacts elsewhere if you part ways. The ones worth hiring answer all three without flinching.
- Code ownership in writing. The contract should assign full intellectual property to you on payment, not license it back to you. If the word ‘license’ appears where ‘assignment’ should be, that clause is the whole negotiation. Read it before the pricing pages; a great price for software you don’t own is not a great price.
- Where the code lives. Repositories and cloud accounts should be yours from day one, with the vendor working inside them as invited collaborators. This costs nothing to set up and removes the single most common exit dispute. If leaving the relationship means asking for your own code, don’t sign.
- The scope change process. Every project changes; pretending otherwise is how fixed prices turn into disputes. Ask exactly how changes get estimated, priced, and approved, who signs off, and where the running list of changes lives. Vague answers here are the origin of every horror-story invoice you’ve heard. The best vendors volunteer this process before you ask.
- Communication cadence and overlap. Who do you talk to weekly, and is that person on the build team or standing between you and it? How many working hours overlap with yours? When do you see demos: every sprint, or only at milestones? You’re buying a months-long working relationship, and the rhythm is part of the product. Insist on seeing unfinished work regularly; polish hides problems.
- Testing as a line item. QA should appear in the estimate with its own hours and, ideally, its own people. When testing is ‘included’, it’s invisible, and invisible work is the first thing cut when a deadline slips. Ask what gets tested automatically, what gets tested by hand, and who signs off that a release is ready.
- Post-launch support terms. Ask for the defect warranty period, response times by severity, and what maintenance costs monthly once the warranty ends. Software isn’t finished at launch; it’s finished when it’s retired. A vendor with no support offering is planning to be gone by the time you find the first real bug.
- Team continuity. Ask what happens when your lead engineer leaves mid-project, because on a six-month build, someone will. The honest answer involves documentation standards, code review practices, and overlap periods between people. The dishonest answer is that it won’t happen. You’re listening for a system, not a promise.
- Security and data handling. Who gets access to production data, how are development and production environments separated, and can they describe their access controls without a pause to think? If you operate in a regulated space, ask for evidence of comparable work under comparable rules, not assurances that it will be fine.
- References you choose. Don’t call the two clients they offer; every vendor has two happy clients. Ask for one from two years ago whose system is still running. What software looks like after two years of maintenance, and what the vendor was like when things broke, tells you more than any launch-week testimonial.
A practical way to use the twelve: score each vendor 2, 1, or 0 per item, and treat four of them (ownership, repository access, the change process, and discovery) as disqualifiers rather than preferences. A vendor can be forgiven a thin portfolio. A vendor who won’t put IP assignment in writing isn’t a maybe; they’re a no wearing a good proposal.
One structural de-risking move outranks everything else on this page: start with a bounded first engagement. A paid discovery, or a small first module with its own budget and deadline, tests every checklist answer against reality for a fraction of the commitment. Vendors who perform well in a four-week engagement rarely transform in month three, and vendors who resist a small start are telling you the relationship only works when leaving is expensive.
Pricing models compared: fixed, T&M, dedicated team
Vendors typically offer one of three commercial structures, and each moves risk in a different direction.
| Pricing model | How it works | Best for | Watch out for |
| Fixed price | One quote for a defined scope, paid by milestones | Small, tightly defined projects with a finished spec | Change requests get expensive; vendors pad the quote to absorb risk |
| Time & materials | You pay agreed rates for hours actually worked | Evolving scope and ongoing product development | Budget discipline sits with you; needs active oversight and caps |
| Dedicated team | A standing team billed monthly, directed by you | Long-term products with a continuous roadmap | Overkill for one-off builds; ramp-up time before full productivity |
In practice, most healthy engagements are hybrids: a fixed-price discovery phase, then time and materials with a monthly cap for the build. The model matters less than the change process attached to it. And no pricing structure protects you from a bad brief; it only decides who pays for the ambiguity.
When quotes arrive, normalize before comparing. Ask every vendor to price the same one-page brief, state what’s excluded, and separate discovery, build, and first-year support into their own lines. Two quotes that differ by 40 percent usually aren’t pricing the same project; the gap is scope you can’t see yet, and it’s cheaper to find it in a spreadsheet than in month four.
Red flags in proposals and portfolios
A price after one conversation. If they can quote your project after a single call, they priced a template, not your problem. The number will survive right up until the work starts.
A portfolio with no live links and no client names. Confidentiality covers some work; it doesn’t cover all of it. A vendor with years of history should have something you can click and someone you can call.
A perfect track record. Every experienced firm has a project that went sideways. The useful question is what they changed afterward. A vendor with no scars either hasn’t shipped much or isn’t telling you the truth, and both answers matter.
The team switch. Senior people run the sales process, then delivery is handed to people you’ve never met. Ask, in writing, who is assigned to your project and what happens if that changes.
The rate as the headline. Cheap hours that need twice as many of them aren’t cheap. Compare estimates at the level of total cost to outcome, including the change process, support, and the price of delays.
Pressure discounts. A price that expires on Friday is a sales tactic borrowed from car lots. Custom software is a months-long relationship; a partner who opens it with manufactured urgency has told you how the rest will go.
No questions about your business. If the proposal could have been sent to your competitor without edits, it was. A vendor selling custom software should be curious about the thing the software is for; indifference during the courtship is the high-water mark of the attention you’ll get.
IP, code ownership, and contract terms
The contract is where good vendors and bad vendors finally look different on paper. Four terms carry most of the weight. First, IP assignment: everything built for you is assigned to you on payment, full stop. Second, access: your repositories, your cloud accounts, your credentials vault, from the first commit. Third, warranty: a defined period, usually 60 to 90 days, during which defects are fixed without debate about whose fault they are. Fourth, exit: termination rights with a written handover obligation, so leaving is a decision rather than a hostage negotiation.
One nuance worth understanding rather than fearing: pre-existing components. Most firms bring their own internal libraries and tooling to every build, and assigning you ownership of those would be unreasonable. The correct structure is a perpetual, irrevocable license to use them within your product, and a contract that lists them explicitly. What you’re avoiding isn’t shared components; it’s discovering them for the first time during a dispute.
Confidentiality runs both directions and deserves one deliberate paragraph. A mutual NDA before discovery is standard, and any vendor should sign one without ceremony. Less standard, and worth asking for, is a clause covering your data during development: where copies of it live, who can see them, and when they get destroyed. Vendors who handle production data casually during builds are more common than anyone admits.
If a vendor resists any of the four core terms, believe the resistance. Contracts are where intentions live, and a firm that plans to treat you well loses nothing by writing it down.
