Forem: Tombri Bowei

Trace AI: I Pointed a Camera at a Whiteboard. Notion Built the Entire System Design Doc.

Tombri Bowei — Sun, 29 Mar 2026 21:03:36 +0000

This is a submission for the Notion MCP Challenge

What I Built

Every engineering team has the same graveyard: folders full of blurry whiteboard photos that were supposed to become

documentation. They never do. The meeting ends, the momentum dies, and that brilliant architecture sketch slowly rots in

someone's camera roll.

Trace AI kills that problem dead.

Trace is an autonomous pipeline that watches your Notion Design Inbox, your Slack workspace, and your Discord server

simultaneously. The moment you drop in a whiteboard photo, Trace wakes up, reasons through the sketch using Claude vision,

and uses the official Notion MCP server to build a complete, structured system design document — entirely on its own.

Not a summary. Not a description. A full engineering document:

Mermaid.js architecture diagrams — flowchart and sequence, auto-generated from your ink
Component breakdown — every service, database, and load balancer identified and described
Security analysis — potential vulnerabilities flagged with recommendations
Bottleneck detection — performance risks spotted before they hit production
Actionable task cards — your handwritten To-Dos extracted and created as real entries in your Notion engineering board, with Priority, Category, and Status pre-filled
AWS cost estimates — rough monthly infrastructure projections for every component
Complexity scoring — team size and build timeline estimates

The entire process takes under 2 minutes from photo to polished doc.

In a large company, information decays. A project manager marks a project as "completed", but the task database still has 5 open items. A budget page says '$10k', but the invoice page says '$12k'. Usually, these contradictions stay hidden until something breaks.

Sentinel fixes this. Using the new Model Context Protocol (MCP), Sentinel acts as a "shared brain" across your entire workspace. It observes every edit and cross-references it against a set of global truths you define. If a contradiction occurs, Sentinel doesn't just watch—it acts.

Video Demo

Show us the code

https://github.com/Boweii22/Arch-Vision
Deployed live on Render using Docker (nikolaik/python-nodejs for Python + Node.js in one container — required to run the MCP
server subprocess).

How I Used Notion MCP

This is where Trace AI goes beyond a simple API wrapper.

Trace spawns the official @notionhq/notion-mcp-server as a live subprocess using the MCP Python SDK. Claude then enters an

agentic tool-use loop — it doesn't receive a rigid set of instructions and execute them blindly. It reasons about what

blocks to append, how to structure the content, and how to handle edge cases like long Mermaid diagrams that exceed Notion's
2000-character rich text limit.

Whiteboard photo
↓
Claude Vision → Architecture Analysis (structured JSON)
↓
npx @notionhq/notion-mcp-server ←→ Claude agentic loop
↓ ↓
Notion Page created MCP tool calls:
(direct API, correct parent) - append_block_children
- create_database_page
- (up to 25 iterations)
↓
Tasks Database ← action items extracted
Projects DB ← relational mapping

MCP unlocks something that raw API calls can't: judgment. Claude decides when to split a code block, how to format a

callout, when to skip a section because the data isn't there. The document isn't templated — it's reasoned.

On top of that, Trace runs a bi-directional sync loop: if you manually edit the Mermaid diagram in Notion, Trace detects the change, re-analyzes the modified architecture, and updates the analysis sections to stay consistent with your edits. Your

Notion workspace stays alive, not static.

Three ways to trigger it — Notion Inbox, Slack, Discord — because great tools meet teams where they already live.

The 8-Month Feature Nobody Wanted (Including Me, Eventually)

Tombri Bowei — Thu, 26 Mar 2026 23:26:18 +0000

TL;DR: I built something so obsessively specific to my own workflow that I convinced myself it was universal. It wasn't. The moment I stopped refreshing analytics, it shipped better.

The Problem I Solved (For Myself)

I was drowning in a particular flavor of repetitive work. Not a common problem—my problem. The kind where you're the only one in your Slack thread who really gets why it's broken. So I decided: I'll build the fix.

Eight months. Custom parsing logic, a UI that only I understood, database schema decisions that made sense only because I lived in that headspace daily.

The Honest Part

I launched it to silence. Not criticism silence—indifference silence. I refreshed GitHub stars. Checked analytics every 6 hours. Posted in communities. Nothing. The feature was objectively good—it worked, it was fast, it solved the problem it was designed for.

But it was designed for an audience of one.

What Changed Everything

One afternoon I just... stopped checking. Deleted the analytics bookmark. Moved on to the next thing.

That's when something weird happened: people started using it. Not because it went viral. But because the moment I stopped optimizing for adoption, I started shipping faster. I added features because I needed them. I fixed bugs I actually encountered. The product got honest.

Turns out people can smell when you're building for them versus building for yourself. They prefer the latter.

What I Learned

Specific beats universal. A tool built with religious specificity for one person often beats a generic solution built for "everyone."
Analytics are a trap. The refresh-check-despair loop kills momentum. You don't need permission to build—you need focus.
Shipping > perfecting. The moment I stopped trying to predict what others wanted, I built something worth using.

The real victory wasn't adoption. It was finishing something.

If you're sitting on a feature you're "shocked nobody wants"—that's not failure feedback. That's a signal you're too deep in your own head. Either go deeper (own your specificity) or ship it and forget about it. The middle ground—optimizing for invisible users—is where projects die.

What's the feature you've been gatekeeping because you think nobody else cares?

Remote Work Didn't Fix Toxic Culture—It Just Made It Async

Tombri Bowei — Thu, 26 Mar 2026 19:32:57 +0000

TL;DR: Your team's dysfunction didn't disappear when everyone went remote. It just moved into Slack, and now it's worse because you can't read the room.

I spent 3 years watching this play out. Pre-pandemic, your manager's bad mood was obvious—you'd catch it in a hallway conversation. Now? That same manager writes passive-aggressive comments in PRs at 11 PM and you're supposed to interpret tone through a screen.

The real problem: We mistook silence for health.

Remote work did expose one thing clearly—bad code, bad decisions, bad people all leave a digital paper trail. But instead of fixing the culture, teams just learned to code-switch better. The senior engineer who bullied juniors in meetings? Now they bully them in GitHub comments. The meeting-obsessed manager? Just scheduled 8 async updates instead.

The Pattern

Think of it like this:

Old culture toxicity:
visibility = high
confrontation = forced
resolution = sometimes happens

Remote culture toxicity:
visibility = hidden in timestamps
confrontation = deniable
resolution = "that's just how they communicate"

The dysfunction didn't change. The accountability did.

What I Learned

Culture is a system, not a setting. Flipping "remote" doesn't rewrite how people treat each other—it just changes the medium. I've seen amazing remote teams and soul-crushing ones. The difference? Teams that actually addressed why people were unhappy, not just where they worked.

The teams that thrived remotely did something radical: they explicitly named their values, called out bad behavior in public channels, and held leadership accountable the same way they held junior devs accountable in code review.

It took work. It wasn't comfortable. But it worked.

What I'm Curious About

Have you seen this in your org? Did remote work unmask problems or just rearrange them? And more importantly—did your team actually address the culture, or just accept a quieter version of the same dysfunction?

Drop a comment. I'm betting you've got a story.

My AI Caught a £3,200 Scope Creep at 3am While I Was Asleep—Here's the Notion MCP System I Built

Tombri Bowei — Tue, 24 Mar 2026 17:27:37 +0000

This is a submission for the Notion MCP Challenge

I want to show you something that happened at 3:17 am on a Tuesday.

I was asleep. My phone was on silent. I wasn't thinking about work.
But my Notion workspace was changing.

