The product core: thesis, five surfaces, and the entity model
What Tomero is, the five surfaces it ships, and the data model underneath them
Folake owns a community pharmacy in Surulere. She restocks shelves in the morning, checks what is running low at noon, and reviews the month's payroll draft on the bus home. Tomero is the app she does that from: one product on her phone that carries her stock, her people, and her pay records.
What Tomero is #
Tomero is a mobile-first operations app for Nigerian small and medium businesses (SMEs). It combines two jobs in one product: pay people correctly, and know what stock you have.
Payroll computes gross to net under versioned statutory rules. The seeded rule set, NG-NTA-2025, carries the PAYE tax bands and the employee-side pension, NHF, and NHIS deductions. Inventory records every stock change in a movement ledger, an append-only list of stock changes, and derives the current level of each product from it.
The app is mobile-first because the primary user runs the business from a phone, under real interruptions. Every screen helps the user finish one operational task quickly. Accuracy outranks surface area: a feature that would introduce ambiguity into payroll, sync, or auditability waits for a later slice.
Trust is a product feature. It comes from accurate calculations, a visible audit history, clear sync state, capability-scoped access, and a payslip record for every employee in a finalized run.
Who it serves #
The launch is designed for a specific shape of business:
- 0 to 25 employees
- a single operating location
- one owner or manager as the main operator
- monthly payroll as the dominant pattern
- one inventory pool with recurring stock-in and stock-out activity
- unreliable internet connectivity
- low tolerance for complicated setup
A single-location supermarket, a community pharmacy, or a small workshop with a stock room is the best fit at launch.
The five surfaces #
The product ships five primary surfaces. Every other interaction opens as a task-focused form, sheet, or step flow launched from one of them.
| Surface | What it carries |
|---|---|
| Dashboard | Setup progress, summary cards, and the Recent Activity preview |
| Inventory | Products, stock movements, balances, and low-stock thresholds |
| Payroll | Employees, compensation profiles, runs, and payslips |
| Alerts | Needs-attention items across areas, plus the client-owned Sync tab |
| Settings | Account, business, team, support, and access concerns |
The navigation stays stable while the capabilities underneath it deepen.
The entity model #
Postgres holds the canonical record: 23 tables in four groups. The design sorts every table into one of three data categories:
- Canonical business facts: current configuration and entities, such as businesses, memberships, employees, compensation profiles, products, and thresholds.
- Append-only history: records of something that happened, such as stock movements, audit events, finalized payroll snapshots, and idempotency claims (records that stop a retried write from applying twice).
- Derived read models: cached summaries that make screens fast, such as inventory balances and dashboard totals.
Where trust matters, the append-only history is the source of truth. The current stock level of a product derives from its movement ledger. A finalized payroll run keeps immutable snapshots of the inputs it used. Audit events only append.
When Folake records a stock-in of 40 packs of paracetamol, the app appends one movement and updates the derived balance from it. The ledger stays replayable, and the balance stays fast.
A user acts inside a business through a membership. Each membership carries its own granted capability set; a capability is a named protected action, such as recording stock movements. The Owner, the one team member with full access across the business, implicitly holds all 18 capabilities.
The 23 tables by group
| Group | Tables |
|---|---|
| Identity and access (9) | businesses, users, verification_challenges, refresh_tokens, business_memberships, business_membership_capability_grants, business_invitations, business_invitation_capability_grants, locations |
| Payroll (6) | employees, compensation_profiles, payroll_rule_sets, payroll_runs, payroll_run_items, payslips |
| Inventory (4) | products, inventory_thresholds, stock_movements, inventory_balances |
| Trust, sync, and operations (4) | approval_requests, alerts, audit_events, idempotency_keys |
The capability vocabulary
The 18 capabilities: view_inventory, add_products_directly, submit_products_for_approval, create_stock_movements, view_stock_history, view_employees, manage_employees, view_payroll, create_payroll_drafts, review_payroll, view_payslips, share_payslips, manage_business_settings, manage_members, manage_products, finalize_payroll, view_audit_history, decide_product_approvals.
The last six are Owner-only at launch. Attention items derive their visibility from area grants only: low-stock items follow view_inventory, and payroll-readiness items follow view_payroll or view_employees.
Storage conventions
- Primary keys are UUIDs.
- Timestamps are UTC.
- Business-owned rows carry
business_id. - Money is stored as integer minor units, kobo for NGN.
- Offline-capable write endpoints are idempotent.
Launch boundaries #
Launch scope is delivery sequencing; the data model is built so later workflows arrive as additions. The boundaries today:
- Every business has exactly one Owner, created at onboarding.
- Every business operates one Default Location. Multi-location management is a deferred workflow.
- Payroll runs monthly only, with employee-side statutory deductions only.
- Two writes queue offline: creating a product and creating an employee. Every other write needs a connection.
- Tomero ships as a mobile app only. A web dashboard is deferred.