How to choose a software development company

Choose a software development company by checking how it works from day to day. A good partner puts the code and accounts in your name, gives you a written scope and estimate before you commit, shows working software at regular intervals, tests the parts that handle money and personal data, documents what it builds, and stays available after launch. Ask about each of these on the first call and ask to see evidence. The cheapest or fastest quote is rarely the best one if it leaves any of them out.

#What to look for in a development partner

Portfolios and sales decks tell you what a company has built for others. The points below tell you what working with it will be like for you.

Ownership of the code and accounts

The source code should live in a repository you own or can take over at any time. Hosting, domains, app store accounts, payment provider accounts and third-party services should be registered in your company's name, with the developer added as a user. If the relationship ends, you should be able to hand everything to another team without asking for permission. Our article on who owns the code and accounts when you hire a developer lists what to check in detail.

A written scope and estimate

Before you agree to anything, you should receive a document that restates your goal, lists what is included and what is not, names the assumptions behind the estimate, and explains how changes will be handled. A price in an email with a one-line description is not a scope. The written version protects both sides, because disagreements later can be settled by reading it.

Visible progress

Ask how you will see the work while it happens. The strongest answer is a working demo at a fixed rhythm, for example every two or three weeks, on a test server you can open yourself. Status reports and screenshots are weaker evidence. A team that only shows the product near the end leaves you no room to correct course.

Testing

Ask which parts of the system get automated tests. You do not need tests on every screen, but payments, logins, permissions and anything that changes important data should be covered. Ask how a bug found after launch is handled and who pays for fixing it.

Documentation

At minimum you need instructions for setting up the project on a new machine, a description of how it is deployed, a list of external services and their credentials stored somewhere you control, and API documentation if the project has an API. Documentation is what makes a later handover possible.

Support after launch

Software needs updates for security patches, new browser and operating system versions, and changes in the services it connects to. Ask what support looks like after launch, how requests are made and priced, and whether you can stop at any time.

#Red flags to watch for

• A firm price before any questions. If a company quotes without asking about users, integrations or data, it is guessing, and the guess will be corrected later at your expense.
• Accounts in the developer's name. Hosting, domains or store accounts registered to the agency make you dependent on it.
• No access to the code until the final payment. Paying for milestones is reasonable. Being unable to see what you are paying for is not.
• Everything is possible, quickly. A serious team tells you what is hard, what is risky and what it would leave out of a first version.
• Vague answers about who does the work. You should know whether the project is built in house or passed to subcontractors, and who is responsible for quality.
• No mention of testing or documentation. If these do not come up until you ask, they probably are not part of the plan.
• Pressure to sign. Discounts that expire in days are a sales tactic. A good proposal is still good next week.

#Questions to ask on the first call

Use the first conversation to learn how the company works. These questions tend to produce useful answers:

1. What do you need from us before you can give a written estimate?
2. Who will own the repository, the hosting and the other accounts from the first day?
3. How often will we see working software, and where?
4. Which parts of a project like ours do you cover with automated tests?
5. What documentation do we receive, and when?
6. How do you handle a change in scope halfway through?
7. Which pricing model do you suggest for this project, and why?
8. What happens after launch, and what does support involve?
9. If we later move to another team, what will the handover include?
10. Can you show us a similar project, or the code of something you have built?

Listen for specific answers. "We use modern best practices" says nothing. "Payments and login have automated tests that run on every change" tells you something you can check later. If you want to prepare before the call, a short written brief of your goal, users and key flows will make the conversation and the estimates far more precise.

#How to compare proposals fairly

Proposals from different companies are often hard to compare because each one describes a slightly different product. Before comparing prices, make them describe the same thing.

• Build a scope table. List your key features and flows down the left side and each proposal across the top. Mark what is included, excluded or unclear. Unclear items become questions for each company.
• Read the assumptions. One quote may assume you supply all texts and images, another may include design. One may assume a single language, another two. These differences explain most price gaps.
• Check the exclusions. Data migration, admin screens, email templates, store submission and hosting setup are common items that one proposal includes and another leaves out.
• Compare the pricing model. A fixed price and a time-based estimate carry different risks. Our article on fixed price or time and materials explains the trade-off.
• Look at what happens after launch. Include support terms in the comparison, since the first year after launch often brings more requests than expected.

Point to compare	Weak proposal	Strong proposal
Scope	A list of feature names	Flows, roles, integrations and explicit exclusions
Estimate	One number	A breakdown with the assumptions behind it
Progress	A delivery date	Demos at a fixed rhythm on a test server
Ownership	Not mentioned	Code and accounts in your name from the start
Quality	"Fully tested"	Named areas covered by automated tests
After launch	"Support available"	How requests are made, handled and priced

After this exercise the lowest price is often no longer the lowest, because it covered less. The proposal you understand best, with the fewest open questions, is usually the safest choice.

#Trust what you can verify

References and reviews can help, but treat them as one input among several. Things you can verify yourself carry more weight: a sample of written scope, public code on GitHub, a demo of a past project, a clear answer about ownership. A short paid first phase, such as a technical review or a prototype of the riskiest feature, is another good test. It shows you how the team communicates, estimates and delivers before you commit to the whole project.

#How PN Scripts can help

PN Scripts works the way this article describes: the code, accounts and documentation are in the client's name from day one, you get a written scope and estimate before anything is agreed, and web projects show a working demo every two to three weeks. If you are comparing companies, send us your project and we will reply within one business day.