How to Choose a Software Development Company
· 6 min read · TintSol
Start with a written brief, not a search
The best software house for you depends on what you are building, so write that down before you contact anyone. A one- or two-page brief makes every conversation sharper and lets you compare answers like for like.
- The problem: who uses the product and what they cannot do today.
- The scope you know about: platforms (web, iOS, Android), key features, integrations with systems you already run.
- Constraints: launch date drivers, budget ceiling, languages, regulatory or data-residency needs.
- What you already have: designs, an existing codebase, an internal team, documentation.
- How you want to work: a defined project with milestones, or an ongoing team that keeps building.
If you cannot fill in a line, say so in the brief. A good company will help you close those gaps during discovery; a weak one will quote without asking.
Evaluation checklist: what to verify
Verify claims with evidence. Every item below can be checked in a call, a document or a reference conversation.
- Relevant shipped work: ask for two or three products similar in shape to yours (a marketplace, an internal tool, a consumer app) and ask what they would do differently now.
- Who will actually work on it: names and roles of the team, how much of their time is yours, and whether the people in the sales call stay involved.
- Discovery process: how they turn your brief into a scope, what you receive at the end (user flows, estimates, risks), and whether discovery can be bought on its own.
- Delivery rhythm: how often you see working software, how progress is reported and how you raise changes.
- Quality practice: how code is reviewed and tested before you see it, and who is responsible for testing.
- Ownership and access: you should own the code, designs and accounts, and have access to the code repository from the first day.
- Security basics: how they handle credentials, personal data and access for departing staff.
- Support after launch: what happens when something breaks at night, and how ongoing maintenance is priced.
- Communication: a named point of contact, overlap hours in your timezone, and a reply time they will commit to.
- References: at least one client you can speak to directly, ideally one whose project ran into trouble and recovered.
Red flags that should end the conversation
Most bad engagements are visible early. These warning signs come up repeatedly and are worth treating as deal-breakers or, at minimum, as questions that need a convincing answer.
| Red flag | Why it matters | What to ask instead |
|---|---|---|
| A firm quote after one short call | Nobody can estimate scope they have not explored; the gaps become change requests later. | What assumptions is this quote based on, and what is excluded? |
| Every feature is a yes | No pushback means no one is thinking about cost, risk or your users. | What would you cut from the first release, and why? |
| Portfolio with no detail | Logos and screenshots prove nothing about who built what. | What exactly did your team build here, and who can confirm it? |
| Code ownership is vague | You may not be able to move to another vendor or hire your own team. | Show me the clause that assigns intellectual property to us. |
| No access to work in progress | You only find problems at the end, when they are expensive. | When will I first see working software, and how often after that? |
| Sales team you never see again | The people who understood your brief are not the ones building it. | Who leads delivery, and can we meet them before signing? |
How to run a fair shortlist
A structured shortlist saves time and makes the final decision defensible to your board or co-founders. Keep it small and keep the inputs identical.
- Pick three or four companies with relevant work. More than that and you will not have time to read the proposals properly.
- Send the same brief to each, with the same deadline and the same list of questions.
- Hold one call per firm with the people who would lead delivery, not only sales.
- Score each proposal on understanding of the problem, clarity of scope, risks identified, team, process and price.
- Call references for your top two.
- If you are still unsure, pay for a short discovery phase with your preferred firm before committing to the full build.
When comparing prices, check that each quote covers the same things: design, testing, project management, deployment and a warranty period. A lower number often means something has been left out.
Contract points to settle before you sign
The contract is where a good relationship is protected. Read it with the same care as the proposal.
- Intellectual property passes to you on payment, including source code, designs and documentation.
- Milestones are tied to deliverables you can test, not to calendar dates alone.
- A clear change-request process: how changes are estimated, approved and billed.
- A warranty period after launch during which defects are fixed at no extra cost.
- Confidentiality and data-handling terms that match the data-protection law in your country.
- An exit clause covering handover of code, credentials and documentation if either side ends the engagement.
At TintSol we work on fixed-scope projects with defined milestones or on ongoing retainers, and we quote every engagement after reading a brief. If you would like us on your shortlist, send your brief through the contact page; we reply within one business day.