Choosing a software development company is a high-stakes, low-information decision: quotes vary wildly, everyone's website says "award-winning," and you often can't judge the work until it's too late. This checklist is how to cut through it — the same way we'd want a client to vet us. We build and operate our own products, so we've sat on both sides of this table.
Start with the problem, not the vendor
Before you talk to anyone, write down three things: the problem you're solving in one sentence, who will use the software, and what "success" looks like in six months. The clearer you are here, the better every conversation that follows — and the easier it is to spot a vendor who's listening versus one who's pitching. Vague briefs attract vague quotes.
Freelancer, agency or product studio?
Three broad options, each with a sweet spot:
- Freelancer. Best for small, well-defined tasks or augmenting an existing team. Lowest cost, highest key-person risk — if they're unavailable, you're stuck.
- Agency / dev shop. Best for most business software: you get design, engineering, QA and project management as a unit. Quality varies enormously, so due diligence matters.
- Product studio. An agency that also builds and runs its own products. The advantage is operational scar tissue — they've felt what it takes to keep software live, secure and scaling, not just to launch it and walk away.
There's no universally "best" choice; there's a best fit for your project's size, risk and longevity.
Building a shortlist
Good sources: review platforms like Clutch, GoodFirms and DesignRush (read the detailed client reviews, not just the star rating), referrals from people who've shipped something similar, and the portfolios of studios whose own products you admire. Aim for a shortlist of three to five, then put each through the tests below.
The portfolio test
A portfolio of pretty mockups proves a design tool was opened. What you want is software you can actually use. Ask for live products or apps and go use them. Are they fast? Stable? Thoughtful in the details? If a company builds and runs its own product, that's the strongest possible signal — they're eating their own cooking. When we point clients at Deskloc or the Dentalk apps, the point isn't the feature list; it's that they're real, live, and ours.
Ask: "Which of these can I use right now, and can I talk to the client you built it for?" The answer tells you most of what you need to know.
Technical due diligence
You don't need to be technical to run a useful 30-minute due-diligence call. Ask how they choose a tech stack, how they handle testing and code review, how they deploy and roll back, and how they approach security. You're not grading the answers line by line — you're checking whether they have a considered process or are improvising. Improvisation is fine for a weekend project and dangerous for your business.
Who owns the code and IP
This is the clause most buyers forget, and the one that hurts most later. By default, ownership of custom software is not automatically yours just because you paid for it — it depends on the contract. Insist on explicit language that, on payment, assigns all source code, intellectual property and design assets to you, with direct access to the code repository. If a vendor hesitates here, treat it as a serious warning. You should never be locked out of software you funded.
Pricing and contracts
Expect one of three models — fixed price, time & materials, or a dedicated team (we explain the trade-offs in our cost guide). What matters more than the model is transparency: a clear scope, a defined milestone plan, and no surprise government-fee or "platform" mark-ups buried in the total. A good partner will happily fix the price for a small discovery or MVP phase so you can budget the first step before committing to the whole journey.
Red flags to walk away from
- A precise quote before any discovery — it's a guess dressed as a commitment.
- A portfolio of concepts and mockups, with nothing live to try.
- Hand-wavy answers on testing, security or what happens when something breaks.
- Reluctance to put code and IP ownership in writing.
- One charming salesperson up front and silence once the work starts.
- A quote dramatically below everyone else's — it usually means a different (smaller) scope, or rework later.
15 questions to ask before you sign
- Which live products can I use that you built?
- Can I speak to two or three past clients?
- Who, specifically, will work on my project — and will they change?
- How do you run discovery and scoping?
- How do you choose the tech stack, and why?
- How do you handle testing and quality?
- How do you deploy, monitor and roll back?
- How do you approach security and data protection?
- Does the contract assign all code and IP to me on payment?
- Will I have direct access to the code repository?
- What's your pricing model, and what's included?
- What's not included — hosting, third-party fees, maintenance?
- What does support look like after launch?
- How do you handle changes mid-project?
- What happens if we decide to part ways?
A partner worth hiring will answer all fifteen without flinching. If you'd like to put us through them, start a conversation — or see our work first.