How to choose a software house in Angola: 8 questions

Choose the team that shows you real work, names the people who will build yours, puts scope, timeline and price in writing, shows progress every week, hands over the code and the accounts, understands how customers in Angola use the internet, and stays available after launch.

Ask the eight questions below to two or three software houses and compare the answers side by side. The differences are usually clear within one conversation.

Ask for live projects you can open and use, and for one or two clients you can speak to. A polished slide deck tells you little about how the software behaves.

Open the projects on your own phone. Check how fast they load, whether the text is easy to read, and whether the forms and buttons work. A team that builds carefully shows it in details you can test yourself.

A newer team may not have a long client list. That is not a reason to rule it out, but then ask how it works: a sample scope, an example of its process, or a small first step you can judge before committing to more.

A good answer is links you can open and a client willing to talk. A weak answer is screenshots only, or projects that no longer exist.

Ask for the names and roles of the people who will design and build your project, and whether you will talk to them directly. Small teams where the people you meet are the people who build tend to make decisions faster.

Be careful when the people who sell the project are not the people who build it, and you never meet the builders. Questions get passed along, and details get lost on the way.

If part of the work is done with AI tools, ask how the results are checked. The answer you want is that a named person reviews everything before you see it.

Before work starts you should have all three in writing. If the scope changes, the change and its cost should also be written down before it happens.

A written scope says what you will get and, just as important, what is not included. Read that part twice. Many disagreements between clients and software houses come from something each side assumed was included.

Ask what happens if the timeline slips, and what you need to provide for it to hold, such as content, logos or decisions.

Look for weekly steps with working software, not a long silence followed by a big reveal. Seeing the product early lets you correct course while it is cheap.

Ask how you will review the work, for example a link you can open on your phone, and who you send feedback to. Agree how many rounds of changes are part of the price.

You should. At handover you should receive the source code, the documentation and ownership of the domain, hosting and store accounts. Ask this before you sign.

Check that the domain is registered in your name and that hosting and email accounts are created under your company, not the software house's. Moving these later is possible, but it is slower and sometimes costs money.

Also ask which third-party tools your project depends on, such as hosting, a payment provider or an email service, and who pays for them after launch.

Good local design starts with these questions:

• Is it designed for phones first?
• Does it work on slow or unstable connections?
• Can customers contact you by WhatsApp?
• Is it in Portuguese, and in English if you need it?
• Can it accept the payment methods your customers use, where the provider offers an integration?

Test this yourself: open their earlier work on a phone with a weak signal. If it feels slow or hard to use there, it will feel the same to your customers.

Software needs updates and fixes. Ask what support is offered, what it costs, and how quickly problems are handled.

A good answer says what is covered, how to report a problem, and what is charged separately. Ask whether you can end the arrangement without losing access to your own project.

A good team explains options, costs and trade-offs without jargon, and tells you when you do not need what you asked for. If an answer is vague now, it will be vague later.

Notice whether they ask about your business before they talk about technology. Questions about your customers and goals are a good sign.

• A price with no written scope behind it.
• No live work to look at and no willingness to explain the process.
• Pressure to sign quickly, or a discount that expires today.
• Vague answers about who owns the code and the accounts.
• No plan for support after launch.
• Promises that sound too good, such as a complex system in a few days.

Put the proposals side by side and compare what is included, not only the total. Check the scope, the timeline, who owns what at the end, how many rounds of changes are covered, and what support looks like after launch.

The cheapest proposal is not always the lowest cost. A proposal that leaves things out can cost more once the missing parts are added. Ask each team to explain any difference you do not understand.