Six Lessons From Building Software for Organizations in Liberia

I have built software for a school, a news organization, a university and a marine operations company. The projects are very different, but the same lessons keep coming back. None of them are about a particular framework or tool. They are about the real conditions that software has to survive.

Here are six that I would tell any developer, or any organization commissioning software, to keep in mind.

Design for weak and unreliable connections

You cannot assume a fast, steady internet connection. People work on phones, on mobile data, in buildings where the signal comes and goes. A page that is heavy, or an app that stops working when the network drops, quietly fails the people who need it most.

That means keeping pages light, compressing images, and showing something useful quickly. For work that happens in the field, such as recording cargo at a port, it can mean building the app to keep working offline and sync later. If a system only works with perfect internet, it does not really work.

Think phone first

For many people a phone is the main computer, and sometimes the only one. A system that looks great on a large desktop screen but is awkward on a phone will be avoided. When I plan a screen now, I picture it on a small display first and then let it grow, not the other way around.

This is also why mobile apps matter so much in practice. Students, parents, readers and field staff all reach for the phone in their pocket before they sit at a desk.

Expect more than one currency

Money is rarely simple. In the school finance view I built, income and expenses are shown in both Liberian dollars and US dollars, because both are part of how the organization really works. A system that assumes a single currency forces people back to spreadsheets to fill the gap.

Any time money is involved, ask early which currencies are used, how they should be shown, and whether they should ever be added together. Getting this right at the start is far easier than fixing it later.

Let staff edit their own content

Organizations change. Opening hours change, new services appear, a leader is replaced, a notice needs to go out today. If every small change needs a developer, the website goes out of date, and the organization loses trust in it.

So wherever I can, I build the editing into the system. On one corporate website, the team can change text and images and even show or hide whole sections without touching code. The result is a site that stays current because the people who know the content can keep it current.

Give each person only what they need

A school administrator, a teacher, a parent and a student should not see the same things. Role-based access means each person gets the tools that belong to them and nothing more. It protects private information, keeps screens simple, and reduces mistakes.

It is easier to design this from the beginning than to add it later. Before building, I like to list the types of users and write down what each one should and should not be able to do.

Remember the people who will use it

The most beautiful system is worthless if people do not use it. The users may be new to software, short of time, or sceptical because a previous system let them down. Clear labels, plain language, and a few well-chosen features beat a long list of options nobody understands.

I try to ask the people who will actually use the system what they do all day, and I show them early versions rather than waiting for a perfect launch. Their reactions teach me more than any plan.

What ties it together

Each of these lessons comes down to the same idea: build for the real conditions, not the ideal ones. Real connections are weak, real users are busy, real money comes in more than one form, and real organizations keep changing.

If you are planning software for an organization and would like to talk through the real conditions it will face, get in touch through the contact page.