How to choose a software development company by its portfolio and references
A pretty portfolio proves nothing. Anyone can put together slides with client logos. What counts is what you can verify.
Ask to see products that are live: download the app from the store, open the system, check the date of the last update. A published, maintained app says more than ten presentations. Also ask what the company's role was in each project, because plenty of companies present as their own a job that was only design, or only one part of the code.
References are worth something when you actually talk to the person. Ask for the contact of a client with a project similar to yours and of another who has worked with them for years. A long relationship is strong evidence: nobody renews with a vendor that delivers poorly and disappears.
Useful questions at this stage:
- Which products you built are live today, and can I try them?
- What exactly was your part in each one?
- Can I speak with a current client and with one whose contract has ended?
- Is there a project similar to mine in size and type of problem?
Who will actually work on the project
The most common mistake we see is meeting the sales team and only finding out who the technical team is after the contract is signed. The person presenting the proposal is almost never the one who writes the code.
Ask for the names, experience and role of each person assigned: who decides the architecture, who develops, who tests. Ask whether they are employees or contractors, and what happens if someone leaves in the middle of the project. A good answer includes documentation and code review, so that one person leaving doesn't bring everything to a halt.
Talk to the person who will lead the project technically, not just the sales rep. In half an hour of conversation you can tell whether they understand your business or are just repeating technical terms.
Scope and change: how the company handles what wasn't in the plan
Every project changes. A company that promises a fixed scope with no flexibility at all is either underestimating the work or will charge you heavily for every change. You need to know in advance how change is handled.
Ask how the scope is described (features, screens, business rules, what is left out), how a new request is estimated and approved, and who decides when something goes in and something comes out. Fixed-price, hourly and dedicated-team models all work, each for a different type of project, and the company should be able to explain why it suggests one of them. If you want to understand what drives the final price, we have a guide on how much a custom system or app costs.
The same logic applies to timelines. Be wary of an estimate given in five minutes, with no questions asked. A serious proposal comes only after understanding the rules, integrations and users.
Code ownership, access credentials and vendor lock-in
This is the issue that causes the most headaches years later, and almost nobody asks about it. Make it clear in the contract that the source code is yours, or under what conditions it becomes yours.
Also check where the code is stored. The repository should be in an account owned by your company, or with you as administrator, and not only in the vendor's account. The same goes for the domain, app store accounts, server, database and third-party services. If everything is in the software company's name, switching vendors makes you a hostage.
Also ask whether there is enough documentation for another team to take over the system. You don't have to leave, but you need to be able to. It's a good measure of how much confidence the company has in its own work.
Testing, partial deliveries, security and maintenance after delivery
Software delivered all at once, at the end of several months, is a recipe for surprises. Prefer partial deliveries every few weeks, in an environment you can open and use. That way a misunderstanding shows up in week three, not in month eight.
On testing, ask what is tested and by whom: automated tests on the most critical rules, code review, testing on real devices in the case of apps. On security, ask how passwords and personal data are handled, who has access to the production environment, how backups are made and whether they have ever actually been restored. A backup that has never been restored is just a hope.
And then there's the after. A system doesn't end at delivery: libraries become outdated, stores change their requirements, users ask for adjustments. Ask who fixes bugs, within what timeframe, and how hosting and updates work. We wrote a separate piece on what is included in software maintenance and how to contract it, which is worth reading before you sign any contract.
Software company or freelancer: what about an in-house team?
There is no universal answer. Each option solves a different problem.
A freelancer is usually the right choice for small, well-defined tasks: a tweak, a simple website, a one-off integration. It costs less and is agile. The risk is depending on a single person: if they fall ill, change jobs or run out of time, the project stops, and nobody else knows the code.
A software company makes sense when the project requires several skill sets (back end, front end, mobile, design, testing) and continuity. You get a team, a process and someone to answer to after delivery. In exchange, you pay more per hour and need to verify everything we've listed above, because a company's size doesn't guarantee quality.
An in-house team pays off when software is at the core of your business and will evolve for many years. Hiring, training and retaining engineers is expensive and slow. Many companies start with a software company, learn what they need and only then build their own team, with a product already up and running.
When deciding between a software company and a freelancer, ask yourself: what happens to this system two years from now? If the answer matters, you need more than one person.
Red flags before hiring a software development company
In our experience, a few behaviors almost always foreshadow problems:
- Price and deadline set in a single meeting, with no questions about your business.
- Refusal to show live products or to provide client contacts.
- Evasive answers about who will work on the project.
- A contract that doesn't say who owns the code, or that keeps the repository and accounts only in the vendor's name.
- A promise to deliver everything, for everything, fast and cheap.
- No mention of testing, security or maintenance, as if the project ended on delivery day.
- A steep discount conditional on signing today.
- Refusal of any smaller, paid phase before the full contract.
How to reduce risk with a small first phase before the big contract
The best way to evaluate a vendor is to work with them on a small slice. Instead of signing the whole project, hire a first phase of a few weeks: one main flow working, a clickable prototype or an isolated module of the system.
In a few weeks you see what the presentation doesn't show: how the team asks questions, how it reacts to a change, whether it does what it agreed to, whether communication is clear and whether what was delivered really runs. If you like the result, the larger contract starts with far less uncertainty, and the estimate is already based on real work.
If your case is an old system, the reasoning is the same: start with one module, not a full rewrite. That's how we do it in legacy system modernization, incrementally and without stopping operations. The complete guide to legacy system modernization explains the step-by-step process.
For apps, a prototype is the cheapest small phase. You can validate screens, flow and idea before writing the first line of the final system. We offer a free app prototype precisely for this.
From our experience
At SKAD, based in São José dos Campos since 2015, we take products all the way to the end user, not just deliver code. Eu Católico, our own app with more than 100,000 downloads on iOS and Android, and Proxi, a new app built from scratch in Node.js, React and React Native, published on Google Play and the App Store and with a web version designed for SEO, are examples of products you can download and evaluate.
We also have long-term relationships. We have served the Inspefire client for 10 years and have developed more than 10 new modules from the specifications they send us. For The Horus, we maintain and host the system and the apps under a monthly fee. That's why we talk about maintenance and continuity as part of the choice, not as a contract detail.
Our founder, Lucas Natal da Silva, has 13 years of software engineering experience, with stints at Embraer, Ericsson, Atlas Schindler, Accenture and the city governments of São Bernardo do Campo and São José dos Campos, plus remote work for an American company. Today he is also the CTO of another software company.
Frequently asked questions
What questions should I ask before hiring a software development company?
Ask which products are live, who will work on the project, how scope changes are handled, who owns the code and who controls the access credentials, how testing and deliveries are done, and what happens after delivery. Ask for the answers in writing.
Software company or freelancer: which is better?
A freelancer suits small, well-defined tasks. A software company is better suited to projects that need several skill sets, continuity and maintenance.
Does the source code belong to the client?
It depends on the contract, which is why it must be written down. Require ownership of the code, and that the repository and accounts be in your name or with you as administrator.
Is it worth starting with a small project?
Yes. A short, paid phase, such as a prototype or a module, shows how the team works before you make a big commitment.
How can I tell if a software company's portfolio is trustworthy?
Check that the products are live, what the company's role was in each one, and talk to at least one current client. A portfolio you can't verify is worth little.
What does the contract need to say about maintenance?
It should state who fixes bugs and within what timeframe, how hosting and updates work, and what is charged separately. Without that, any adjustment after delivery becomes a negotiation.
Conclusion
Before signing with any vendor, write your ten most important questions based on this article and send them to two or three companies. Compare the clarity of the answers, not just the price. Then, instead of signing the whole project, ask for a small first phase. If you have an app idea, the cheapest path is to validate the flow in a clickable prototype before investing in full development. That's what we offer with the free prototype: you see the app and our way of working, and you decide based on evidence, not promises.