The greenfield thesis, in one page.

If we were starting OgaHQ from scratch today, we would build one system that runs an African trader's shop, keeps their books, and answers their customers — all from a WhatsApp message in whatever language the trader speaks. Nobody has shipped this combination. The window for someone to claim the category is the next 24 months.

The strategic bets

This document defends seven bets that shape everything downstream:

1. WhatsApp-native, not WhatsApp-as-a-feature. Every competitor treats WhatsApp as a notification channel. We treat it as the operating surface.
2. Multi-modal in local languages. Voice notes in Pidgin, Yoruba, Igbo, and Hausa. Photos of receipts. Screenshots of bank alerts. All understood.
3. Two-sided WhatsApp. Merchant and customer message the same number. Nobody has shipped this at scale.
4. Reconciliation is the moat. The data compounds. Once every sale ties cleanly to every payment, we own the ground truth on merchant cash flow — which is the foundation for lending, credit, and category expansion later.
5. Freemium land-and-expand. Starts free. Business tier at $15/mo anchors monetisation. Follows Shopify and Notion's playbook, adapted to African price sensitivity.
6. Operations first, payments close the loop. Ship the operations OS. Then layer OgaPay (payment reconciliation) as the killer feature that makes everything above it truthful.
7. Nigeria first. Then linear expansion. Own Lagos. Then Accra. Then Nairobi. Pattern proved by every African fintech that scaled.

The path

Twelve weeks to MVP with 10 pilot merchants in Balogun and Ikeja markets. Nine months to 500 paying merchants across Nigeria. Eighteen months to break-even. Three years to 10,000 merchants and category leadership across four African markets.

The ask

$150,000–$300,000 seed round. 40% into product, 30% into field acquisition (Business Relationship Managers on the ground in Lagos markets), 15% into infrastructure and compliance, 15% operational reserve. Break-even projected at month 18. Target Year-3 metrics: 10,000 active businesses, $150K MRR, 80% gross margin, LTV:CAC of 7:1 or better.

How we'd build it, and why exactly like this.

Every technology choice here is defensible. We are optimising for three properties: trust (financial records must never be wrong), reach (must work on a $50 Android over 3G), and iteration speed (small team, need to ship weekly).

2.1Architectural principles

1. Multi-tenant from day one. Every table carries tenant_id. Every query filters on it. No exceptions. Cross-tenant contamination is architecturally impossible.
2. Offline-first for POS. The till works without internet. Local IndexedDB queue + service worker. Sync when online. Conflict resolution: server-timestamp-wins with client-generated UUIDs for dedup.
3. Financial integrity is non-negotiable. Double-entry accounting. Every mutation writes an append-only audit log. Seven-year retention.
4. Modular monolith, not microservices. Every module (auth, pos, inventory, accounting, etc.) ships in one deployable, but with clean router→service→repository boundaries. Extraction to separate services is a rename, not a rebuild — but we don't extract until traction demands it.
5. AI is an overlay, never authority. The AI proposes; the human decides. AI never mutates business data directly — it calls the same service layer the dashboard calls, subject to the same RBAC.
6. Every write is idempotent. WhatsApp deliveries retry, users double-tap, networks flake. Idempotency keys on every POST prevent duplicate posts.

2.2System context

Three human actors (merchant, staff, customer), three system contexts (web dashboard, mobile PWA, WhatsApp), and three critical external systems (payment providers, WhatsApp Business Cloud API, LLM providers). The OgaHQ backend is the central integrator.

2.3Tech stack & rationale

2.4Data architecture

Postgres tables share a common shape. Every row inherits Base which supplies four columns: id (UUID), tenant_id (UUID FK), created_at, updated_at. The application layer enforces that every query filters by tenant_id.

