12 Questions to Ask Before You Hire a Software Studio in Africa

Picture the first meeting: a laptop on a table at a Nairobi cafe, a founder on one side, two people from a studio on the other. The studio shows a slide deck. The founder wants to ask about money and is not sure what else to ask.

This list is for that founder. It covers twelve questions, with what a good answer sounds like and what should make you pause. We are a studio ourselves, so we have answered each one honestly from the other side of the table.

The questions work for any studio, including us. For the budget side, read how much it costs to build an app in Kenya first, so the price conversation starts with line items.

1. Who will actually do my work?

Good: names and roles, and whether they are employees or contractors. Pause if: the person who sells the job is not the person who builds it, and nobody will say who that is.

2. What have you shipped that is like mine, and can I see it running?

Good: a live product you can open on your phone, and a client you may speak to. Pause if: only screenshots, or "under NDA" for everything. Some work is private, but not all of it.

3. What did you get wrong on a past project?

Good: a plain story with what changed afterwards. Pause if: "nothing, our clients are always happy". Every studio has a late job somewhere.

The answers to these three are easier to judge if you have seen real products. A few of ours are public: the HackHouse case study shows a client platform with ticketing and M-Pesa payments, and our other products are listed on the same site.

4. How will you turn my idea into a scope I can sign?

Good: a short discovery step, then a written list of screens, roles and rules, and a list of what is out. Pause if: a price arrives before anyone has asked you a question.

5. How often will I see working software?

Good: a demo every week or two that you can click, on a real address. Pause if: "you will see it at the end". Our own habit is a first working version in the first week where scope allows, and weekly demos after.

6. How do you test, especially payments?

Good: testing in a sandbox, then small real payments, then a check on late and duplicate notices. Pause if: the developer tests only the happy path. For M-Pesa work, read what it costs a business to integrate M-Pesa to see what a full test covers.

7. What is not included in this quote?

Good: a written list: hosting, third-party fees, content, training, store fees. Pause if: "everything is included". Nothing is.

8. How are changes priced after we sign?

Good: a rate or a process: you ask, they estimate, you approve before work starts. Pause if: changes are free but unlimited with no process. That ends in missed dates.

9. How are payments staged?

Good: payments tied to demos you have accepted. Pause if: most of the money is due upfront with nothing delivered, or the final payment has no acceptance step.

Payment plan	What it protects	What it risks
Small deposit, then per accepted demo	You pay for what you saw	The studio waits for your sign-off, so respond quickly
Half upfront, half at the end	Simple to understand	You carry risk until the end
Monthly retainer	Steady team for steady work	You need a clear list of what the month buys

If you want to see how we would answer these on your project, you can book a scoping call with Mctaba Labs.

10. Who owns the code, the accounts and the data?

Good: you own the code once you have paid, and your business opens the hosting, domain, app store and payment accounts. Pause if: the studio holds the accounts "for convenience", or the contract is silent on code. This is the most common hard lesson for first-time buyers.

11. What happens after launch?

Good: a named upkeep plan: bug fixes, monitoring, a response time and a price. Pause if: support depends on one person's phone number.

12. How do I leave?

Good: a handover that includes the code repository, deployment notes and credentials, within a set number of days of your request. Pause if: leaving means a fee, or means starting from nothing.

Ask for the answer to question 10 to be written into the contract. The clause can be short: the client owns the code on payment, third-party libraries stay under their own licences, and all accounts are in the client's name.

A reference call is worth more than any pitch. Ask the studio for two past clients and call both, preferably one whose project ran late.

1. "What did they build for you, and is it still in use?"
2. "Was the first demo what you expected?"
3. "What happened when something broke after launch?"
4. "Did the final bill match the quote? If not, why?"
5. "Would you hire them again for the next project?"

Listen for pauses. A client who says "yes, but" is giving you the useful half of the answer. Write down the "but" and put it to the studio in your next meeting.

If the studio cannot name a single client who will take your call, treat that as a red flag from the list above, however polished the slides look.

• A price in the first message, before any questions.
• A very low quote with no testing line.
• No written scope, or a scope that says "as discussed".
• Accounts opened in the studio's name.
• No live product to look at.
• Pressure to pay today for a discount.
• A refusal to let you talk to a past client.
• A promise that sounds too good: "ready in three days", "never any bugs".

None of these alone is proof of a bad studio. Two or three together is a reason to walk away.

We are not lawyers. For anything large, have a lawyer read the contract. These are the points we would look for as a buyer.

1. The scope, as a list, attached to the contract.
2. A timeline in dates, with what happens if either side is late.
3. Payments tied to accepted deliveries.
4. Ownership of code and accounts, as above.
5. How change requests are handled.
6. Confidentiality and how your customers' data is treated. Kenya's Data Protection Act applies to personal data you collect, so ask how the studio handles it.
7. Warranty: how long they fix bugs from the original scope at no cost.
8. Termination: how either side ends the work, and what is handed over.

Two payment questions matter for any app that takes money. Ask who holds the Safaricom or Paystack account (it should be yours) and who receives the settlement. Our note on a checkout for M-Pesa, MoMo and cards shows why.

Sometimes the answer is no. If a ready-made till does your job, buy it. Our guide to custom software or off-the-shelf POS gives a decision table. If you will build software every month for years, an employee may cost less than a studio, as hiring an in-house developer or a studio shows.

When a studio is right, use the twelve questions above on every candidate, and score the answers side by side. The studio that is comfortable with specific, written answers is usually the one that will deliver the same way.

We would like you to ask us all twelve. If you are speaking to us, bring the one-page brief from the budget guide and your list of questions. We will answer in writing and tell you where a different choice suits you better.

To start, book a scoping call with Mctaba Labs.