DEV Community: Nandawula Kabali-Kagwa

Why I Built an Automated Marketing Desk Inside My Monorepo

Nandawula Kabali-Kagwa — Thu, 22 Oct 2026 13:30:31 +0000

As developers, we love building the product. The database schema, the API routes, the buttery-smooth UI transitions, that is our playground. But once you ship eight production apps and run a registered software studio from East London, you realize a brutal truth: code that nobody sees solves no problems.

Instead of hiring out or getting sucked into daily manual social media loops, I decided to engineer my way out of the problem. This week inside JarvisOS, I shipped a complete marketing department into the codebase.

Here is what the stack looks like now:

B2 Weekly Auto-Plan: A deterministic slot planner executing on a Sunday cron at 18:00.
B3 Generators: Reading directly from our internal markdown corpus slots.
B4 Command Center: A full API and UI for dispatching content.
B5 Account Portfolio: Tracking roles, strategies, streaks, and best-performing posts per account.
CF1 Cloudflare Browser Run: Offloading PNG/PDF renders to the edge with a local Chrome fallback.

One of the most satisfying engineering moments this week was fixing our corpus reading pipelines. An unanchored gitignore rule had silently hidden any new src/**/corpus file, and a silent 1,000-row cap was truncating our corpus database stats. We also tackled UTF-8 mojibake across 27 files where special characters had turned into cryptographic-looking garbage during early AI prompt generation.

// Ensuring honest corpuses: paged corpus reads and strict URL hardening
export async function readPagedCorpus(cursor: string, limit = 100) {
  const slice = await db.corpus.findMany({
    take: limit,
    skip: cursor ? 1 : 0,
    cursor: cursor ? { id: cursor } : undefined,
  });
  return slice;
}

We also built read-only Instagram and Facebook historical graph importers that backfill likes and comments onto existing posts idempotently across a 180-day window, and hardened our wing-insight URLs to prevent token-leaking query parameters.

When your tooling lives inside your monorepo, marketing stops feeling like a distraction and starts feeling like an extension of your compiler.

How do you balance writing code with getting it into the hands of users?

Engineering for Reality: What Managing 14 Live Systems Taught Me About Solo Shipping

Nandawula Kabali-Kagwa — Thu, 15 Oct 2026 13:30:19 +0000

There is a distinct kind of silence that settles over a desk at 2:00 AM in East London. The hum of the inverter, the rhythmic blinking of a terminal, and the quiet satisfaction of a passing test suite. This week, my codebase logs hit a milestone that still catches me by surprise: fourteen live production systems under my studio, Mirembe Muse, with total product reach crossing 1,384+ users.

If you told me in June 2025, when I first touched code, that I would be shipping institutional platforms like the ICSA Summit OS, ECDC, ISD, and Green Diaspora alongside student tools like VarsityOS and SME solutions like AdminOS, I would have laughed. Yet, here we are.

The Reality of Shipping Solo

When you are a self-taught engineer building for African realities, you don't have the luxury of bloated teams or endless sprint retrospectives. Every line of code has to pull its weight.

This week’s commits were all about institutional proof and system clarity. We pushed comprehensive case studies into MirembeApp, formalizing the work done for summits and regional development bodies. We also locked in the metrics: VarsityOS standing firm with offline capabilities through load shedding and 11-language support, and CreativelyNanda nurturing a growing creative community.

Code Architecture Under Constraints

Building for environments marked by power outages and varied device specs changes how you think about frontend performance and backend reliability:

Zero Bloat: Every dependency is interrogated. If a package can be written in twenty lines of vanilla TypeScript, it doesn't enter the dependency tree.
Defensive UI: Components must look pristine whether rendered on a flagship iPhone in Sandton or a budget Android device in a township.
Transparent Pricing: As a studio, we publish fixed prices. Software should not be an opaque mystery; clients deserve predictable economics.

The Developer's Loop

Being a developer who also writes poetry (yes, the two brains live happily in the same skull) changes how I view code. Code is syntax, yes, but it is also rhythm. It is the cadence of functions calling each other, the clean architecture of a well-structured component tree.

Fourteen systems live. The studio is standing. The compiler is quiet. Back to the editor.

From 46 Raw Errors to Zero: Lessons in API Hardening and SAST Calendars

Nandawula Kabali-Kagwa — Thu, 08 Oct 2026 13:31:13 +0000

