Why these questions protect you
Most software disappointments do not come from bad code. They come from mismatched expectations that were never discussed. The questions below surface those gaps before any money changes hands, when you still have all the leverage.
Think of them as a filter. A strong developer welcomes them and answers with specifics. A weak one gets vague or defensive, and that reaction alone can save you from a costly mistake.
1. Who owns the code, domain, and credentials?
This is the most important question of all. You should own your source code, your domain, and every server and service credential outright, from day one. If ownership is unclear or the developer keeps the keys, you are locked in and exposed if they leave.
Get the answer in writing. Real ownership means you can hand the project to anyone else if you ever need to, which is exactly the protection you want.
2. How will I see progress along the way?
You should never have to take "it is almost done" on faith. Ask how and how often you will see working software, not screenshots or status updates. Regular access to a running version keeps everyone honest and catches misunderstandings early.
A developer who commits to frequent demos is confident in their pace. One who wants to disappear and reveal everything at the end is a risk.
3. How are payments structured?
Tie money to delivered milestones, each with something you can actually see and test. Avoid paying large amounts up front against promises; that is how abandonment stories begin.
A fair structure protects both sides: the developer is paid for real progress, and you are never far ahead of what has been delivered. Be wary of anyone demanding most of the fee before meaningful work exists.
4. Do you have real experience with the integrations I need?
For Kenyan businesses this usually means M-Pesa via Daraja, eTIMS invoicing with KRA, and statutory items like SHIF, NSSF, and PAYE. Do not accept a simple yes. Ask them to describe how they have handled these before, including reconciliation and edge cases.
Specific, detailed answers show real experience. Vague confidence often means they will be learning on your budget, and mistakes in payments or tax are expensive and public.
6. What do support and maintenance look like after launch?
Software is never finished at launch. eTIMS rules change, M-Pesa APIs update, and your team will always want improvements. Ask how bugs are handled after go-live, what a support arrangement costs, and how change requests work.
A developer who plans for the long term is thinking about your success, not just collecting a build fee and vanishing. Silence on maintenance is a sign they see this as a one-off transaction.
7 to 10. The questions that reveal how they really work
The remaining questions round out the picture and expose how a developer actually operates day to day.
- 7. Can you show me similar work or clients I can speak to? Real references beat polished portfolios.
- 8. How do you handle changes to scope once we start? A clear process prevents disputes later.
- 9. Where will my data and system be hosted, and is it secure and backed up?
- 10. What do you need from me to succeed? Good developers know the project is a partnership, not a drop-off.
How Upeosoft answers these questions
We welcome every one of these questions because we answer them the way you would want. You own your code, domain, and credentials from day one. We work in phases with regular working demos and milestone-based payments, and we handle M-Pesa, eTIMS, and statutory integrations as routine.
Because we are local, you can meet us, hold us accountable, and rely on us for support long after launch. If you are interviewing developers, bring this list to us and see how the answers compare.
