The short answer
To hire a software house, start with the problem in your operation, ask every candidate the same questions about method, team, use of AI, code ownership and support, and compare proposals by what each one includes, excludes and documents. Only sign a contract that puts all of this in writing.
The portfolio shows what the company has already done. The answers show how it will work on your case. A company that works well explains its own method clearly, asks a lot about your operation and puts in writing what is left out of scope.
What to bring to the first meeting with a software house
Come with the problem, not the solution. You do not need a finished scope, but it helps to know what is causing extra work, delays or errors today, who uses the process, which systems already exist and what happens if nothing changes in the coming months. A good software house turns that into scope; the article on how to define the scope of a software project shows how that work is usually done.
If you have documents, spreadsheets, reports or screens from the current process, bring them. They show in minutes what would take a whole meeting to explain. Also bring the person who will use the system every day, or at least their questions: they often see problems that management does not.
Be wary of anyone who skips this step and arrives with the technology already chosen, a fixed deadline and a price in the first conversation. Without understanding the operation, any number is a guess.
Checklist of questions for the first meeting
Ask every company you are evaluating the same questions and write the answers down side by side. Next to each question, what you should expect to hear.
- How do you understand the problem before proposing a solution? Expect to hear about conversations with the people who run the process, a survey of what already exists, prototypes and hypothesis validation before any code.
- How often will we see working software? The right answer is every short cycle, with a demo to test and approve, not only at the end of the project.
- How do you define when a deliverable is done? The acceptance criteria should be agreed before each item starts, so that "done" means the same thing to both sides.
- What happens when priorities change midway? A serious method absorbs the change when planning the next cycle and shows the impact on the timeline, without hiding it.
- Who will work on the project and who makes decisions on your side? Find out whether product, design, development, infrastructure, security and support stay with the same team or go through different vendors. Every handoff is a point where information gets lost.
- Have you worked with operations similar to ours? Ask for concrete examples: the problem, who it was built for, what was delivered and what turned out to be hard.
- How do you use artificial intelligence and who reviews what it produces? Almost every software house uses AI today. The question is whether there is human review before production and which tools your data goes into.
- How are access control, LGPD and security handled? Expect to hear that they are built in from the design stage, with checks before every release, and not patched in at the end. (LGPD is Brazil's data protection law.)
- Who owns the code and what gets documented? Code ownership and knowledge transfer should be in the contract, with decisions, versions and risks on record.
- Who provides support after the system goes live? Find out the channel, the response times and how real usage becomes the next improvement before you sign.
Also notice what the company asks you in return. A company that is interested in your operation, in who uses the system and in what already exists is trying to understand the problem. One that only talks about technology and deadlines does not yet know what it is going to build. If you want to see how we answer these questions, our method is described in how we work.
Good signs and red flags in a software proposal
After the meetings, the proposals arrive. Read each one looking for the points below, which say more about the project's risk than the final price.
| Proposal item | Good sign | Red flag |
|---|---|---|
| Scope | Lists what is included, what is left out and the assumptions made | Describes the system in generic sentences, with no exclusions |
| Timeline | Comes from a study of the scope and shows intermediate deliveries | A fixed date before any conversation about the operation |
| How it is delivered | Working software every cycle, with a demo and acceptance | Nothing to see or test until the end of the project |
| Team | Says who does each part and who the point of contact is | Does not say who works on the project, or subcontracts parts without telling you |
| Ownership and documentation | Code, access and documentation stay with the client, in writing | Silence about who owns the code and the data |
| Use of AI | Explains where AI comes in and guarantees human review before production | Promises AI will solve everything on its own and cuts the timeline because of it |
| After delivery | Describes support, the service channel and ongoing improvement | Ends at go-live, with no mention of who handles support requests |
A more expensive proposal can turn out cheaper if it is the only one that says what is left out. Vague scope is the most common source of disputes in the middle of a project. To understand why an honest timeline depends on scope, see how long it takes to develop a custom system.
How to compare proposals from different software houses
Comparing only the total price is misleading, because each company includes different things. Build a simple spreadsheet with the same rows for all of them: what is in scope, what is left out, how each part is delivered and accepted, who is on the team, who owns the code and what happens after go-live. The gaps show up on their own.
When the problem is not yet well defined, it makes sense to hire a short study first, which produces a validated scope and priorities, and only then the development. That is how we start our custom software development projects: a study that defines scope, timeline and investment before any larger commitment. With that material in hand, you can also ask other companies for comparable proposals.
If the question comes earlier, between outsourcing and hiring your own people, the comparison between a software house or an in-house team helps you decide before you go out for bids.
What the contract with a software house should include
The contract is where the good answers from the meeting become obligations. Before signing, check that it covers these points:
- Scope, assumptions and exclusions. What will be delivered, what will not, and which information or access the project depends on from the client's side.
- How deliveries are made and accepted. How each delivery is demonstrated, who approves it and within what time, and what happens if it does not meet the agreed criteria.
- Scope changes. How a new request is assessed, estimated and approved before it goes in, so that neither side is caught off guard.
- Code ownership and access. Who owns the code, the data, the environments and the service accounts, and how everything is handed over at the end. The article on who owns the code of custom software covers the topic in detail.
- Confidentiality and data handling. Who can access the data, for what purpose, and each party's responsibilities under the LGPD when the system processes personal data.
- Support and maintenance. Service channels, response times, what counts as a fix and what counts as an enhancement, and how enhancements are quoted.
- Exit. How the transition works if the contract ends: handover of code, documentation and access, and a period of support for whoever takes over.
None of this needs to be in difficult language. It needs to be in writing. What was agreed only verbally tends to be remembered differently by each side six months later.
How to tell if a software house uses AI responsibly
Artificial intelligence speeds up research, code drafts, testing and log analysis, and it is reasonable for the company you hire to use it. The risk lies in generated code reaching production without review, or in client data going into tools nobody authorized.
Ask who reviews what the AI produces, which tools your data goes into and whether you will know at which stages it was used. In our case, no AI-generated code or content goes to production without review by a professional on our team, who checks it, corrects it and takes ownership of it, and the client knows where AI was used.
How to hire a software house as a public agency
The same questions apply, but the path is different. Brazilian public agencies hire through a public bidding process, or through direct contracting in the cases the law allows, both currently governed by Law 14.133/2021. This requires planning before the purchase: the problem, the intended solution and the acceptance criteria must be described in the procurement documents, and the contract is formally overseen during execution.
That is why documentation carries even more weight. Rituals, responsible parties and records defined from the start support the contract inspector, and accessibility, LGPD and a record of every action are part of the scope from the beginning. The step-by-step is in the guide on how to procure software for a public agency. It is with this same care that we develop and maintain Ágil Cidadão, our citizen service system.