How to choose a software development company

To choose a software or web development company, look less at the pitch and more at the evidence: live projects you can open and test, how the company investigates your problem before quoting, how clearly the proposal defines the scope, and who will actually work on the project.

Then check what guarantees your independence: the code, the domain, the hosting and the repository must be in your company's name. Finally, understand what happens after delivery, with documentation, support and maintenance defined in writing.

Price matters, but you can only compare it when the proposals describe the same thing. A cheap proposal with a vague scope often ends up costing more.

What to evaluate before hiring

Live projects you can open and test

Portfolio images show the look, not whether the product works. Ask for links to websites and systems in production. Open them on your phone, fill out a form, browse the pages, see whether they load quickly. For apps, find the listing in the app stores and read the reviews.

When the system is internal and cannot be opened, ask for a demo with sample data and a conversation with someone who uses the product. Projects similar to yours in complexity, not necessarily in industry, say more than a long list of logos. PERVOX's projects can be checked right on this website.

How the company runs discovery

Discovery is the stage in which the vendor works to understand the problem: who will use the system, which processes it supports, what it needs to integrate with, what is essential and what can wait. A good company asks uncomfortable questions, challenges features that do not seem necessary and suggests starting smaller when that makes sense.

If you arrive with a well-written brief, notice whether the company reads it, discusses it and digs deeper, or replies with a standard quote within a few hours.

Clarity of the proposal and scope

Scope is the list of what will be delivered. A clear proposal describes the features, the main screens or pages, the integrations, what is excluded, the phases, the criteria for accepting each delivery and the support terms. If two proposals cannot be compared line by line, ask for more detail before deciding. The article on fixed-price vs. hourly development explains how each pricing model affects what should be in writing.

Communication

During negotiation, pay attention to how quickly and how well the company responds. Ask how progress will be tracked: how often there will be meetings or reports, where decisions are recorded, who your point of contact is, and whether you will have access to a test environment to follow progress before final delivery.

Who will work on the project

The people in the sales conversation are not always the ones who build the product. Ask who will be on the project, what experience they have and whether any part of the work will be subcontracted. Subcontracting is not a problem in itself, as long as it is disclosed and accountability stays clear.

Ownership of the code and accounts

This is the point that causes the most trouble later on. Make sure the contract states that:

• The source code belongs to your company at the end of the project, or under the agreed conditions.
• The repository (where the code and its history are stored, such as GitHub or GitLab) is in an account owned by your company or will be transferred to it.
• The domain is registered to your company. In Brazil, that means under the company's CNPJ, its national business registration number. The article on domain and hosting shows how to check this.
• Hosting, app store, email and third-party service accounts are in the company's name, with administrator access for someone on your side.

Documentation

Documentation is the record of how the system works and how to deploy it. A reasonable minimum includes a high-level view of the architecture, installation and deployment instructions, configuration variables and the main business rules. Without it, switching vendors becomes slow and expensive.

Support after delivery

All software needs care after launch: fixes, security updates, adjustments. Ask whether there is a warranty for fixing defects and for how long, and how software maintenance works after that.

Security and data protection

If the system handles personal data, protection must be part of the project from the start. Ask how the company controls access, stores passwords, makes backups and logs who accessed what. The guide on LGPD, Brazil's data protection law, for websites and software helps you know what to ask for. If you operate elsewhere, check the rules that apply in your country.

Red flags

• A proposal without a scope. A price and a deadline with no description of what will be delivered leave everything open to interpretation. The disputes show up precisely at delivery.
• A price far below the others with no explanation. Sometimes there is a legitimate reason, such as building on an existing platform. If there is no explanation, the difference is usually something left out: testing, responsive design, security, documentation or support. The article on how much a website costs details what usually explains price differences.
• A promised deadline before the problem is understood. Anyone who guarantees a date in the first conversation does not yet know what they will build.
• No access to the code. If the vendor resists giving you access to the repository during the project, or makes handing over the code conditional on an unplanned extra fee, your company becomes dependent on them.
• Accounts in the vendor's name. A domain, hosting plan or app store developer account registered to the developer makes any change of vendor difficult.
• Nobody questions anything. Agreeing to every requested feature without discussing priority or cost points to little analysis.

Questions to ask in the first conversation

1. Which projects similar to this one are live, and can I test them?
2. How do you gather requirements before finalizing the scope? Is that stage billed separately?
3. Who will work on the project, and who will be my point of contact?
4. How often will I see progress? Will there be a test environment?
5. Will the code, repository, domain and hosting be in my company's name?
6. What documentation will be delivered with the system?
7. Is there a warranty for fixes after delivery? For how long?
8. How are scope changes handled during the project?
9. How will the system protect the personal data it handles?

More than the right answers, look for specific ones. "It depends" is an acceptable answer when it is followed by "on what".

Freelancer, agency or in-house team

Freelancer

An independent professional usually costs less and communicates directly. This works well for small, well-defined projects, such as a business website or a landing page. The risk is concentration: if that person gets sick, changes careers or runs out of availability, the project stops. It is also rare for one person to be strong in design, development, infrastructure and security at the same time.

Development company

A company brings together different skills, has delivery processes and does not depend on a single person. It is a registered legal entity bound by contract, which makes it easier to formalize warranties. It makes sense for custom software, apps, integrations and projects expected to continue over time. The hourly cost tends to be higher than a freelancer's, and it is important to check that the company is actually the one doing the work.

In-house team

Hiring your own developers makes sense when software is central to the business and will keep evolving for years. It gives you full control, but it requires recruiting, managing and retaining people, plus keeping knowledge in several areas. A common path is to start with an external company and build the in-house team gradually, with the documentation and code already under your company's control.

To decide, consider the size of the project, its expected duration, how strategic the system is and who inside the company will have time to follow the work.

Frequently asked questions

Should I pick the cheapest proposal?

Only if it delivers the same scope, with the same quality and the same guarantees as the others. Compare line by line: features, testing, documentation, support, code ownership. When the items match, price becomes a fair criterion.

Is it normal to pay for discovery?

Yes, on larger projects or ones with a lot of uncertainty. Paid discovery, with defined deliverables such as a detailed scope, a list of risks and an estimate per phase, reduces risk for both sides. On small projects, requirements gathering is usually part of the proposal.

Do I need to understand technology to evaluate a vendor?

No. Most of the criteria in this guide can be checked by any manager: test live projects, read the proposal, check whose name the accounts are in, ask who works on the project. For specific technical points, it is worth getting a second opinion.

How do I switch vendors without losing the system?

First, confirm that you have access to the code, the repository, the hosting and the domain. Ask for the documentation and an agreed transition, with time for the new vendor to assess the system before taking over.

Choosing a vendor is, at heart, choosing who you will share decisions with for quite a while. PERVOX builds websites, custom software, apps and integrations, and can start with a conversation about the problem, before any quote. We work remotely and can run projects in English. Get in touch if you want to talk about your project.