A database row — a client called Holloway Studio — had its health score property quietly drop from 84 to 31. Its status flipped from "On track" to "Breach flagged". A new page appeared in its linked interaction log database: "Scope creep detected — client requested 4 additional deliverables beyond contracted scope in email thread at 23:42."

And in a drafts section of the same Notion page, a complete, professional email had appeared — written by Claude AI, addressed to the client, asserting the contract terms, proposing a change order. Ready to send. Waiting for me when I woke up.

I hadn't written a single line of that. I was asleep.

That's what Notion MCP unlocked for me. Not a chatbot you talk to. It's not a dashboard you check. A system that runs — reads your world, reasons about it, and writes the results back to the place you actually work — while you do literally anything else.

I built Contract OS. And I want to show you exactly how it works.

What I Built

Contract OS is an autonomous AI agent that protects freelancers from the three things that silently drain their income every year:

Scope creep — clients casually requesting extra work in emails, knowing most freelancers won't push back.

Late payments — invoices that go a week past due, then two weeks, while you're too busy working to chase them.

Revision abuse — clients burning through revision rounds the contract doesn't allow because nobody's counting.

The system connects to Gmail, Google Calendar, and—at the absolute centre of everything—Notion, via the Notion MCP server. Every 6 hours, automatically, it:

Reads every active contract from a Notion database
Fetches recent emails and calendar events for each client
Sends all of it to Claude to detect breaches and score contract health
Writes every result back to Notion — health scores, statuses, breach alerts, drafted emails, interaction logs

Notion isn't where the results get saved. Notion is the brain. The agent reads from it, reasons against it, and writes back to it in a continuous loop. Every cycle makes the workspace smarter.

The Landing Page

Before the dashboard, there's a landing page that explains the problem, shows the product, and gives you clear next steps whether you want to try the live demo or clone the repo.

Video Demo

Show us the code

GitHub: https://github.com/Boweii22/Contract-OS, Live Demo: https://contract-os-dashboard.vercel.app/

The live demo uses a seeded Notion workspace with fake client data — safe to explore fully. To run against your own contracts, clone and add your keys. The README walks through everything in about 15 minutes.

git clone https://github.com/Boweii22/Contract-OS
cd contract-os
cp .env.example .env.local
# Fill in: ANTHROPIC_API_KEY, NOTION_TOKEN, 
# NOTION_CONTRACTS_DB_ID, GOOGLE_CLIENT_ID,
# GOOGLE_CLIENT_SECRET, GOOGLE_REFRESH_TOKEN
npm install && npm run dev

How I Used Notion MCP

This is the part I want to spend real time on — because the Notion MCP integration here is doing something I haven't seen any other project attempt. It's not a one-way pipe. It's a living read/write loop that makes Notion the persistent memory of an AI agent.

Let me walk through every layer.

The Notion database schema — contracts as structured AI-readable data
The first thing I built was the Notion database. Two of them, actually.

Database 1: Contracts

Every active client contract lives here as a structured row. Not just a name and a number — every property the AI needs to reason about a potential breach:

Property	Type	What the AI uses it for
Client name	Title	Primary identifier — also used as the Gmail search term to find that client's emails
Contract value	Number	Detects payment shortfalls and calculates outstanding balance
Payment terms	Select	The AI reads this to judge whether a payment is late
Deposit received	Checkbox	Confirms whether the upfront payment has landed
Deposit amount	Number	Cross-referenced against contract value to calculate what's still owed
Balance due	Number	Outstanding amount — triggers payment breach detection if overdue
Deadline	Date	Calculates deadline proximity risk — penalties kick in inside 14 days
Status	Select	Flipped by the AI each cycle: On track / Scope creep / Breach flagged / Payment late
Health score	Number	Written by the AI — 0 to 100, validated against the deterministic formula
Revision rounds	Number	The contracted allowance — the ceiling the AI enforces
Revisions used	Number	Written back by the AI — compared against rounds to detect revision abuse
Notice period days	Number	Used to flag if a termination risk is approaching without proper notice
Contract type	Select	Fixed price / Retainer / Time & materials — affects how payment breach logic runs
Last signal	Rich text	The AI's one-sentence summary of the most recent finding
Last synced	Date	Timestamp of the last completed agent cycle
Client email domain	Rich text	e.g. `@acmestudio.com` — how the agent filters Gmail to the right client thread
Notion log page URL	URL	Direct link to the client's interaction log page in Notion
Log database ID	Rich text	The ID of the linked log database — used by the agent to write new signal entries

The AI reads this entire row at the start of every cycle. This is what it knows. This is what it checks against.

Database 2: Interaction Log (one per client, linked sub-page)

Every signal detected — every email flagged, every breach logged, every draft created — becomes a structured entry in this database. Timestamp d. Categorised. Permanent.

Property	Type	What the AI uses it for
Name	Title	Auto-generated entry title — e.g. `PAYMENT_BREACH · Nova Agency`
Contract	Relation	Links back to the parent contract row in the Contracts database
Type	Select	Signal category — `SCOPE_CREEP` / `PAYMENT_BREACH` / `REVISION_BREACH` / `FEEDBACK_DELAY` / `DEADLINE_RISK`
Severity	Select	How serious the finding is — `BREACH` / `WARNING` / `INFO`
Description	Rich text	Human-readable explanation of exactly what was detected
Evidence	Rich text	The raw data that triggered the signal — quoted email content, calendar events, or contract values
Contract clause violated	Rich text	The specific contract term that was broken or put at risk
Recommended action	Select	What the agent did next — `Draft email` / `Log only` / `Book meeting`
Detected at	Date	Timestamp of when the signal was fired during the agent cycle
Health score at detection	Number	The contract's health score at the exact moment the signal was logged — creates a timeline of decline

This is the audit trail. Every decision the AI ever made, recorded in Notion forever.

Reading contracts via Notion MCP — the agent's starting point
Every agent cycle begins with a single Notion MCP call: query the Contracts database, filter for active contracts, return everything.

// tools/notion.ts
import { Client } from '@notionhq/client';

const notion = new Client({ auth: process.env.NOTION_TOKEN });

export async function getActiveContracts(): Promise<Contract[]> {
  const response = await notion.databases.query({
    database_id: process.env.NOTION_CONTRACTS_DB_ID!,
    filter: {
      and: [
        {
          property: 'Status',
          select: { does_not_equal: 'Completed' }
        },
        {
          property: 'Status', 
          select: { does_not_equal: 'Archived' }
        }
      ]
    }
  });

  return response.results.map(page => ({
    id: page.id,
    clientName: page.properties['Client name'].title[0]?.plain_text,
    contractValue: page.properties['Contract value'].number,
    paymentTerms: page.properties['Payment terms'].rich_text[0]?.plain_text,
    deadline: page.properties['Deadline'].date?.start,
    revisionRounds: page.properties['Revision rounds'].number,
    revisionsUsed: page.properties['Revisions used'].number,
    gmailLabel: page.properties['Gmail thread label'].rich_text[0]?.plain_text,
    logDatabaseId: page.properties['Log database ID'].rich_text[0]?.plain_text,
    notionPageId: page.id,
  }));
}

This is the foundation of everything. The agent knows nothing about your contracts except what Notion tells it. Notion is the source of truth.

Claude signal detection — the AI reasoning layer

With the contract data in hand, the agent fetches the last 15 emails from that client's Gmail thread and the next 30 days of calendar events. Then it sends all of it to Claude in a single, structured prompt — and Claude returns a clean JSON breach report.

// prompts/signal-detector.ts