There is a specific kind of humility that comes from running 7 industry persona tenants against a live production environment and watching your authz matrix test every single role check. This week, our work on AdminOS and JarvisOS was less about shipping shiny new buttons and more about nailing the unglamorous plumbing that keeps real businesses running.

Catching What the Database Drops

Let’s start with the database layer. In our API routes, we had a silent vulnerability: 46 distinct endpoints could potentially leak raw Postgres error strings back to the client if a query malformed or a constraint failed. That is a security risk and a terrible user experience. We audited every single one of those 46 routes, routing exceptions through a unified validation layer that returns graceful, type-safe responses.

Next came the hard delete problem. When building rapidly, it is easy to write a quick DELETE FROM query. But in enterprise systems, especially when managing finance books, client records, and POPIA compliance registers, deleting data is a cardinal sin. We hunted down six legacy hard-delete methods and refactored them into soft deletes, ensuring our audit gates remain unbroken.

The SAST Calendar Sweep

One of the most insidious bugs we tackled this week involved dates. Compliance countdowns and licence expirations were drifting by an hour or two because of server-client timezone mismatches between 00:00 and 02:00. We implemented an app-wide SAST (South African Standard Time) sweep.

We rebuilt our SA statutory calendar on SARS-verified dates that roll forward monthly. Persona provisioners now use this TypeScript calendar, ensuring that when an SME back-office agent checks a tax deadline or a sequence broadcast date, the calendar matches the physical reality of the business owner sitting across the screen.

Making WhatsApp and Sequences Work

Finally, we tackled the reach and messaging engine. POPIA section 69 requires explicit, verifiable consent for broadcasts and sequences. We wired up POPIA s69 consent checks directly into our broadcast enrolment pipelines. Combined with Meta Tech Provider coexistence plans and clean template execution, WhatsApp, NPS, and n8n automations finally click together without silent failures.

When totals stop silently at 1,000 rows because of pagination oversights, you fix the pagination. When permissions need validation down to the method level, you write the matrix. That is what building real systems looks like.

Building for Real Realities: Why We Eliminated Em Dashes and Standardized Equal Thirds

Nandawula Kabali-Kagwa — Thu, 01 Oct 2026 13:02:32 +0000

When you are writing code that represents a physical and digital studio from East London, South Africa, aesthetic choices quickly become engineering constraints. This week, our main repository (CreativelyNanda.co.za) underwent a massive structural refinement. We didn't add a flashy new database or migrate to an exotic edge runtime. Instead, we focused on the bones: equal thirds, strict color tokens, print stylesheets, and brutal typographic minimalism.

Let’s talk about the stack decisions behind this week's commits.

1. The Geometry of Equal Thirds

Layout drift is the silent killer of frontend polish. Across our shop, Notion integration, business archives, and the Poem Wall, we enforced an equal-thirds layout structure. This wasn't just a whim; it was a deliberate move to create predictable mental models for users navigating heavy literary and commercial content simultaneously. We extended this rhythm to the legal pages, roots, testimonials, and imprints, ensuring that whether a user is reading a poem or buying a physical volume, the container feels anchored.

2. Styling for Paper: When CSS Meets the Physical World

One of the most challenging frontend tasks this week was making the digital design system translate seamlessly to physical print. We configured the remaining navy pages to print accurately on paper, ensuring that coloured buttons retain stark white labels and Forge masthead pockets align precisely with the words beneath them. Stage reel captions were locked directly under their frames.

In a region where load shedding is a structural reality, thinking about how a web page behaves when printed or saved offline isn't a retro novelty, it's robust engineering. It’s the same philosophy that drives VarsityOS to remain fully functional offline for students navigating NSFAS budgets.

3. Typography as an API

We instituted a strict style rule: no em dashes anywhere on the site.

From a parser and readability perspective, em dashes often act as a crutch for run-on architectural logic in copywriting. By stripping them out, we forced our prose to rely on hinge words, pauses, and clean pulse lines. We updated our X-ray poetry modes and garden layouts to respect this newfound restraint.

4. The Gotchas: JSX Comments and Selector Escaping

No build log is complete without a bug post-mortem. Early in the week, a stray comment hidden inside a JSX conditional broke our product page build. It's a humbling reminder that even with mature tooling, JSX parsing edge cases will catch you off guard if your components mix declarative markup with raw scripting comments.

We also escaped our CSS remap selectors (fix(css): escape the remap selectors; journal §25), cleaning up specificity wars before they could compound.

Building apps like AdminOS (our six-agent SME back office) and the K53 Drill Master (rigorously audited against official DLTC docs this week) teaches you one unchanging truth: discipline in the small files saves your life in the large ones. Clean up your tokens. Check your build logs. And let your code breathe.

