SesaHub
For growing Ghanaian businesses becoming too complex to run from separate tools: one workspace to manage staff, review finance, control stock, handle orders and decide who can see what.
2025
- Client
- Nyande ERP Solutions (internal)
- Type
- Internal operations workspace
- Stack
- Laravel 11, React, TypeScript, Inertia.js, Tailwind, PostgreSQL
- Team
- Dominic Nyande, business analyst; Amy Nyande, data analyst
A product proposition
A growing company still has to manage staff, review finance, control stock, handle orders and set policies — and those jobs do not always live in one place.
The target was growing businesses in Ghana moving from owner-led operations into something that needed more structure. SesaHub asked whether those jobs could live in one workspace, with access shaped by the person’s role and organisation. I defined that product model, designed the screens, and built the system. There was a wider ambition that the product could later be relevant in other African markets. We did not research that region, and this page does not treat that ambition as a finding. There is no external client. TechCorp Solutions Ltd in the screenshots is seeded test data, not a customer.
Initial proposal
The product started from a hypothesis: growing businesses could benefit from managing more of their operation in one place. Reviewing finance, managing staff, setting policies, controlling stock, handling orders and reporting were treated as related jobs. The question was whether they could sit in one workspace, with access changing by the person’s role and organisation, rather than requiring a separate tool for each job.
Discovery
Ghana was the starting context. The work was an internal family product for Nyande ERP Solutions. Dominic Nyande was the business analyst: he helped define business requirements, discuss what each module needed to support, and challenge how the product should work from an operational perspective. There are no formal research reports or user-interview outputs from that work. Amy Nyande worked from the data side: she helped think through the information the system needed to hold and what a business would need to understand from it. That was not external user research. I do not have a formal competitor study from the original project.
Product response
I designed the product around those jobs: control who can see what, manage staff, keep customer and supplier records, control stock, review finance, and handle orders — with the purchase-order path left unfinished. Owners and managers needed the overall picture; finance needed transactions and records; HR and operations needed people and organisational information; employees needed only the parts relevant to their work. Company isolation, roles and the ledger are how that product idea becomes a system. Implementation is in Design to code.
The jobs.
The jobs a growing company has to do, designed so they can live together.
Built December 2024 to October 2025. The target was businesses moving from owner-led operations into something that needs structure: manage staff, review finance, control stock, handle orders, and decide who can see what. Screens are from the running app on seeded test data. Purchase-order request-to-receipt is not shipped. Company policies and recruitment were part of the original idea; they are not presented here as finished modules.
Problem
SesaHub was intended to serve many independent businesses from one product. If companies share a single set of records, isolation is only a dropdown. Permissions, currency and the books have to start from the organisation.
Solution
A company record is the workspace. Creating a company also starts its financial setup, so the books belong to that organisation from the beginning rather than arriving as a later add-on.
Before
- Separate tools per company, or one database everyone can see
- Access treated as a filter on a shared list
After
- Each organisation as its own workspace
- Roles that can cross companies without mixing records
- Financial setup started with the company
Problem
A growing company may run more than one location. Stock, people and fulfilment are per site. If a site is only a name on the company, inventory and employees have nothing reliable to join to.
Solution
Sites sit under the company. Each site gets a generated code. Employees and inventory attach to that record.
Before
- Location as a note on the company
- Hand-assigned site codes
After
- Site list under the company
- Generated codes
- Employees and inventory join to the site
Problem
A business owner, a finance person, an HR or admin employee and general staff should not have the same access. If people live in a spreadsheet beside the product, assignment, login and responsibility drift apart.
Solution
An employee record with site assignment, generated IDs, department and status, tied into the same login and permission model as the rest of the product.
Before
- Staff lists off-system
- No join from a person to a site or a role
After
- People on the same product as the work
- Site and company on the record
- Login and role on the same person
Problem
Stock and money need counterparties. Without customer and supplier records, orders and purchases have nowhere to live.
Solution
Customers with addresses and customer orders, and suppliers as their own records. That is the party layer. It is not a finished purchase-order workflow.
Before
- Counterparties in a sheet or in someone’s head
After
- Customer records, addresses and orders
- Supplier records
- Purchase-order steps still a later module
Problem
A single quantity on the company hides which site can fulfil an order. Categories and identifiers have to survive more than one location.
Solution
Parts, product categories and inventory. Stock levels live on the site. SKU and barcode sit on the part.
Before
- One stock number for the whole company
- Categories remembered, not stored
After
- Part records with SKU and barcode
- Category taxonomy
- Inventory rows per site
Problem
A growing business may need to work in more than one currency. Looking rates up beside the system makes the books and the stock disagree.
Solution
Currency records in the same workspace, with conversion available on the company and on a transaction rather than only as a global default.
Before
- One currency assumed for every company
- Rates looked up off-system
After
- Currency records in the product
- Conversion available in the same workspace
- Company and transaction overrides
Problem
The finance module was trying to support proper financial records for the kind of growing business SesaHub was aimed at. Totals on a dashboard are not enough if there is no underlying record of transactions, and the books have to belong to the same organisation as the people and the stock.
Solution
Accounts, ledger, journal entries, trial balance, account analysis and a fiscal calendar as a first-class part of the product. The screenshot is the TechCorp test company with zeroed balances.
Before
- Books in a separate tool, or not at all
- No fiscal period on the company
After
- Chart of accounts and general ledger
- Journal entries and trial balance
- Fiscal calendar on the same login
Problem
Orders were part of the original operational picture. The public write-up listed an end-to-end purchase workflow. Shipping that copy as a finished module would have presented work the product does not do yet.
Solution
Supplier records and customer orders are in the build. The request → approval → purchase → shipment → receipt path is not. It stays marked in progress.
Before
- A written purchase pipeline with no screen to show
After
- Supplier and order foundations in place
- Purchase-order workflow not presented as shipped
04 / Deep dives
Product questions the system had to answer
Company isolation, roles and the ledger are how one workspace can control access, manage staff, review finance and keep stock without mixing organisations.
Access follows role and organisation
Problem
SesaHub was meant to serve many independent businesses from one product. A business owner, a finance person, an HR or admin employee and general staff needed different visibility. A company dropdown on a shared table would mix organisations.
Contribution
I treated the company as the workspace and designed access around the person’s role inside that organisation. Consultants and family users can hold roles across companies without sharing rows. Creating a company starts its financial setup in the same step.
Constraints
- No external client brief — this is an internal product.
- Dominic helped define what the modules needed to support from an operational perspective.
- Amy helped think through the information the system needed to hold.
- Isolation had to hold for employees, sites, stock and the ledger, not only the company list.
Scope access by organisation
Permissions sit on the records, so a missed filter in the interface cannot mix companies.
Start the books with the company
A company without financial setup is a list of names. The workspace and the records are created together.
Employees list. Company is a column on the record — TechCorp and East Africa Trading are seed data, not a shared staff table.
Outcome
Shipped. Companies, sites, people and the ledger share the same organisation rules.
05 / Design to code
Making the product model run as one system
Owning both the interface and its implementation meant the module and permission model could be tested against a running multi-company system. Laravel, React, TypeScript and Inertia are how those records stay on one login. Docker on Render is how it shipped.
Permissions on the company
A person’s cross-company role is still a role on a company.
Let the system issue the codes
Site codes and employee IDs come from the service layer so lists stay joinable when someone forgets a naming convention.
Keep conversion in the product
Currency conversion and rate updates run in the same workspace as the books.
- Laravel 11
- PHP
- React
- TypeScript
- Inertia.js
- Tailwind CSS
- PostgreSQL
- Docker
- Render
06 / Outcome and status
Where the product stands
SesaHub shipped on Render as Nyande ERP Solutions in October 2025, after work that started in December 2024. It is an internal product proposition: a working system for the jobs we believed a growing business would need to coordinate. The running app is seeded with test data. There is no external client and no named quote. The live URL is not on this page until there is one to give.
Evidence
- Shipped: company workspaces, sites, employees, customers and suppliers, products and inventory, currency, and core financial records.
- Observed: a running internal app on Render, on seeded data. There is no public customer deployment on this page.
- Design evidence: modules and access designed around different responsibilities inside an organisation, with finance as records rather than totals only.
- Launch architecture: one product for multiple organisations. Implementation is in Design to code.
Evidence boundary
There was no external client and no Ghanaian SME interview programme. Screens use seeded demo data. I do not claim adoption, revenue or operational impact.
What I would validate next
If I were developing this now, I would interview the growing Ghanaian businesses the product was aimed at and test which modules are essential versus unnecessary complexity. I would finish the purchase-order workflow only if that job is confirmed. The mobile, voice and AI items on the older page stay later work. The wider African ambition would remain an intent until it is researched.
Looking back
Ghana Statistical Service's 2024 Integrated Business Establishment Survey reported that 92.3% of businesses operate informally, with informal status including businesses that do not maintain formal accounts. The same survey found that the overwhelming majority of establishments are micro businesses. That does not validate SesaHub by itself. It gives later context to the opportunity we were exploring: what happens when a growing business begins to need more structured records, responsibilities and operational systems.
Reflection
The honest version of this project is a 0→1 product proposition, not a client transformation. I would still start from the jobs a growing company has to coordinate, and I would still design access around role and organisation. I would validate those jobs with the businesses themselves before expanding the system, and I would not describe an African-market ambition as a finding.