Igun Africa SaaS — Product Requirements (PRD)

Last updated: 2026-09-16

Overview

Igun is a B2B metals-trading SaaS that moves African metal and mineral trades from email and spreadsheets onto one verified platform, from KYC to signed contract, inspection and settlement. This PRD covers the next release beyond the existing MVP (marketplace, basic RFQ, buyer plans), based on the Module & Feature Scope by Kingsley Udoh.

Problem. Buyers and suppliers negotiate by email, compare offers in spreadsheets, and have no defensible record of sample custody, assay results or who signed what. Counterparty verification across African jurisdictions is slow and manual.

Goals

1. Verified counterparties: every company passes KYC, registry and licence checks before trading.
2. One digital trade flow: request → offer → negotiation → contract → inspection → logistics → settlement.
3. Comparable offers: one-click landed-cost normalisation replaces manual spreadsheet analysis.
4. Defensible trades: immutable audit trail, chain of custody, assay-driven price adjustment.
5. Revenue: supplier and buyer subscriptions plus a USD 10/tonne brokerage fee on every negotiated trade.

Out of scope for this release: transactions made off-platform, translation of user-generated content, phone layout (tablet is required; phone is a separate decision).

Users and personas

Four personas share one identity system; a single company email can hold both buyer and supplier roles, each with its own plan.

Within a company, users hold roles (admin, compliance officer, operations, finance) and granular permissions. Signature authority is always granted explicitly.

Scope and priorities

The source document lists five modules but no phasing; the priorities below are a proposal based on dependencies (you can’t trade without KYC, or settle without contracts).

Functional requirements

The core trade flow every module plugs into:

A trade is created only on acceptance or award; publishing a listing or request never creates one.

1. Onboarding and KYC (all personas)

• Supplier registration has seven sections: general info, documents and certificates, self-disclosures, users, account, locations, ESG questionnaire. Required fields follow the source spec.
• Buyer registration: company, contact, account, compliance (KYC docs, directors and shareholding, bank details, VAT/TIN), optional preferences (currency, units, interested metals).
• Registration auto-saves and can be resumed without losing uploads.
• The company registration number is checked against the national registry where an API exists; otherwise it is queued for manual compliance review. Certificates store expiry and verification status.
• Email is verified before first login. Access to bid/respond is granted only after admin KYC approval.
• Invitations carry the inviter and the request; on completion the invitee is linked in CRM and routed to that request. Invites expire after 7 days and can be reissued.
• KYC data is read-only for users; changes go through Igun support and are logged.
• Password rules: at least 8 characters, with uppercase, lowercase, number and special character; confirm-password field for buyers.
• Forgot password: link on the login screen, verified by email or SMS link/OTP.
• Preferred communication channel (email, SMS, portal) is compulsory for suppliers; 2FA setup is optional at signup.
• Supplier registration also captures contact person, beneficial ownership (compulsory), and optional mine-site GPS. It supports regulatory documents for conflict minerals, IRMA, Nickel Mark, carbon footprint and recycled content.
• A supplier invited via an RFQ starts on the Open plan and can respond to that RFQ and to public RFQs; anything more needs an upgrade.
• Buyer “interested metals” (multi-select plus “Other” free text) is stored on the profile and drives RFO recommendations, new-offer alerts and supplier targeting.
• Registry and mining-licence authorities per country are listed in the appendix.

2. Subscriptions and billing

• Supplier plans: Open (basic support, respond to RFOs), Premium (+ CRM, standard analytics), Enterprise (+ publish RFOs, bidding events, enquiry and inventory management, dedicated support). Upgrades go through sales; entitlements change on successful payment.
• Entitlements are enforced server-side; blocked actions show the reason and an upgrade route.
• Users can view plan, entitlements, renewal date and billing history; manage saved cards and a default card. Igun never stores card data.
• Failed renewals retry on a schedule, notify the customer, and have a defined entitlement consequence.
• Invoices and receipts can be downloaded.
• The feature list marks two supplier features as paid-plan only: raising RFOs and AI buyer recommendations (see open questions for the conflict with the plan table).

3. Sales module (suppliers)