VarsityOS: An AI Study OS Built for African Students

Nandawula Kabali-Kagwa — Sun, 27 Sep 2026 16:03:11 +0000

VarsityOS: An AI Study OS Built for African Students

South African students face study conditions Silicon Valley tools were never designed for. Load shedding, NSFAS deadlines, overcrowded libraries. VarsityOS was built to meet them where they are.

What it actually does

AI-powered study sessions that adapt to your energy levels and available time
Offline-first architecture so load shedding never kills a session mid-flow
NSFAS deadline tracking with intelligent reminders tied to the academic calendar
Past paper engine with 26 drill modes and step-by-step explanations

The stack and one interesting decision

Next.js 14 App Router, Supabase, and Claude AI (routed through a Groq adapter on the free tier). Every AI call routes through Inngest workers rather than route handlers, so a slow generation never times out on Vercel and retries happen automatically.

What is next

Collaborative study rooms and a curriculum-linked flashcard engine ship in October.

Try it free at varsityos.co.za

Building an AI-Powered Engineering OS: Cron Jobs, ADRs, and Autonomous Workflows

Nandawula Kabali-Kagwa — Sun, 27 Sep 2026 15:31:33 +0000

There is a distinct moment in software development when you realize you are spending more time maintaining your workflow than writing code. As a self-taught engineer managing 8 production apps and a registered studio, I hit that wall hard. When you're building for African realities from East London, South Africa—where reliability and efficiency are non-negotiable—manual project management wastes precious cycles.

So, I decided to let JarvisOS manage itself.

Over the past week, I engineered a suite of autonomous background systems and architectural pipelines inside JarvisOS. Let's look at how automation can replace administrative fatigue.

Automating the Paper Trail: Commit to ADRs

Documentation is where good software goes to die. Everyone intends to write comprehensive Architecture Decision Records, but life moves fast. To fix this, I built an automated pipeline that intercepts git pushes, analyzes the diff, and auto-suggests structured ADRs.

Instead of hunting through months of git logs to figure out why a database schema was refactored, the system documents the decision context at the exact moment the code is shipped.

The Autonomous Engineering Team

When you don't have a large engineering team, you build synthetic guardrails. I set up five specialized cron jobs that act as automated colleagues:

The Cost Watchdog: Runs every 2 hours, monitoring AI token expenditure to catch runaway recursive loops before they drain API budgets.
The Impact Detector: Evaluates system health every 30 minutes following any production deployment.
The Decision Aging Monitor: Daily alerts on technical debt and overdue architectural decisions.
The Dependency Brief: A weekly pulse check on stale packages.
The Friday Retrospective: Automatically compiles the week's output into a clean markdown retro every Friday at 17:00 SAST.

Content Systems at Scale: MirembeApp

Automation isn't just for backend engineering; it applies to content delivery too. This week, MirembeApp migrated to a fully database-driven article architecture, seeding all 22 foundational pieces with a polished migration script.

We paired this with robust ISR (Incremental Static Regeneration) and an hourly revalidating sitemap with article priorities set to 0.8/weekly. By ensuring analytics (GA4 with Consent Mode v2) load unconditionally and cleanly, we maintain strict visibility while respecting user privacy.

Closing Thoughts

Engineering is ultimately about leverage. By turning administrative overhead into automated background pipelines, we free up cognitive bandwidth to focus on what matters: shipping resilient software that serves real people.

Article about how I actually build for Africa and why

Nandawula Kabali-Kagwa — Sat, 26 Sep 2026 18:51:09 +0000

TITLE: How I Build Software That Survives Load-Shedding and Spotty Connectivity in South Africa

If you build software from a comfortable office with a gigabit fibre connection and uninterrupted grid power, your assumptions about network resilience are almost certainly broken.

Over the last two years building apps like AdminOS and VarsityOS from East London, South Africa, I’ve had to throw away standard web development playbooks. When Eskom stage 4 load-shedding hits mid-afternoon, your fancy cloud-native microservices architecture doesn't matter if the local cellphone tower drops offline ten minutes later.

Here is the exact technical stack and architectural pattern I use to build offline-first, resilient web applications that don't choke when the power goes out.

The Local-First Reality

In San Francisco, local-first is a philosophical choice about data ownership. In the Eastern Cape, local-first is survival. If a spaza shop owner or a university student in Braamfontein loses their internet connection for three hours, they cannot afford an infinite loading spinner.

