Building Aismax — a bilingual grain‑trading site for Northern Nigeria.
One site, two audiences who share almost nothing, and two languages that had to be treated as equals rather than as an original and a translation.
The client.
Aismax Grains and Logistics Services buys grain at the farm gate in Northern Nigeria, grades and stores it, and delivers it to industrial buyers on haulage it contracts itself. Maize, soybeans, sorghum, rice, millet. The company is registered in Zaria, Kaduna State, and its pitch is a structural one: most grain in Nigeria changes hands several times between the farm and the factory gate, and every hand adds cost, delay, and uncertainty about quality. Aismax holds the whole chain rather than passing it on.
That claim is the entire business, and it created the first design constraint. A company whose differentiator is accountability across a chain cannot have a website that looks like a broker's. It has to show the chain — sourcing, aggregation, grading, warehousing, haulage, delivery — as one continuous thing the company owns end to end.
Two audiences, one site.
The brief looked simple until we wrote down who the site was actually for. Aismax has two constituencies, and they share almost nothing.
On one side is the industrial buyer — a procurement officer at a mill, a feed producer, a brewery, an oil crusher, sitting in Kano or Kaduna or Oyo or Lagos. They arrive with a specification and a volume. They want to know what is graded to what standard, whether it can be delivered to their plant, and how fast someone will come back with a price. They read English, they read fast, and they are comparing you against a broker who answered within the hour.
On the other side is the smallholder farmer with grain to sell, arriving on a phone, on a connection that comes and goes, reading Hausa. They want one question answered: will Aismax buy from me, and how do I reach someone.
A single site serving both audiences fails in a predictable way — it gets written for the buyer, because the buyer is the one who signs the invoice, and the farmer side becomes a paragraph nobody maintains. We built the two paths as peers instead: a quote route and a sell‑to‑us route, each with its own landing surface, each reachable from every page.
A language toggle that dumps you back on the homepage isn't bilingual. It just tells the reader which language the site was really written in.
Hausa as a first‑class locale.
This is the decision the rest of the build hangs off, and the one most likely to be done badly elsewhere. The cheap version of “we support Hausa” is a translation widget bolted into the corner — machine output, no indexable URL, and a toggle that loses your place. It signals the opposite of what it intends.
We routed the two languages as separate trees. Every page exists at /en/… and /ha/…, both rendered from the same content model, both server‑rendered, both in the sitemap. The root path redirects to a locale rather than serving a third, unversioned copy, and the choice persists in a NEXT_LOCALE cookie so a returning reader lands where they left off.
01Telling search engines they are equals
Two language trees are worth little if a crawler reads one as the original and the other as a duplicate. Each page declares its alternates explicitly — an hreflang for English, one for Hausa, and an x‑default so an engine with no language signal has somewhere defined to go.
The practical payoff is narrow and real: a Hausa‑language search for a grain buyer in the North can surface the Hausa page directly, rather than an English page a reader bounces off. That is the whole point. Nobody switches languages on a site they have already decided isn't for them.
02Where the translation work actually is
The engineering is the easy half. The hard half is that grain trading has vocabulary — grades, moisture content, delivery terms — that does not survive machine translation intact, and a farmer reading a mistranslated spec is a support call at best. The copy was written for each locale rather than piped through one, which is slower and is the only version that works.
A CMS the client actually runs.
Commodity specifications change. Trading records change. The states Aismax delivers to will change. A site where any of that needs a developer is a site that is accurate on launch day and stale within a month — and the client learns to stop asking.
Content is managed in Sanity, structured per commodity and per locale, so the Aismax team edits specs, figures, and gallery imagery themselves in both languages without touching a deploy. The handover is not an afterthought at the end of the engagement; it is the thing being delivered. A build the client cannot maintain is a build with an expiry date on it.
A build the client can't maintain has an expiry date on it. Handover isn't the last task in the engagement — it's the deliverable.
Making a physical business findable.
A procurement officer looking for maize in Kaduna types something close to “maize supplier Kaduna” and gets a local‑intent result set. That is a different search problem from ranking an article, and it is won on whether a search engine can resolve you as a real, located, contactable business entity rather than a page of adjectives.
So the site publishes the entity in structured data rather than leaving it to be inferred: the registered name, the Business Name registration number, the street address in Zaria, geographic coordinates, the states served, and two sales contact points each declaring that they are answered in English and Hausa. The same details a buyer would ask for before wiring money.
This is unglamorous and it is most of the job. Nigerian SMEs are routinely invisible to search not because their sites are bad but because nothing on them is machine‑readable as a business — no address, no registration, no coordinates, a phone number rendered inside an image.
03WhatsApp is the contact primitive
Nigerian B2B runs on WhatsApp, so the quote path opens a WhatsApp thread rather than a contact form that lands in a mailbox nobody watches. A form is the polite answer. A thread is the one that gets a reply the same afternoon.
Headers on a brochure site.
The site ships a content security policy, a same‑origin opener policy, HSTS, frame denial, and a permissions policy switching off the browser capabilities the site has no use for — camera, microphone, geolocation, payment, and a dozen more.
It is fair to ask why a marketing site needs any of that. The answer is that a company's public site is its identity to buyers who have never met it. A site that can be framed, injected into, or served over plain HTTP is a reputational liability for a business whose entire pitch is that it can be held accountable. The cost of setting these headers correctly at build time is close to zero. The cost of not having them is paid once, publicly, at the worst moment.
What we'd do again.
Routing the locales as peers, first and most of all. Every shortcut available at that fork — a widget, a subdomain, a machine‑translated second tree — would have been cheaper in week one and worse in every week after.
Building the farmer path as a real destination rather than a paragraph on the contact page. The buyer side is where the invoices come from, which is exactly why the supply side is the part that quietly rots on sites like this.
And treating the entity markup as part of the build rather than as something to add later. Later does not arrive. The site goes live, everyone moves on, and the business stays invisible to the searches that would have found it.