const response = await anthropic.messages.create({
  model: 'claude-sonnet-4-6',
  max_tokens: 1000,
  system: `You are a contract compliance AI for a freelancer.
You receive contract terms, recent client emails, and calendar data.
Detect any of these breach types:
- SCOPE_CREEP: work requested outside the contract scope
- PAYMENT_BREACH: payment overdue per the agreed terms
- REVISION_BREACH: more revisions requested than contracted
- FEEDBACK_DELAY: client has not responded within their window
- DEADLINE_RISK: deadline within 14 days with unresolved blockers

Respond ONLY with valid JSON. No markdown. No preamble. No explanation.`,
  messages: [{
    role: 'user',
    content: `CONTRACT TERMS:
${contract.paymentTerms}
Deadline: ${contract.deadline}
Revision rounds allowed: ${contract.revisionRounds}
Revisions used: ${contract.revisionsUsed}

RECENT EMAILS (last 15):
${emailThreads.map(e => `[${e.date}] ${e.from}: ${e.snippet}`).join('\n')}

CALENDAR EVENTS (next 30 days):
${calendarEvents.map(e => `${e.date}: ${e.title}`).join('\n')}

Respond with this exact JSON structure:
{
  "signals": [{
    "type": "SCOPE_CREEP|PAYMENT_BREACH|REVISION_BREACH|FEEDBACK_DELAY|DEADLINE_RISK",
    "severity": "INFO|WARNING|BREACH",
    "description": "One sentence finding",
    "evidence": "Direct quote from the email",
    "recommended_action": "Draft email|Book meeting|Log only",
    "contract_clause_violated": "Which term was breached"
  }],
  "health_score": <0-100>,
  "health_reasoning": "Two sentence explanation"
}`
  }]
});

const result = JSON.parse(response.content[0].text);

The health score Claude returns gets validated against a deterministic formula — breach severity deductions, deadline proximity penalties, revision overuse penalties. The final score written to Notion is always the lower of the two. Claude cannot hallucinate your contract health upward.

Writing results back to Notion MCP — the loop closes

This is the moment I find most satisfying about this system. After Claude analyses a contract, every single result flows back into Notion via MCP. The database row updates. The interaction log grows. If an email needs drafting, the draft lands in Notion too.

// tools/notion.ts — write results back after every agent cycle

export async function updateContractHealth(
  contract: Contract,
  healthScore: number,
  status: string,
  latestSignal: string
) {
  // Update the contract database row
  await notion.pages.update({
    page_id: contract.notionPageId,
    properties: {
      'Health score': { 
        number: healthScore 
      },
      'Status': { 
        select: { name: status } 
      },
      'Last signal': { 
        rich_text: [{ text: { content: latestSignal } }] 
      },
      'Last synced': { 
        date: { start: new Date().toISOString() } 
      },
    }
  });
}

export async function appendInteractionLog(
  contract: Contract,
  signal: Signal
) {
  // Create a new log entry in the client's linked database
  await notion.pages.create({
    parent: { database_id: contract.logDatabaseId },
    properties: {
      'Event': { 
        title: [{ text: { content: signal.description } }] 
      },
      'Type': { 
        select: { name: signal.source } 
      },
      'Detail': { 
        rich_text: [{ text: { content: signal.evidence } }] 
      },
      'Signal level': { 
        select: { name: signal.severity } 
      },
      'Timestamp': { 
        date: { start: new Date().toISOString() } 
      },
      'Action taken': { 
        rich_text: [{ text: { content: signal.recommendedAction } }] 
      }
    }
  });
}

export async function saveDraftEmailToNotion(
  contract: Contract,
  subject: string,
  body: string
) {
  // The drafted email lives in Notion — survives page refresh,
  // survives server restart, accessible from any device
  await notion.pages.create({
    parent: { database_id: contract.logDatabaseId },
    properties: {
      'Event': { 
        title: [{ text: { content: `Draft: ${subject}` } }] 
      },
      'Type': { select: { name: 'Draft email' } },
      'Detail': { rich_text: [{ text: { content: body } }] },
      'Signal level': { select: { name: 'Breach' } },
      'Timestamp': { date: { start: new Date().toISOString() } },
      'Action taken': { 
        rich_text: [{ text: { content: 'Claude drafted response — awaiting send' } }] 
      }
    }
  });
}

The write-back is what completes the loop. Notion isn't a destination. It's a relay station. The agent reads from it, Claude reasons against it, and the results flow back into it — richer than before, ready for the next cycle to read.

The bidirectional loop — visualised
Here's the full cycle, end to end, every 6 hours:

Notion Contracts DB
       │
       │  notion.databases.query() — reads all active contracts
       ▼
  Agent Orchestrator
       │
       ├──► Gmail MCP — fetches last 15 emails per client
       ├──► Calendar MCP — fetches next 30 days of events
       │
       ▼
  Claude claude-sonnet-4-6
  (contract terms + emails + calendar → JSON breach report)
       │
       ▼
  Agent Orchestrator
       │
       ├──► notion.pages.update() — health score, status, last signal
       ├──► notion.pages.create() — new interaction log entry
       └──► notion.pages.create() — draft email saved to Notion
       │
       ▼
Notion Contracts DB
(now richer — ready for the next cycle to read)
       │
       ▼
  SSE broadcast → Dashboard updates in real time

Three MCP servers. One agent. One brain — Notion. Every 6 hours, automatically, whether I'm at my desk or asleep.

Real-time dashboard — SSE from agent to UI
The dashboard connects to the agent via Server-Sent Events. The moment a contract is processed, the health score updates in the UI without a refresh:

// dashboard — useSSE hook
useEffect(() => {
  const source = new EventSource('/api/stream');

  source.addEventListener('contract:updated', (e) => {
    const updated = JSON.parse(e.data);
    setContracts(prev =>
      prev.map(c => c.id === updated.id ? { ...c, ...updated } : c)
    );
  });

  source.addEventListener('signal:detected', (e) => {
    const signal = JSON.parse(e.data);
    setSignalFeed(prev => [signal, ...prev]);
  });

  return () => source.close();
}, []);

The health ring animates. The breach badge appears. The signal card slides in. All from Notion data, flowing through Claude, pushed to the browser in real time.

The FullStack

AI model — Claude claude-sonnet-4-6
Structured JSON output, multi-source reasoning, zero hallucinated health scores

Primary MCP — Notion MCP
Reads contracts, writes health scores, creates log entries — the persistent brain

Supporting MCP — Gmail MCP + Google Calendar MCP
Real email threads + real calendar data fed directly into Claude

Agent runtime — Node.js 20 + TypeScript
Fully typed orchestration, fast async parallel contract processing

Scheduler — node-cron
Runs every 6 hours automatically — no manual triggers, no babysitting

API + real-time — Fastify + Server-Sent Events
Sub-second health score push to dashboard the moment a contract is processed

State cache — lowdb
Flat-file JSON deduplication — never re-fires a signal Claude already caught

Dashboard — Next.js 14 App Router
Server components + streaming for instant first paint

Animations — Framer Motion 11
Spring-based health ring, staggered loads, sliding tab indicator

Styling — Tailwind CSS v4
Utility-first with CSS custom properties for the full design system

Fonts — DM Serif Display + DM Mono + Geist
Display headlines, monospace data values, clean UI body text

Hosting — Railway (agent) + Vercel (dashboard)
Persistent Node server for cron + edge-optimised Next.js — both free tier

What Notion MCP Actually Unlocked

I want to be specific about this because it's easy to say "Notion MCP is central" and leave it vague. Here's what specifically would not be possible without it:

Without Notion MCP reading contracts: The agent has no idea what your contract terms are. It cannot judge what's a breach versus what's normal. It's blind.

