NaijaPoultryHub
Designing one mobile hub for running a poultry farm and reaching the poultry market.
NaijaPoultryHub is a mobile app designed to help poultry businesses manage their farms and connect with the poultry market. It brings Farm Management and Marketplace into one account, while supporting three distinct jobs: running a farm, buying from the marketplace, and selling through the marketplace.
I worked across the product, from the overall architecture to the individual flows that make the system work. The challenge was not simply deciding where features should live. It was understanding how farm activities relate to one another, while keeping the Marketplace useful without turning it into a large e-commerce product.
The product is still in development, so the focus is on the product decisions and system relationships already designed and created.

The useful part was what happened between the records.
Poultry farms need to track birds, production, mortality, feed, treatments, workers, expenses and sales. The more I looked at the problem, the less it felt like a collection of separate record-keeping tasks.
If mortality is recorded, the flock count should reflect it. If feed is used, available stock should decrease. Medication and labour costs should contribute to the financial picture. If birds are sold, inventory and revenue should change with them.
Marketplace introduced a different problem. Buyers needed a simple way to discover poultry products and understand who was selling them, while sellers needed a practical way to become visible and manage listings. The answer was not to recreate carts, wallets, checkout and complicated order management.
That gave the product two complementary principles: connect farm records where relationships matter, and keep the Marketplace light where extra complexity does not.
Record the work once. Let the system carry it forward.
One account became the bridge between two sides of the business.
An early direction treated Farm Management and Marketplace more like separate products, with separate registration paths. That created unnecessary friction for someone who might manage a farm today and start buying or selling through the Marketplace later.
I changed the model to a shared account. A person creates one NaijaPoultryHub account, verifies it, and then activates what they need. Farm-specific information only appears when Farm Management is activated, while Marketplace-specific setup only appears when Marketplace is activated.
The account belongs to the person. Farm Management and Marketplace are capabilities they can turn on when they need them.
One account is the bridge. Each part of the product only asks for what it needs.

The product had to make sense for three different jobs.
The experience separates into three primary paths. Farm Management is for running the operation, Marketplace Buyer is for discovering products and contacting sellers, and Marketplace Seller is for setting up a selling presence and managing listings.
A single person can move between these experiences over time, so I did not design them as isolated identities. The shared account stays stable while the tools and setup change around the job the person is trying to do.
Within Farm Management, responsibility can vary too. An owner or admin may need access to performance, workers and settings, while a worker may only need permission to record specific farm activities.

Everyday farm activity needed to behave like one connected system.
The Farm Management experience became the operational foundation of the product. Birds produce eggs, birds can be lost through mortality, feed is consumed by those birds, and medication, labour, utilities and other expenses contribute to the cost of running the farm.
Instead of making the farmer think about those calculations while recording work, I kept the individual actions focused and let the system use that information later.
The dashboard follows the same idea. Egg production, total birds, feed stock, mortality, Performance and recent activity act as both summaries and routes into the underlying records.
The birds became the thread connecting the rest of the farm.
Flocks became one of the main building blocks of Farm Management because almost everything else eventually connects back to them.
I designed a Flock Management space where farmers can see bird inventory and move into the records associated with it. A flock can carry details such as breed, bird type, number of birds, location, status and acquisition cost.
The important part was making the flock more than a static record. Production, mortality, feed usage and health records can be associated with the birds they belong to, so the flock becomes a reference point for the wider farm.
A daily collection should become more useful than a daily number.
Egg production is one of the clearest signals of what is happening on a poultry farm, so I designed a dedicated production experience rather than treating it as another dashboard statistic.
Farmers can record collections and look back at production over time. The dashboard can surface a quick view, while the full records remain available when more detail is needed.
The recording action stays simple, but the information can become a trend instead of forcing the farmer to rebuild the same history in a spreadsheet.
Record the collection once. Let the product turn it into a trend.

Losses needed to affect the flock without making reporting feel heavy.
Mortality can easily become a disconnected record, even though it directly changes the state of the flock. I kept it close to the flock experience while giving farmers enough space to monitor what has happened over time.
A mortality record can capture the flock, number of birds lost, date and supporting documentation where needed. Those records can then contribute to the wider picture of flock health and mortality rate.
The aim was to make a difficult but necessary farm action clear to record and useful elsewhere in the system.

Feed inventory needed to show what was bought, used and still available.
Knowing how many bags were purchased is only part of the job. Day to day, the farmer also needs to know how much feed is left and where it is being used.
I gave Feed its own management area rather than hiding it inside a general inventory screen. Farmers can record purchases, quantities, suppliers and costs, then record usage against a particular flock.
That relationship allows remaining stock to stay current and gives feed costs a second purpose later in the farm's performance and financial picture.

