Straight answers for teams choosing a software partner.

Ask what they operate today, not what they have built. Building and running are different disciplines — plenty of teams can ship a system that nobody has to keep alive at 2am.

Ask to see how a platform behaves under load, how it is monitored, and what happens when a dependency fails. A partner who runs production systems will answer immediately and in detail, because they have lived it.

Then ask what they would not take on. A team that claims every capability equally has usually gone deep on none of them.

Who owns the code and the data when the engagement ends. Get it in writing.

What happens after launch — who fixes a production fault, on what timeline, and at what cost.

Whether the people who pitched you are the people who will build it.

How they handle change, because scope always moves. A partner who cannot describe their change process has not thought about it.

Watch how they handle disagreement in the first conversation. A partner who tells you an idea is expensive or risky before you sign is a partner who will tell you the truth later, when it costs more to hear.

Look for specificity. Vague answers about scale and security usually mean the question has not come up in anger yet.

Ask about something that went wrong. Everyone has one. A team that cannot name a failure is either inexperienced or not being straight with you.

Honestly: it depends on what has to be certain. A tool used internally by twenty people and a platform clearing real-time transactions inside a mobile network differ by an order of magnitude, even if both are 'an app'.

The cost driver is rarely the number of screens. It is the cost of being wrong — what happens if a charge is applied twice, a prescription is dispensed against the wrong record, or a payment is released early. Systems where mistakes are expensive need engineering that makes them unlikely.

The useful conversation is not 'what does it cost' but 'what must not fail'. Tell a partner that, and the number becomes explainable.

Fixed price suits work where the scope is genuinely known and unlikely to move — a defined integration, a migration with a clear endpoint. You buy certainty and pay a premium for the risk the supplier absorbs.

Time and materials suits work where you expect to learn as you go, which is most product work. It needs more trust and more visibility, and it is the more honest model when nobody can yet describe the finished thing.

A fixed price on an unclear scope is the worst of both. It pushes the supplier to defend the boundary instead of solving the problem.

Sequence the work so something real is running early. A platform that is live in a limited form tells you more about the remaining cost than any estimate.

Decide what you are not doing in the first release, explicitly, and write it down. Unspoken scope is where budgets go.

Insist on visibility — what was worked on, what it cost, what changed. A partner who resists that is managing your perception, not your budget.

Yes, and the time zone helps more than people expect. Addis Ababa is close to Central European time for most of the year and ahead of it in winter, so a working day overlaps substantially with Europe and almost entirely with the Gulf.

The practical requirements are the same as with any partner: a written agreement on ownership and confidentiality, clear points of contact, and an agreed way to handle production issues.

Where we process personal data on your behalf, you are the controller and we are the processor. That relationship is governed by a data processing agreement, not by goodwill.

Where personal data originating in the European Economic Area is transferred, we rely on an approved safeguard such as the European Commission's standard contractual clauses.

Our own handling of data collected through this site is set out in the privacy policy.

Overlap is the point, not availability at all hours. We aim for a reliable window each day when decisions can be made, and asynchronous, written progress the rest of the time.

Written by default matters more than any tool. Decisions recorded in writing survive a holiday, a handover and a disagreement about what was agreed.

We design and engineer platforms that run in production — telecom and value-added services, health and clinical systems, education, commerce, fintech, and bespoke AI and web products.

Our depth is in telecom: dial-in (USSD) services, SMS at carrier scale, real-time charging and signaling integration with mobile networks. That work sets the engineering standard for everything else we build.

We are set up for systems that have to keep running and keep changing — that is where our engineering is worth paying for. A brochure site or a one-off script is not work we are the right partner for, and we will say so rather than take it.

Yes. Several of our platforms have live deployments, and each product page lists what it does, the standards it implements and the stack it runs on.

Where a system sits inside a client's network and cannot be shown publicly, we can walk you through its architecture and how it is monitored.