How to choose a software development company

Start from the problem, not the technology

A good conversation starts with the people, the steps and the errors in the current process. If the supplier proposes technology before asking who uses the application, what data exists and where time is lost, the solution has been chosen too early.

Describe the outcome you want and the constraints: what has to happen faster, what must not break, which system has to be kept, and who approves changes. The right team will turn that into options, not into a list of technical terms.

Ask for evidence that can be checked

A portfolio is useful if it explains the starting situation, the decisions and the outcome, not only if it shows attractive screenshots. Ask which part was built by the team in front of you, what difficulty came up and what they would do differently today.

When confidentiality prevents naming the client, the supplier should still be able to describe the domain, the flow and the technologies without inventing figures. For important projects, ask for a direct reference with the client's consent.

Check ownership and access before the contract

• The source code must sit in a repository your company controls, or be transferable with no hidden conditions.
• The domain, cloud accounts, app stores and external services must be opened in your name.
• The contract must say who owns the code, the design, the databases and the documentation.
• You must be able to receive a working copy and installation instructions, not merely access to a product hosted by the supplier.
• Passwords and keys must not live only in a single developer's personal accounts.

A good estimate makes its assumptions visible

Look for stages, verifiable outcomes and the things that are not included. The deadline has to be tied to decisions and dependencies: API access, data to import, feedback, approvals, or publication in the app stores.

Ask what happens when an unknown appears. A serious team explains the mechanism for changing requirements and its effect on the deadline before the conflict arises.

Treat the communication process as part of the product

You have to see intermediate versions and be able to test while a change is still cheap. A regular demonstration and a clear list of open decisions are worth more than a long report sent at month end.

Agree who owns the product on your side and who makes the technical decisions on the supplier's. If every conversation passes through people who cannot decide, the lost days add up even when development moves quickly.

Warning signs before you start

• A firm price and deadline after a very short conversation, with no written assumptions.
• A refusal to hand over the code or the infrastructure at the end.
• A portfolio without context, without the team's exact role, or with results that cannot be verified.
• A promise that no maintenance will be needed after launch.
• No separate test environment, and changes made directly in production.
• Security treated as a final stage rather than a rule across the whole project.