• Products: create, edit, archive and search specs (metal type, grade/purity, moisture, origin, mine region, media: up to 8 images at 10MB, up to 2 videos). Licence and sourcing certificates auto-fill from the profile. Specs in use cannot be deleted. Terms must be accepted. CSV import/export with a template.
• Product details: commodity type and physical form are dropdowns with an “Other” free-text option; purity has a unit dropdown; moisture is 1–100%. Optional uploads: contaminants report, Certificate of Analysis (e.g. SGS, Intertek), technical spec (PDF, up to 10MB). Images are JPEG, PNG or WebP; videos are MP4 or MOV, 100MB–1GB. Deleting a product needs a confirmation prompt. Terms are at staging.igunafrica.com/terms.
• Listings: built from a spec with quantity, UoM, MOQ, packaging, price, Incoterms, loading port, payment terms (EXW/CIF), payment method (Verto global account or direct + separate commission). Validity at most 1 year; reminders 3 days and 24 hours before expiry; expired listings are hidden. The USD 10/tonne brokerage notice is always shown.
• Listing management: edit, delete, publish, unpublish, archive and unarchive, with one view showing every listing’s status.
• Inventory: lots with ID, spec, quantity, location, status (available, allocated, in transit, delivered, written off). Allocated quantity cannot be double-allocated; delivery auto-decrements; every movement is logged.
• Inventory extras: lead-time monitoring; visibility follows permissions across purchasing, sales, operations and planning; off-platform transactions are not tracked.
• RFQ responses: quotation with price, currency, quantity, Incoterms, lead time, validity, documents. Decline with reason, withdraw before acceptance, auto-expiry, visible status.
• RFQ view: the source links a screen recording of a simplified RFQ view to show buyers first.
• RFOs: to all or selected buyers; intent Indicative (max 3 per month, no trade workflow) or Firm; listing type Negotiation or Auction (bidders see their rank); non-negotiable fields locked; CO2 source required (self-declared, calculated, verified) with a badge. Suppliers may close an RFO without selling.
• RFO details: suppliers can invite buyers by email to a specific RFO. Required fields: system RFO ID, supplier ID, intent, product, metal type, quantity, UoM, specs, images/videos, delivery location, delivery timeline, payment terms (EXW/CIF), currency (USD), offer validity, notes. Buyers can filter by intent; tooltips explain Indicative vs Firm; buyers are told when an RFO is exploratory. Igun tracks buyer engagement on RFOs. The non-negotiable field picker follows the linked screen recording.

4. Procurement module (buyers)

• Buyers save frequently purchased products for reuse in RFQs.
• RFQs: to all or selected suppliers; editable before publish, withdrawable after with notice. Delivery mode single or multiple, with an editable delivery schedule and a calculate action.
• Delivery schedule: set the contract start and end dates, then add, edit or delete delivery periods (screen recordings linked in source).
• Evaluation: compare, normalise, negotiate, award or decline. Split awards create one trade per supplier, linked to the parent RFQ, with the awarded quantity (may exceed the request) and a split log. Suppliers see full vs partial award. Declining a quotation notifies the supplier.
• Invited buyers: after approval, they go straight to the RFO that invited them and are linked to that supplier in CRM.
• RFO responses: offer with price, currency, quantity (if different), Incoterms, destination, additional terms, validity; the response time is recorded. Save as draft; decline or withdraw. Both parties are notified on acceptance.
• Bids: bid on marketplace listings only after acknowledging terms, including the USD 10/tonne fee deducted at settlement.
• Lab and logistics selection: after award, before contract. Choose an onboarded inspection agency and logistics company plus optional vessel, or enter a custom provider. Choices are stored on the trade, embedded in the contract, and the provider is notified.
• Inspection form: each agency shows accreditation (e.g. ISO/IEC), coverage (global, regional, local) and service scope. Optional inspection types: pre-shipment inspection, loading supervision, quality verification, environmental compliance audit. Optional preferred date and notes. The inspection requirement appears in the contract for the supplier.
• Logistics form: each provider shows routes, accreditation or insurance, and service scope (bulk, containerised, specialised metals). Vessels show name, capacity, route and departure dates. Optional preferred shipping date and notes. Buyers can book a vessel or shipping slot and see provider contacts and reviews.
• Tracking: buyers see shipping documents and tracking updates on their trades. A custom (non-onboarded) logistics company is notified automatically when the trade is confirmed.

5. Negotiation and counter-offers (shared)

