How to Choose a Software Development Company: 10 Questions to Ask

Most failed software projects were lost before the first line of code — at vendor selection. The polished pitch decks all look alike, so the way to tell partners apart is to ask questions that force specific answers. Here are the ten we'd ask if we were on your side of the table, including the ones that make agencies uncomfortable.

The 10 questions

1. Who exactly will write my code? The people in the sales call are rarely the people on your project. Ask to meet the actual engineers, or at minimum see their profiles. High subcontracting churn is where quality goes to die.

2. Who owns the intellectual property, and when? The only acceptable answer: you own everything, transferred as it's paid for, in writing. Vendors who keep IP hostage until final payment — or forever — are building leverage, not software.

3. How will we communicate, and how often? You want a named point of contact, a fixed weekly demo of working software, and asynchronous updates in between. "We'll send monthly reports" is a warning sign; a month is long enough to build the wrong thing twice.

4. Can I see the code while it's being written? You should have access to the repository from day one. If a vendor resists this, ask yourself why.

5. What happens at handover? Documentation, deployment scripts, credential transfer, and a walkthrough for whoever maintains the system next. Ask for a sample of handover docs from a past project. Vague answers here mean expensive lock-in later.

6. What are your security practices? Concrete answers include code review requirements, dependency scanning, secrets management, and access control for staff. "We take security seriously" is not an answer.

7. What does post-launch support look like, and what does it cost? Software needs ongoing care — typically 15–20% of build cost per year, as we covered in our breakdown of custom software costs. A vendor with no support offering is planning to disappear.

8. Tell me about a project that went badly. Everyone has one. A vendor who can describe a failure and what changed afterward has a learning process. A vendor who's never had a rough project is either brand new or lying.

9. What would you cut from my project? This is our favorite. A good partner will push back on scope and tell you what not to build in version one. A vendor who enthusiastically agrees to everything is quoting, not thinking.

10. Who are your references — and can I call them? Then actually call them. Ask the reference one question above all: "Would you hire them again for something bigger?"

Red flags that override good answers

• A detailed fixed quote produced within 24 hours of your first call, before anyone asked hard questions.
• Prices dramatically below market. The money you save up front reappears as rework — usually with interest.
• No pushback on anything you propose.
• Reluctance to give repository access, meet engineers, or share references.
• Contracts that make leaving painful: IP retention, punitive termination clauses, proprietary platforms only they can maintain.

Any one of these should slow you down. Two or more should end the conversation.

Score it, don't feel it

Selection meetings reward charisma, and charisma doesn't ship software. Put the ten questions in a spreadsheet, score each vendor 1–5 per question, and add a column for red flags. It takes twenty minutes per vendor and forces a comparison of substance instead of vibes. When two vendors score similarly, weight questions 5, 7, and 9 — handover, support, and willingness to say no are what you'll actually live with for years.

Honest aside: sometimes you don't need a company

If your project is small, well-defined, and low-risk — a marketing site, a simple internal tool, a prototype to test an idea — a good freelancer is often the better choice: cheaper, faster, less overhead. Where a company earns its premium is continuity (people can leave a freelancer arrangement instantly), breadth (design, development, DevOps, security in one team), and projects that will live for years and need someone accountable at 2 a.m. If you're genuinely unsure which you need, that scoping question is itself worth an hour of independent consulting before you commit to anyone.

Where we stand

We're obviously not neutral — Kodenique is one of the companies you might be evaluating. So judge us by our own checklist: our engineers join calls, clients get repository access from the first sprint, IP transfers as it's paid for, and we'll tell you when we think you shouldn't build something. You can read more about how we work on our about page.

If you're comparing vendors right now, get in touch — bring these ten questions, and we'll answer all of them on the first call.