Our architecture rests on three pillars:

SQLite at the edge (via Turso or local IndexedDB adapters).
Optimistic UI updates with zero-latency local state mutation.
Background sync queues that retry silently when carrier signal returns.

Let’s look at how we handle local mutations without losing transactional integrity.

import { useState, useEffect } from 'turso';

interface SyncQueueItem {
  id: string;
  action: 'INSERT' | 'UPDATE' | 'DELETE';
  table: string;
  payload: Record<string, any>;
  timestamp: number;
}

export function useOfflineSync(table: string) {
  const [isOnline, setIsOnline] = useState(navigator.onLine);

  useEffect(() => {
    const handleOnline = () => { 
      setIsOnline(true);
      flushQueue();
    };
    const handleOffline = () => setIsOnline(false);

    window.addEventListener('online', handleOnline);
    window.addEventListener('offline', handleOffline);

    return () => {
      window.removeEventListener('online', handleOnline);
      window.removeEventListener('offline', handleOffline);
    };
  }, []);

  const mutateLocally = async (payload: Record<string, any>) => {
    const localId = crypto.randomUUID();
    // Write immediately to local IndexedDB/SQLite cache
    await window.localDb.execute(
      `INSERT INTO ${table} (id, data, synced) VALUES (?, ?, 0)`,
      [localId, JSON.stringify(payload)]
    );

    if (isOnline) {
      try {
        await syncToServer(localId, payload);
      } catch (err) {
        queueForLater(localId, payload);
      }
    } else {
      queueForLater(localId, payload);
    }
  };

  return { isOnline, mutateLocally };
}

async function queueForLater(id: string, payload: any) {
  const existing = JSON.parse(localStorage.getItem('sync_queue') || '[]');
  localStorage.setItem('sync_queue', JSON.stringify([...existing, { id, payload, timestamp: Date.now() }]));
}

async function flushQueue() {
  const queue: SyncQueueItem[] = JSON.parse(localStorage.getItem('sync_queue') || '[]');
  if (queue.length === 0) return;

  for (const item of queue) {
    try {
      await fetch('/api/sync', { method: 'POST', body: JSON.stringify(item) });
      // Remove successfully synced item
    } catch {
      break; // Stop flushing if connection drops again
    }
  }
}

Handling Latency Spikes (3G vs Fibre)

Most Western users are on broadband. In South Africa, a huge portion of users access web applications via mobile data on 3G or unstable 4G networks where latency can spike from 50ms to 4,000ms instantly.

If you use heavy client-side hydration frameworks without aggressive code-splitting, your JavaScript bundle size will penalize users paying high rates per megabyte. We enforce a strict rule across Mirembe Muse products: initial JavaScript bundles must stay under 85KB compressed.

We achieve this by:

Eliminating heavy UI component libraries in favour of bespoke, headless Tailwind primitives.
Server-side rendering critical shell layouts so the user sees painted pixels in under 300ms, even on a budget Android device.

Why This Matters Beyond Africa

When you build for extreme constraints—unstable power grids, high data costs, intermittent latency—you don't just build for Africa. You build better software.

The same resilience that keeps an inventory app running during stage 3 load-shedding will keep your app running smoothly for a user on a shaky commuter train in London or a subway in New York.

Stop designing for the ideal network condition. Build for the real world.

I Rebuilt JarvisOS Marketing Wing From Scratch Mid-Sprint — Here's Every Trade-Off

Nandawula Kabali-Kagwa — Fri, 11 Sep 2026 10:31:14 +0000

There is a specific kind of dread that arrives when a save + publish button silently breaks in production. No 500 in the logs. No red banner for the user. The data just... stops moving. That was Monday.

This is the technical record of a week inside JarvisOS — an AI operating system I'm building for African founders — where the marketing wing collapsed under its own accumulated shortcuts and I had to decide: patch it again, or tear the architecture down and rebuild it correctly.

I rebuilt it.

The Root Cause: Schema Drift

The save + publish failure traced back to a schema mismatch. Columns I was writing to in the API layer didn't exist in the actual database table — specifically thumbnail_url, image_brief, and external_url. The inserts were silently swallowed because the ORM wasn't set to strict mode. The user saw a success toast. The row was incomplete. Every downstream read that touched those fields returned a 400.

This is a category of bug that feels embarrassing in retrospect but is genuinely easy to accumulate when you are shipping fast and migrating features across wings of a larger system. The fix was:

Add the missing columns via migration
Audit every SELECT and INSERT that touched the marketing content table
Add a NOT NULL constraint with a safe default on external_url to make future drift loud and immediate

Trade-off: Strict constraints slow down exploratory schema work. I accepted that cost. At production scale, silent data corruption is worse than a loud migration failure.

Five Live Crashes, One Sweep

Once I was in the codebase, I ran a full sweep. What I found:

withCostLogging not a function — a utility I'd refactored had changed its export signature. Call sites weren't updated. Classic named-vs-default export drift in a JavaScript monorepo.
visual_brief.slice() crash — visual_brief was returning null from the DB on older rows. I was calling .slice() directly without a null guard. Fixed with optional chaining: visual_brief?.slice(0, 200) ?? ''.
brand_posts lane skipped — when content_calendar was empty, the lane generation function returned early before populating brand posts. The condition was checking the wrong array. One line fix, embarrassing in scale, real in consequence.
TikTok StrategyTab syntax errors — apostrophes in JSX string props that weren't escaped. South African copy tends to contract heavily (it's, you're, brand's) and I hadn't sanitised the AI-generated content before rendering it as JSX attributes.
JSON crash on paste queue hashtags — JSON.parse() on a value that was already a parsed object. typeof guard added.

Five crashes. One sweep. Three hours.

The Cockpit Architecture Rebuild

The deeper issue the bug sweep revealed: the marketing wing had grown as a series of bolted-on tabs rather than as a coherent architecture. Each platform (TikTok, Threads, etc.) had its own component with its own data-fetching logic, its own state shape, its own styling overrides.

I introduced what I'm calling the platform cockpit architecture. The design principle: every social platform is a wing of the cockpit, and every wing shares a single contract:

interface PlatformWing {
  platformId: string;
  strategyTab: React.FC<WingProps>;
  calendarTab: React.FC<WingProps>;
  analyticsTab: React.FC<WingProps>;
  dataFetcher: (userId: string) => Promise<PlatformData>;
}

This means adding a new platform — say, LinkedIn — requires implementing the interface, not copy-pasting a component tree. The dataFetcher contract also forced me to centralise error handling: one boundary, one logging call, one cost-tracking wrapper.

What I'd do differently: Define this interface at week one, not month four. The refactor cost was non-trivial. The lesson isn't novel but it bears repeating for anyone building multi-platform SaaS: your platforms are a collection, not a list of one-offs.

Threads OAuth + Cloudinary Migration

Two infrastructure moves happened in parallel.

First, Threads OAuth. I shipped the callback route, the deauthorize webhook, and the delete webhook — all required by Meta's API compliance checklist. The deauthorize and delete routes are easy to defer (we'll do it later) and catastrophic to forget when your app goes for review. They're in now.

Second, a full storage migration from Supabase Storage to Cloudinary. Supabase Storage is fine for getting started. Under real media volume — campaign thumbnails, visual briefs, CEO wing assets — the transformation pipeline limitations and egress costs became visible. Cloudinary's upload API with eager transformations gives me WebP conversion, responsive breakpoints, and CDN delivery in a single upload call. The migration script ran against existing rows, updated every storage_url column, and verified the new URLs returned 200 before deleting originals.

The Cron That Keeps the DB Honest

One small but meaningful addition: a monthly pruning cron that runs at 03:00 SAST on the first of every month, sweeping 7 tables of rows older than the retention window. Running on African infrastructure means cost discipline matters at every layer. A database that quietly grows forever is a bill that quietly grows forever.

Git Push → Sprint Board

Finally, a quality-of-life engineering feature that I'll write more about separately: push a commit, Haiku (the AI agent inside JarvisOS's engineering wing) reads the commit message, parses the scope and description, and auto-populates the sprint board task. It sounds small. For a solo founder shipping across 8 apps, it removes the gap between doing the work and tracking the work. That gap is where context goes to die.

The marketing wing is stable now. The cockpit architecture is clean. The schema is honest.

Next week I turn back to HCI — the human-computer interaction layer that makes the AI agents in JarvisOS feel less like tools and more like a team. Phase 4 closed this week. Phase 5 is already open.

Building in Africa

Nandawula Kabali-Kagwa — Fri, 11 Sep 2026 08:45:35 +0000

Welcome to a journey of a lifetime, building for Africa in Africa.

Building in Africa

Nandawula Kabali-Kagwa — Fri, 11 Sep 2026 08:37:52 +0000

Welcome to a journey of a lifetime, building for Africa in Africa.