• Counter-proposals can change price, quantity, delivery timeline, payment terms, Incoterms; locked fields (product, origin, destination, non-negotiables) cannot change.
• RFO round order: buyer offers → supplier accepts, rejects or counters → buyer accepts, rejects or counters again.
• Max 2 counters per party; each has author, timestamp, changes and its own validity; auto-expires.
• Outcomes: accepted (creates trade), rejected, withdrawn, expired. Full history is kept, including rejections.
• Only permitted users can accept; concurrent acceptance by two colleagues must never create two trades.
• UI shows a thread with colour-coded statuses and a diff summary (e.g. “Price reduced by 5%”).
• Each counter-offer sends a notification with a clear call to action. Every round is kept in the audit trail.

6. Offer comparison and normalisation

• Side-by-side view of all responses to one request; one action converts each to landed cost per unit using FX, freight, import duties (from RFO origin/destination) and Incoterms.
• FX rate is locked at RFO creation, displayed, and stored per transaction.
• Each comparison records the parameter set and rates used; missing inputs show as incomplete, never silently filled.
• Users can see the cost breakdown, export the comparison, and search/filter by parameter. Counter-offers are normalised the same way.

7. Contracts

• Generated in English from an accepted trade using a versioned template; embeds provider selections, price-adjustment formula and who-pays rules.
• Signed via DocuSign by users with signature authority; names, dates and times recorded.
• Statuses: generated, awaiting signature, partially signed, executed, superseded, terminated. Executed contracts are immutable; changes use a superseding document. PDF export for both parties.

8. Service provider module

• Admin invites providers (no self-registration); approval flow pending → approved → active. Providers may hold multiple service categories.
• Admin onboarding form: company name, service types, accreditation documents, contact details, regions served. Licences, certifications and insurance are verified. Custom providers that buyers add can later be onboarded formally.
• Profile shows contacts, services, coverage, compliance documents, ratings. Providers can edit their own profile; KYC changes go through Igun support.
• Providers accept, decline (comment required, visible to buyer), reschedule or confirm capacity. Buyers can re-engage another provider.
• Providers see only trades they are engaged on, and only the data needed. They upload inspection reports, manifests and clearance certificates; labs cannot delete uploaded reports. Status updates (in transit, cleared, delivered) sync to the trade.
• Chain of custody: each sample has a QR/barcode ID; every handoff (collector → transporter → lab → buyer) is a timestamped, immutable event with photo evidence.
• Sampling protocols: standard procedures (sealed bags, numbered containers) and photos at collection, linked to the custody record.
• Assay to price: assay values stored as structured data; contract formula recalculates price (e.g. $2,000/t at 99.5% → $1,985.93/t at 98.8%). Disputes pause settlement and allow re-sampling or a second lab.
• Who pays: per-service payer (buyer, supplier or split %) set at contract, with admin defaults. Provider invoices route to the payer and settle with the trade or directly (status still logged). Disputed charges pause payout.
• Provider payments: providers are notified of who pays, the amount and the method (direct transfer or settlement deduction). Buyers and suppliers see provider charges before settlement.
• Buyers rate providers after service.

9. CRM, recommendations, analytics

• CRM: counterparty list, reference requests, pending ratings. Records show trade documents, evaluations, self-disclosures, portfolio — never the counterparty’s KYC documents. Internal notes are visible only to the own company. References are grouped by product category and public; ratings show overall and per deal.
• Completing a trade adds the supplier to the buyer’s supplier list automatically. Buyers can answer reference requests from suppliers.
• Recommendations (paid plans): suggest counterparties from the request spec, matching preferred metals, grade, volume, geography; show only paying buyers; exclude own company and blocked parties.
• Analytics: activity overview; volumes and values by partner and product; transaction prices by product; CO2 of traded products for Scope 3. Filters: side, product, visibility, Incoterms, period. Charts stay legible in greyscale.
• Chart colours: primary and secondary palettes for up to three values, tertiary beyond that, red only for negative performance.

10. Administration module

• Staff roles: compliance, sales, support. Manage invitations (issue, track, resend, revoke) for all personas.
• Approve or reject registrations with reasons; resolve failed registry checks; amend KYC with attribution.
• Create and price enterprise plans; adjust entitlements per account.
• Maintain the service-provider directory, normalisation parameters and (later) product taxonomy.
• Publish announcements; suspend or close accounts with defined effects on open requests, live trades and contracts.
• View audit trails; impersonate for support, clearly shown and logged to the customer.