Without Notion MCP writing health scores: The results of every AI analysis evaporate the moment the agent process ends. There's no memory. The next cycle starts from zero.

Without Notion MCP creating log entries: There's no audit trail. No proof of what the AI detected, when it detected it, or what it did about it. The system is a black box.

Without Notion MCP saving draft emails: The drafted response dies in memory. It never reaches you. It never becomes an action you can take.
Notion MCP is what transforms this from a script that runs once into a system that learns and accumulates — every cycle building on the last, every result persisted, every decision traceable.

That's the unlock. That's what makes it a product instead of a demo.

What's Next

Slack + WhatsApp push alerts — breach detected at 3am? Get a message, not just a Notion update
Contract generator — describe a project in plain English, get a full contract drafted and saved to Notion
Client portal — a read-only Notion share link showing your client their deliverable statuses in real time
Stripe webhook — detect payment received automatically, close the payment breach loop without reading emails
Multi-currency — GBP-first today, trivial to extend

Try It

Live demo — fake data, fully interactive: contract-os.vercel.app
GitHub — MIT licensed, clone and add your keys: https://github.com/Boweii22/Contract-OS
Landing page: https://contract-os-dashboard.vercel.app/

If you're a freelancer — I want to hear from you in the comments. Tell me about the scope creep that cost you. The invoice that went 30 days past due. The client who asked for "just one more small change" six times in a row.

My guess is every single person reading this has a story. And I built this because I got tired of those stories being the price of doing business.

They don't have to be.

Built for the DEV × Notion MCP Challenge, March 2026.
Claude + Notion MCP + Gmail + Google Calendar + Next.js + Framer Motion

I Mapped My Entire Freelance Client Onboarding Process. It took 6 tools and 73 minutes. Here's What I Found.

Tombri Bowei — Wed, 18 Mar 2026 12:00:46 +0000

And why do I think most freelancers have quietly accepted broken workflows as normal?

Last month I decided to do something slightly embarrassing: I timed myself.

Not during the project. Before it. I wanted to know exactly how long it took me to go from "yes, I'm interested in working with you" to "okay, the deposit's paid and we can start."

The answer was 73 minutes. Across 6 different tools. For a single client.

I'm a developer who's been freelancing for a few years. I've shipped dozens of projects. I have a favourable reputation. Clients come back. And yet somewhere along the way I'd built this completely invisible tax into every single engagement—a manual, fragmented, cobbled-together workflow that I'd never once stopped to actually look at.

When I finally looked at it, I couldn't unsee it.

The Audit: What My "Process" Actually Looked Like

Here's the exact sequence I went through, step by step:

Step 1: The proposal (~25 minutes)
Open a previous Google Doc. Start a new one — I never have a good template, so I'm always rebuilding from scratch. Write the scope. Second-guess the scope. Rewrite the scope. Format it to look professional. Export to PDF. Realise the PDF looks weird. Reformat. Export again.

Step 2: The contract (~15 minutes)
Open HelloSign (now Dropbox Sign). Find a contract template I saved two years ago. Update the client name, dates, and project scope. Send it. Wait for the client to create an account before they can even open it.

Step 3: The deposit (~10 minutes)
Send a PayPal invoice. Wonder if the client has PayPal. They don't always. Explain bank transfer as an alternative. Wait for them to figure out international transfer fees. Occasionally chase it 3 days later when it hasn't arrived.

Step 4: The confirmation (~8 minutes)
Email back and forth to confirm receipt of deposit, confirm project start date, and confirm which version of the scope we're working from.

Step 5: The actual invoice (later, but it counts)
Weeks later, open Wave (my invoice tool). Recreate the project details from memory. Send. Sometimes I get asked, "What is this for again?" because it looks nothing like the proposal.

Total: ~73 minutes of admin, 6 different tools, zero of which talk to each other.

And here's the part that really got me: none of this is visible in my work. A client sees a beautiful final deliverable. They have no idea how chaotic the paper trail behind it was.

The Real Cost Nobody Talks About

The obvious cost is time. 73 minutes per client adds up fast — if you onboard 15 clients a year, that's 18 hours of pure admin before a single line of code or pixel is moved.

But the less obvious cost is professionalism.

There's a gap between the quality of most freelancers' work and the quality of their onboarding process. You might have an incredible portfolio, strong references, and 5-star reviews — and then your client receives a Google Doc, a separate DocuSign email, a PayPal request, and three emails trying to stitch it all together.

It doesn't match. And I think clients feel it even if they can't articulate it.

A designer friend of mine put it best: "My proposals look nothing like my actual design work. My work is clean and intentional. My proposals are... a PDF I made in 2021 that I keep patching."

I Asked Around. Turns Out This Is Almost Universal.

After doing my own audit, I started asking other freelancers how they handle this. Developers, designers, photographers, copywriters, videographers. The answers were remarkably consistent:

The most common setup (probably 60% of people I asked):

Google Docs or Word → PDF email → HelloSign/DocuSign → PayPal or bank transfer → Wave/FreshBooks invoice