The records become valuable when they explain how the farm is performing.
A farm owner can record plenty of information and still have no clear picture of whether the farm is performing well. Performance connects the operational side of the product to the business side.
Flock costs, feed, medication, labour, utilities, maintenance, rent and other expenses can contribute to production cost, while recorded sales contribute to revenue. Together they support measures such as Cost per Bird, Total Production Cost, Total Revenue, Profit or Loss, Mortality Rate and Revenue per Bird.
I did not want analytics to feel like a separate place where numbers simply appear. It is designed as the natural result of work the farmer has already recorded.

A worker should be able to do the job without seeing the whole business.
Not everyone working on a farm needs access to everything. An admin may need to manage workers, finances and farm settings, while another person may only need to record egg production or feed usage.
I designed permissions around the work each person actually needs to perform. The farm admin creates the worker and generates an access code, which acts as an invitation rather than becoming the worker's permanent credential.
I also treated deactivation, reactivation and deletion as part of the worker lifecycle. Removing access should not automatically erase the history of work that has already been recorded.

The marketplace needed to connect both sides without becoming a second product.
Marketplace sits beside Farm Management as the commercial side of NaijaPoultryHub. It gives poultry businesses a place to be discovered and gives buyers a clearer way to find products, understand who is selling them and decide whether to make contact.
The main design decision was to keep the marketplace focused on discovery, context and trust. I did not add a cart, wallet, checkout flow or heavy order-management layer because the product did not need to own every step of the transaction to be useful.
That meant designing two connected but different journeys underneath the same marketplace: a seller experience with the extra setup needed to publish responsibly, and a buyer experience that stays lightweight enough to move from browsing to conversation quickly.
Selling needed more setup because trust starts before a listing goes live.
The seller journey begins with creating a selling presence rather than immediately posting a product. Sellers need a profile that helps buyers understand who they are, alongside identity verification that gives the marketplace a stronger trust signal.
Selling is also treated as an activated capability. A seller completes the required setup and subscription before publishing listings, so the extra steps only appear for people who actually want to sell.
Once activated, the seller can create listings with the product information buyers need, publish them to the marketplace, and return to manage what is currently available. The experience keeps listing management separate from farm records while allowing the same person to use both parts of the product through one account.
The aim was to give sellers enough structure to look credible and manage their presence without turning the product into a complicated merchant back office.

Buying needed to stay lightweight from discovery to conversation.
The buyer journey is deliberately simpler. Buyers can browse what is available, open a product, understand the listing, see information about the seller and decide whether they want to continue the conversation.
I kept the path focused on the questions that matter before contact: what is being sold, whether it fits what the buyer needs, who is selling it and whether there are enough trust signals to reach out.
When the buyer is ready, the product hands the conversation to WhatsApp instead of introducing a checkout system that NaijaPoultryHub would then have to own, verify and support. That keeps the marketplace close to an existing communication habit while still giving the product a clear role before the handoff.
If the buyer later returns, the product can ask whether the interaction resulted in a purchase and invite feedback. That supports useful reviews without claiming that an external transaction was verified inside the app.

When the transaction leaves the app, trust has to be designed honestly.
Once a buyer moves to WhatsApp, NaijaPoultryHub cannot genuinely know whether a purchase happened. That meant a verified-purchase system would claim evidence the product does not have.
Instead, the review flow starts from something the product can observe: the buyer choosing to contact the seller and later returning to the app. The product can then ask whether a purchase was completed and invite feedback without presenting that interaction as proof of a transaction.
Seller identity verification adds another layer of trust. Together, verification, visible seller information and the review flow acknowledge the limits of an external transaction instead of hiding them.

The strongest decisions were usually the ones that removed a second job.
The shared account removed duplicate registration. Connected records reduce repeated calculations. Permissions let workers participate without exposing the whole business. The Marketplace avoids unnecessary e-commerce complexity by letting buyers and sellers continue the conversation where they already communicate.
The smaller interface decisions came from the same principle. Clear labels, short paths to important actions and strong contrast matter when the product is being used around real farm work rather than at a desk.
The product is still in development, so the next meaningful test is real-world use: how easily farm activity can be recorded, whether Performance helps owners understand the business, and whether the Marketplace feels trustworthy enough for buyers and sellers.
What the design changed.
Because the product is still in development, these are design outcomes and system decisions rather than invented launch metrics.
Different jobs, one product
Farm Management, Marketplace Buyer and Marketplace Seller are treated as distinct journeys without splitting the experience into separate apps.
One shared product foundation
A single account can activate Farm Management or Marketplace when needed, removing duplicate registration and unnecessary setup.
Farm records work together
Flock, feed, production, mortality, expenses and sales are designed to carry information forward into inventory and Performance instead of becoming isolated logs.
Permissions fit real farm roles
Workers can be invited with an access code and receive only the actions their farm admin permits.
A lighter, more honest marketplace
Buyer discovery, seller verification, listings, WhatsApp handoff and interaction-based reviews support trust without adding unnecessary checkout complexity or pretending the app can verify an external purchase.

