Forem: sharkflow ltd

ReserveFlow — devto

sharkflow ltd — Tue, 05 May 2026 04:00:05 +0000

{
  "title": "Building ReserveFlow: AI-Powered Property Search for Kenya's Mobile-First Market",
  "content": "# Building ReserveFlow: AI-Powered Property Search for Kenya's Mobile-First Market\n\nLast month, a developer in Kisumu used ReserveFlow to find a bedsitter in Karen, Nairobi—without visiting a single property in person. Three WhatsApp messages. Two AI-powered property recommendations. One completed booking via M-Pesa in under 20 minutes.\n\nThis is the future of real estate in Africa, and it's built on some seriously interesting engineering challenges. Let me walk you through how ReserveFlow actually works under the hood.\n\n## The Problem We're Solving\n\nKenya's real estate market is fragmented. You've got:\n- **Fragmented data**: Properties listed across 50+ websites, WhatsApp groups, and spreadsheets\n- **Mobile-first users**: 60M+ mobile money users, but most property platforms are desktop-optimized\n- **Inconsistent connectivity**: Average speeds of 8-12 Mbps in Nairobi, dropping to 2-3 Mbps in secondary cities\n- **Trust gaps**: Unverified listings, inflated prices, and sketchy agents dominate the market\n\nWe built ReserveFlow to aggregate, verify, and intelligently surface properties using AI—optimized for 2G fallback and offline-first architectures.\n\n## Architecture Overview\n\n```

\n┌─────────────────────────────────────────┐\n│  Mobile Client (React Native)           │\n│  - Offline-first with SQLite            │\n│  - Compressed image syncing             │\n└────────────┬────────────────────────────┘\n             │\n             ▼\n┌─────────────────────────────────────────┐\n│  API Gateway (Kong)                     │\n│  - Rate limiting (100req/min for free)  │\n│  - Request compression (gzip)           │\n│  - M-Pesa webhook routing               │\n└────────────┬────────────────────────────┘\n             │\n        ┌────┴────┐\n        ▼         ▼\n   ┌─────────┐  ┌──────────────┐\n   │ GraphQL │  │ REST (Legacy)│\n   │ Server  │  │ Endpoints    │\n   └────┬────┘  └──────┬───────┘\n        │               │\n        └───────┬───────┘\n                ▼\n     ┌──────────────────────┐\n     │  Service Layer       │\n     │ - Property AI        │\n     │ - Payment Handler    │\n     │ - Verification Bot   │\n     └──────────┬───────────┘\n                ▼\n     ┌──────────────────────┐\n     │  Data Layer          │\n     │ - PostgreSQL (props) │\n     │ - Redis (cache)      │\n     │ - Elasticsearch      │\n     └──────────────────────┘\n

```\n\n## Database Design for African Constraints\n\nWe use **PostgreSQL for structured data** (properties, bookings, users) and **Elasticsearch for search**. Here's why this matters in Kenya's context:\n\n### 1. Property Schema (Optimized for Queries)\n\n```

sql\nCREATE TABLE properties (\n  id UUID PRIMARY KEY,\n  title VARCHAR(255) NOT NULL,\n  description TEXT,\n  price_ksh BIGINT NOT NULL,\n  location_point GEOGRAPHY(POINT, 4326), -- Indexed for spatial queries\n  bedrooms SMALLINT,\n  bathrooms SMALLINT,\n  area_sqm DECIMAL(10, 2),\n  amenities JSONB, -- Flexible schema for varied data\n  images_urls TEXT[] -- Array for multiple images\n  verification_score DECIMAL(3, 2), -- AI confidence (0-1)\n  verified_at TIMESTAMP,\n  agent_id UUID REFERENCES agents(id),\n  created_at TIMESTAMP DEFAULT NOW(),\n  updated_at TIMESTAMP DEFAULT NOW()\n);\n\nCREATE INDEX idx_location ON properties USING GIST(location_point);\nCREATE INDEX idx_price ON properties(price_ksh);\nCREATE INDEX idx_verified ON properties(verification_score DESC, created_at DESC);\n

```\n\n**Why JSONB for amenities?** Real estate data in Kenya is messy. One agent lists \"WiFi+Generator,Solar\" as a string. Another lists it as an array. JSONB lets us normalize queries across inconsistent sources.\n\n### 2. Booking Schema with M-Pesa Integration\n\n```

sql\nCREATE TABLE bookings (\n  id UUID PRIMARY KEY,\n  property_id UUID REFERENCES properties(id),\n  user_id UUID REFERENCES users(id),\n  check_in_date DATE,\n  check_out_date DATE,\n  total_price_ksh BIGINT,\n  payment_status VARCHAR(20) DEFAULT 'pending', -- pending, processing, completed, failed\n  mpesa_transaction_id VARCHAR(10) UNIQUE,\n  mpesa_receipt_number VARCHAR(32),\n  mpesa_initiated_at TIMESTAMP,\n  mpesa_completed_at TIMESTAMP,\n  status VARCHAR(20) DEFAULT 'confirmed', -- confirmed, cancelled, completed\n  created_at TIMESTAMP DEFAULT NOW()\n);\n\nCREATE INDEX idx_user_bookings ON bookings(user_id, created_at DESC);\nCREATE INDEX idx_mpesa_status ON bookings(payment_status, mpesa_transaction_id);\n

\n\n## API Design: GraphQL + REST Hybrid\n\nWe expose GraphQL for complex queries (ideal for mobile with slow connections) and REST

FundFlow — devto

sharkflow ltd — Mon, 04 May 2026 04:00:03 +0000

{
  "title": "How FundFlow Matches Angel Investors with Kenya Startups: The Technical Deep Dive",
  "content": "# How FundFlow Matches Angel Investors with Kenya Startups: The Technical Deep Dive\n\nKenyan startups raise roughly $400M annually, but here's the brutal truth: most never meet a single angel investor. Why? The infrastructure doesn't exist. There's no standardized way for a founder in Kisumu to connect with an angel in Nairobi who invests in fintech. There's no API layer connecting Kenya's fragmented investor networks.\n\nThis is what FundFlow's engineering team built. We're a Kenyan tech company solving one of Africa's hardest problems: *how do you programmatically match founders with the right capital, over unreliable networks, in markets where investor data is fragmented?*\n\nLet's talk about how we did it.\n\n## The Problem: Africa's Unique Infrastructure Constraints\n\nBefore we wrote a single line of code, we had to understand our constraints:\n\n- **Network reliability**: Kenya's mobile networks have ~95% uptime in urban areas, ~65% in rural areas. Your API calls might timeout. Your database connection might drop mid-transaction.\n- **Data fragmentation**: Angel investor data lives in spreadsheets, WhatsApp groups, LinkedIn, and closed Facebook communities. There's no central registry.\n- **Mobile-first users**: 60M+ Kenyans use M-Pesa daily. Most founders checking their funding status do it on a 3G connection from a matatu.\n- **Cost sensitivity**: Every API call, every database query, every megabyte of data costs real money.\n\nThis shaped every architectural decision we made.\n\n## FundFlow's Architecture: API-First Design\n\nWe built FundFlow around three core services:\n\n```

\n┌─────────────────────────────────────────┐\n│         Mobile Client Layer              │\n│  (React Native + offline-first)          │\n└──────────────┬──────────────────────────┘\n               │\n┌──────────────▼──────────────────────────┐\n│     API Gateway (Kong)                   │\n│  Rate limiting, circuit breakers         │\n└──────────────┬──────────────────────────┘\n               │\n    ┌──────────┼──────────┐\n    │          │          │\n┌───▼──┐  ┌────▼───┐  ┌──▼────┐\n│Match │  │Profile │  │Payment│\n│ API  │  │ API    │  │API    │\n└───┬──┘  └────┬───┘  └──┬────┘\n    │          │         │\n└───┴──────────┴─────────┘\n        │\n    ┌───▼─────────────────┐\n    │  PostgreSQL + Redis  │\n    │  (Replication ready) │\n    └──────────────────────┘\n

```\n\n**Why this design?**\n\n1. **Kong API Gateway**: Handles rate limiting (crucial when your user base jumps from 1,000 to 50,000 overnight). Implements circuit breakers so if our investor-matching service slows down, we don't cascade failures across other services.\n\n2. **Microservices**: Decoupled services mean we can scale the matching engine independently from payment processing. If M-Pesa integration gets hammered, our matching API stays responsive.\n\n3. **Offline-first mobile**: The app syncs investor profiles and portfolio data when connection is available. When it's not, founders can still browse matches and draft pitches.\n\n## The Matching Algorithm: Building a Smart Recommendation Engine\n\nHere's where it gets interesting. We couldn't use off-the-shelf recommendation engines because:\n\n- Investor data is sparse and incomplete\n- Investors in Kenya have deep domain expertise but no standardized way to tag it\n- Success is binary: did the investor actually fund this startup?\n\nWe built a hybrid approach:\n\n```

python\n# Simplified version of our matching algorithm\nfrom enum import Enum\nfrom typing import List, Tuple\n\nclass InvestorType(Enum):\n    ANGEL = \"angel\"\n    MICRO_VC = \"micro_vc\"\n    CORPORATE = \"corporate\"\n\nclass StartupProfile:\n    def __init__(self, founder_id, sector, stage, amount_seeking, location):\n        self.founder_id = founder_id\n        self.sector = sector  # fintech, agritech, etc.\n        self.stage = stage    # pre-seed, seed, series-a\n        self.amount_seeking = amount_seeking  # KES\n        self.location = location  # Nairobi, Kisumu, etc.\n        self.pitch_sentiment = None\n        self.team_quality_score = None\n\nclass InvestorProfile:\n    def __init__(self, investor_id, sector_focus, check_size, location):\n        self.investor_id = investor_id\n        self.sector_focus = sector_focus  # tags: [\"fintech\", \"climate\"]\n        self.check_size = check_size  # (min_kes, max_kes)\n        self.location = location\n        self.portfolio_quality_score = None\n\ndef calculate_match_score(\n    startup: StartupProfile,\n    investor: InvestorProfile\n) -> Tuple[float, dict]:\n    \"\"\"\n    Multi-factor matching score (0-100).\n    Weights tuned from 2 years of real funding data.\n    \"\"\"\n    score = 0.0\n    factors = {}\n    \n    # Factor 1: Sector alignment (40% weight)\n    if startup.sector in investor.sector_focus:\n        sector_score = 40.0\n    else:\n        sector_score = 10.0\n    score += sector_

FlowTasks — devto

sharkflow ltd — Sun, 03 May 2026 04:00:04 +0000

{
  "title": "Building FlowTasks for Africa's Mobile-First Entrepreneurs: The Engineering Behind Productivity at Scale",
  "content": "# Building FlowTasks for Africa's Mobile-First Entrepreneurs: The Engineering Behind Productivity at Scale\n\nWhen we started building FlowTasks at SharkFlow, we weren't thinking about Silicon Valley's productivity stack. We were thinking about a Nairobi-based logistics entrepreneur managing 50+ daily deliveries on a 3G connection, or a Kampala fashion business owner juggling inventory and client orders during peak hours.\n\nThat constraint — unreliable connectivity, limited bandwidth, low-end devices — became our north star for technical design. Here's how we built productivity software that actually works in Africa.\n\n## The API Philosophy: Offline-First, Sync-Later\n\nMost task management tools assume constant connectivity. We built the opposite.\n\n```

typescript\n// Core sync strategy: works offline, syncs when possible\ninterface Task {\n  id: string;\n  title: string;\n  status: 'pending' | 'in-progress' | 'completed';\n  priority: number;\n  createdAt: number;\n  updatedAt: number;\n  syncStatus: 'local' | 'syncing' | 'synced' | 'conflict';\n  localVersion: number;\n  serverVersion?: number;\n}\n\nclass TaskService {\n  async addTask(task: Omit<Task, 'id' | 'syncStatus'>): Promise<Task> {\n    // 1. Write to local storage immediately\n    const localTask = {\n      ...task,\n      id: generateUUID(),\n      syncStatus: 'local',\n      localVersion: 1\n    };\n    await this.localDB.insert('tasks', localTask);\n    \n    // 2. Queue for sync (doesn't block the user)\n    this.syncQueue.enqueue(localTask);\n    \n    // 3. Return immediately to UI\n    return localTask;\n  }\n}\n

```\n\nThis pattern is critical. On African networks, you can't afford to wait for API responses before letting users see their work. We use SQLite on mobile and IndexedDB on web — local-first databases that exist entirely on the device.\n\n## Database Strategy: SQLite + EdgeDB + Smart Replication\n\nOur stack is deliberately minimal:\n\n- **Mobile**: SQLite (battle-tested, 600KB, zero dependencies)\n- **Edge**: EdgeDB (typed queries, built-in migrations, excellent JSON support)\n- **Sync logic**: Custom conflict-resolution engine\n\nWhy not PostgreSQL directly? Three reasons:\n\n1. **Network unpredictability**: A dropped connection mid-transaction on spotty 3G is painful with traditional SQL. Our replication layer handles partial syncs.\n2. **Schema versioning**: With 60M+ mobile money users spreading across Africa, we needed schema evolution without API versioning hell.\n3. **Real-time collaboration**: EdgeDB's subscription API gives us WebSocket-based sync for free, critical when three team members are updating tasks simultaneously.\n\n```

typescript\n// Conflict resolution: last-write-wins with tombstones\nclass SyncEngine {\n  async resolveConflict(\n    local: Task,\n    server: Task\n  ): Promise<Task> {\n    // If both changed, compare timestamps\n    if (local.updatedAt > server.updatedAt) {\n      return local; // Trust local if more recent\n    }\n    \n    // For critical fields (like payment status), require manual merge\n    if (this.isCriticalField(local, server)) {\n      return { ...server, syncStatus: 'conflict' };\n    }\n    \n    return server;\n  }\n  \n  async bulkSync(localTasks: Task[]): Promise<SyncResult> {\n    // Batch uploads to minimize API calls\n    const chunks = chunk(localTasks, 50);\n    const results = await Promise.all(\n      chunks.map(c => this.api.batchUpsert('/tasks', c))\n    );\n    \n    return this.mergeSyncResults(results);\n  }\n}\n

```\n\n## Bandwidth Optimization: Why We Cache Aggressively\n\nM-Pesa's $320B annual transaction volume runs on 2G. Your task app needs to respect that.\n\n```

typescript\n// Request batching + compression\nclass NetworkOptimizer {\n  private requestBatch: any[] = [];\n  private batchTimeout: NodeJS.Timeout;\n  \n  async queueRequest(endpoint: string, data: any) {\n    this.requestBatch.push({ endpoint, data });\n    \n    // Wait 2 seconds for more requests to batch\n    clearTimeout(this.batchTimeout);\n    this.batchTimeout = setTimeout(() => this.flushBatch(), 2000);\n  }\n  \n  private async flushBatch() {\n    if (!this.requestBatch.length) return;\n    \n    const payload = JSON.stringify(this.requestBatch);\n    const compressed = await gzip(payload);\n    \n    // Typical reduction: 40KB → 8KB\n    await fetch('/api/batch', {\n      method: 'POST',\n      headers: { 'Content-Encoding': 'gzip' },\n      body: compressed\n    });\n    \n    this.requestBatch = [];\n  }\n}\n

```\n\nWe compress all payloads by default. On a typical task sync (50 tasks), this drops from 40KB to 8KB. Over a month, that's 1GB saved for users in high-cost data markets.\n\n## Smart Scheduling: Syncing When It's Free\n\nHere's something most productivity apps miss: in Kenya, Uganda, Tanzania, many plans offer free data during specific hours. We detect and exploit that.\n\n```

typescript\n// Intelligent sync scheduler\nclass SyncScheduler {\

Trading Bot (QUANT ELITE) — devto

sharkflow ltd — Sat, 02 May 2026 04:00:12 +0000

{
  "title": "Building Profitable MT5 Expert Advisors for Kenya: The SharkFlow QUANT ELITE Technical Deep Dive",
  "content": "# Building Profitable MT5 Expert Advisors for Kenya: The SharkFlow QUANT ELITE Technical Deep Dive\n\nIf you're a developer in Nairobi, Lagos, or Cape Town watching the fintech explosion, you've probably wondered: *How do trading bots actually work?* More importantly—how do you build one that's actually profitable, especially when you're deploying it across Africa's unreliable networks?\n\nAt SharkFlow, we spent two years building QUANT ELITE, our algorithmic trading engine that runs on MT5 (MetaTrader 5) and optimizes for African market conditions. This article breaks down the technical architecture, the engineering decisions we made, and why some approaches that work in Wall Street data centers completely fail when your users are trading from Kampala on a 3G connection.\n\n## Why MT5 for African Markets?\n\nFirst, context: MetaTrader 5 dominates forex and derivatives trading across Africa. It's lightweight, it works offline, and brokers here already support it. Building on top of MT5 rather than against it was our key architectural decision. Unlike building a proprietary trading engine (expensive, risky, reinventing wheels), MT5 Expert Advisors let us focus on the quant logic while the platform handles order execution, chart data, and broker connectivity.\n\nThe trade-off? We're constrained by MQL5 (MetaTrader's language), which is C++-ish but not quite C++. But the ecosystem advantage is massive: 90%+ of retail traders in East Africa already have MT5 installed.\n\n## API Architecture: The Bridge Between Cloud Quant and Edge Trading\n\nOur first design challenge: the algo logic needs to run both on user devices (for speed, offline resilience) and in cloud servers (for backtesting, risk management, signal generation).\n\nHere's our three-layer architecture:\n\n```

\n┌─────────────────────────────────────────────────┐\n│  Cloud Layer (Google Cloud, Nairobi region)     │\n│  - Signal generation                            │\n│  - Historical data aggregation                  │\n│  - Risk management rules                        │\n└─────────────┬───────────────────────────────────┘\n              │ REST API (optimized for 2G/3G)\n              │\n┌─────────────▼───────────────────────────────────┐\n│  Edge Layer (User's MT5 instance)               │\n│  - Execute signals                              │\n│  - Real-time order management                   │\n│  - Offline fallback logic                       │\n└─────────────────────────────────────────────────┘\n

```\n\n### API Design for Bandwidth-Constrained Networks\n\nThis is where most fintech solutions fail in Africa. A typical REST API call to a US-based trading system might be 50KB of JSON. On a Kenyan 3G connection at 500KB/s, that's latency hell.\n\nOur solution: **Compressed Protocol Buffers** for cloud communication.\n\n```

protobuf\n// signal.proto - Minimal message definition\nsyntax = \"proto3\";\n\nmessage TradingSignal {\n  int32 symbol_id = 1;        // 0=EURUSD, 1=GBPUSD, etc. (lookup table)\n  enum Action { BUY = 0; SELL = 1; CLOSE = 2; }\n  Action action = 2;\n  float price = 3;            // Entry price\n  float stop_loss = 4;\n  float take_profit = 5;\n  int64 timestamp = 6;        // Unix ms\n}\n

```\n\nA typical signal that's 8KB in JSON is ~200 bytes in protobuf. Over a 50-signal update (worst case), that's 400KB saved. When you're refreshing every 15 seconds, you're looking at 2.3MB/day vs 46MB/day. That matters when users are on KES-priced data bundles.\n\n### The MQL5 Expert Advisor: Signal Reception & Execution\n\n```

cpp\n// QuantElite.mq5 - Simplified version\n#property copyright \"SharkFlow Ltd\"\n#property strict\n\n// Incoming signal from cloud\nstruct CloudSignal {\n    int symbolCode;\n    int action;     // 0=BUY, 1=SELL, 2=CLOSE\n    double price;\n    double sl;\n    double tp;\n    long timestamp;\n};\n\nclass QuantEliteBot {\nprivate:\n    CTrade trade;                  // MT5's trading object\n    string CloudAPIKey;            // Secured in encrypted storage\n    int lastSignalTime = 0;\n    double maxDrawdown = 0.05;     // 5% max\n    double riskPerTrade = 0.01;    // 1% per trade\n    \npublic:\n    void OnTick() {\n        // Every tick, check for new cloud signals\n        CloudSignal signal = FetchSignalFromCloud();\n        \n        if (signal.timestamp > lastSignalTime) {\n            lastSignalTime = signal.timestamp;\n            \n            // Risk check before execution\n            if (!CheckRiskLimits()) {\n                PrintFormat(\"Risk limit breached. Skipping signal.\");\n                return;\n            }\n            \n            ExecuteSignal(signal);\n        }\n    }\n    \n    CloudSignal FetchSignalFromCloud() {\n        // Offline fallback: use last valid signal if network fails\n        string response = HTTPRequestWithRetry(\n            \"https://api.sharkflow.ai/signal\",\n            CloudAPIKey,\n            3  // 3 retry attempts\n        );\n        \n        if (response == \"\") {\n            // Network

SharkFlow CFA — devto

sharkflow ltd — Fri, 01 May 2026 04:00:12 +0000

{
  "title": "Building a CFA Study Platform That Actually Works on African Mobile Networks: SharkFlow's Technical Deep Dive",
  "content": "# Building a CFA Study Platform That Actually Works on African Mobile Networks: SharkFlow's Technical Deep Dive\n\nPreparing for the CFA exam is brutal. Doing it on a 2G connection in Nairobi? That's a different kind of hell.\n\nWhen we started building SharkFlow's CFA preparation module, we realized most EdTech platforms treat African markets as afterthoughts. They optimize for Wi-Fi. They assume reliable power. They ignore that Kenya's 60M+ mobile money users work on devices with 512MB RAM and unstable networks.\n\nThis article breaks down how we engineered a CFA study platform that doesn't just *exist* in Africa—it genuinely thrives here.\n\n## The Problem We Solved\n\nThe CFA curriculum is dense: 300+ hours of study across derivatives, portfolio management, ethics, and quantitative methods. Traditional platforms require constant connectivity and heavy data transfer. In Kenya, where mobile data costs ~KES 50 ($0.38 USD) for 100MB, every kilobyte matters.\n\nWe had three non-negotiable constraints:\n1. **Work offline-first**: Download once, study everywhere\n2. **Handle ~10Mbps fluctuations**: Network conditions are real\n3. **Scale to 50,000 concurrent users** without melting our infrastructure\n\n## Our Architecture: Offline-First by Default\n\n### Progressive Data Sync\n\nWe built a two-tier content system:\n\n```

typescript\n// Content strategy: Cloud-sourced, device-stored\ninterface ContentTier {\n  tier1: {\n    size: '85MB',\n    content: 'Core curriculum (Ethics, Quantitative)',\n    syncStrategy: 'aggressive_prefetch',\n    frequency: 'weekly'\n  },\n  tier2: {\n    size: '250MB',\n    content: 'Full question banks + video lectures',\n    syncStrategy: 'background_sync',\n    frequency: 'on_demand'\n  },\n  tier3: {\n    size: '15MB',\n    content: 'Real-time market data + performance analytics',\n    syncStrategy: 'delta_sync',\n    frequency: 'hourly'\n  }\n}\n

```\n\nUsers can start studying immediately with Tier 1 (~85MB), which covers the essentials. Tier 2 downloads in the background during low-cost hours (most Kenyan carriers offer off-peak data). Tier 3 syncs only when connected.\n\n### Smart Compression\n\nOur content pipeline compresses ruthlessly:\n\n```

python\n# Content compression strategy\nclass ContentCompressor:\n    def compress_materials(self, material_type: str):\n        if material_type == 'video':\n            # H.265 codec, 480p target (not 4K)\n            # Bitrate: 800kbps (vs 5Mbps standard)\n            return self._transcode_video()\n        \n        elif material_type == 'pdf':\n            # Remove embedded fonts, compress images\n            # Target: 60% size reduction\n            return self._optimize_pdf()\n        \n        elif material_type == 'questions':\n            # Plain JSON with heavy gzip\n            # 10,000 questions = 12MB (uncompressed: 85MB)\n            return self._serialize_questions()\n

```\n\nOur question bank of 10,000 CFA questions compressed from 85MB to 12MB. That's the difference between \"I'll download later\" and \"done in 2 minutes.\"\n\n## Database Architecture: SQLite Locally, PostgreSQL Globally\n\nMost EdTech platforms use Firebase or MongoDB. Both are overkill and expensive at scale in Africa.\n\nWe use a hybrid:\n\n```

sql\n-- Local SQLite schema (device-side)\nCREATE TABLE questions (\n    id INTEGER PRIMARY KEY,\n    level INTEGER,  -- L1, L2, L3\n    topic TEXT,\n    question_text BLOB,  -- Compressed\n    answers BLOB,\n    explanation BLOB,\n    last_reviewed INTEGER,\n    performance_score REAL,\n    FOREIGN KEY(topic) REFERENCES topics(id)\n);\n\nCREATE INDEX idx_topic_level ON questions(topic, level);\nCREATE INDEX idx_performance ON questions(performance_score);\n\n-- User progress (syncs bidirectionally)\nCREATE TABLE sync_queue (\n    id INTEGER PRIMARY KEY,\n    action TEXT,  -- 'quiz_completed', 'bookmark_added'\n    payload BLOB,\n    timestamp INTEGER,\n    synced BOOLEAN DEFAULT 0\n);\n

```\n\n**Why SQLite?**\n- Zero setup. Instant. ~300KB footprint.\n- Handles 100K+ records per device without breaking a sweat\n- Built-in on iOS and Android\n- Sync conflicts? We handle them client-side with timestamp-based resolution\n\n**Backend (PostgreSQL):**\n\n```

sql\n-- Aggregates user progress across 50K students\nCREATE TABLE user_performance (\n    user_id UUID PRIMARY KEY,\n    level_1_score REAL,\n    level_2_score REAL,\n    level_3_score REAL,\n    total_questions_answered INTEGER,\n    last_active TIMESTAMP,\n    device_type TEXT,  -- iOS, Android, Web\n    region TEXT  -- For performance tracking\n);\n\nCREATE MATERIALIZED VIEW topic_difficulty AS\nSELECT \n    topic,\n    AVG(performance_score) as avg_difficulty,\n    COUNT(*) as attempts,\n    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY time_spent) as median_time\nFROM user_attempts\nGROUP

SharkFlow Legal — devto

sharkflow ltd — Thu, 30 Apr 2026 04:00:13 +0000

{
  "title": "Building AI Legal Assistance for Africa: How SharkFlow's API Handles Lawyer Consultations at Scale",
  "content": "# Building AI Legal Assistance for Africa: How SharkFlow's API Handles Lawyer Consultations at Scale\n\nLet's be honest: getting lawyer consultation in Kenya costs money most small businesses don't have. A basic contract review runs you 5,000–15,000 KES. A trademark search? Another 3,000–5,000 KES. For a startup burning through capital, these add up fast.\n\nThat's the problem SharkFlow Legal solves. But the technical implementation? That's where it gets interesting.\n\nIn this article, I'll walk through how we built an AI-powered legal assistance platform that works reliably across African mobile networks, integrates with M-Pesa for instant payments, and scales to handle Kenya's 400M+ potential users without breaking.\n\n## The Challenge: Building for Africa's Infrastructure Reality\n\nIf you've built for Silicon Valley, you haven't built for Nairobi.\n\nAfrican developers know this intimately. Your servers might be in Frankfurt. Your users? On 3G networks with 2–3 second latency and spotty connectivity. You need to design for this reality from day one, not patch it in later.\n\nWhen we architected SharkFlow Legal, we made three core technical decisions:\n\n1. **Offline-first architecture** – Users shouldn't need constant connectivity\n2. **Lightweight API responses** – Sub-50KB payloads as a hard rule\n3. **M-Pesa-native payments** – Because 99% of our users prefer it to cards\n\nLet's dig into each.\n\n## API Design: Efficiency Over Elegance\n\nHere's our lawyer consultation endpoint:\n\n```

javascript\n// POST /api/v1/legal/consult\n// Request: ~2.3KB\n{\n  \"document_type\": \"contract_review\", // enum: contract_review, trademark_search, nda\n  \"document_base64\": \"JVBERi0xLjQK...\", // max 2MB, we compress\n  \"jurisdiction\": \"KE\", // Critical: Kenyan law ≠ Nigerian law\n  \"user_id\": \"usr_abc123\",\n  \"priority\": \"standard\" // standard, express (faster AI processing)\n}\n\n// Response: ~18KB (including analysis)\n{\n  \"consultation_id\": \"cons_xyz789\",\n  \"status\": \"completed\",\n  \"jurisdiction\": \"KE\",\n  \"summary\": {\n    \"document_type\": \"Employment Contract\",\n    \"risk_level\": \"medium\",\n    \"key_issues\": [\n      {\n        \"issue\": \"Non-compete clause extends beyond employment\",\n        \"severity\": \"high\",\n        \"suggestion\": \"Negotiate to 6 months post-termination max per Kenyan employment law\"\n      }\n    ]\n  },\n  \"next_steps\": \"Request human lawyer review for final signature\",\n  \"cost_kes\": 799,\n  \"cost_cents\": 85 // for M-Pesa integration\n}\n

```\n\nThree design choices here that matter:\n\n**1. Jurisdiction-first approach**\n\nWe don't have a generic \"legal AI.\" Each jurisdiction gets its own prompt engineering, fine-tuned models, and compliance rules. A contract valid in Kenya might violate Tanzanian employment law.\n\n```

python\n# api/handlers/legal_consultation.py\n\nclass JurisdictionalHandler:\n    JURISDICTION_CONFIGS = {\n        'KE': {\n            'model': 'gpt-4-kenya-legal-v2',\n            'knowledge_cutoff': '2024-01',\n            'compliance_framework': 'kenyan_law_2024',\n            'max_tokens': 2000,\n        },\n        'NG': {\n            'model': 'gpt-4-nigeria-legal-v2',\n            'compliance_framework': 'nigerian_law_2024',\n        }\n    }\n    \n    @staticmethod\n    def get_handler(jurisdiction_code: str):\n        config = JurisdictionalHandler.JURISDICTION_CONFIGS.get(jurisdiction_code)\n        if not config:\n            raise UnsupportedJurisdictionError(f\"{jurisdiction_code} not yet supported\")\n        return LegalAIHandler(config)\n

```\n\n**2. Compressed document handling**\n\nPDFs are huge. Users on slow networks can't upload 5MB contracts.\n\n```

python\n# api/utils/document_processor.py\n\nimport zlib\nfrom PyPDF2 import PdfReader\n\nclass DocumentOptimizer:\n    @staticmethod\n    def compress_document(base64_pdf: str) -> tuple[str, dict]:\n        \"\"\"Extract text, discard images, compress to ~50KB\"\"\"\n        pdf_data = base64.b64decode(base64_pdf)\n        reader = PdfReader(BytesIO(pdf_data))\n        \n        # Extract text only—no images, no formatting\n        text = \"\".join([page.extract_text() for page in reader.pages])\n        \n        # Compress with zlib\n        compressed = zlib.compress(text.encode('utf-8'), level=9)\n        compressed_b64 = base64.b64encode(compressed).decode()\n        \n        return compressed_b64, {\n            'original_size_kb': len(base64_pdf) / 1024,\n            'compressed_size_kb': len(compressed_b64) / 1024,\n            'compression_ratio': (1 - len(compressed) / len(pdf_data)) * 100\n        }\n

\n\nOur

MpesaBooks — devto

sharkflow ltd — Wed, 29 Apr 2026 04:00:04 +0000

{
  "title": "Building M-Pesa Accounting Software: The Technical Stack Behind MpesaBooks",
  "content": "# Building M-Pesa Accounting Software: The Technical Stack Behind MpesaBooks\n\nKenya processes over $320 billion annually through M-Pesa. Yet most SMEs still reconcile these transactions in spreadsheets.\n\nThat's the problem MpesaBooks solves. But here's what most people don't realize: building M-Pesa accounting software isn't just about connecting to an API. It's about designing systems that survive on African mobile networks, handle concurrency at scale, and make sense of chaotic cash flow patterns.\n\nThis is how we built it.\n\n## The Core Challenge: M-Pesa Isn't a Ledger\n\nM-Pesa transactions are notifications. Notifications that arrive out of order, sometimes duplicate, sometimes late. A customer sends you 500 KES. You get notified 30 seconds later. Then again 2 minutes later (network hiccup). Meanwhile, your accountant needs to see your cash position *right now*.\n\nTraditional accounting software assumes instant, sequential transactions. M-Pesa assumes none of this.\n\nSo we built around three principles:\n1. **Idempotency first** — Every transaction is a unique event\n2. **Eventually consistent** — Real-time is nice; correct is essential\n3. **Network-first** — Assume phones will drop, reconnect, and retry\n\n## API Design: Webhook Reliability Over Perfection\n\nWe use M-Pesa's C2B (Customer to Business) webhook system. Here's the flow:\n\n```

javascript\n// Our webhook receiver — first line of defense\napp.post('/mpesa/callback', async (req, res) => {\n  const transaction = req.body;\n  \n  // Step 1: Acknowledge immediately (before processing)\n  res.status(200).json({ \n    ResultCode: 0, \n    ResultDesc: 'Accepted'\n  });\n  \n  // Step 2: Queue async (don't process in the request)\n  await queue.add('process-mpesa-txn', transaction, {\n    attempts: 5,\n    backoff: {\n      type: 'exponential',\n      delay: 2000\n    }\n  });\n});\n

```\n\nWhy this pattern? M-Pesa expects a response within 30 seconds. If we're slow, it retries. If we acknowledge first, then process in the background, we never lose a transaction.\n\nWe use Bull queues (backed by Redis) for this. On Heroku? AWS SQS works too. The point: decouple receipt from processing.\n\n## Database Design: Events Over Entities\n\nWe store transactions as immutable events, not mutable records.\n\n```

sql\n-- The source of truth: raw M-Pesa notifications\nCREATE TABLE mpesa_events (\n  id UUID PRIMARY KEY,\n  merchant_request_id VARCHAR(255) UNIQUE NOT NULL,\n  checkout_request_id VARCHAR(255),\n  mpesa_receipt_number VARCHAR(100) UNIQUE,\n  amount DECIMAL(15, 2) NOT NULL,\n  phone_number VARCHAR(20) NOT NULL,\n  transaction_timestamp TIMESTAMP NOT NULL,\n  received_at TIMESTAMP DEFAULT NOW(),\n  raw_payload JSONB,\n  idempotency_key VARCHAR(255) UNIQUE,\n  status ENUM('pending', 'processed', 'failed', 'reversed'),\n  created_at TIMESTAMP DEFAULT NOW()\n);\n\n-- Derived: account ledger (rebuilt from events)\nCREATE TABLE account_ledger (\n  id UUID PRIMARY KEY,\n  business_id UUID REFERENCES businesses(id),\n  mpesa_event_id UUID REFERENCES mpesa_events(id),\n  debit DECIMAL(15, 2),\n  credit DECIMAL(15, 2),\n  balance DECIMAL(15, 2),\n  posted_at TIMESTAMP,\n  created_at TIMESTAMP DEFAULT NOW(),\n  INDEX (business_id, posted_at)\n);\n

```\n\nWhy separate tables? **Auditability + Flexibility**.\n\nIf M-Pesa sends a reversal (refund), it arrives as a new event with a reference to the original `mpesa_receipt_number`. We don't delete or update the original transaction. We add a new event and let the ledger rebuild itself.\n\n```

javascript\n// Processing a transaction\nconst processTransaction = async (mpesaEvent) => {\n  const db = await getConnection();\n  \n  try {\n    await db.transaction(async (trx) => {\n      // Check if already processed\n      const existing = await trx('mpesa_events')\n        .where('mpesa_receipt_number', mpesaEvent.mpesa_receipt_number)\n        .first();\n      \n      if (existing) {\n        return; // Idempotent — don't reprocess\n      }\n      \n      // Insert the event\n      const [eventId] = await trx('mpesa_events').insert({\n        mpesa_receipt_number: mpesaEvent.mpesa_receipt_number,\n        amount: mpesaEvent.amount,\n        phone_number: mpesaEvent.phone_number,\n        transaction_timestamp: mpesaEvent.transaction_date,\n        raw_payload: mpesaEvent,\n        status: 'processed'\n      });\n      \n      // Append to ledger\n      await trx('account_ledger').insert({\n        mpesa_event_id: eventId,\n        business_id: mpesaEvent.business_id,\n        credit: mpesaEvent.amount,\n        posted_at: new Date()\n      });\n      \n      // Trigger balance recalculation\n      await recalculateBalance(trx, mpesaEvent.business_id

ReserveFlow — devto

sharkflow ltd — Tue, 28 Apr 2026 09:55:06 +0000

{
  "title": "Building ReserveFlow: AI-Powered Booking Infrastructure for Africa's Mobile-First Reality",
  "content": "# Building ReserveFlow: AI-Powered Booking Infrastructure for Africa's Mobile-First Reality\n\nWhen we started building ReserveFlow at SharkFlow, we had one brutal constraint: **most of our users would be on 3G, 2G fallback networks, accessing via phones with 2GB RAM max**. This isn't a edge case in Kenya—it's the norm. M-Pesa processes $320B annually through USSD and SMS-based systems. If they could build payments for 60M+ users on fragile networks, we could build bookings.\n\nBut real estate and hotel booking? That's different. You're moving complex data: property listings, pricing calendars, availability states, user preferences, booking confirmations, and payment reconciliation—all needing instant updates across terrible networks.\n\nHere's how we engineered ReserveFlow to actually work in Nairobi, Kampala, and Lagos.\n\n## 1. API Design: Embrace Unreliability\n\nMost booking APIs assume good connectivity. Ours doesn't.\n\nWe built ReserveFlow on a **graph-based REST API with explicit offline-first principles**. Every endpoint returns a `_metadata` object:\n\n```

json\n{\n  \"data\": {\n    \"property_id\": \"prop_8472kd\",\n    \"name\": \"Westlands Studio\",\n    \"available_dates\": [\"2024-02-15\", \"2024-02-16\"],\n    \"price_per_night\": 4500\n  },\n  \"_metadata\": {\n    \"timestamp\": 1707900000,\n    \"version\": 3,\n    \"cache_ttl\": 3600,\n    \"checksum\": \"a3f9d2e1\"\n  }\n}\n

```\n\nWhy the `_metadata`? Because:\n- **Timestamps** let clients detect stale data (critical when re-syncing after network drops)\n- **Version numbers** prevent conflicts when offline changes sync back online\n- **Cache TTL** tells mobile apps how long to trust cached responses\n- **Checksums** let us verify data integrity after spotty downloads\n\nWe keep endpoints **intentionally chunky**—one request returns 50 properties with their full calendar availability for a month, not multiple requests that fail halfway. Bandwidth is expensive in Kenya; latency is brutal.\n\n## 2. Database: PostgreSQL with Smart Partitioning\n\nWe chose **PostgreSQL with time-based partitioning** over NoSQL, because booking state is transactional and consistency matters more than horizontal scaling at our scale.\n\nBooking availability is the hottest table. Here's the schema:\n\n```

sql\nCREATE TABLE property_availability (\n  id BIGSERIAL,\n  property_id UUID NOT NULL,\n  date DATE NOT NULL,\n  available_units INT NOT NULL,\n  reserved_units INT NOT NULL,\n  price_base INT NOT NULL,  -- in KES cents\n  surge_multiplier DECIMAL(3,2) DEFAULT 1.0,\n  updated_at TIMESTAMP DEFAULT NOW(),\n  PRIMARY KEY (property_id, date)\n) PARTITION BY RANGE (date);\n\nCREATE INDEX idx_availability_property_date \n  ON property_availability(property_id, date DESC);\n

```\n\nWhy partitioning? Two reasons:\n- **Query performance**: Users always ask \"what's available in the next 90 days?\" Partitioning by date means we scan only relevant partitions.\n- **Archive pattern**: Old data (>1 year) gets archived to cold storage monthly without locking active tables.\n\nFor booking reservations themselves, we use **SERIALIZABLE isolation level** on critical transactions:\n\n```

sql\nBEGIN ISOLATION LEVEL SERIALIZABLE;\n\n-- Check availability\nSELECT available_units - reserved_units as open_slots\nFROM property_availability\nWHERE property_id = $1 AND date >= $2 AND date < $3\nFOR UPDATE;  -- Lock these rows\n\n-- Create reservation\nINSERT INTO reservations (property_id, user_id, check_in, check_out, status)\nVALUES ($1, $2, $3, $4, 'pending_payment');\n\nUPDATE property_availability\nSET reserved_units = reserved_units + 1\nWHERE property_id = $1 AND date = $3;\n\nCOMMIT;\n

```\n\nThis prevents double-bookings even under concurrent requests. Essential when 10,000 users are browsing the same popular apartment.\n\n## 3. Scaling for African Mobile Networks\n\n**Here's the honest part**: We don't try to scale like Instagram. We scale *efficiently*.\n\n### 3.1 Request Coalescing\n\nWhen the network is slow, users click \"check availability\" multiple times hoping something happens. We detect this:\n\n```

python\nfrom functools import wraps\nimport hashlib\n\nrequest_cache = {}  # Simple in-memory cache; Redis in production\n\ndef coalesce_requests(timeout=2):  # 2 seconds\n    def decorator(f):\n        @wraps(f)\n        def wrapper(*args, **kwargs):\n            # Create fingerprint of request\n            cache_key = hashlib.md5(\n                str((f.__name__, args, tuple(sorted(kwargs.items()))))\n                .encode()\n            ).hexdigest()\n            \n            # Return pending promise if same request in flight\n            if cache_key in request_cache:\n                return request_cache[cache_key]\n            \n            # Otherwise, execute and cache\n            promise = f(*args, **kwargs)\n            request_cache[cache_key] = promise\n            \n            # Clear after timeout\n            async def

ReserveFlow — devto

sharkflow ltd — Tue, 28 Apr 2026 04:00:05 +0000

{
  "title": "Building ReserveFlow: AI-Powered Booking Infrastructure for Africa's Mobile-First Reality",
  "content": "# Building ReserveFlow: AI-Powered Booking Infrastructure for Africa's Mobile-First Reality\n\nWhen SharkFlow started building ReserveFlow, our real estate and hotel booking AI, we faced a problem most Silicon Valley engineers never encounter: our users aren't on fiber. They're on 3G, dodgy 4G, or sometimes just EDGE networks. And they're booking properties while minibus-ing through Nairobi traffic.\n\nThis isn't a scaling problem that throwing more servers at solves. It's a fundamental architectural problem. Here's how we built it.\n\n## The Reality Check: Mobile-First Isn't Optional in Kenya\n\nLet's be clear: 60% of Kenya's 60M+ mobile money users don't have desktop computers. They're transacting on phones with 1-2GB RAM, unreliable connectivity, and data bundles that cost real money. ReserveFlow's API had to assume latency, packet loss, and intermittent connectivity as default states, not edge cases.\n\nMost SaaS platforms optimize for latency in milliseconds. We optimized for completing transactions in environments where you might lose connection mid-booking.\n\n## API Design: Designing for Offline-First Sync\n\nOur REST API is deliberately stateless and chunked. Instead of the typical monolithic booking flow, we broke it into atomic operations that can be queued, retried, and synced.\n\n```

typescript\n// Client-side queue manager\ninterface BookingOperation {\n  id: string;\n  type: 'SEARCH' | 'RESERVE' | 'PAY' | 'CONFIRM';\n  timestamp: number;\n  payload: any;\n  retryCount: number;\n  status: 'PENDING' | 'SYNCED' | 'FAILED';\n}\n\nclass BookingQueue {\n  private queue: BookingOperation[] = [];\n  private readonly MAX_RETRIES = 5;\n  private readonly SYNC_INTERVAL = 15000; // 15 seconds\n\n  async enqueue(operation: BookingOperation): Promise<void> {\n    this.queue.push({\n      ...operation,\n      timestamp: Date.now(),\n      retryCount: 0,\n      status: 'PENDING'\n    });\n    await this.persistToLocalDB();\n  }\n\n  async syncWithServer(): Promise<void> {\n    const pending = this.queue.filter(op => op.status === 'PENDING');\n    \n    for (const operation of pending) {\n      try {\n        const response = await fetch(\n          `${API_BASE}/bookings/${operation.type.toLowerCase()}`,\n          {\n            method: 'POST',\n            body: JSON.stringify(operation.payload),\n            headers: { 'X-Idempotency-Key': operation.id }\n          }\n        );\n        \n        if (response.ok) {\n          operation.status = 'SYNCED';\n        } else if (response.status === 429 || response.status >= 500) {\n          // Server error or rate limited - retry later\n          operation.retryCount++;\n          if (operation.retryCount >= this.MAX_RETRIES) {\n            operation.status = 'FAILED';\n          }\n        }\n      } catch (error) {\n        // Network error - will retry on next sync\n        operation.retryCount++;\n      }\n    }\n    \n    await this.persistToLocalDB();\n  }\n\n  private async persistToLocalDB(): Promise<void> {\n    // SQLite on mobile, IndexedDB on web\n    await localDB.saveOperations(this.queue);\n  }\n}\n

```\n\nThe key insight: idempotency is non-negotiable. Every operation gets a unique ID, and the server never processes the same booking twice, even if the client retries five times.\n\n## Backend API Endpoints: Minimal Data Transfer\n\nOur endpoints are designed to minimize payload size. We use compression, pagination, and field filtering.\n\n```

javascript\n// Example: Search properties with minimal payload\nGET /api/v1/properties/search?limit=10&offset=0&fields=id,name,price,rating&location=nairobi&budget=5000-15000\n\nResponse (gzipped, ~4KB):\n{\n  \"properties\": [\n    {\n      \"id\": \"prop_abc123\",\n      \"name\": \"Riverside Apartments\",\n      \"price\": 8500,\n      \"rating\": 4.7,\n      \"location\": \"Westlands\"\n    }\n  ],\n  \"next\": \"/api/v1/properties/search?offset=10&...\",\n  \"total\": 234\n}\n

```\n\nCompare that to the typical SPA approach where you'd send the entire property object with 50+ fields, nested user reviews, amenities arrays, etc. Our responses are 70-80% smaller.\n\n## Database Architecture: PostgreSQL + Redis + S3\n\nWe use PostgreSQL for transactional data because real estate bookings aren't eventual-consistent problems—double-booking costs money. But we needed to make it fast on slow networks.\n\n```

sql\n-- Core booking table with denormalized fields for quick queries\nCREATE TABLE bookings (\n  id UUID PRIMARY KEY,\n  user_id UUID NOT NULL,\n  property_id UUID NOT NULL,\n  check_in DATE NOT NULL,\n  check_out DATE NOT NULL,\n  status ENUM ('RESERVED', 'PAID', 'CONFIRMED', 'CANCELLED') NOT NULL,\n  total_price DECIMAL(10,2) NOT NULL,\n  payment_method VARCHAR(50),\n  m_pesa_tx_id VARCHAR(255) UNIQUE,\n  created_at

FundFlow — devto

sharkflow ltd — Mon, 27 Apr 2026 08:34:58 +0000

{
  "title": "Building FundFlow: How We Match African Startups with Investors at Scale (And Why Your Database Choice Matters)",
  "content": "# Building FundFlow: How We Match African Startups with Investors at Scale (And Why Your Database Choice Matters)\n\nWhen SharkFlow started building FundFlow—our investor matching platform—we faced a problem that most Silicon Valley startups never encounter: 60% of our users are on 2G networks, and a significant portion have data plans measured in MB, not GB.\n\nThis article walks through how we designed FundFlow's backend to solve real African infrastructure constraints while matching thousands of startups with investors in real time. If you're building for emerging markets, this is for you.\n\n## The Problem We're Solving\n\nAfrica has 400M+ unbanked people, but we also have **vibrant startup ecosystems**—Nairobi's Silicon Savannah pumps out unicorns, Lagos is a fintech powerhouse, and Kigali's tech scene is exploding. Yet finding capital remains inefficient.\n\nTraditional investor matching platforms (Crunchbase, AngelList) assume:\n- Fast internet\n- Desktop-first usage\n- Large file uploads\n- Real-time push notifications\n\nNone of these assumptions hold in Nairobi's traffic or rural Uganda. FundFlow needed to work differently.\n\n## Architecture Decision #1: API-First, Mobile-Native\n\nWe started with a REST API, but quickly pivoted to **GraphQL with aggressive caching**. Here's why:\n\nA startup founder in Kampala might check FundFlow on their 3G connection during lunch. With REST, fetching a founder profile (basic info + funding needs + similar investors + recent updates) would require 4-5 separate calls. Each call = latency + battery drain.\n\nWith GraphQL, one query:\n\n```

graphql\nquery GetFounderMatchProfile($id: ID!) {\n  founder(id: $id) {\n    name\n    companyStage\n    fundingNeeded\n    matchedInvestors(limit: 10) {\n      id\n      name\n      checkSize\n      focusAreas\n      responseRate\n    }\n    similarFounders(limit: 5) {\n      id\n      company\n    }\n  }\n}\n

```\n\nOne request, one response. We then layer **HTTP/2 server push** to proactively send investor updates without the founder asking.\n\n### Response Optimization\n\nBut here's the crucial part: we **gzip everything** and implement a custom compression layer for JSON payloads:\n\n```

typescript\n// Custom compression for slow networks\nimport { transform } from 'jsoncrush';\n\nconst compressForMobile = (data: any) => {\n  // Remove null values, use shorter keys\n  const crushed = transform(data, {\n    removeNulls: true,\n    aliasMap: {\n      'fundingNeeded': 'fn',\n      'companyStage': 'cs',\n      'responseRate': 'rr'\n    }\n  });\n  return crushed;\n};\n

```\n\nOn 2G, this reduces payload size by 60-70%. It matters when someone's data plan costs KSH 100/GB.\n\n## Architecture Decision #2: Database Strategy for Emerging Markets\n\nThis is where most startups fail. Using PostgreSQL is great for consistency, but we needed:\n\n1. **Fast reads for investor matching** (needs to be sub-500ms)\n2. **Offline-first capability** (users lose connection constantly)\n3. **Cheap scaling** (we're not burning VC cash on cloud bills)\n\nOur stack:\n\n- **PostgreSQL** (primary data store, Nairobi-hosted on Linode): Startups, investors, funding history\n- **Redis** (matching cache + session store): Real-time investor/founder matching\n- **DuckDB** (edge analytics): Local processing on phones for pattern matching\n\n### The Matching Algorithm\n\nMatching 15,000 startups with 3,000 investors requires smart indexing. We use **vector similarity** on founder + investor profiles:\n\n```

python\n# Simplified matching logic\nimport numpy as np\nfrom sklearn.metrics.pairwise import cosine_similarity\n\nclass InvestorMatcher:\n    def __init__(self, redis_client):\n        self.redis = redis_client\n    \n    def get_matches(self, founder_id: str, limit: int = 10):\n        # Fetch cached vectors (precomputed daily)\n        founder_vector = self.redis.get(f'vector:founder:{founder_id}')\n        \n        # Get all investor vectors\n        investor_vectors = self.redis.hgetall('vectors:investors')\n        \n        # Compute similarity\n        similarities = cosine_similarity(\n            [founder_vector],\n            list(investor_vectors.values())\n        )[0]\n        \n        # Return top matches\n        top_indices = np.argsort(similarities)[-limit:][::-1]\n        return [list(investor_vectors.keys())[i] for i in top_indices]\n

```\n\nVectors are precomputed nightly (not in real-time), reducing compute load by 80%. This is crucial when your servers are in a data center without unlimited power.\n\n## Architecture Decision #3: M-Pesa Integration for Founder Trust\n\nHere's a feature that only works in Africa: We verify founders through M-Pesa transaction history.\n\nWhy? Because in Kenya, M-Pesa transactions are a proxy for business legitimacy. If you've moved KSH 10M+ through M-Pesa in the last year, you probably exist and have customers.\n\n```

typescript\n// Simplified M-Pesa verification\nimport axios from 'axios';\n\nclass MPesaVerifier {\n  async verifyFounder(\n    phoneNumber: string,\n    mp