The aspirational setup (people who'd invested in proper tools):

HoneyBook or Bonsai or Dubsado

The honest feedback about those proper tools:

"Too expensive." / "Way more than I need." / "Took me weeks to set up and I barely used half the features." / "Designed for agencies, not individual freelancers."

HoneyBook is $39–79/month. Bonsai is $25–52/month. Dubsado has a learning curve that rivals some SaaS products I've been paid to build. These are serious tools for serious agencies. They're not really built for someone who wants to send a proposal and get paid.

The Specific Things That Are Broken

After all these conversations, here's what I think are the actual broken parts — in order of how painful they are:

There's no standard proposal format

Every freelancer I spoke to described starting proposals from scratch or from an old document they keep patching. There's no "proposal.template" you can pull up and trust. Every client feels like the first client in terms of the process.

The result: enormous variation in quality and a massive time sink on something that should be repeatable.

Proposals are static dead documents

You send a PDF. The client receives it. You have zero idea what happens next. Did they open it? Did they read it? Did they forward it to someone else? Did they misplace it? You're flying blind from the moment you hit send.

The anxiety of not knowing is surprisingly real. I've sent proposals and then spent three days wondering if the email even arrived.

The signature and payment are separate, awkward steps

Right now, for most freelancers, a client has to:

Open a DocuSign/ HelloSign email and create an account to sign
Then separately figure out PayPal or bank transfer to pay the deposit
Then email you to confirm

That is three friction points between "yes, I want to work with you" and "money is moving." Each one is a moment where a client can lose momentum, get distracted, or decide it's more trouble than it's worth.

I genuinely believe some clients ghost after receiving proposals not because they're not interested but because the process of saying yes is annoying enough that they put it off until they forget.

The tools don't talk to each other

Your proposal lives in Google Docs. Your contract lives in HelloSign. Your payment lives in PayPal. Your invoice lives in Wave. When you need to reference "what did we agree to" six weeks into a project, you're digging through four different apps trying to reconstruct the truth.

There's no single source of record. And when disputes happen (they do), this matters.

Everything has to be rebuilt for every client

The scope of the proposal changes per client. That's expected and fine. But the structure of the proposal? The payment terms? The contract language? The invoice format? These should be templates. d. They rarely are.

What a Better Version Looks Like

I've been thinking about what the ideal workflow actually looks like for an independent freelancer (not an agency, not a team — one person with good work and a handful of clients at any given time).

Here's what I want:

I fill in a form — client name, project, scope, pricing, timeline. Two minutes.
A link is generated — a clean, professional-looking page that the client can open. Not a PDF attachment. A live URL.
The client reads, signs, and pays — all on the same page. No separate tools. No account creation. Type their name to sign, enter card, done.
I get notified, and funds move — I know the moment they opened it, signed it, and paid.
Everything lives in one place — one dashboard with all proposals, their status, and the ability to convert any signed proposal into a final invoice.

That's it. No CRM. No time tracking. No project management. Just create a proposal, send a link, and get paid.

The version I have in my head is something like $15–20/month. Not $60/month. Not a 2-hour setup process. Something I could have running and used within the same afternoon I signed up.

The Broader Pattern: Freelancers Are Remarkably Bad at Selling to Themselves
Here's the thing that strikes me most about all of this.

Freelancers — especially developers and designers — are often incredibly good at building products. We understand UX. We know what makes a clean, frictionless flow. We can spot a broken onboarding process in a client's product from a mile away.

And then we go home and send proposals in Google Docs and chase deposits over PayPal.

There's a weird blind spot where we've accepted our own workflow as "just how it is" while we'd never let a client ship a product with that many friction points.

I think part of it is that nobody teaches you this stuff. You start freelancing, you send your first proposal however you can, and then you just keep doing it that way. The tools you'd need to fix it cost too much or require too much setup, so the path of least resistance is to keep doing the broken thing.

What I'm Actually Curious About

I've shared my setup (chaos) and what I think the ideal looks like (one link, everything in one place). But I'm genuinely curious what other people have found.

Specifically:

How long does your client onboarding take — from first "yes, interested" to deposit paid and project started?
What's the actual worst part — is it the proposal writing, the contract, the deposit, the back-and-forth?
If you've tried a proper tool (HoneyBook, Bonsai, Dubsado, anything else) — did it stick? Why or why not?
What would you pay for something that genuinely solved this? Or does it not bother you enough to pay anything?

Drop your answers in the comments. Genuinely collecting these — not for any agenda, just because I think this problem is more interesting than it looks on the surface.

The Loneliness of Being the Only Dev in the Room

Tombri Bowei — Wed, 18 Mar 2026 05:24:33 +0000

Nobody writes about this. Maybe because the people who live it are too busy being the only ones who can fix the WiFi.

There's a specific kind of loneliness that has no name yet.

It's not the loneliness of working remotely. It's not the loneliness of being an introvert in an open-plan office. It's sharper than both of those and quieter.

It's the loneliness of being the only developer in a company full of people who don't speak your language — and never will.

You didn't notice it at first
The job sounded exciting. A real company. Real problems. And you—the person who could actually build things—walking in like someone who finally has superpowers in a world that needs them.

The first few months felt like that. You shipped things. People were impressed. Someone in a meeting called you "our tech guy/girl", and you smiled because it felt like belonging.

Then, slowly, quietly, you started to notice.

There was no one to review your pull requests. Not because people were lazy — but because nobody could. You merged your own code. You reviewed your own architecture decisions. You Googled your own doubts.

You started having conversations with yourself dressed up as documentation.

The weight of being the only one who knows

Here's what nobody tells you about being the sole developer:

You never get to be junior again.

In a team, you can say, "I'm not sure; let me check with someone." You can say, "I think we should do X, but I want a second opinion." " You can be wrong in a safe container where someone catches you.

When you're alone, every decision is final until it catastrophically isn't. The codebase becomes a direct mirror of your blind spots — and you can't see your blind spots. That's what makes them blind spots.

The worst part? You can't tell anyone at work. Because to them, you're the expert. The wizard. The one with the answers. Admitting uncertainty feels like the whole illusion shatters.

So you carry it. You carry the uncertainty, the technical debt you made at 2am when something was on fire, the architectural decisions you're not proud of, and the library you chose because it was familiar, not because it was right.

You carry it alone.

The meetings. Oh, the meetings.

You sit in a room where someone is explaining a problem using words that mean something different to you than to them.

"Can't we just make it automatic?"
"How long would it take to just connect the two systems?"

"We had something like this at my last company; they built it in a weekend."

And you smile. Because explaining why it's not that simple requires first explaining what a system even is, what an API is, and what "connecting" two things actually means at 3am when the data formats don't match and one of the services has been deprecated and the documentation is a lie.
You smile. You say, "I'll look into it." " You go back to your desk and stare at the ceiling for ten minutes.

This isn't frustration at your colleagues. They're smart. They're good at what they do. This is something else — the particular ache of expertise becoming isolation.

The more you know, the more alone you are in knowing it.

You become the IT department by accident

At some point — and you won't remember exactly when — you became responsible for things nobody assigned you.

The printer. The WiFi. "My laptop is slow." "Can you look at this spreadsheet? Something's wrong with the formula." "We need a new tool for X; can you find one?" "Can you just automate this thing we do every Tuesday?"

You say yes. Because you're kind. Because it's easier. Because saying "that's not really my job" when you're the only technical person feels like abandonment.

But something quietly breaks inside you each time. Not because the tasks are beneath you. But because each one is a reminder: you are not here as a peer. You are here as infrastructure.

The thing that actually hurts

It's not the workload. It's not even the loneliness in the textbook sense.

It's the absence of intellectual companionship.

There's a specific joy that exists only when someone else deeply understands what you're building. When you can say, "I used an event-driven architecture here because—", before you finish the sentence, they're already nodding, already pushing back, already making it better.
That conversation. That specific aliveness of two minds on the same problem.

You haven't had it in months. Maybe years.

You've had good conversations. Friendly conversations. But not that conversation. The one where you leave feeling like your brain grew.

So instead you go to Twitter/X. You go to dev.to. You go to Hacker News and read comment threads at 11pm not because you're avoiding sleep but because you're desperately, quietly, trying to feel less alone in the thing you care most about.

What it does to you over time

It makes you doubt yourself in strange ways.

Not the obvious "Am I good enough?" kind of doubt — though that's there too. But a subtler erosion. You start to wonder if the way you think about problems is normal. You have no reference point. No colleague who builds things like you do.

You over-engineer sometimes, chasing elegance that nobody will ever see. You under-engineer other times, cutting corners you're ashamed of because there's no one to hold the standard with you.

You develop strange habits. Talking to rubber ducks. Writing READMEs with the exhaustive detail of someone who fears being misunderstood.

Commenting code is not for the next developer but as a kind of message in a bottle, proof that you were here, that you thought carefully, and that you weren't just someone who kept the lights on.

But here's the thing

There are thousands of us.

In insurance companies and law firms and small NGOs and family businesses and local councils and restaurants that needed an app. Everywhere that the world runs on software but doesn't quite run as software yet.

We are the quiet layer. The ones who translated "we need a thing" into a thing, alone, and then went home without anyone to debrief with.

And for some reason—maybe because dev culture is so focused on startups and big tech and 10x teams and Silicon Valley origin stories—nobody writes about us.

Our loneliness doesn't get a conference talk. Our specific exhaustion doesn't get a Medium think piece. Our wins are invisible because there's no one internally who understands what winning even looked like.

To the only dev in the room

Your instinct to Google things isn't weakness. It's what self-reliance looks like in practice.

The code you wrote alone, that nobody reviewed, that's been held up in production for two years — that counts. That's real. That took courage even if nobody clapped.

The meetings you sat through smiling, translating the untranslatable — that's emotional labour nobody put on your job description, and you've been doing it quietly without credit.

And the longing you feel for a peer, for someone who gets it — that's not neediness. That's just being human and loving something deeply enough to want to share it.

Are you (or were you) the only dev at your company? Tell me what it was actually like in the comments. I promise I'll read every single one.

Something the internet doesn't say enough

Tombri Bowei — Sun, 08 Mar 2026 14:28:54 +0000

Some of the most brilliant, generous, and genuinely inspiring people I've come across in this dev community are women.

@anjelica_, Jess Lee. Sylwia Laskowska, Sandra. Warda. And honestly — too many to name.

We've never met in person. But a comment here, a post there, a like at the right moment — it counts more than you think.

And offline? My mum taught me resilience before I even knew the word. My sisters keep me grounded. My girlfriend makes the hard days lighter.

Happy International Women's Day to every woman building, writing, mentoring, debugging, and showing up.

You are not background characters in this story. You're the plot. 🌍💙

I Built an AI That Writes Victorian Funeral Rites for Dead Websites — Using 5 Specialised Agents 🕯️

Tombri Bowei — Fri, 06 Mar 2026 15:56:03 +0000

This post is my submission for the DEV Education Track: Build Multi-Agent Systems with ADK.

"Here lies Flash Player. It asked you to update it one final time, and you said no."

That's a real output from my project. And honestly? I felt something.

What I Built

We've all seen "one giant prompt" AI apps. You throw everything at a single model and hope it figures it out. But what if the task is genuinely complex — requiring research, historical analysis, literary writing, sharp comedy, AND poetic compression all at once?
That's exactly the problem I set out to solve. And the solution? Give each job to a specialist.

Eulogy for the Internet is a multi-agent AI system that takes any website, app, or digital phenomenon and generates a full Victorian-style funeral obituary — as if historians from the year 2124 are looking back on it.

You type in "Vine". Five AI agents spring into action. Thirty seconds later, you have a beautifully typeset parchment eulogy complete with a tombstone inscription that will make you simultaneously laugh and feel genuinely sad about a 6-second video app.

Try it yourself: https://eulogy-frontend-rqlox4dhaq-uc.a.run.app

⚠️ Disclaimer: This project is satire and creative commentary. All eulogies are fictional AI-generated writing for entertainment purposes only. No companies were harmed in the making of this application.

Cloud Run Embed

Your Agents

This is where it gets interesting. Instead of one monolithic prompt trying to do everything, I built 5 specialised agents, each an expert at exactly one thing. They're orchestrated via a coordinator that passes outputs between them like a relay race.
Here's the full pipeline:

🔍 Agent 1: The Researcher
What it does: Given any URL or topic, it searches for real facts — when it was founded, what it was famous for, who used it, and how it declined.
Why a dedicated agent: Research requires breadth. You need facts first before any creative writing begins. Mixing research and writing in one prompt produces vague, hallucinated nonsense.

Sample output for "Vine":

"Vine was a short-form video hosting service founded in June 2012... acquired by Twitter in October 2012 before launch... at its peak, hosted content from creators like King Bach and Lele Pons with hundreds of millions of followers... shut down in January 2017 after Twitter announced discontinuation..."

📜 Agent 2: The Historian
What it does: Takes the raw research and rewrites it through the lens of a historian writing in 2124, with 100 years of hindsight.
Why a dedicated agent: This requires a complete shift in voice and temporal perspective. Asking a single prompt to be both factual AND a future historian simultaneously produces an identity crisis. Giving it its context produces something genuinely literary.

Sample output:

"Vine occupies a peculiar chapter in the annals of early digital culture — a platform whose entire creative vocabulary was six seconds long, and yet somehow those six seconds were enough to birth an entirely new form of celebrity, comedy, and human expression..."

✒️ Agent 3: The Eulogy Writer
What it does: takes the research and historical framing and composes a proper three-act eulogy — What It Was, What It Wrought Upon the World, and On Its Undignified End.

Why a dedicated agent: Literary writing requires full focus. This agent's only job is to be eloquent. It writes with drop caps, rolling sentences, and devastating final lines. No distraction.

🕯️ Agent 4: The Roast Agent
What it does: Writes the dissenting mourner's speech — the person at the funeral who loved the deceased but refuses to pretend they were perfect.
Why a dedicated agent (and my personal favourite): Runs in parallel with the Eulogy Writer. While the writer crafts gravitas, the Roast Agent sharpens its skills. Every eulogy needs an uncomfortable truth-teller. This agent delivers.

Sample output for Vine:

"Let us not romanticise the deceased overmuch. Vine was a website where fame was measured in loops, where a teenager doing a funny voice could accumulate more cultural influence than a documentary filmmaker with thirty years of experience... I shall miss the creativity it accidentally unlocked. I shall not miss what we became while watching it."

🪦 Agent 5: The Epitaph Agent
What it does: Reads everything — all four previous outputs — and distils the entire eulogy into a single tombstone inscription. Maximum 15 words. Must be something you'd screenshot.
Why a dedicated agent: Compression is its own art form. You cannot ask the same model that just wrote 800 words of flowing prose to suddenly become a master of the pithy one-liner. The Epitaph Agent thinks in epitaphs and nothing else.

Sample outputs:

Vine: "It gave the world six seconds of genius, then ran out of time."
Flash Player: "It asked you to update one final time. You said no."
Google+: "Built by engineers who understood computers but not loneliness."

🎭 The Orchestrator
What it does: Coordinates the entire pipeline. Calls Researcher → Historian → (Writer + Roast in parallel) → Epitaph. Passes outputs between agents. The system then returns the final assembled JSON to the frontend.

Why parallel execution: The Writer and Roast agents don't need each other's output — they both just need the research and history. Running them in parallel cuts response time nearly in half.

Key Learnings

Specialisation genuinely produces better output
I was sceptical at first. Surely one good prompt could do all this? I was wrong. When I tested a single-prompt version against the multi-agent version, the difference was stark. The single prompt hedged everything, wrote blandly, and produced generic output. Each specialised agent went deep because it had one job and full context for that one job.
Deployment is where ideas meet reality — hard
I hit every possible deployment error: billing not enabled, wrong IAM permissions, container startup timeouts, model names that weren't available on my account, and environment variables with literal newline characters baked into them from shell output. Every single one was solvable, but each one required understanding why it broke. The debugging process taught me more about Cloud Run than any tutorial would have.
The A2 A pattern is powerful but the contract matters
Agent-to-agent communication lives and dies by the contract between agents. I had to be very deliberate about what each agent returns — structured JSON vs plain text, how errors bubble up, and what happens when one agent in the chain produces unexpected output. Getting the Epitaph Agent to reliably return JSON (and not wrap it in markdown code fences half the time) was its own mini-battle.
Parallelism is free speed
Running the Eulogy Writer and Roast Agent in parallel using asyncio.gather() was one of the most satisfying moments of the build. Two agents, running simultaneously, each producing their best work, then both landing at the Epitaph Agent at roughly the same time. It felt like watching a well-drilled team.
The creative constraint made it better
Forcing the Epitaph Agent to produce a maximum 15-word tombstone inscription sounds limiting. It's actually what makes the whole project shareable. People don't screenshot 800-word eulogies. They screenshot one devastating sentence. The constraint is the feature.

What's Next

Add tone selection — Tragic / Comic / Academic / Shakespearean
Generate a shareable image card of the epitaph for social media
Add real web search to the Researcher agent for even more accurate facts
A "Roast My Startup" mode where you paste your own product URL

Built with Google ADK, Gemini 1.5 Flash, Cloud Run, FastAPI, and A2A Protocol
Five agents. One funeral. Zero survivors.
🕯️

I built a tool that turns bugs into diary entries—and debugging it taught me more than the tool itself

Tombri Bowei — Tue, 03 Mar 2026 13:38:04 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

Every developer has a ritual they're quietly ashamed of: Google the error, copy the fix, paste it in, move on. No reflection. No understanding. Same mistake next week.

I built DebugDiary to break that cycle.

DebugDiary is a full-stack web app where you paste your broken code, describe what went wrong in plain English, and Google Gemini doesn't just fix it — it writes you a personal diary entry. A reflection. A mirror.

Each entry contains:

A poetic title ("The Async Blind Spot", "When JavaScript Doesn't Wait for You")
The technical root cause, explained clearly
A deeper psychological lesson — why this mistake happens, not just what it is
A "Remember This" rule of thumb burned into an inky black card
Tags that categorise your error type over time

The dashboard then builds up a personal map of your weaknesses — your most common bug categories, your streak of consecutive days logging bugs, and an animated breakdown of your error patterns. Over time, it stops being a debugger and starts being a journal of your growth as a developer.

Gemini plays the central role: every entry is generated by a carefully engineered prompt that instructs it to respond not like Stack Overflow, but like a thoughtful senior developer who's seen your mistake a hundred times and wants you to actually learn from it this time. The response comes back as structured JSON — title, fix, root cause, deeper lesson, pattern warning, tags, severity, mood — which the app maps directly into a beautiful, readable diary page.

Tech stack: React + Vite frontend, Node.js + Express backend, Google Gemini API (gemini-2.5-flash), local JSON persistence, Framer Motion animations, React Syntax Highlighter for code diffs.

Demo

Demo URL: https://debug-diary-ten.vercel.app/

What I Learned

I learned more building DebugDiary in one evening than I expected — and most of it wasn't what I planned to learn.

Technically, I deepened my understanding of prompt engineering in ways that surprised me. My first attempt at the Gemini prompt was a wall of instructions that returned inconsistent, unparseable JSON. The breakthrough came when I stopped telling Gemini what to do and started showing it the exact output shape I needed, with no room for interpretation. Shorter, more constrained prompts produced dramatically better structured output than longer, more descriptive ones. That's a counterintuitive lesson I'll carry into every AI integration I build.

I also ran headfirst into the moving target that is the Gemini model ecosystem. Within a single evening I hit 404s from deprecated model names (gemini-1.5-flash, gemini-2.0-flash, gemini-2.0-flash-001 — all returned "no longer available for new users"), SDK version mismatches routing to the wrong API endpoint, and 429 rate limits on the free tier. I ended up switching from the @google/generative-ai SDK to direct fetch calls against the REST API, then back to the SDK once I identified the correct model string (gemini-2.5-flash) and endpoint (v1beta). It was frustrating in the moment. In retrospect, it was the most valuable part of the build — I now understand the Gemini API surface deeply rather than just cargo-culting a quickstart.

On the soft skills side, I learned something about scope. My original plan was a full database, user authentication, sharing features, and a weekly email digest. What I shipped was a local JSON file and four clean pages. And it's better for it. The constraints forced clarity — every design decision became about the core loop: paste bug, get lesson, see pattern. Nothing else.

The most unexpected lesson was noticing the irony of what I'd built. DebugDiary is a tool for learning from your mistakes. And building it, I made more mistakes per hour than I have in months. Every 404, every malformed JSON response, every SDK quirk — DebugDiary would have written a diary entry about each one. The tool ate its own dog food before I'd even finished building it.

Google Gemini Feedback

What worked brilliantly: The quality of Gemini's reflective writing genuinely surprised me. I expected it to produce dry, technical explanations. Instead, when prompted correctly, it produced entries that felt warm and human — the kind of feedback you'd get from a patient mentor rather than a linter. The "deeper lesson" section in particular consistently hit a level of psychological insight I didn't anticipate. Lines like "under time pressure, you revert to synchronous thinking" aren't just accurate — they're the kind of observation that makes you pause and recognise yourself.

The speed of gemini-2.5-flash is also excellent for this use case. Diary entries generate in 3–5 seconds, which feels fast enough to not break the flow of a debugging session.

Where I ran into friction: The model availability situation is genuinely rough for new developers. I spent a significant portion of my build time fighting 404 errors caused by model names that appear in tutorials and documentation but are no longer available for new API accounts. There's no clear "here's what you should actually use if you created an account this month" guide. For a developer experience that's supposed to feel magical, the onboarding friction is real and it's the first thing a new user hits.

The structured JSON output reliability also has room to improve. Even with explicit instructions to return only raw JSON, Gemini occasionally wrapped the response in markdown code fences, which broke my parser until I added a cleanup step. A native structured output mode — where you pass a schema and get guaranteed valid JSON back — would eliminate this entirely and make Gemini dramatically more useful for production applications that depend on parseable responses.

Despite the friction, I'd use Gemini again without hesitation. The output quality when it works is genuinely ahead of what I've seen from other models for this kind of reflective, nuanced text generation. I just want the path from "I have an API key" to "I have working output" to be shorter.

BridgeTheGap: Turning GitHub Intimidation into First PRs

Tombri Bowei — Sat, 28 Feb 2026 23:33:40 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I built this for the aspiring open-source contributor.

We’ve all been there: You want to contribute to a major project, but you open a repository and feel hit by a "Wall of Code". It’s intimidating, the issues are full of jargon, and you don’t know where to start. This community is full of talent, but they are often stuck behind a "contribution paralysis" barrier. I wanted to build a bridge to help them cross it.

What I Built

FirstPRCpncierge is an AI-powered "Contribution Concierge".

Instead of scrolling through thousands of GitHub issues, users simply enter their GitHub username. The app analyses their most-used languages and matches them with real-time "Good First Issues" that actually fit their skill level.

The "Magic" Feature:
The app uses AI to "demystify" complex issues. It takes a technical GitHub description and translates it into a 3-step beginner roadmap:

📂 Where to look: The specific folders to explore.
🛠️ What to change: A plain-English explanation of the logic.
🧪 How to test: How to verify the fix works.

Demo

✨ Try FirstPRConcierge. Live: https://first-pr-concierge.vercel.app/
Demo video: https://youtu.be/-X8p4mz4Wy0
Watch how the AI breaks down a complex React issue into a 60-second roadmap.

Code

GitHub Link: https://github.com/Boweii22/First-PR-Concierge

How I Built It

I wanted the app to be lightning-fast and accessible, so I chose a modern, high-performance stack:

Framework: Next.js 15 for seamless server-side rendering.
Styling: Tailwind CSS + Shadcn/UI to give it a professional, trustworthy "SaaS" aesthetic that judges love.
Intelligence: Gemini API (or OpenAI) to power the "Issue De-mystifier".
Data: GitHub REST API to fetch live issues and user profile data.

The hardest part? Fine-tuning the AI prompt to ensure it didn't just give the answer but gave the guidance a mentor would provide. I wanted to make sure users still learned by doing.

I Built DevConnect — Because My Developer WhatsApp Group Is a Goldmine That Keeps Forgetting Everything

Tombri Bowei — Sat, 28 Feb 2026 04:29:52 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I'm part of a developer WhatsApp group. Over 100 members. All time zones. Every stage — from someone writing their very first console.log to senior engineers who've shipped at scale.
It's one of the best communities I've ever been part of.
And it has a devastating problem.
Someone asks a brilliant question about async/await. Three senior devs drop genuinely life-changing explanations. A resource gets shared that would have saved you six hours last week. An accountability thread starts where people share what they're building.
Then 48 hours later?
Gone. Buried under good morning messages, memes, and someone asking the same async/await question again.
The knowledge was there. The people were there. But WhatsApp has no memory. Every insight, every resource, every connection — evaporates.
I've watched this happen week after week. And this weekend, I finally did something about it.

What I Built

DevConnect — a dedicated community platform that acts as the organised, permanent layer on top of your existing WhatsApp group.

Your WhatsApp group keeps the chat. DevConnect keeps the knowledge.

The idea is simple: your admin shares a 6-character invite code in the WhatsApp group. Members join DevConnect with that code. From that point forward, everything valuable gets posted here — where it lives forever, stays searchable, and is actually findable when you need it.
Core Features
📬 Four post types — because not all posts are the same:

❓ Need Help — post a question, get threaded replies from people who actually know the answer
💡 Share — drop a resource, article, or lesson learned. It auto-saves to the Resources library
🤝 Collab — find an accountability partner, a code reviewer, or someone to build with
📅 Weekly Goal — post what you're working on this week. The community keeps you honest

👥 Member Directory — finally know who in your group is good at what. Filter by skill level (Beginner / Mid-level / Senior) or search by technology. No more posting "does anyone know Rust?" into the void
📚 Resources Library — every Share post with a link automatically appears here. Tagged, searchable, permanent. The link graveyard problem: solved
🔑 Invite-only Communities — your community stays private. Only people with your code can join. Share the code in WhatsApp, keep the knowledge in DevConnect
❤️ Likes & Replies — the best answers rise. The community rewards good knowledge

Demo

🚀 Live app: https://devvconnectt.netlify.app/app
To try it:

Sign up — you'll need an email and password to create an account. Don't want to use your real email? A throwaway like test@mailinator.com works perfectly fine
Click Create a Community and set up your profile (name, bio, skill level, skills)
Share the invite code with a friend (or open a second browser tab, sign up with a different email, and join with it)
Start posting — try all four post types
Check the Member Directory and Resources Library

Code

Github Link : https://github.com/Boweii22/devconnect

How I Built It

The Stack

Architecture
The frontend talks exclusively to the Express API — never directly to Supabase. The API uses the Supabase service-role key server-side, so the database is never exposed to the client. Every route is protected by JWT middleware that verifies the token against Supabase Auth before anything happens.
The invite code system works properly: codes are generated server-side, stored in the database, and validated on join. If you enter a code that doesn't exist, you get an error. If you've already joined that community, it handles that gracefully too.

Database Schema
Six tables cover everything:
profiles → extends auth.users (name, bio, level, skills[])
communities → name, description, invite_code (unique), creator_id
community_members → community_id + user_id (unique pair)
posts → type, title, body, link, tags[], author_id, community_id
replies → post_id, author_id, text
post_likes → post_id + user_id (unique pair, toggleable)

Row-level security enabled on all tables. Indexes on every foreign key and the posts feed query.

The Honest Part
The bit that actually stumped me longest wasn't the database schema or the auth flow. It was the invite code join logic — specifically handling the case where someone joins, leaves the tab open, and tries to join again from a different window. The server needs to check membership, return the community either way, and not throw a duplicate key error. Tiny edge case, genuinely fiddly to get right. But getting it right is what separates something that looks like a real app from something that is one.

The community this was built for has been running for years on WhatsApp. The knowledge has always been there. The people have always been there. This weekend I just gave it somewhere to live.
If your dev group has the same problem — try it. The invite code is the same one you'd drop in your WhatsApp chat.

We Built Voice Chat That Lives Entirely in Your Terminal (Yes, Really)

Tombri Bowei — Sun, 15 Feb 2026 01:18:21 +0000

This is a submission for the GitHub Copilot CLI Challenge

What we Built

VoiceSync — because who needs a GUI when you can have hacker vibes? 😎

We built a fully functional voice chat app that runs entirely in your terminal. It's like Discord and Zoom had a baby and raised it on command-line aesthetics.

Here's what makes it actually sick:

🎙️ Real-time voice chat with live waveform visualization (you can literally SEE sound waves)
🔐 End-to-end encryption (AES-256-GCM + Diffie-Hellman because we're not savages)
💬 Text chat + desktop notifications (so you know when your friend roasts you)
🌍 Works over the internet via ngrok tunnels
🤖 Built-in AI assistant powered by GitHub Copilot CLI (yeah, Copilot inside Copilot; we went there)
📊 Audio quality indicators showing latency, bitrate, and packet jitter in real-time
👥 Join/leave notifications so you know who's lurking

Tech Stack: Node.js, WebSockets, SoX (for audio), Blessed.js (for the terminal UI), and a concerning amount of energy drinks.
Shoutout to my team: @muhammedameen_enesiibrah and @thecodedaniel — couldn't have debugged that audio echo nightmare without y'all 🙏

Demo

Screenshots to Add:

GitHub Repo: [https://github.com/Boweii22/Copilot]

Live Demo Recording: [https://youtu.be/vtDgEqb9GcU]

My Experience with GitHub Copilot CLI

The Good Stuff

Before Copilot: "How do I encrypt WebSocket audio streams again?"

After Copilot: gh copilot suggest "encrypt websocket audio stream nodejs" → instant answers

Copilot CLI was basically our third brain. We integrated it INSIDE the app so users can literally ask questions while using VoiceSync:

[You]: @copilot how does encryption work in this app?
[Copilot]: VoiceSync uses AES-256-GCM encryption with Diffie-Hellman key exchange...

Meta? Yes. Useful? Absolutely.

Real Scenarios Where Copilot Saved Us

The Audio Echo Bug from Hell We spent 3 days with the host hearing themselves twice. Copilot suggested checking if the server was broadcasting to itself. One line fix. Pain = over.

gh copilot explain "websocket server broadcasting to sender"

SoX Cross-Platform Nightmare

Windows uses -t waveaudio, Mac uses -d, Linux uses... something else? Copilot helped us write a config module that detects the platform and uses the right args.

gh copilot suggest "detect platform and use correct audio device args nodejs"

Terminal UI Rendering Issues Text was bleeding across panels like a cursed PowerPoint. Asked Copilot about Blessed.js batched rendering and it explained we were calling screen.render() too many times. Boom, fixed.

The "Oh Damn" Moment

The coolest part? We used Copilot so much during development that we thought: "What if users could do this too?" So we added @copilot as an in-app command. Now anyone using VoiceSync can ask questions without leaving the terminal. It's like having a dev team on standby.

Productivity Boost

Honestly? We probably saved 40-50 hours.

No more alt-tabbing to Stack Overflow
No more "wait let me Google that"
No more deciphering cryptic error messages alone

Copilot CLI became our debugging buddy, our documentation search engine, and our rubber duck all in one.

What We Learned

GitHub Copilot CLI isn't just for writing code — it's for understanding code. When we hit errors, instead of rage-Googling, we'd just:

gh copilot explain "SyntaxError: Unexpected token in JSON"

And it'd tell us we were trying to parse binary audio frames as JSON (which... yeah that makes sense now).

Try It Yourself

# Install
git clone https://github.com/Boweii22/Copilot
npm install

# Host a room
npm run host

# Join from another terminal/machine
npm run join -- localhost ABC123 YourName

Full instructions in the README. Works on Windows, Mac, and Linux. Requires Node.js and SoX (we documented EVERYTHING because we're not monsters).

Final Thoughts

We built this in a very short amount of time so it was quite a bit of disturbing stress 😭😅 while juggling sleep deprivation. GitHub Copilot CLI was the fourth team member we didn't know we needed. If you've ever thought "I wish I could ask my terminal for help" — you can now.

Also if you're still using Discord for voice calls with friends, you're missing out on the superior terminal experience. Come @ us. 😤

Built with: Way too much sweets, GitHub Copilot CLI, and the power of friendship (and WebSockets 😅)
P.S. — Yes, we know P2P would be cooler. That's v2.0. For now, enjoy self-hosted voice chat that actually works.
Team: @_boweii , @muhammedameen_enesiibrah , @thecodedaniel