-- Every table looks like this, minimum
CREATE TABLE sales (
  id           UUID PRIMARY KEY,
  tenant_id    UUID NOT NULL REFERENCES tenants(id),
  created_at   TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  updated_at   TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  -- domain columns below
  invoice_number   VARCHAR(64) NOT NULL,
  sale_type        sale_type_enum NOT NULL, -- 'standard' | 'rapid'
  customer_id      UUID REFERENCES customers(id),
  total_amount     NUMERIC(18, 2) NOT NULL,
  payment_mode     payment_mode_enum NOT NULL,
  status           sale_status_enum NOT NULL,
  client_uuid      UUID UNIQUE, -- for offline dedup
  ...
);
CREATE UNIQUE INDEX ON sales(tenant_id, invoice_number);

Double-entry accounting. Every business event that changes money produces balanced journal entries. A cash sale of ₦3,250 debits Cash and credits Revenue. A credit sale debits Accounts Receivable, credits Revenue. A payment on receivable debits Cash, credits Accounts Receivable. The invariant: every journal entry's debits sum to its credits.

Audit log. Every mutation writes to audit_log (append-only, no UPDATE/DELETE permissions for app role). Retention: seven years for financial events, indefinite for logs of admin actions.

Multi-tenancy invariants.

1. Every table carries tenant_id. Enforced by base model.
2. Every repository method requires an explicit tenant_id argument.
3. TenantMiddleware extracts tenant_id from JWT and pins it into request state.
4. Cross-tenant JOINs are architecturally impossible — services can't reach another tenant's repository.
5. Database backups partitioned by tenant for legal-hold and right-to-erasure compliance.

2.5Integration architecture

Payment providers. Abstracted behind a PaymentProvider interface. Each provider (Paystack, Flutterwave, Anchor, Providus, M-Pesa Daraja) implements the same methods: create_intent(), verify_webhook(), initiate_refund(), get_transaction(). Switching providers is a config change, not a refactor. Two providers active in production from day one to prevent concentration risk.

WhatsApp Business Cloud API. Direct integration with Meta. No third-party BSP dependency. This is a deliberate choice — third-party providers add latency, cost, and a single point of failure. Meta provides the API directly; we own the phone number and templates.

LLM providers. Two-provider strategy from day one. Claude for planning + tool-calling (most reliable). Gemini for vision and as fallback. All LLM calls traced via Opik. Cost per merchant/month capped by tenant-level budget with graceful degradation to template-menu fallback.

2.6Security & compliance

• Authentication. Short-lived access token (30 min) + long-lived refresh token (30 days, httpOnly secure cookie). JWT signed with Ed25519 keys stored in Key Vault.
• Authorization. RBAC enforced at every service method. Permission checks before dispatch, not inside handlers.
• Password policy. Minimum 12 characters, must include at least one digit or symbol. Argon2id for hashing.
• Session security. Account lockout after 5 failed logins. Sessions expire after 30 min of inactivity.
• PII handling. Customer phone numbers stored only where explicitly needed. Never sent to LLM in raw form (tokenised as <customer:UUID>, resolved server-side).
• Data residency. Azure South Africa North primary; EU as fallback. Data physically leaves neither region.
• No training on tenant data. Explicit contractual clause. Table stakes for enterprise adoption.
• Compliance targets. Nigeria NDPA + Kenya DPA registration within 6 months of launch. SOC 2 Type I within 12 months. SOC 2 Type II by month 18.

2.7Deployment & operations

Infrastructure as code via OpenTofu. Full stack reproducible: terraform apply creates resource group, Postgres, storage, ACR, Container Apps environment, both apps, Key Vault, managed identities, RBAC. Deploy pipeline: GitHub Actions builds and pushes images to ACR, updates Container Apps to new revision, waits for health check.

Environments. Two: dev (branch previews) and prod (main). Staging deliberately omitted — Container Apps revisions provide staged rollout via traffic percentage. Merge to main = production. Revisions can be rolled back in seconds.

Observability. Application Insights for APM. Log Analytics for structured logs. Opik for LLM turn tracing. Custom dashboards for per-tenant cost, error rate, tool-call success rate.

2.8Scaling plan

The architecture scales to 100K tenants without material changes. Beyond that, four things get extracted or scaled:

1. Postgres → sharded per-region. Nigeria, Ghana, Kenya, SA each get their own Postgres primary. Cross-region queries impossible; each tenant lives in one region.
2. WhatsApp module → separate service. Message volume grows super-linearly. Extract when messages exceed 10M/day.
3. MCP + Agent runtime → separate service. Reusable across channels (WhatsApp, web copilot, SMS). Natural extraction candidate for the OgaKit platform play.
4. Analytics → dedicated warehouse. When cross-tenant analytics load starts affecting transactional performance, move analytics to Snowflake or ClickHouse.

The visual and interaction language.

A design system is not decoration. It's a decision-compression tool: every time we skip re-picking a colour or re-picking a spacing value, the team ships faster. This is the OgaHQ system. It is opinionated on purpose.

5.1Design principles

1. The 10-second rule. The most common merchant actions — check today's sales, add a product, record a sale, check a customer balance — must complete in under 10 seconds. If a flow takes longer, we redesign it.
2. Zero training. A first-time user should complete their first sale within 5 minutes of signup. No manuals. No videos. No support tickets.
3. Graceful degradation. When the internet fails, the system gets simpler, not broken. Offline mode strips features but never functionality on the critical path.
4. Channel-appropriate communication. Dashboard responses are visual. WhatsApp responses are conversational. Push notifications are urgent. Emails are archival.
5. Owner authority preserved. The AI recommends. The owner decides. Every AI-suggested action carries a rationale and a confidence score.
6. Progress not perfection. When we're 80% sure and the merchant has been waiting, we ship the answer with a confidence caveat rather than nothing.

5.2Colour system

Chosen neutrals with intent, three semantic accents, and semantic pairs for status. Every value in the system defers to accessibility contrast ratios (WCAG 2.1 AA minimum).

Semantic pairs (status)

Semantic colours are separate from accents. A "success" state is green not because green is our brand — it's green because it's semantic.

• Success / paid / balanced: forest green, #1F4A3E
• Warning / attention / pending: ochre, #C58F1A
• Error / failed / unpaid: terracotta, #B54A2E
• Neutral / info: ink-soft, #3A342B

5.3Typography

Three type roles: display, body, mono. All from system stacks. No webfont dependency — loads instantly, works offline.

Type scale. Modular scale of 1.25 ("major third"), anchored at 16px body. Sizes: 12 / 13 / 14 / 16 / 18 / 20 / 24 / 30 / 38 / 48 / 60.

Currency rendering. Always ₦12,500 or ₦12,500.00. Currency symbol before the number. Thousands separated by comma. Two decimals for amounts requiring precision.

5.4Component library

Base on shadcn/ui + Radix primitives. Copy-paste-and-customise, not a runtime dependency. Core components v1:

• Button — three variants (primary, secondary, ghost), three sizes (sm, md, lg). Loading state built in. 44×44px minimum touch target.
• Input — labels, help text, error state, disabled state. Currency-aware inputs auto-format on blur.
• Table — sortable, sticky headers, mobile "card view" fallback below 640px. Never horizontal scroll.
• Card — the primary content container. Padding scale (16 / 24 / 32).
• Modal / Sheet — modal on desktop, bottom sheet on mobile. Close on backdrop tap.
• Toast — 4-second auto-dismiss, one at a time, semantic colour by type.
• Badge / Pill — semantic status indicators. Same colour system as text.
• Stat card — big number, label. Used across dashboards.
• Empty state — always with a next action. "No sales yet today — your first customer is just a scan away."
• Search / Combobox — the primary product-lookup pattern. Debounced, keyboard-navigable, mobile-friendly.

5.5Voice & tone

The OgaHQ writing voice is: direct, warm, culturally grounded, and never condescending. We speak to the merchant as a peer, not as a novice user.

5.6Accessibility

• Target WCAG 2.1 AA for all customer-facing surfaces.
• Colour contrast: 4.5:1 for body text, 3:1 for large text and UI elements.
• Keyboard navigation for every interactive element. Visible focus states.
• Touch targets ≥ 44×44px on mobile.
• Semantic HTML (landmarks, headings, buttons vs. links).
• Screen-reader labels for every icon-only control.
• Respect prefers-reduced-motion — no essential info conveyed via animation.
• Autocomplete attributes on form fields.

