Nantty
A pre-launch social marketplace for Nigeria, bringing product discovery, creators, seller operations and buyer protection into one product. Built as a multi-app platform with Go and TypeScript services, local mock and backend modes, and an AWS deployment plan that has not yet been applied.
- 7
- Product applications
- 15 Jan 2027
- Early beta target
- 1 Mar 2027
- Public launch target
- In development
- Current status
- Role
- Founder & lead engineer
- Year
- 2026 — present
- Status
- Private
- Type
- Social marketplace
01Overview
Nantty is a pre-launch social marketplace for African buyers, sellers and creators, starting in Nigeria. People discover sellers through posts, clips, stories and live shopping, then move into product pages, carts and protected checkout. Sellers manage their catalog and orders; creators have studio, audience and monetisation tools.
I am the founder and lead engineer. Nantty is under development, with a focused first market in Nigeria and seller-led commerce and buyer trust at its core; social and creator surfaces connect to that transaction journey.
The repository is a multi-application workspace rather than one monolithic web app: Expo mobile, buyer web, creator studio, seller dashboard, Ads Manager, staff console and a public marketing site sit over Go, TypeScript, Elixir and Python services.
Nantty is under development and has not launched. The public site lists an early beta target of 15 January 2027 and a public launch target of 1 March 2027; both are planning targets, not confirmed availability dates. Its apps can run against built-in mocks or a local backend, while the AWS Terraform is written but unapplied.
02The problem
A social marketplace has several product surfaces that must agree about one transaction: discovery, seller inventory, checkout, payment, delivery, escrow, dispute handling and payout. If those surfaces evolve independently, buyers see inconsistent order state and sellers cannot trust their balances.
There is also a deployment constraint. The product spans mobile, multiple web applications and services in different languages, but a small team cannot afford to operate a large cloud platform before validating the core journey.
The system therefore needs explicit ownership and contracts between domains, a local environment that can exercise the real service stack, and a mock mode that supports product iteration without being mistaken for production behavior.
The central product boundary is trust in commerce: show the buyer what they are paying for, keep the payment and order states auditable, and make delivery confirmation, disputes and release part of the workflow rather than informal support promises.
03Architecture
- 01
Clients organized around product roles
The workspace separates the Expo mobile app, buyer web app, creator Studio, seller dashboard, Ads Manager, staff admin and public marketing site. The product Next.js applications use a same-origin backend-for-frontend and httpOnly session cookies; mobile and web clients call the gateway. Local mock and real-backend modes are explicit development choices.
- 02
Escrow and money ownership
The documented Nigeria model uses Flutterwave payout subaccounts in each user's name. Escrow is a ledger lock on the buyer's own balance; release moves funds to the seller's subaccount after confirmation or the documented delivery window, while an open dispute pauses release. Nantty's stated design is that it does not hold customer funds. Live production payment credentials and provider readiness remain launch requirements.
- 03
Service boundaries and asynchronous work
Go deployables own identity, commerce, money, live, ads and trust domains; TypeScript services own gateway, social, notifications, search, media and support; Phoenix handles realtime fan-out; Python intelligence returns rankings and risk scores. Services publish transactional outbox events through RabbitMQ. These boundaries are in the codebase, but the architecture documents mark some domains as partial or proposed, so this is not a claim that every listed capability is complete.
- 04
Data ownership and contracts
The design uses PostgreSQL schemas owned by their services, Prisma for TypeScript persistence and ent with Atlas migrations for Go. Shared protobuf, event JSON Schema and TypeScript contract packages define cross-service shapes. Money is represented in integer minor units with a currency, and the Go ledger is documented as the financial source of truth.
- 05
Local stack before cloud operations
Docker Compose provides local Postgres/PostGIS, Valkey, RabbitMQ, object storage, LiveKit and observability dependencies. Scripts start the backend, apply migrations, seed demo data and check core paths. AWS Terraform describes an ECS Fargate deployment but has not been applied, so production deployment is a future milestone rather than an existing environment.
- 06
Scores do not own product decisions
The Python intelligence service supplies ranking, recommendation, ads, risk and moderation scores; Go and TypeScript services retain the allow, hold, review or reject decision and are documented to fall back to deterministic logic if intelligence is slow or unavailable. This keeps model output separate from money movement and enforcement authority.
- 07
Pre-launch maturity is explicit
Mock mode supports UI work; backend mode points clients at the local gateway and real services. A build check is intended to prevent mocks from leaking into production bundles. The source README states no environment is deployed yet, and live Flutterwave setup and written provider answers remain outstanding.
04Key decisions
One product, multiple clients
Different roles need different workspaces: buyers browse and order, sellers manage commerce, creators manage live content, staff handle support and safety. Keeping these as separate clients makes each workflow legible while shared contracts and backend services preserve common identity, money and policy rules.
Escrow as a state machine
The payment design distinguishes buyer-owned funds, ledger liabilities, pending transfers, disputes, refunds and seller payout. Provider webhooks are treated as hints that require verification; money movement is not retried blindly. The provider integration and live launch readiness remain active work, which is why the case study does not call the payment flow production-tested.
Start with a runnable local system
A documented backend:up, mode:backend, backend:check workflow makes it possible to exercise service integration locally, while mock mode avoids requiring the entire stack for every UI change. The two modes make development faster while keeping the real service path available for integration checks.
Keep model output advisory
Ranking, recommendations and risk signals are separated from the services that own product state and financial decisions. That boundary allows model behavior to be replaced or degraded without silently granting a model authority over payments, account sanctions or transaction outcomes.
Build for pre-launch truth
The public story should match the operating state: Nantty is being built, the marketing site and local development flows exist, and cloud deployment and provider readiness are unfinished. This avoids implying active users, production uptime or payment availability before those have been established.
05Stack
- Go 1.26
- Expo / React Native
- Next.js
- TypeScript
- Go
- Elixir / Phoenix
- Python / FastAPI
- PostgreSQL + PostGIS
- Prisma
- ent + Atlas
- RabbitMQ
- Valkey
- LiveKit
- Flutterwave (planned live integration)
- Docker Compose
- AWS ECS Terraform (unapplied)