How to choose a software development company.

Ask every company on your list to show how it works, not only what it can do. This guide is about choosing a partner for custom software development: a system built around how your business works, not a product you license.

• Fit with your use case: has the company built a system like yours, such as a CRM, an internal tool or a portal, and can it explain the decisions it made along the way?
• Process: can it describe the steps from the first call to launch, what each step produces and what you review at each one?
• Proof: can it show working software or let you speak with a past client? Reviews help, but a conversation says more than a star rating.
• Terms for code and data: does the contract say who owns the code and from when, where the code is stored and how your data is handled and returned?
• Communication and change: who will you talk to each week, in what form, and what happens when your requirements move?

Not sure you should outsource? In-house or outsourced software development compares an in-house team, freelancers and a development company on speed, skills, risk and ownership.

The software project brief template walks through each part of a brief and shows how to turn it into a request that companies can quote. With a brief in hand, a few checks from your desk narrow the field before any call.

• Read the company's own pages for specifics. Named kinds of systems, a described process and plain terms are good signs. A list of general promises is not.
• Look for work you can inspect: a live product, a demo or a description of a delivered system in a field close to yours.
• Notice how the company writes. Clear, specific answers to a short email predict clear updates once the work starts.
• Look at who answers. If the person selling cannot connect you with the people who would do the work, ask why.
• Ask for the contract template early. Reading the terms for code, data and change before you have invested time saves a late surprise.
• Search for independent reviews and read the critical ones for patterns: a complaint that several clients repeat is worth raising with the company.

Keep the shortlist short enough that you can read every proposal properly. Give each company the same brief, the same deadline for questions and the same list of calls to take part in.

1. Which projects have you built that resemble ours, and can we speak to a client about one? Listen for a specific system and a real reference, or a plain reason one is not available.
2. Who would work on our project, and what does each person do? Listen for roles and responsibilities, and for whether the people you meet are the people who build.
3. What does the discovery phase produce? Listen for named outputs you receive in writing, such as a proposal with milestones and deliverables. What Foxefy sends after discovery is one example.
4. How do you estimate, and what happens when scope changes? Listen for a described change process and for the things that make an estimate move.
5. How often will we see working software? Listen for regular demos of real features on a test version, not slide decks or progress percentages.
6. How many working hours will we share, and how do we reach you day to day? Listen for a concrete overlap, a named channel and written updates. Working with a remote team explains why this matters.
7. Who owns the code and the intellectual property, and from what point? Listen for a direct answer that you can then find in the contract.
8. Where does the code live while it is being written? Listen for a repository in an account you can access, not only on the company's own systems.
9. How do you handle our data and access to our systems? Listen for limited access, separate test and live environments, and a plan for returning or deleting data at the end.
10. What security practices do you follow? Listen for specific practices such as access control, backups and code review, and for honesty about certifications the company does not hold. Security and data protection shows how Foxefy answers.
11. How do you test, and who signs off a release? Listen for testing during the build, not only at the end, and for a clear approval step on your side.
12. What does support cover after launch? Listen for what is included, how issues are reported and whether support is a separate agreement.
13. Which stack do you propose, and why? Listen for reasons tied to your needs and to who will maintain the system, not a default choice.
14. What documentation do we receive at handover? Listen for what is written down: setup steps, notes on how the system is structured and how to deploy it.
15. How would we move to another team later? Listen for a calm answer that covers access to the code, documentation and cooperation during the move, not a defensive one.

Write each answer in one table with a column per company. Differences stand out on paper long after the details of each call have faded. Where a company says it will send an answer later, note the date it promised and whether it arrived.

• A price quoted before anyone has asked what the system must do.
• A firm promise of cost or speed with no scope behind it.
• No working software shown until the end of the project.
• Vague answers about who owns the code or where it is stored.
• A team you do not meet before signing, or one sales contact who answers for everyone.
• Reluctance to put the process, the terms or the proposal in writing.
• No questions back to you. A company that agrees with everything has not understood the project.
• A deadline on the offer that pushes you to sign before you have compared options.
• Criticism of every other option and no explanation of its own method.

Do not read a red flag as proof of bad intent. Some are habits of a busy company. Ask about it directly, and judge the reply.

• Working hours and written updates: find out how many hours you share with the team each day and what the team does outside them. Good remote teams send written updates and keep a shared tracker, so a question asked at the end of your day is answered by the start of the next. Working with a remote software team across time zones covers the rhythm in detail.
• Contracts and governing law: a contract names the law that governs it and the place where disputes are settled. If these differ from your own, ask a lawyer to review the clauses on liability, termination and dispute resolution before you sign.
• IP assignment: ownership of the code should be assigned to you in writing, with the point at which it passes to you stated. Ask what the contract says about components the company reuses across clients.
• Data protection law: the rules that apply depend on whose data it is and where those people live, not on where the developers sit. Examples are the GDPR, PIPEDA and, for health data, HIPAA. Foxefy's security page covers these laws in more detail.
• Payments across borders: agree on the currency, the invoice schedule and who pays transfer fees before work starts, and ask how late payments and disputed invoices are handled.

Ask about each one early, while the answers are still easy to change.