DEV Community: Rono

How I Designed Invariants for AI-Human Collaboration

Rono — Sat, 06 Jun 2026 02:53:38 +0000

The morning it clicked

April 27, 2026. 8:30 AM. I opened my laptop with a specific problem: the AI kept overwriting human corrections, and my team was starting to lose trust in the tool we were building.

Not because the AI was bad. Because the architecture was wrong.

We had built a beautiful real-time collaborative status sheet. AI read weekly summaries and generated project rows. Multiple people could edit simultaneously. WebSockets broadcast changes instantly. It felt like magic.

But every time the AI ran again, it would regenerate the sheet from scratch. Human corrections? Gone. Manual overrides? Vanished. The project manager who spent ten minutes fixing deadlines and adding comments would come back the next day to find the AI's original, wrong version staring back at her.

She stopped correcting. She stopped trusting. She stopped using the tool.

That morning, I wrote three invariants into the code. They took 42 minutes to implement. They have not changed in the months since. And they turned a chaotic prototype into a system people actually rely on.

This article is about those invariants: what they are, why they matter, and how you can apply the same thinking to your own AI-human collaboration systems.

The problem with AI-generated content in collaborative tools

Before we get to the invariants, let me describe the problem precisely.

You have an AI that reads unstructured text (weekly summaries, Daraja Workspace messages, email threads) and extracts structured data (tasks, deadlines, owners, status). You present this data in a collaborative interface where humans can view, edit, and enrich it.

This creates a tension:

The AI is good at	Humans are good at
Processing large volumes of text quickly	Understanding nuance and context
Extracting obvious structure	Catching subtle errors
Working 24/7 with no fatigue	Making judgment calls
Being consistent	Being correct when it matters

Neither can fully replace the other. The AI will make mistakes. The humans will not have time to fix everything. The system needs both.

But traditional architectures treat AI output as ephemeral and human input as temporary. The AI regenerates on every view. The human corrections are stored in the UI state but not protected from future AI runs. The result is a system where trust never builds because the machine keeps forgetting what it was taught.

Here is what I learned: the problem is not the AI. The problem is the absence of invariants.

Invariants are rules that the system guarantees will always be true. They are not features. They are not configurable. They are the bedrock. When you design invariants for AI-human collaboration, you are answering one question: in any conflict between machine output and human judgment, who wins?

My answer:

The human wins. Always. Immediately. Permanently.

That answer became three lines in the code.

Invariant 1: The POST-once rule

The code

Future<void> _loadExistingStatus() async {
  setState(() => _isLoading = true);

  try {
    final response = await http.get(
      Uri.parse('https://api.rucks.co.ke/unfo/'),
    );

    if (response.statusCode == 200) {
      final List<dynamic> data = jsonDecode(response.body);
      final existingStatus = data.firstWhere(
        (item) => item['username'] == _roomName,
        orElse: () => null,
      );

      if (existingStatus != null && existingStatus['likes'] != null) {
        final savedData = jsonDecode(existingStatus['likes']);
        if (savedData['rows'] != null) {
          _rows = (savedData['rows'] as List)
              .map((row) => StatusRow.fromJson(row))
              .toList();
          _foundOnServer = true; // ✅ Mark as already on server — no POST needed
        }
      }
    }
  } catch (e) {
    // Error handling omitted for clarity
  }

  // Only generate (and POST) if nothing came back from the server
  if (_rows.isEmpty && !_foundOnServer) {
    await _generateNewStatus();
  }

  setState(() => _isLoading = false);
}

What it does

The system performs a GET lookup before ever invoking the AI. Generation — and the subsequent POST to persist results — occurs only when the lookup returns no existing data for the current week.

Why it matters

Most systems treat AI as an on-demand service. Every user, every refresh, every navigation triggers a new call to the model. This is fine for chatbots and search. It is disastrous for collaborative documents.

Here is what happens without this invariant:

User A opens the week sheet → AI generates → POST saved
User B opens the same week sheet → AI generates again → POST overwrites
User A makes corrections → saves locally
User C opens the sheet → AI generates again → User A's corrections are gone

The sheet becomes a game of last-write-wins between the AI and every human who opens it. The AI, being faster and more frequent, usually wins.

The POST-once rule changes everything:

Without the rule	With the rule
AI runs on every view	AI runs once per week
Storage scales with views	Storage scales with weeks
Human corrections are fragile	Human corrections are permanent
No auditable baseline	First AI output is frozen baseline

The deeper insight

The _foundOnServer flag is the key. The system is not just checking if data exists — it is checking if data exists for this specific room name. The room name encodes the week number (week42_status). This means the invariant is scoped to the domain entity, not to the user session.

This is the difference between streaming intelligence (ephemeral, unrepeatable, distrustful) and settled intelligence (auditable, comparable, learnable). The first AI output becomes the fixed point against which all human corrections are measured.

What broke without it

Before this invariant, we had a week where the AI ran 47 times for the same status sheet. Forty-seven. Different users, different times of day, different devices. Each run overwrote the previous state. The sheet was never stable. Users reported that their corrections "disappeared" but could never reproduce the bug because the bug was the architecture itself.

The POST-once rule reduced API calls by 98% and eliminated the disappearing-corrections bug entirely.

Invariant 2: The override-is-sacred rule

The code

class StatusRow {
  final String client;
  final String brand;
  final String project;
  final String team;
  final String activities;
  final String pic;
  final String creative;
  final String timelines;
  final String comments;
  final bool isManuallyEdited;  // ← THE INVARIANT LIVES HERE

  StatusRow({
    required this.client,
    required this.brand,
    required this.project,
    required this.team,
    required this.activities,
    required this.pic,
    required this.creative,
    required this.timelines,
    required this.comments,
    this.isManuallyEdited = false,  // Default: AI-generated
  });

  StatusRow copyWith({
    // ... other fields
    bool? isManuallyEdited,
  }) {
    return StatusRow(
      // ... other fields
      isManuallyEdited: isManuallyEdited ?? this.isManuallyEdited,
    );
  }
}

And the edit handler:

void _editCell(int rowIndex, String column, String currentValue) {
  // ... dialog shown, user edits, newValue received

  // When saving the edit, we mark the row as manually edited
  final updatedRow = _rows[rowIndex].copyWith(
    [column]: newValue,
    isManuallyEdited: true,  // ← FLIP THE FLAG
  );

  setState(() {
    _rows[rowIndex] = updatedRow;
  });

  // Broadcast to other users
  _sendCellEdit(rowIndex, column, currentValue, newValue);
}

What it does

Every StatusRow carries a boolean flag: isManuallyEdited. It starts false for AI-generated rows. The first time a human edits any field in that row, the flag flips to true and never flips back.

The system preserves the original AI values in an audit trail (not shown in the simplified code), but the main view shows only the human-corrected version.

Why it matters

In most AI systems, human feedback is treated as a training signal — something that eventually improves the model after retraining, fine-tuning, or prompt adjustment. The latency between correction and effect can be hours, days, or weeks.

In operational environments, that latency is unacceptable. The human correction must be immediately authoritative. Not "the model will learn from this." Not "we'll update the prompt next sprint." Right now.

