most tutorials live in a very cooperative country.
the address format is predictable. payments have one clean API. identity verification returns a neat boolean. tax is a percentage in a configuration file. every service responds quickly and users apparently read validation messages before submitting forms.
then you build software for a real Nigerian process.
local complexity is not an edge case
building TaxBook made one thing difficult to ignore: the business rule is often the product.
a tax calculator is not just a form multiplied by a rate. there are reliefs, bands, annual and monthly views, changing regulations, different interpretations and the responsibility of explaining a number the user may need to act on.
if the calculation is correct but impossible to understand, the software has not completed its job.
this applies beyond tax. Nigerian products often sit between users and institutions with their own forms, references, identifiers and manual exceptions. the integration is not decoration around the product. it is where the product touches reality.
payments are workflows
"add payments" sounds like a button task.
in practice there is initialization, redirection, callbacks, verification, references, retries and reconciliation. a browser returning to a success page does not prove that money settled. a callback arriving twice should not create two records. a delayed status should not leave the user permanently confused.
the payment record needs its own state machine:
textcreated -> pending -> successful -> failed -> needs reconciliation
the provider is one source of information. the application's verified record is what the rest of the product should trust.
design for interruption
connections fail. phones run out of battery. users switch between devices. external services become slow exactly when a deadline is close.
long forms should preserve progress. actions should be safe to retry. a user should be able to return to a pending operation and understand its state. important documents should not require starting the entire journey again because one request timed out.
this is sometimes described as resilience architecture. to the user it simply feels like the software respects their time.
support is part of the interface
when software touches money, government rules or business records, users need confidence, not only functionality.
clear explanations, receipts, reference numbers, visible status and a reachable support path are product features. hiding every detail behind a spinner creates anxiety. showing the relevant state gives the user something concrete to hold onto.
importing assumptions is expensive
good engineering practices travel. product assumptions do not always travel with them.
building for Nigeria means learning the exact local process, naming its awkward parts and designing around what people actually do. the software can still be modern. it just cannot be imaginary.