11. Cross-cutting

• “Remember me” uses a revocable token; users can view and revoke sessions instantly. MFA available and enforceable by company admins.
• Team invites with per-user permissions (products/inventory, publish, negotiate, sign, payments/subscriptions, analytics). Always at least one admin; permission changes take effect on live sessions and are audited.
• Users can add a profile picture and edit contact details and password. Company admins upload or replace the company logo from the header.
• Languages: English, Chinese, French, Portuguese, Arabic (full RTL), Spanish; locale-aware numbers, dates, currencies. Contracts and user content are not translated.
• Company profile field visibility is governed by explicit per-field rules.
• Notifications: in-app bell and email per category, both on by default; security notices cannot be disabled; time-critical items (closing requests, expiring counters) are sent in advance.
• Notification categories: subscriptions, contracts, trades, payments, deliveries, announcements. The source refers to a “who receives what” matrix that is not in the text version.

12. Navigation and landing pages

• Left menu (both modules): Inventory, Requests (RFQs and RFOs), Products, Listings, Marketplace, Negotiations, Contracts, CRM, Company profile, Analytics centre.
• Header: notifications (bell plus notification settings), company logo upload, settings.
• Landing: buyers open on the Marketplace; suppliers open on Open Requests.

Non-functional requirements

Success metrics, open questions and assumptions

Proposed metrics (targets not set in the source; Igun to define):

• Time from registration to KYC approval, and % verified automatically vs manually
• Verified companies per side and paid-plan conversion
• Requests published, response rate, and request-to-trade conversion
• Traded tonnage and brokerage revenue (USD 10/t)
• % of offers compared via normalisation
• Disputes raised and median resolution time
• Buyer engagement on RFOs (already named in the source as a credibility metric)

Open questions

• Buyer plan entitlements (Open, Starter, Merchant, Partner) — defined in MVP but not in this document.
• Pricing for Premium and Enterprise supplier plans and for dual-role companies.
• Final permission matrix, especially signature authority — needs compliance sign-off.
• Providers for registry verification, KYC, FX, duties and vessel data (six dependencies must be chosen before dependent builds).
• Data residency jurisdictions, retention periods, uptime and performance targets.
• Failed-renewal retry schedule and its entitlement consequence.
• Account suspension effects on open requests, live trades and contracts.
• Enterprise lists “Respond to RfOs” but not “Respond to RFQs”; the source says invited Open suppliers can respond to RFQs. Confirm RFQ access per plan.
• Scope 3 CO2 methodology for “platform-calculated” figures.
• Is the USD 10/t fee charged to buyer, supplier, or netted in settlement? The source says both “payable to Igun” and “deducted at settlement”.
• Morocco registry link in the source points to a Nigerian CAC URL — needs correcting.

Found on second review of the source

• The permission matrix and notification matrix are referenced but missing from the text version (possibly images). Please share them.
• Plan conflict: the feature list says any paid supplier can raise RFOs, but the plan table gives “Publish RfOs” only to Enterprise.
• The Open and Premium supplier plans say “Respond to RfOs”, but suppliers raise RFOs, not respond to them. Is “RFQs” meant?
• Payment terms: listings and RFOs use EXW/CIF (these are Incoterms), while counter-offers use “upfront vs net 30”. Define payment terms and Incoterms as separate fields?
• Currency: RFOs are USD only, but buyer preferences offer EUR and GBP and listings mention “preferred currency”. Which currencies are supported?
• The “Shipping Agency” field lists inspection firms (SGS, Bureau Veritas, Intertek, Cotecna). Rename it to “Inspection agency”?
• Recommendations exclude “blocked” counterparties, but no blocking feature is specified.
• Logo upload is described as both top-left and top-right.
• SMS is needed (OTP, preferred channel), but no SMS provider is listed among the third-party services.
• The Senegal registry link points to africanlegalfactory.com rather than an official registry.
• Save the linked screen recordings (screenrec.com) into this project; shared links can expire.

Assumptions

• The MVP marketplace, basic RFQ and buyer plans are reused and extended, not rebuilt.
• The priorities in Scope and priorities are a proposal, not from the source.

Appendix: verification authorities

Copied from the source for the registry and licence verification work. Links are as given there; two are flagged in open questions.

Company registries

Mining licence authorities