5.7Motion & interaction

Motion is used for two things only: state feedback (something happened) and hierarchy (this is more important than that). No motion for decoration.

• Micro-transitions: 120-180ms cubic-bezier(0.4, 0, 0.2, 1). Buttons, hovers, focus states.
• Layout transitions: 240-320ms same curve. Panels opening, tabs switching.
• Success moments: subtle 400-600ms confirmation animations. Never blocking.
• Loading: skeletons for content, spinners for actions. Never both simultaneously.

Free-to-paid, then payment margin, then platform.

Every enduring commerce infrastructure company evolved from a single revenue stream into three or four. Stripe went from payments → banking → capital → issuing → billing → tax. Shopify went from stores → payments → shipping → capital → POS → fulfillment. OgaHQ's path is: SaaS subscription → payment processing margin → AI add-ons → potential lending rail.

7.1Revenue streams

7.2Pricing philosophy

Three principles determine our pricing:

1. Free tier must be usable, not crippled. A trader on the free tier can run their whole day. That's the point — they experience the value, then convert when they need capacity or capability the free tier caps out.
2. Business tier is the anchor. $15/mo. Priced under Sage/QuickBooks by 3-5×. Priced above Prokip and Loyverse for capability we deliver that they don't (accounting, WhatsApp integration, etc.).
3. Pro tier adds concrete capabilities, not just quantity. Multi-branch. Full accounting. Social. AI features. These are the things a business needs when it has grown beyond one shop.

7.3The four tiers

7.4Unit economics

Rigorous unit economics discipline from day one. Our target curve:

The maths that has to hold: at ARPU $15 and 4% monthly churn, LTV = $15 × (1/0.04) = $375. At CAC $25, LTV:CAC = 15:1. Even at pessimistic 8% monthly churn and $20 CAC, LTV:CAC = 9.4:1. The unit economics are viable across a wide range of assumptions.

7.5Payment processing margin (OgaPay)

Nigerian card + transfer processing typically costs merchants 1.5-2%. Paystack/Flutterwave charge merchants directly. OgaPay adds a small margin (0.3-0.5%) on top for the reconciliation service. At $10K/mo GMV per Pro-tier merchant, that's $30-50/mo per merchant in additional revenue — potentially larger than the subscription itself.

The critical decision: transparent, tiered payment fees, with volume discounts for Pro/Enterprise. Never hidden. Always disclosed at signup. Merchants trust us because we tell them the truth about our take.

7.6Path to profitability

Break-even at Month 18. The maths:

• Fixed cost (small team + infrastructure): $15-20K/month by Month 12.
• At 1,500 paying merchants × $15 ARPU = $22.5K MRR at Month 18.
• Plus ~$5K/mo in payment margin from Pro-tier merchants using OgaPay.
• Total ~$27.5K MRR against ~$22K burn = break-even with modest headroom.

7.7Comparable case studies

All four companies made the same core bet: own the primary workflow, then monetise the adjacent value pools. Payments is the highest-value adjacent pool in commerce; that's why every one of them ended up there. OgaHQ's path is the same.

Where the merchants actually come from.

Every African fintech that scaled did so through three channels: field agents, peer referral, and partnerships. Digital marketing is a distant fourth. This section builds the acquisition engine around what actually works in this market, not what looks good in a pitch deck.

9.1Channel mix

Target channel mix by end of Year 1:

9.2Field BRM playbook — the trust channel

This is how Paystack acquired its early merchants. It is how Prokip acquired its early merchants. It is how M-Pesa built its agent network. Human trust wins.

Who a BRM is. A locally-hired sales rep with a smartphone, comfortable in market environments, ideally fluent in the local trading language (Yoruba, Hausa, Igbo, Twi, Swahili). Compensation: base salary + per-activated-merchant commission + retention bonus after 90 days.