The isManuallyEdited flag enforces this at the storage layer, not just the application layer. Even if the AI reruns (which it won't, thanks to Invariant 1), it cannot overwrite a field where isManuallyEdited is true.

The trust multiplier

This invariant creates psychological safety. The AI is allowed to be wrong. No one is blamed for a bad extraction. The system simply accepts the correction and moves on.

I watched this happen in real time. A project manager corrected the same deadline field seventeen times over two months because the AI kept extracting the wrong date from the weekly summaries. (The summaries said "Friday" but the actual deadline was "Wednesday" due to a client change that was never updated in the summaries.)

Without the flag, she would have corrected it seventeen times and been frustrated seventeen times. With the flag, she corrected it once and never saw the wrong date again. The AI did not get smarter — the system simply stopped showing its mistake.

The audit trail pattern

The full implementation preserves the original AI values. The code snippet above does not show this for brevity, but here is the pattern:

class StatusRow {
  // Current values (human-corrected if applicable)
  final String client;
  final String brand;
  // ... other fields

  // Provenance
  final bool isManuallyEdited;
  final StatusRow? originalAiValues;  // Preserved on first edit

  // When a human edits:
  StatusRow humanEdit(String field, String newValue) {
    return StatusRow(
      // ... copy all fields, updating the edited one
      isManuallyEdited: true,
      originalAiValues: this.originalAiValues ?? this,  // Store original on first edit
    );
  }
}

This means you can always answer the question: "What did the AI originally think?" The answer is never lost. It is just demoted from the main view.

Invariant 3: The ephemeral presence boundary

The code

class _RealTimeStatusSheetPageState extends State<RealTimeStatusSheetPage> {
  // Track users in the room — stored in memory only, NEVER persisted
  final Set<String> _activeUsers = {};

  void _handleWebSocketMessage(dynamic message) {
    // ...
    if (messageText.contains('USER_JOINED')) {
      String username = extractUsername(messageText);
      if (username.isNotEmpty && username != widget.mUsername) {
        setState(() => _activeUsers.add(username));
      }
    }
    else if (messageText.contains('USER_LEFT')) {
      String username = extractUsername(messageText);
      if (username.isNotEmpty) {
        setState(() => _activeUsers.remove(username));
      }
    }
  }

  @override
  void dispose() {
    _sendUserLeaveMessage();  // Announce departure
    _channel.sink.close();
    super.dispose();
  }
}

What it does

User presence — who is looking at the status sheet right now — is stored exclusively in client-side memory. It is sent via WebSocket messages but never written to the database. When a user disconnects, they disappear from _activeUsers. When they reconnect, they re-announce themselves and reappear.

Why it matters

Ontologies and data models have a tendency to capture everything, including ephemeral state. This creates two problems:

Storage grows with activity, not with domain complexity. If you persist presence, you generate a record every time someone opens a sheet and every time they close it. For a team of 50 people working 5 days a week, that is 500 presence events per week — all of which are useless the moment they are written.
Queries become cluttered with irrelevant state. If you store presence in the same table as settled facts (like StatusRow values), every query has to filter out "is this person still online?" nonsense.

The invariant is simple: *if the information becomes false the moment you look away, do not write it to disk. *

What belongs in the database vs. what belongs in memory

Information	Storage location	Why
Status row values (client, project, deadlines)	Database	Settled truth, persists across sessions
Who created a row	Database	Historical record, audit requirement
When a row was last edited	Database	Track freshness, conflict resolution
Who is looking at the sheet right now	Memory only	Ephemeral, changes by the second
Who edited which cell and when	Database	Audit trail, compliance
Cursor positions	Memory only	Transient, session-specific

The reconnection pattern

Because presence is not persisted, the system must handle reconnections gracefully. The pattern is simple:

void _connectWebSocket() {
  _channel = WebSocketChannel.connect(Uri.parse(wsUrl));

  _channel.stream.listen(
    (message) => _handleMessage(message),
    onDone: () {
      // Connection lost
      setState(() => _activeUsers.clear());  // Clear presence
      _reconnect();  // Try to reconnect after delay
    },
  );

  // After reconnection, re-announce presence
  _sendUserJoinMessage();
}

When the WebSocket reconnects (after network blip, laptop sleep, or server restart), the client re-announces its presence. The server does not remember who was online before — it does not need to. The current set of connected clients self-assembles from scratch.

This is simpler, more reliable, and infinitely easier to debug than a persisted presence system with heartbeat timeouts and stale-cleanup jobs.

How the invariants work together

Alone, each invariant is useful. Together, they form a coherent system.

Invariant	Problem it solves	What it enables
POST-once	AI overwrites human work	Stable baseline, auditable first draft
Override-is-sacred	Human corrections are temporary	Trust, psychological safety, immediate authority
Ephemeral presence	Storage bloat, stale state	Real-time awareness without persistence complexity

Here is how they compose in a real scenario:

Monday, 9:00 AM: First user opens Week 42 sheet. POST-once rule triggers AI generation. Sheet saved to database. isManuallyEdited = false on all rows.
Monday, 2:00 PM: Project manager opens sheet. Sees wrong deadline. Edits cell. Override-is-sacred rule flips isManuallyEdited = true for that row. Edit broadcasts to all connected users via WebSocket.
Tuesday, 10:00 AM: Another user opens sheet. POST-once rule prevents regeneration. Override-is-sacred rule ensures they see the corrected deadline, not the AI's original. Ephemeral presence adds them to _activeUsers (memory only).
Tuesday, 3:00 PM: Network blip. All users disconnect. Ephemeral presence clears _activeUsers. No data lost because presence was never the source of truth.
Wednesday, 9:00 AM: Users reconnect. Ephemeral presence re-announces them. The corrected deadline is still there because it was written to the database under Invariant 2.

The invariants create a system where the AI is useful but not dominant, human judgment is respected but not overburdened, and real-time awareness is present but not over-engineered.

What these invariants are NOT

Let me be clear about what I am not claiming.

This is not CRDT or OT. I am not solving concurrent editing conflicts. If two users edit the same cell simultaneously, last-write-wins. For our use case (project status sheets), this is acceptable. For a Google Docs clone, it is not.
This is not a general AI training loop. The isManuallyEdited flag is not yet fed back into the model. The AI does not learn from corrections. That is the next phase. Right now, the flag only protects human edits from being overwritten.
This is not production-scale presence. The ephemeral presence system works for dozens of concurrent users. For thousands, you would need a more sophisticated approach (Redis, Ably, Pusher). Our scale is smaller, so the simple solution wins.
This is not a replacement for proper auditing. The audit trail preserves original AI values, but there is no per-cell timestamp or username tracking in the simplified code shown here. The production version has those.

I am sharing what worked for us. Your mileage may vary. The principles generalize; the specific implementations will need adaptation to your stack and scale.

How to apply these invariants to your own systems

You do not need to copy the code. You need to copy the thinking.

For the POST-once rule

Ask yourself: what operation am I performing repeatedly that should only happen once per domain entity?

Common candidates:

AI generation (obviously)
Data enrichment from external APIs
Summarization or aggregation
Notification sending ("first time someone views X, send an alert")
Expensive computation that does not change between views

The pattern is always the same: check before you compute. Store the result. Serve the stored result on subsequent requests. The storage can be a database, a cache, or even a file. The key is the if not exists check.

For the override-is-sacred rule

Ask yourself: what human action should the system never override?

Common candidates:

Manual corrections to AI output
User preferences and settings
Explicit "mark as reviewed" actions
Human-entered data in a system that also ingests from external sources

The pattern: add a provenance flag. When the human acts, flip the flag. On subsequent automated updates, check the flag. If it is true, skip that field or that entity. Store the original automated value elsewhere if needed for audit.

For the ephemeral presence boundary

Ask yourself: what information is only true at this exact moment?

Common candidates:

Who is online right now
Cursor positions
Typing indicators
Scroll positions
Temporary selections or highlights

The pattern: keep it in memory. Send it via real-time channel (WebSocket, SSE, MQTT). Never write it to a persistent store. On reconnection, re-establish from scratch. Do not try to remember the past.

The test of time

That code has been running since April 27, 2026. The invariants have not changed.

Not because I am stubborn — because they have not needed to change.

The POST-once rule survived a hundred-page-refresh stress test where we simulated 50 users opening the same week sheet simultaneously. One API call. One database write. Perfect consistency.
The override-is-sacred rule survived a project manager correcting the same field seventeen times across two months. The AI was very wrong about that deadline. The flag never failed.
The ephemeral presence boundary survived a WebSocket server restart with zero data corruption. Presence reset. All other data intact. No cleanup jobs needed.

I wrote these rules in 42 minutes on a Tuesday morning. They have saved hundreds of hours since. Not in code complexity — in trust. The team trusts the sheet. The project managers trust the data. The stakeholders trust the status.

That is the real metric. Not API latency. Not database size. Trust.

The code comment

If you look at the original file, there is a comment at the top:

//worked well 27th April 2026 - 08:30 AM - 09:12 AM

That is not a boast. It is a reminder.

Good ideas arrive in focused windows. The trick is to recognize them and write them down as invariants before they slip away. Features can be added later. Invariants are structural. Get them right once, and the system becomes something you can build on for years.

That morning, I stopped adding features. I wrote three rules. I have not regretted it since.

Kiprono Ngetich builds AI-assisted collaboration tools. He thinks too much about data provenance and WebSocket protocols.

The Living Ontology

Rono — Mon, 01 Jun 2026 16:02:46 +0000

A pattern for AI-generated, human-verified project intelligence in real time

Kiprono Ngetich

Ontology is the difference between data and intelligence. A static schema is a prison. A living ontology one that evolves, respects human override, and traces provenance — is the only way to make AI useful in operational environments.

This document describes an ontological pattern built for project status intelligence. But the pattern generalizes.

Any domain where:

unstructured human communication contains structured intent

AI can propose, but humans must verify

real-time collaboration is non-negotiable

auditability is a compliance requirement

...can use this pattern.

The core tension

Every operational ontology faces a fundamental tension:

The AI can extract structure from chaos, but the AI is often wrong. The human knows the truth, but the human won't maintain the ontology.

Traditional solutions fail in one of two directions:

AI-first: The ontology is generated automatically. Humans are viewers. The system drifts. Trust erodes.

Human-first: The ontology is manually maintained. AI is ignored. The system is accurate but stale. Humans burn out.

A third way exists.

The pattern: provenance as the primary axis
Most ontologies organize around what things are. This one organizes around how we know what we know.

Every entity carries a provenance flag: isManuallyEdited.

This single boolean transforms the ontology from a static classification into a dynamic trust layer.

The ontology in minimal form:

text
WeekData
  - contains → Task (AI-extracted)
  - generates → StatusRow (human-editable)
      - has flag → isManuallyEdited (boolean)
      - has lineage → sourceTask (reference)

The critical insight: AI-generated and human-verified are not separate entity types. They are the same entity type with different provenance states.

This means:

The query layer can filter by provenance (show me only human-verified rows)

The AI layer can learn from provenance (rows where isManuallyEdited=true are training data)

The compliance layer can audit provenance (every field has a traceable source: AI or human)

The three ontological invariants
Invariant 1: The POST-once constraint
An AI generation occurs at most once per unique domain entity (in this case, per week).

Why this matters for ontology: Most systems treat AI as an on-demand service. Every view triggers generation. This makes provenance meaningless — there is no "original" AI state to compare against.

This invariant creates a fixed point. The first AI output is frozen as the baseline. All subsequent human edits are deltas against that baseline.

This is the difference between streaming intelligence (ephemeral, unrepeatable) and settled intelligence (auditable, comparable, learnable).

Invariant 2: The override-is-sacred rule
When isManuallyEdited transitions from false to true, the system records the original AI value but never surfaces it again.

Why this matters: In most AI systems, human feedback is treated as a training signal — something that eventually improves the model. In operational environments, that latency is unacceptable. The human correction must be immediately authoritative.

The ontology enforces this at the storage layer, not just the application layer. Even if the AI reruns, it cannot overwrite a field where isManuallyEdited is true.

Invariant 3:** The ephemeral presence boundary**
User presence — who is looking at what right now — is explicitly excluded from persistence.

Why this matters: Ontologies have a tendency to capture everything, including ephemeral state. This creates two problems:

Storage grows with activity, not with domain complexity

Queries become cluttered with irrelevant "current state"

By declaring presence as out-of-ontology, it is forced into a separate channel (WebSocket presence messages). The ontology remains focused on settled truth.

What this enables
For AI operations
The provenance flag creates a natural training loop:

AI generates initial state

Human corrects specific fields

System compares original vs. edited

Corrections become labeled training data

The ontology preserves the alignment between input (raw message) and corrected output (edited row). This is significantly more valuable than generic human feedback — the model can learn why it was wrong by re-examining the original message in light of the correction.

For human operations
Users never see the AI's mistakes. They see the corrected truth. But they can see the AI's original output if they choose — the audit trail is there, just behind a toggle.

This creates psychological safety. The AI is allowed to be wrong. No one is blamed for a bad extraction. The system simply learns and improves.

For compliance
Every field has a provenance chain:

If isManuallyEdited = false, the value came from the AI, which was operating on the rawMessage (stored, immutable, timestamped)

If isManuallyEdited = true, the value came from a specific agent (username) at a specific time, with the original AI value retained

This is sufficient for regulated environments where documentation must meet evidentiary standards.

Comparison with conventional approaches
Concern Conventional ontology This pattern

AI output   Ephemeral, regenerated on each view Fixed point, auditable baseline
Human correction    Overwrites AI output, no trace  Preserves original, flags override
Training data   Separate collection pipeline    Natural byproduct of use
Real-time sync  Out of scope or bolted on   First-class via separate channel
Storage scaling O(views × entities)    O(weeks × projects)

The generalization
This pattern applies to any domain where:

Unstructured inputs (emails, transcripts, logs, messages) contain latent structure

AI can propose that structure with acceptable accuracy (70-90%)

Humans must verify corrections with high confidence

Real-time visibility is required across multiple actors

Auditability is a compliance requirement

Example domains:

Intelligence analysis: AI extracts entities and relationships from raw intelligence; analysts correct and enrich; the ontology tracks provenance

Incident response: AI proposes timeline and impact from alert streams; responders correct in real time; command sees live status

Supply chain visibility: AI extracts shipment status from carrier messages; logistics teams correct exceptions; stakeholders see authoritative truth

Clinical trials: AI extracts patient status from site reports; monitors verify; regulators audit the provenance chain

In every case, the core pattern is the same:

AI proposes. Human disposes. The ontology remembers the difference.

The open question
This ontology is one-way: AI → human → (frozen). There is no closed loop where human corrections flow back into the AI's world model for future extractions, beyond being training data.

The instinct is that the solution lives in the ontology itself: treat isManuallyEdited as a signal that the original extraction should be re-weighted in the model's latent space. But that remains unbuilt.

Closing
A small ontology for a small problem (project status reporting). But the pattern — provenance as primary axis, POST-once generation, sacred human override, ephemeral presence separation — feels general.

It solves the core tension of AI in operational environments: the machine proposes, the human disposes, and the system never confuses the two.

That is not just a data model. That is a trust model.

Kiprono Ngetich

Appendix: Ontology specification (condensed)
Entities:

Entity  Key fields  Provenance
WeekData    weekNumber, year, rawMessage    Immutable after creation
StatusRow   9 content fields, isManuallyEdited, sourceTask  Flag toggles once (false→true)
Agent   agentId, agentType (HUMAN/AI/SYSTEM)    Immutable
EditOperation   oldValue, newValue, timestamp, username Immutable, append-only
Invariants:

(weekNumber, year) unique

AI generation ≤1 per (weekNumber, year)

isManuallyEdited = true → AI never overwrites

StatusSheet.rows indices contiguous

presentIn relationships never persisted

How We Cut Status Reporting Overhead to Near Zero

Rono — Mon, 01 Jun 2026 15:03:53 +0000

A three-week build, three technologies, and one rule we refuse to break

By Kiprono Ngetich

The before

Before building Daraja Workspace, our project managers spent an average of 6-8 hours per week on status reporting.

That's not an exaggeration we tracked it.

The breakdown looked like this:

2 hours chasing updates from team members

2 hours reconciling conflicting information

2 hours formatting reports for different stakeholders

2 hours in status meetings discussing what was already outdated

According to the Project Management Institute, organizations waste an average of 11.4% of their investment due to poor project performance — much of which stems from inadequate communication and status visibility.

We were living that statistic.

The insight

One day, I looked at the raw material our teams were already producing: weekly summary messages, task comments, deadline discussions, Slack threads.

Every single one contained structured project intelligence project names, responsible parties, deadlines, blockers, next steps. It was just trapped in unstructured text, invisible to anyone who needed to report on it.

The insight was simple: the best status report is one that writes itself.

We stopped asking "how do we make people update status sheets?" and started asking "how do we extract status from work people already do?"

The build

We built the first version in three weeks, using three core technologies:

Week    Focus   Technology
1   Real-time collaboration layer   WebSockets + optimistic UI updates
2   AI extraction pipeline  Cohere Command-A + prompt engineering
3   UI + fallback handling  Conditional persistence (POST-once model)

The POST-once model was the key architectural insight: the system calls the AI at most once per week, regardless of how many people view the status sheet. Storage grows by one record per week per project. No redundant API calls. No spiraling costs.

The result

After six weeks of internal use:

Status reporting time: 6-8 hours per week → effectively zero (the sheet maintains itself)

Information freshness: Updated daily via AI extraction + real-time human edits

Team adoption: 100% of active projects migrated

Server cost: One API call per project per week (regardless of view count)

But the numbers don't capture the real change.

The Thursday afternoon panic is gone. Project managers don't chase updates anymore — they read them. They clarify. They unblock. The time they used to spend formatting tables now goes to actual project management.

The rule we refuse to break
Throughout the build, we held one line:

AI writes the first draft. Humans own the truth.

Every AI-generated status row carries a flag — isManuallyEdited — that distinguishes model output from human input. When a project manager corrects a deadline or adds a comment, that change propagates in real time and never gets overwritten.

We don't let the AI learn from corrections in a way that overrides human judgment. The model assists. It does not decide.

What's next
The current system is one-way: AI → humans. Human corrections don't yet flow back to improve the AI's understanding.

We're closing that gap. The roadmap includes:

Two-way feedback loop — AI learns from human edits over time

Export pipeline — one-click PDF and XLSX exports

Cross-week analytics — trend visualization across multiple weeks

Cell audit trails — per-change history with username and timestamp

The broader takeaway
We built this because our Thursdays were broken.

If yours are too, you don't need better templates or stricter deadlines. You need a different architecture. One where status visibility is a side effect of working — not another job.

The information you need is already there. It's in your Slack, your email, your weekly updates, your task comments.

You just need to extract it.

Kiprono Ngetich builds AI-assisted collaboration tools.

Building Real-Time Collaborative Status Sheets with WebSockets and Cohere Command-A

Rono — Mon, 01 Jun 2026 14:38:19 +0000

Conditional persistence, optimistic updates, and why we only call the AI once per week

By Kiprono Ngetich

We wanted live collaboration. We wanted AI-generated status extraction. And we wanted server costs that didn't explode when 50 people opened the same sheet.

The standard approach store everything, recalculate on every view was a non-starter.

So we built something different: a POST-once persistence model where the REST API is a write-once initialization store and WebSockets handle everything else.

Here's how it works, why we chose Cohere Command-A for extraction, and what broke along the way.

1. The core problem

Status sheets die on write.

Traditional project management tools (Jira, Asana, Monday.com) require disciplined data entry from contributors who are primarily focused on delivery. The result is a system that is accurate only when it is actively maintained — creating a secondary task burden on the people least likely to have capacity for it.

Our goal was to flip this: make the status sheet a byproduct of normal work, not an additional job.

2. The WeekData abstraction

The central data structure in our system is the WeekData object, which encapsulates all intelligence associated with a discrete working week.

A WeekData instance carries:

weekNumber (ISO week identifier)

quarter (fiscal quarter)

tasks (ordered list of WeekTask objects)

rawMessage (the unprocessed source text for auditability)

summaryText (AI-extracted executive summary)

The key design choice: WeekData is constructed from a single raw message. This means the platform can reconstruct full week intelligence from one stored message — making the raw WebSocket stream the authoritative source of record.

3. The POST-once model

This is the most important architectural decision.

Before invoking the AI model, the system performs a GET lookup against the persistence API. Generation — and the subsequent POST to persist results — occurs only when the lookup returns no existing data for the current week.

The implications:

Server storage grows at a rate of at most one record per week, regardless of how many users open the status sheet

The AI model is invoked at most once per week, regardless of page refresh frequency

All subsequent changes are propagated exclusively via WebSocket, with no REST API writes

The conditional persistence model sounds obvious in retrospect, but it wasn't obvious at the start. Our first design stored every user's view state separately. For a team of 50 people looking at the same week's status sheet, we were storing 50 identical copies of the same data.

The current design cut storage costs by two orders of magnitude.

Lesson: Cache at the domain level, not the view level.

text
# Generation trigger logic (simplified)
async def get_or_generate_status_sheet(week_id):
    existing = await db.find(f"week_{week_id}")
    if existing:
        return existing

    raw_messages = await fetch_workspace_messages(week_id)
    ai_output = await cohere_generate(raw_messages)
    status_rows = parse_markdown_table(ai_output)

    if not status_rows:
        status_rows = create_fallback_rows(raw_messages)

    await db.post(f"week_{week_id}", status_rows)
    return status_rows

4. AI pipeline: prompt engineering for reliability

We use Cohere's Command-A model (command-a-03-2025), selected for its strong instruction-following characteristics and structured output reliability.

The generation prompt is structured in two parts:

System prompt: Defines the output schema (a markdown table with exactly nine columns) and quality constraints (10-20 word activity descriptions, specific comment formats). The model is explicitly prohibited from adding explanatory prose outside the table structure.

User prompt: Constructed from the WeekData's task list, serialized into structured text that surfaces each task's title, brief, deadline, responsible party, and full detail text.

The model's markdown output is parsed line-by-line with pipe-delimited split and header detection. Rows failing the 9-column minimum are silently dropped.

If the parsed output yields zero rows — due to model refusal, formatting deviation, or network failure — the system falls back to constructing rows directly from the WeekTask list without AI enrichment. This graceful degradation ensures status sheets are always available.

5. WebSocket protocol: five message types

The collaboration protocol is built on three principles:

Operation-based messaging (transmitting what changed, not the full state)

Human-readable formats (pipe-delimited strings that can be logged without a parser)

Optimistic local application (changes apply locally before server confirmation)

The five message types:

Message Type    Format
CELL_EDIT   CELL_EDIT|rowIndex|column|oldValue|newValue|username
BATCH_UPDATE    BATCH_UPDATE|rowIndex|column|value|username
ROW_DELETE  ROW_DELETE|rowIndex|username
ROW_ADD ROW_ADD|{rowJson}|username
USER_JOINED USER_JOINED|username
USER_LEFT   USER_LEFT|username

CELL_EDIT carries both old and new values to enable future conflict detection and undo functionality. ROW_ADD carries a JSON-serialized StatusRow to ensure type fidelity when transmitting multi-field objects.

User presence is maintained client-side as an ephemeral set — presence is a live indicator, not a historical record. Reconnecting clients re-announce themselves, ensuring the presence set self-heals after disconnections.

6. What broke (honest failures)

Three things broke in production:

Model refusal: Occasionally, the model would output "I cannot complete this request" instead of a table. Our fallback to _createFallbackRows() handled this, but we added retry logic with a modified prompt (removing date references) which reduced refusal rates by ~80%.

Formatting drift: The model sometimes added extra columns or merged cells. We made the parser tolerant — it drops extra columns and treats missing columns as empty strings rather than failing the entire row.

Reconnection storms: When the WebSocket server restarted, all clients reconnected simultaneously and re-requested the full status sheet. We added jittered backoff (3s + random 0-2s) to spread the load.

7. What we'd do differently

The biggest missing piece is the two-way feedback loop.

Right now, human edits to the status sheet don't flow back to the AI's understanding of project state. If a project manager corrects a deadline, the AI doesn't learn that it was wrong.

We're building toward this. The isManuallyEdited flag on each StatusRow is the foundation — it tells us which fields represent human judgment vs. AI extraction. The next step is feeding corrected rows back into the prompt context for future weeks.

Other improvements on the roadmap:

Operational transforms or CRDTs for concurrent cell edits

Per-cell audit trails (username + timestamp)

Export to PDF and XLSX

Closing
The system isn't perfect. The AI misses context sometimes. The WebSocket protocol doesn't yet handle concurrent cell edits with operational transforms.

But the core pattern — conditional persistence, operation-based messaging, graceful AI degradation — has proven reliable across months of internal use.

If you're building a collaborative, AI-assisted document tool, steal the POST-once pattern. It's the difference between a demo and a deployment.

Kiprono Ngetich builds software at the intersection of AI and collaboration.

How this Game is won

Rono — Wed, 25 Mar 2026 20:49:40 +0000

A playbook from the greats

Most people think this game is about talent...it’s not, it’s about understanding how things actually move.

Let’s not dress it up.

This is a game.

Not a fair one.
Not a clean one.
But a game you can learn.

So forget the noise.

Let’s break it down.

First thing:

Nothing you see working today started from a good position.

Not the banks.
Not the deals.
Not the people you think had an advantage.

It started the same way every time:

Pressure.

Look at Mwai Kibaki.

He’s already inside the system. Smart. Respected.

Then he loses.

Twice.

That usually ends careers.

He doesn’t react the way people expect.

He doesn’t get louder.

He steps back.

Watches.

Waits.

Lesson one:
When you can’t force the outcome, control your position.

Timing beats effort when the system is bigger than you.

He understood that.

So when the window opened—he didn’t scramble.

He stepped in.

Now James Mwangi and Peter Munga.

They walk into something broken.

Not struggling—broken.

No capital. No trust. No momentum.

Everyone says: shut it down.

They ask a different question:

What’s actually missing?

Not money.

Access.

So they remove friction.

No minimum balance.
No intimidation.
Just access.

Lesson two:
Find the constraint. Remove it. Scale what opens up.

They didn’t build a better bank.

They built a bigger door.

Now Chris Kirubi.

He builds something real.

Then it collapses.

Not because he didn’t try.

Because he didn’t control the system around it.

Distribution blocked. Doors closed.

That’s when it clicks.

Lesson three:
If you don’t control movement, you don’t control outcome.

Product is not power.

Access is.

He adjusts.

Everything changes after that.

Then Gideon Muriuki.

He inherits failure.

Mess everywhere.

Most people try to grow out of problems.

He doesn’t.

He slows down.

Fixes structure.
Fixes people.
Fixes discipline.

Only then does he scale.

Lesson four:
Speed without structure kills you. Fix first. Then move fast.

Now Jimmy Wanjigi.

Different play.

He doesn’t start with assets.

He starts with insight:

The biggest opportunities sit behind government.

So he doesn’t build blindly.

He connects intentionally.

Lesson five:
In this game, access multiplies everything.

Ignore that, and you stay small.

Understand it, and things move faster.

Now zoom out.

Different people.

Different styles.

Same game.

Here’s the pattern:

1. Go where others aren’t paying attention
That’s where the opportunity hides.

2. Stay longer than feels comfortable
Most people leave right before things shift.

3. Change angle, not just effort
Pushing harder isn’t always the answer.

Positioning is.

4. Understand power, not just product
Execution matters.
But control decides scale.

5. Build structure before growth
A weak base doesn’t survive success.

6. Treat relationships as infrastructure
Not optional. Not extra.

Core.

7. Use failure as feedback
Not identity. Not a stopping point.

Just data.

That’s the playbook.

No hype.

No shortcuts.

Now the part people avoid:

This system isn’t designed to be fair.

It rewards awareness.

It rewards timing.

It rewards people who understand how things actually move—not how they should move.

So you decide.

Sit outside the system and complain.

Or step inside it and learn the rules.

And if you’re in the middle right now—

Things not working.
Plans not clicking.
Nothing moving the way you expected—

Good.

That’s where this starts.

You’re not late.

You’re early in the real process.

So don’t rush.

Don’t panic.

Just get sharper.

Where’s the real constraint?
Who controls movement?
What position are you building?
And are you staying long enough to catch the shift?

Now let’s go one level deeper.

Because this is where most people break.

The Rules You Don’t Get Taught

No one is coming to save you
Not systems.
Not luck.
Not perfect timing.

You can benefit from them.

But you can’t depend on them.

Build like it’s on you.

Think inward before outward
Blame is easy.

Control is harder.

Focus on what moves with you:

Skill.
Time.
Execution.

That’s your leverage.

Be selective with people
Some people drain you slowly.

Others sharpen you fast.

Choose carefully.

Distance is not disrespect. It’s strategy.

You will need a level of selfishness
You won’t grow if you’re constantly adjusting yourself to fit others.

There are moments you choose your path over approval.

That’s part of the cost.

Focus beats everything
Discipline gets you started.

Obsession keeps you going.

The people who win stay longer on the same problem.

They go deeper.

Results change how people treat you
Before results, you explain yourself.

After results, people explain you.

So build. Don’t argue.

If you don’t create value, your voice stays small
The world listens to output.

Not intention.

Not talk.

Become useful. Then visible.

Courage is staying when it’s uncomfortable
Fear will be there.

Doubt will be there.

That’s not the signal to leave.

It’s the signal you’re in the real part.

Use what you have
Your environment is not just a limitation.

It’s also an angle.

Find it. Use it.

Kill the scarcity mindset
If you think opportunities are rare, you hesitate.

If you hesitate, you miss them.

Train yourself to see more. Move faster.

Drop the anchors
Bad habits.
Wrong environments.
Time-wasting loops.

You don’t rise while holding everything.

Let things go.

That’s the layer most people avoid.

Not because it’s complex.

Because it demands change.

You don’t need perfect conditions.

You need clarity.

You need focus.

And you need time in the game.

That’s how this game is won.

When Ai runs your Workflow

Rono — Tue, 24 Feb 2026 18:03:41 +0000

What happens when your workspace thinks with you?
"One of the ways that I believe people express their appreciation to the rest of humanity is to make something wonderful and put it out there." — Steve Jobs
We built Daraja Workspace because we kept running into the same wall — and we suspected every team did too.
The brief is somewhere in the chat. The feedback is buried three threads down. The decision that took two hours to reach last Tuesday? Nobody can find it. Meanwhile the deadline is tomorrow, the client is waiting, and half the team is spending more time looking for context than actually doing the work. It's not a people problem. It's a workflow problem. And most tools aren't built to solve it — they're built to store things, not understand them.
That's the gap Daraja Workspace was built to close.

A workspace that keeps up with how teams actually work
Real teams don't work in neat, linear steps. A brief comes in, someone has a question, a thread goes sideways, a new idea surfaces, the scope shifts. By the time you're ready to execute, the important information is scattered across dozens of messages and nobody has a clean picture of where things stand.
Daraja Workspace is built around an AI — DarajaAI — that lives inside the workspace and pays attention to all of it. Not as a chatbot you have to prompt, but as a thinking layer running quietly underneath the work. When a new brief lands, it connects it to everything relevant that came before: the last campaign for that client, the feedback that never made it into the brief, the resource conversation from two weeks ago that everyone half-forgot. It keeps the full picture in view so your team doesn't have to.
When a deadline is approaching, it notices. When feedback in a long thread is contradicting itself, it surfaces the conflict and summarizes what was actually said. When a team member joins a project late, they don't have to scroll through weeks of chat to get up to speed — the workspace can bring them current in minutes.
None of this requires anyone to learn a new system or change how they naturally communicate. The team keeps working the way they work. The workspace gets smarter as they do.

Built for the people doing the actual work
One thing we were deliberate about: Daraja Workspace had to work for everyone on the team, not just the people who already have everything in their heads.
For a junior coming onto a project, that means getting context explained clearly — what the client expects, what's been tried before, what the team's shorthand actually means. For a senior managing multiple projects, it means being able to get a clean cross-project overview without having to dig for it. For the founder or team lead who steps away for a few hours, it means the workspace holds the thread so nothing important drops while they're gone.
The point isn't to automate the work. The creative instinct, the client relationship, the judgment call that turns a good campaign into a great one — those are human, and they should stay that way. What Daraja Workspace handles is the connective tissue: the tracking, the remembering, the surfacing of what matters right now. The mechanics that eat up time and mental energy without adding anything to the actual output.
When that friction goes away, something shifts. The team's attention goes back to the work itself. Conversations get sharper. Decisions get made faster because everyone already has the context they need. The energy that used to go into managing chaos goes into building something worth being proud of.

What we've learned building this
We've tested Daraja Workspace with real teams, on real briefs, under real deadline pressure. What surprised us wasn't how much the AI could do — it was how quickly teams stopped thinking of it as a tool and started treating it as part of the team.
Not because it's trying to be human. But because it's genuinely useful in the moments that matter: when a thread gets too long, when the context is getting lost, when someone new needs to get up to speed fast, when the team needs to move and nobody has time to call a meeting.
We've also learned that the best version of this isn't the AI doing more — it's the AI knowing when to step back. The workspace should feel like a calm, organized colleague, not an interruption. So we've been careful about what it surfaces and when, making sure it adds signal rather than noise.

Why we built this
There's a version of work that most teams glimpse occasionally — usually during the best projects, with the best teams — where everything just flows. Everyone knows what they're doing, information moves freely, decisions happen quickly, and the energy stays high from start to finish. It doesn't feel like chaos management. It feels like building something.
That version of work shouldn't be rare. It shouldn't depend on having the right people in the same room at the same time or a team lead who holds everything in their head. It should be the default.
Daraja Workspace is our attempt to make it the default. To take the things that make the best teams work well — shared context, clear communication, a sense of where everything stands — and build them into the workspace itself, so they don't disappear when the project gets complicated or the team gets busy.
We put it out there because we believe work can feel better than it usually does. And we think the right workspace is a big part of how you get there.

Daraja Workspace is built for teams that care about how they work, not just what they produce. If that's you, we'd love to show you what it looks like in practice.

Check out my app

Rono — Fri, 26 Dec 2025 07:20:41 +0000

Hey guys, this is the shortest article I'll probably ever write...

I've been juggling a crazy schedule lately—work, life, school, endless meetings—and got fed up with clunky calendars and scattered notes.

So I built Rucks an app that uses AI to smartly schedule your chaos, suggest optimal times, and make collaboration effortless.

It's simple, powerful, and actually helpful.

Check it out, try it free, and let me know what you think. Feedback welcome—I'm iterating fast!

Thanks for reading (all 100 words of it). 🚀

The unfair advantage your classmates already have

Rono — Sun, 07 Dec 2025 20:51:11 +0000

I’m not launching anything today. I just want every student in the US, South Africa ,Europe and Kenya who’s currently panicking about finals to know this exists.

Real stories from the last 48 hours (names removed because they begged me 😂):

→ Final-year BCom student at UCT dumped 400+ pages of Econ 301 + 302 slides + tutorial answers into Rucks this morning. Typed: “Generate all my macroeconomics questions and answers for revision.” 30 seconds later he had 127 exam-style questions with full model answers pulled straight from his own notes + past papers he uploaded last year. He’s revising right now instead of crying.

→ Riara University dude in Nairobi facing Microeconomics CAT tomorrow: “Bro just type ‘give me 50 multiple-choice questions on elasticity from my notes’” → Rucks scanned everything he ever saved, made the MCQs, gave the answers + page references. He sent me a voice note screaming.

→ UCLA kid grinding for Econ 101 final next week: Uploaded every lecture recording since September. Typed “create a 3-hour past-paper style exam with solutions from everything we’ve covered.” Rucks delivered a 25-question paper + marking scheme in under a minute.

This isn’t some future AI fantasy. This is live right now at rucks.cc and it costs $1.50 a week.

How it actually works for finals week:

You throw in everything — PDFs, lecture recordings, WhatsApp voice notes from group study, photos of whiteboard, past papers, whatever.

When you’re cooked and have zero time left, you just say stuff like:

“Generate 100 KCSE-level Biology questions from my Form 3 & 4 notes” “Make me a full Principles of Accounting mock exam with answers” “Give me every single definition + example we ever learned in Development Economics” “Turn my International Finance notes into Anki cards”

Rucks reads ONLY your stuff (100% private, nothing sent to OpenAI) and spits out perfect revision material instantly.

$1.50 a week. Cancel anytime. Works offline during loadshedding or when campus Wi-Fi dies.

If you’re in the USA, South Africa, Kenya, or anywhere else on Earth and you have finals coming, stop suffering.

Go to rucks.cc → sign up in 9 seconds → throw your notes in → type “generate all my [subject] questions and answers” and thank me later.

No upsells. No “launch discount.” Just the tool that’s already saving thousands of students right now.

Drop your country flag + the subject you’re currently scared of below. I’ll personally send the top 10 most panicked people a free month.

You’ve got this. Your notes have you covered. Rucks just makes them talk back.

rucks.cc

(like so someone who actually needs this sees it before their exam tomorrow ❤️)

10 Productivity Hacks to Boost Your Day with Rucks

Rono — Sun, 16 Nov 2025 07:31:05 +0000

10 Productivity Hacks to Boost Your Day with Rucks.cc

Are you tired of feeling overwhelmed and struggling to stay on top of your tasks? Do you wish there was a way to maximize your productivity and achieve a better work-life balance? Look no further than Rucks.cc, the AI-powered schedule and task manager that's here to revolutionize your daily routine.

In this article, we'll share 10 productivity hacks to boost your day with Rucks.cc. From prioritizing tasks with AI to reviewing and adjusting your schedule, these tips will help you get the most out of your day.

The Productivity Hacks

1. Prioritize with AI

Let Rucks.cc's AI-powered scheduling feature organize your tasks and schedule. By prioritizing your most important tasks, you'll ensure that you're focusing on what matters most.

Pro tip: Tag tasks with high, medium, or low — Rucks AI pushes deadlines automatically.

2. Task Bundling

Group similar tasks together to maximize your time. Whether it's checking emails or making phone calls, task bundling helps you stay focused and efficient.

Example: Bundle all admin tasks into a 30-minute "Power Hour" every morning.

3. Time Blocking

Schedule fixed, uninterrupted blocks of time for important tasks. This technique helps you stay focused and avoid distractions.

Rucks feature: Drag-and-drop blocks in desktop mode — perfect for deep work on laptops.

4. Break it Down

Divide big tasks into smaller, manageable chunks. By breaking down complex tasks, you'll make progress without feeling overwhelmed.

Rucks hack: Use the "Split Task" button — turns "Write 20-page report" into 5 micro-tasks.

5. Use the Eisenhower Matrix

Prioritize tasks based on urgency and importance. This decision-making tool helps you prioritize tasks into four quadrants:

Urgent & Important
Important but Not Urgent
Urgent but Not Important
Not Urgent or Important Rucks integration: Label tasks with quadrant tags — AI auto-sorts your day.

6. Schedule Self-Care

Make time for activities that recharge you. Whether it's exercise, meditation, or spending time with loved ones, self-care is essential for productivity.

Rucks reminder: Set "Recharge Block" — non-negotiable time that teammates can't override.

7. Avoid Multitasking

Focus on one task at a time for maximum productivity. Multitasking can decrease productivity and increase stress.

Rucks focus mode: Enable "Do Not Disturb" — hides notifications until your block ends.

8. Set Realistic Goals

Be realistic about what you can achieve in a day. Set achievable goals and prioritize your tasks accordingly.

Rucks AI: Suggests daily limits based on your past performance (e.g., "Max 6 high-energy tasks").

9. Use Reminders

Set reminders to stay on track and meet deadlines. Rucks.cc's reminder feature ensures that you never miss a deadline or important task.

Bonus: Get WhatsApp alerts at 7 AM — because email is for old people.

10. Review and Adjust

Regularly review your schedule and adjust as needed. By regularly reviewing your progress, you'll identify areas for improvement and optimize your productivity.

Rucks dashboard: Sunday 8 PM → 60-second review with "What Went Well / What to Fix".

Final Thoughts

By implementing these 10 productivity hacks with Rucks.cc, you'll be able to maximize your time and energy, prioritize tasks with ease, and achieve a better work-life balance.

Kenyan students, freelancers, and hustlers — this is your unfair advantage.

Get Started

Website: https://rucks.cc
Sign up in 3 seconds with Google
First 100 users get PRO free till Jan 2026

"Rucks turned my chaotic semester into a system. Group projects? Done in 48hrs." – Mercy, UoN

Tag a friend who needs this.

Let’s make 2026 the year of done > perfect.

productivity #ruckscc #softwaredevelopment #ai

Posted on November 16, 2025

Why the Economy Loves and Hates Lazy People

Rono — Fri, 08 Aug 2025 19:29:34 +0000

Laziness runs the world.
Not ambition, not innovation, not grit laziness. It’s the reason we invented the wheel, elevators, cars, computers, and now AI that can write your emails for you. Humans have always been looking for ways to do less while getting more.
And the modern economy? It’s built on that instinct. Everything around you from the coffee you ordered this morning to the phone in your pocket exists to make your life easier. Laziness isn’t just tolerated. It’s monetized.

But here’s the catch: while laziness makes the economy rich, it also threatens to kill it. This is why the economy loves you for being lazy… and hates you for the exact same reason.

Laziness = Profit
The economy thrives when people outsource their effort. Consumerism is basically the commercialization of “I don’t feel like it.”
Look around:

Amazon isn’t selling products; it’s selling not having to leave your house.
Netflix isn’t selling movies; it’s selling entertainment without effort.
Uber Eats isn’t selling food; it’s selling the 45 minutes you don’t spend cooking.
If you’re the type who will pay extra to save time or avoid hassle, you’re exactly who the market is designed for. You’re the dream customer quick to spend, loyal to convenience, and addicted to comfort.
This is why laziness is profitable. People who don’t want to build or make something themselves are willing to pay for it, and that money fuels entire industries.

The Hard Truth About Convenience
Here’s what we tend to forget: every convenience you enjoy is built on someone else’s hard work.
That app you open before bed? A developer spent months coding and debugging it.
That perfect cup of coffee? It came from a farmer who harvested beans, a roaster who perfected the flavor, and a delivery driver who got it to your door.
That next-day delivery from Amazon? Warehouses full of staff worked non-stop to make it happen.

The “lazy economy” sits on the shoulders of the “hard-working economy.” Without the builders, innovators, and risk-takers, there’s nothing to consume.

Why the Economy Hates Laziness Too
Here’s the flip side laziness on the supply side is poison.
If too many people stop creating, innovating, and putting in hard work, the pipeline of goods and services dries up. You can’t sell convenience if there’s nothing to make life convenient in the first place.

History proves this. Civilizations that became too comfortable, too dependent on the wealth of previous generations, eventually crumbled. When everyone’s consuming and no one’s creating, shortages hit, prices spike, and innovation stalls.

And in the long game, that kills economic growth.

The Balancing Act That Keeps the System Alive
The economy works because there’s a balance between:
Builders people putting in the grind to create new value.
Consumers people spending money to enjoy that value.
If the balance tips too far in either direction, the system breaks.
All builders, no consumers? Production outpaces demand.
All consumers, no builders? There’s nothing left to sell.
The modern economy survives by keeping just enough hard-working creators to feed just enough lazy consumers.
The New Face of Laziness
In 2025, laziness doesn’t always look like lying on the couch all day. Sometimes it’s hidden behind technology. AI, automation, and delivery services make us feel productive while we’re actually avoiding effort.
Yes, tools like ChatGPT or the Mac M4 make life faster and more efficient but they also remove the struggle that once built skills and discipline. The danger isn’t using these tools; it’s letting them do all the thinking for us.

We’re entering a stage where laziness is dressed up as efficiency. And the economy will keep selling it back to us until there aren’t enough real builders left to keep the cycle going.

Where You Stand
Here’s the uncomfortable question: are you a builder or just a consumer?
If you’re building, you’re on the side that keeps the economy alive. You’re creating value, solving problems, and giving people something to pay for.
If you’re just consuming, you’re living off the effort of builders and the economy loves you for your money but hates you for not contributing to its future.

The truth is, most of us are a mix of both. We work hard in some areas, but happily hand over our money to avoid effort in others. The problem comes when the balance in your own life tilts too far toward consumption.

Final Word
Laziness fuels spending. Hard work fuels creation. The economy needs both, but it will always respect the builders more even if it doesn’t say it out loud.
The economy doesn’t care about your feelings. It only cares whether you’re making it money or making it possible.

Why I'm Building a Custom DNS Responder for Embedded Devices

Rono — Sun, 20 Jul 2025 16:11:57 +0000

When working with MicroPython on small microcontrollers like the ESP8266 or ESP32, you quickly hit a wall if you try to do anything with DNS—especially mDNS (multicast DNS). I found out the hard way while building a Bluetooth beacon-powered app that needed to talk to a local server on the same network.

The Problem with micropython-mdns

There’s a package on PyPI called micropython-mdns, but don’t be fooled—this isn’t something that runs on your device. It’s a build utility meant for working with MicroPython code on your desktop. Trying to mip.install("mdns") doesn’t work, and even if you manage to hack something together, you'll face:

Incomplete installs
Memory constraints
Missing socket support
Vague or outdated documentation
In short, DNS support on MicroPython is a mess.

Why This Matters

Many modern apps, especially in IoT or edge scenarios, rely on some form of local device discovery. Whether you’re running a simple HTTP server on your ESP or trying to expose endpoints dynamically, DNS or mDNS is the typical go-to.

But for small micros, this just isn't an option today—not without going native (C/C++) or using an external helper.

My Approach

For now, I’ve pivoted to using dummy data just to prove my app’s concept. The ESP was only acting as a local server—I could use my laptop instead, but I want this system to be portable, low-power, and eventually headless.

That’s why I’ve decided to build my own DNS responder written in C or Rust—tailored for use in embedded projects. It will:

Be lightweight and memory-safe
Run on small MCUs
Support basic A record responses and mDNS
Help other devs avoid the same rabbit hole
Conclusion

This isn’t just a personal fix, it’s something the MicroPython community sorely needs. Reliable, plug-and-play DNS discovery for embedded devices is long overdue. If you’ve been burned trying to get DNS working on a tiny board, stay tuned.

I’ll open-source the DNS tool and write a follow-up on how it works internally once it's ready.

— Kiprono

Making the Future Cool: Lessons from BASiGo’s Bold Move

Rono — Tue, 15 Jul 2025 12:35:28 +0000

The future is not just something that happens. The future is something we must imagine, design, and build.

There’s something deeply unsettling about how we’ve come to accept the world around us. We move through broken pavements, cross potholed roads, dodge open drainage trenches, and wait for water that never runs. And somehow, we call that “normal.”

But here’s the thing: this isn’t normal. It’s just stagnation dressed up as survival.

Our infrastructure is tired. The way we build, move, and live was designed for a time long gone. Our roads weren’t meant for modern logistics. Our homes—built with materials and methods that barely evolved—aren’t optimized for durability, affordability, or sustainability. Drainage systems? Half of them don’t even qualify for the word “system.” Clean water access? Still a luxury for too many.

The solution isn’t waiting for the government to fix things. It’s to build companies that fix them.

We need a wave of innovation not in the clouds, but on the ground—focused on the very basics of daily life.

Why not rethink how walking paths are built and maintained?
Why are we still stuck with outdated road construction materials?
Why do we build houses the same way we did 50 years ago—expensively, inefficiently, and unsustainably?
Why hasn’t someone disrupted how drainage works, or how we collect, purify, and distribute clean water?
The answers aren’t in speeches. They’re in startups.

Take BasiGo. A few years ago, the idea of an electric bus on Nairobi roads sounded like science fiction. Today, BasiGo is quietly reshaping public transport—not just by making it cleaner, but by challenging the assumptions that have kept it broken for decades. This is what innovation actually looks like. Not theory. Not hope. Execution.

So the question is:

What other parts of our infrastructure are waiting for a BasiGo moment?
Our public transport, our housing, our water, our urban design, our construction materials—all of it is ripe for a second look. A smarter take. A better version. But it won’t come from maintaining the status quo. It won’t come from boardrooms or ministries.

In fact, the best thing the government can do right now is to step aside—not because we don’t need them, but because we don’t need them to build. What we need is an environment that rewards risk, protects builders, opens doors, and keeps the red tape away from those solving real problems.

Progress won’t come from policies.
It’ll come from bold builders willing to say: this isn’t good enough. Let’s fix it.

We don’t need to settle for what we have.
We need to question it, redesign it, and rebuild it—smarter, cleaner, cheaper, faster.

The future won’t get better on its own.

It will only get better if we build it.