The daily routine.

1. 8 AM — Team standup. Review yesterday's activations. Plan today's market.
2. 9 AM-12 PM — Market walkabout. Cold visits. Live demos on merchant's own phone. Instant signup.
3. 12-1 PM — Break. Follow-up calls / WhatsApp messages to yesterday's leads.
4. 1 PM-4 PM — Onboarding visits. Sit with new merchants during their first day.
5. 4-6 PM — Existing merchant check-ins. Answer questions. Log friction to product team.
6. 6 PM — Day log into CRM. Metrics: visits, live demos, signups, activations.

Targets. A single BRM should onboard 15-20 merchants per week after ramp. Assuming 60% still active at Day 30, that's 8-12 net weekly. At 4 BRMs by Month 6, we generate 100-150 net new active merchants per month via this channel alone.

The BRM tooling. A merchant-BRM app for logging visits, tracking prospects, running live demos, and closing accounts on the spot. Integrated with the main OgaHQ backend so activations register instantly.

9.3WhatsApp referral programme — the viral channel

Every merchant on OgaHQ has other merchants in their contact list. Every merchant messages other merchants regularly. This is the viral surface.

Mechanics.

• Every merchant gets a unique referral code embedded in their WhatsApp invitation link.
• Referrer gets one month free Business tier for each merchant who signs up and activates (records first sale within 7 days).
• Referee gets one month free Business tier at signup — starts on the paid tier's features immediately.
• Referrer can accumulate months up to 12 (a year free).

WhatsApp-native distribution. "Share via WhatsApp" is the primary sharing button. The invitation message is pre-written, includes a video demo, and can be forwarded to a group.

Referral leaderboard. Public leaderboard of top referrers per market. Social proof + gamification. Top referrer per quarter gets a physical trophy delivered to their shop (this is a $50 marketing spend that becomes a Twitter photo worth $5,000 of earned media).

Expected performance. If 30% of merchants refer at least one other merchant, and referral conversion is 40%, and activation of referred merchants is 60%, then every 10 merchants generates 0.72 additional merchants over their first 6 months. That's a k-factor of 0.72 — not yet viral (need k > 1), but a powerful amplifier of the paid channels.

9.4Partnership channel

Three types of partnerships, each with different mechanics:

9.5Content & organic

Content is a slow compounding channel. We start Month 3, expecting first traction by Month 12.

• Blog. Weekly. Practical "how to run your shop better" content, not thinly-veiled product pitches. E.g.: "5 signs your inventory is out of control," "How to reconcile mobile-money payments across 3 apps."
• Twitter / X. Founder-led. Building in public. Weekly threads on merchant lessons. Product screenshots. Feature launches.
• YouTube shorts + Instagram Reels. 60-second product demos. Merchant testimonials. Real workflows. This is where our target merchants actually watch content.
• Podcast appearances. Founder guest slots on African tech podcasts. Longer-form for early-adopter audiences.

9.6Paid channels

Deliberately deprioritised. CAC via Meta Ads for African SMEs is $30-50+, far higher than our field or referral channels. Paid is used for:

• Retargeting. Waitlist signups who didn't activate get re-engaged via Meta or WhatsApp.
• Feature-launch amplification. When OgaPay launches, paid ads amplify the announcement for 2 weeks.
• Geographic launches. When we enter a new city, a targeted 2-week paid campaign creates awareness.

9.7Conversion funnel

Every channel feeds into the same funnel. What we optimise is each stage:

Each stage has a dedicated intervention:

• Awareness → Interest: compelling landing page + WhatsApp CTA that reduces friction to first message.
• Interest → Signup: minimal signup form (name + phone + business type). Continue in WhatsApp if preferred.
• Signup → Activation: in-app onboarding wizard + WhatsApp check-in from BRM on Day 1 and Day 3.
• Activation → Paid: free tier caps hit + Business tier value framed in currency (revenue insight, credit tracking).
• Paid → Retained: feature-usage tracking; if a paid feature isn't being used, proactive outreach to demonstrate.