DEV Community: Tombri Bowei

The Emotional Lifecycle of Every Side Project (A Map)

Tombri Bowei — Fri, 01 May 2026 00:07:22 +0000

You've been here before. You just didn't have a map.

You've done this enough times to know the pattern exists.

The surge of excitement. The quiet middle where everything gets hard. The weird guilt of abandoning something you cared about. The random Tuesday six months later when you open it again for no reason.

Every side project follows the same emotional arc. Not the same technical arc — the emotional one. The feelings arrive in the same order, at roughly the same intervals, with the same intensity, regardless of what you're building or how experienced you are.

The developers who finish things aren't the ones who escape this cycle. They're the ones who've mapped it. Who know which phase they're in. Who recognise the feeling that's trying to make them quit and call it by its name instead of listening to it.

This is that map.

Phase 1: The Spark ⚡

What it feels like: Electricity. Clarity. The specific euphoria of an idea that feels genuinely new.

You're in the shower. On a walk. Half asleep. And then — there it is. A problem you've had that nobody's solved properly. A tool you wish existed. A thing you could build that would be genuinely useful, genuinely interesting, genuinely yours.

The idea arrives fully formed in a way that never survives contact with reality but feels completely real in the moment. You can see the landing page. You can see the UI. You can see people using it. You open Notes and type three paragraphs in a row without stopping.

For a few hours — sometimes days — the idea is perfect. Untouched by execution. Unspoiled by the actual work of building it.

This phase is intoxicating and completely unreliable as a signal of anything. Every project that got abandoned started here. Every project that changed someone's life also started here.

The spark doesn't tell you which one this is.

The lie this phase tells you: This one is different. This one is the one.

The truth: Maybe. Doesn't matter yet. Write it down and start.

Phase 2: The Setup High 🛠️

What it feels like: Momentum without resistance. Pure possibility.

You create the repo. You scaffold the project. You pick the stack — and honestly this decision takes longer than it should because you're also half-dreaming about what this could become.

Everything in this phase is easy because nothing is real yet. You're not solving the hard problem. You're arranging the tools you'll use to solve it. And arranging tools feels like progress because technically it is.

The README gets written. The folder structure gets decided. The color palette gets chosen. You might even make a Figma file. You're building the scaffolding around a building that doesn't exist yet, and it feels fantastic.

This phase can last hours or days depending on how good you are at starting and how afraid you are of the actual work. Some people have perfected the Setup High into an art form — they have thirty perfectly scaffolded repositories and zero finished products.

The Setup High is the side project equivalent of buying running shoes.

The lie this phase tells you: Starting is the hardest part.

The truth: Starting is the easiest part. By a significant margin.

Phase 3: Early Momentum 🚀

What it feels like: Confirmation. You're doing it. It's actually happening.

The first real features exist. The thing works, roughly. You can open it in a browser and see something that resembles the idea in your head. The gap between vision and reality is still enormous but it's no longer infinite.

You're coding fast. Things are clicking. Each session ends with something visibly different from where it started. You tell someone about it — a friend, a partner, a Discord — and saying it out loud makes it feel more real.

This is the phase where the GitHub contribution graph starts looking good. Where the commits are daily. Where working on the project feels less like effort and more like play.

Sleep suffers. That's how you know it's real.

This phase is deceptive because it creates a false baseline. The pace feels sustainable. It isn't. The easy parts of any project get built first, by definition. The rate of visible progress will slow. When it does, your brain will interpret the slowdown as a sign that something is wrong.

Nothing is wrong. The easy parts just ran out.

The lie this phase tells you: I could ship this in two weeks.

The truth: Multiply that estimate by four. Minimum.

Phase 4: The First Wall 🧱

What it feels like: Friction. Sudden, unexpected, demoralising friction.

You hit the thing you'd been quietly avoiding thinking about. The hard technical problem at the centre of the project. The feature that doesn't have a clean solution. The architecture decision you deferred because you didn't want to deal with it yet.

Progress slows dramatically. Sessions that used to produce visible results now produce invisible ones — refactoring, thinking, reading docs, abandoning approaches, trying again. The gap between where you are and where you want to be stops shrinking.

You spend an entire evening on something that should take an hour. You close the laptop feeling like you went backwards. You open it the next day and spend twenty minutes staring before writing a single line.

This is where most projects die. Not because the problem is unsolvable. Because the slowdown feels like failure. Because the feeling of momentum was so good and this feeling is so bad and your brain presents abandonment as relief.

The First Wall is not a sign that the project is flawed.

It's a sign that the project is real.

The lie this phase tells you: Maybe this idea wasn't as good as I thought.

The truth: The idea is exactly as good as you thought. You just reached the part that requires actual work.

Phase 5: The Trough 🕳️

What it feels like: Contempt. For the project, the code, the original idea, yourself.

You open the codebase and feel nothing but irritation. The early decisions you made look naive. The code that felt clean two weeks ago looks like a mess. The original concept — the thing that felt so obvious and right — suddenly seems embarrassing.

You look at other people's projects. Everything they ship looks better than what you're building. You go on Twitter and see someone announce a product that's adjacent to your idea and it's already further along than you are and better designed and you feel a specific cocktail of envy and deflation that is deeply unpleasant.

The Trough is where you seriously consider:

Scrapping everything and starting over with a better architecture
Pivoting the idea entirely
Abandoning it and pretending it never happened
Finishing it really quickly just to be done with it even though "done" would mean shipping something you're not proud of

None of these are the right move. All of them feel like the right move.

The Trough is a phase. Not a verdict.

Every single project you've ever admired — every product you've used and loved, every open source tool you've depended on, every portfolio piece that impressed you — passed through a Trough. The difference between the ones that made it out and the ones that didn't is almost never quality. It's almost always just someone deciding to keep going when keeping going felt pointless.

The lie this phase tells you: This is when I should quit.

The truth: This is exactly when you shouldn't. The Trough means you're close to something real.

Phase 6: The Quiet Rebuild 🔧

What it feels like: Resignation, then something quieter. Steadier.

You stop expecting sessions to feel exciting. You start treating the project like a job — not in a bad way, in a professional way. You show up. You do the work. You close the laptop without needing it to have felt good.

Something shifts in this phase. The emotional charge fades and in its place comes something more durable: commitment. You're not building because it's fun anymore. You're building because you said you would. Because the idea still matters even when the feeling is gone. Because finishing is a skill and you're practicing it.

The code gets cleaner in this phase, not because you have more energy but because you have more clarity. The decisions you agonised over in the Trough resolve themselves quietly. You know the codebase well enough now to move through it with confidence even without enthusiasm.

This is the phase that separates the developers who ship from the ones who don't. Because nothing about this phase feels like a highlight. There's no story to tell. No dramatic breakthrough. Just sessions of steady, unremarkable work that collectively build the thing.

Most of the best software in the world was built mostly in this phase.

The lie this phase tells you: If I'm not excited, something is wrong.

The truth: Excitement is a spark. Commitment is a furnace. You need both but only one of them keeps burning.

Phase 7: The Emergence 🌅

What it feels like: Surprise. The thing is actually becoming what you imagined.

You can't pinpoint when it happened. One session you were grinding through the Quiet Rebuild and then suddenly — the pieces are connecting. The features that existed in isolation are working together. You load it in the browser and for the first time it looks like software. Real software. The kind someone else might actually use.

The gap between what you imagined in Phase 1 and what exists now is still real. But for the first time it feels closeable. The end is visible from where you're standing.

Excitement comes back, quieter than before, more earned. You find yourself thinking about it during the day. Making notes. Seeing things you want to fix, things you want to add. The project has gravity again.

This phase is also when you start getting scared in a new way. Before you were scared it would never be good enough. Now you're scared of what happens when you actually share it.

The lie this phase tells you: I should keep polishing. It's not ready.

The truth: It will never feel ready. That's not what ready means.

Phase 8: The Pre-Ship Spiral 🌀

What it feels like: Productive procrastination disguised as perfectionism.

You're so close. Which means every remaining imperfection is now visible and intolerable. The mobile layout is slightly off. The loading state isn't quite right. The copy on the landing page doesn't feel tight enough. The README needs one more pass.

You tell yourself you're being professional. Thorough. That you have high standards. All of that is true and also completely irrelevant because what's actually happening is fear.

Fear that it won't land. That nobody will care. That the people who do see it will see the cracks you can see. That shipping means accountability and not shipping means you can still believe it could be great.

The Pre-Ship Spiral can last days. For some projects it lasts long enough that the project never ships. The developer keeps polishing a thing in private indefinitely, always one small fix away from ready, until eventually the moment passes and the project joins the graveyard.

The only move is to pick a date and treat it like a non-negotiable.

Not when it's perfect. When it's good enough to be useful. Those are different things and conflating them is the thing that kills more good projects than any technical problem ever could.

The lie this phase tells you: Just one more thing and then it'll be ready.

The truth: Ship it. Now. Today. The version that exists beats the perfect version that doesn't.

Phase 9: The Deploy 🚢

What it feels like: A strange calm. Then nothing. Then something.

You push to production. You share the link somewhere — Twitter, dev.to, a Discord, a subreddit, an email to three people. You close the tab immediately because you can't watch.

The next twenty minutes are a specific kind of suspended animation. You refresh things you've already refreshed. You make tea you don't drink. You check your phone for no reason.

And then someone sees it. Someone clicks it. Someone says something — anything — and the thing that was only in your head and then only on your laptop and then only on a domain nobody knew existed is suddenly, unmistakably, real.

The feeling isn't always joy. Sometimes it's relief. Sometimes it's anticlimactic. Sometimes you feel less than you expected and that's confusing.

But underneath all of it, quiet and steady, is something that doesn't go away:

I built this. It exists. Nobody can unship it.

The lie this phase tells you: The response will tell me if it was worth it.

The truth: It was already worth it. The response is just data.

Phase 10: The Aftermath 🌊

What it feels like: Everything, in waves.

Pride. Vulnerability. The sudden, sharp vision of every flaw now that other people can see it. Unexpected gratitude when a stranger says it helped them. The strange loneliness of a project that's out in the world and no longer entirely yours.

And eventually, quietly, an itch.

A thing you'd do differently. A feature that would make it better. A new problem the project revealed that you want to go solve.

The cycle doesn't end. It just starts again, smaller, more confident, with the knowledge that you've been through this before and you know where it goes.

That knowledge doesn't make it easier.

But it makes it survivable. And survivable, for a builder, is enough.

The Map Is Not the Territory

Reading this won't stop you from feeling every phase as if it's happening for the first time. Emotions don't care that you've mapped them. The Trough will still feel like a verdict. The Pre-Ship Spiral will still feel like thoroughness.

But somewhere in the middle of Phase 5, when your brain is presenting quitting as the only reasonable option — maybe you'll remember you've seen this before. That you know what phase this is. That the map says you're closer than you feel.

That's all a map is for.

Not to remove the terrain. Just to remind you that others have crossed it.

And that the other side exists.

Which phase are you in right now? Drop it in the comments — no context needed, just the phase number. Let's see where everyone is on the map. 👇

Follow for more honest writing about the craft and psychology of building things.

The Most Important Announcement at Google Cloud NEXT '26 That Nobody Is Talking About

Tombri Bowei — Mon, 27 Apr 2026 23:57:04 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Everyone came out of Google Cloud NEXT '26 talking about the same things.

The Gemini Enterprise Agent Platform. The 8th-generation TPUs. The Apple partnership. The $32 billion Wiz acquisition is baked into their security stack. All legitimate, all impressive, all getting the clicks they deserve.

But buried 35 minutes deep inside the Developer Keynote — sandwiched between a Las Vegas marathon simulation and a joke about running being awful — was a two-minute demo of something called 'A2UI' that I haven't seen a single think piece about.

That's a mistake. Because A2UI is the announcement that will actually change what it means to be a frontend developer.

What Even Is A2UI?

Here's the demo setup from the keynote: the marathon planning system had an evaluator agent that scored proposed race routes. The problem was, how do you show those evaluation results to a user without hardcoding a dashboard?

The answer the team gave was A2UI. The agent didn't return the text. It didn't run code. It returned a declarative JSON description of a UI — cards, maps, scores, and components — and the frontend rendered it natively using its own existing widgets. The agent designed the interface. The frontend just executed it.

That's the shift. And it sounds subtle until you sit with it.

A2UI (Agent-to-User Interface) is an open standard — Apache 2.0, on GitHub, with contributions from Google and CopilotKit — that lets AI agents "speak UI". Instead of responding with a wall of text, an agent sends a structured JSON payload describing what the interface should look like. The client application maintains a trusted catalogue of pre-approved components (a Card, a Button, a DatePicker, a ``), and the agent can only compose from that catalogue. It cannot inject code. It cannot execute anything arbitrary. It declares intent, and the frontend renders it using its own native widgets.

The result: one agent response that renders natively across Angular, Flutter, React, and mobile — without a single extra line of UI code.

Why This Is Bigger Than It Looks

Let me frame the problem A2UI is actually solving, because the keynote moved too fast to do it justice.

Right now, when you build an AI agent, you face a brutal choice. Either you give it a fixed UI — hardcode the dashboard, predecide every screen, ship a design system and pray the agent's outputs fit the layout you chose — or you let it generate code on the fly, which is a security nightmare and a maintenance hell you don't want to have.

Neither option is good. Fixed UIs make your agent feel dumb ("why can't it just show me a chart?"). Generated code makes your security team quit.

A2UI is the third option nobody realised they were waiting for: declarative, sandboxed, generative UI.

The agent says: "I want to show the user a card with a map, two metric tiles, and a confirm button." The client says, "I have those components. Here they are, styled to my design system, following my security policies."* The user sees a beautiful, contextually appropriate interface that didn't exist in code five seconds ago.

What makes this genuinely new — and genuinely safe — is that the agent cannot reach outside the catalogue. There's no UI injection vector. There's no arbitrary code execution. The trust boundary is clean. The developer stays in control of what components exist. The agent only gets to compose.

The Keynote Demo Undersold It

In the marathon simulation demo, the presenters used A2UI to render a route evaluation card. Nice. Functional. Easy to gloss over.

But watch what happens when you extend that idea:

Imagine a customer support agent. A user files a complaint. Instead of the agent dumping a paragraph of text, it generates a structured claim form — pre-filled with the details it already knows, with a date picker for the incident, a dropdown for severity, and a submit button wired to your existing backend. The agent composed that form. Your design system rendered it. The user never typed more than they had to.

Imagine a developer tools agent. A user asks, "What's wrong with my deployment?" Instead of a wall of logs, the agent returns a tabbed interface: one tab for errors, one for warnings, and one for a recommended fix with a one-click apply button. The agent decided that three tabs were the right answer to this question. Tomorrow it might decide a timeline view is better. You didn't write either layout.

This is what the keynote called moving "beyond walls and walls of text". That's underselling it. What A2UI actually moves us beyond is the assumption that the UI is a static thing that developers design in advance and agents fill in. The interface itself becomes a runtime decision. The agent decides what shape the information should take.

Where It Stands Right Now

A2UI is currently at v0.9 (Public Preview), just updated two weeks ago. It's functional, it's on GitHub, and it already supports Angular, Flutter, Lit, and React renderers. The v0.9 release added a shared web-core library, an official React renderer, client-defined functions for validation, and a new Agent SDK that handles streaming, version negotiation, and incremental parsing — so the UI builds in real-time as the agent generates it, rather than waiting for a full JSON block to arrive.

It's not 1.0 yet. The spec is still evolving. Some renderer integrations are more mature than others. But the core idea is stable, the open-source community is active (CopilotKit has already shipped an A2UI starter template and composer tool), and Google is clearly building it into the broader ADK/A2A/Gemini stack as a first-class citizen.

The trajectory is obvious: every agent that ships on Google's platform will eventually be able to speak A2UI. Every frontend that integrates the renderer gets dynamic, agent-composed interfaces for free.

What This Means for Frontend Developers

I want to be precise here, because I'm not making a doom-and-gloom argument.

A2UI doesn't make frontend developers obsolete. It changes what they build.

Instead of building screens, you'll build component catalogues — the vocabulary the agent is allowed to speak. Instead of designing flows, you'll define the grammar. Instead of wiring up every state transition, you'll write the rendering logic once and let the agent decide when and how to assemble it.

That's actually a more interesting job. You're no longer implementing a specific user journey. You're building a system that can express any user journey the agent determines is appropriate.

But it does mean the instinct to hardcode — to say "this agent always shows a table, this one always shows a form" — will increasingly be the wrong instinct. The instinct you want is "What components does this agent need access to, and what should it never be able to render?"

Frontend developers who think in those terms will be indispensable in the agentic era. Those who keep thinking in terms of fixed layouts will find themselves constantly rebuilding UIs to accommodate agent outputs that don't fit the box they designed.

The Underrated Bet

Google announced a lot at NEXT '26. The TPUs are extraordinary. The agent platform is genuinely ambitious. The Apple partnership is a strategic earthquake.

But A2UI is the announcement with the longest tail.

Every other announcement requires infrastructure, budget, and migration planning. A2UI is a protocol. It's open source. It runs today on the frameworks developers already use. It's the kind of thing that quietly becomes load-bearing in the ecosystem before anyone agrees it's important.

It got two minutes on stage at the developer keynote. It deserved twenty.

If you build agents, go read the A2UI spec. If you build frontends that agents talk to, go integrate the renderer. If you're designing the next generation of AI-powered products, go think hard about what a component catalogue means for your design system.

The marathon demo was fun. But A2UI is what I'll still be thinking about in six months.

What It Actually Feels Like to Build Something You're Proud Of

Tombri Bowei — Mon, 27 Apr 2026 21:45:52 +0000

Nobody talks about the emotional side of shipping. Let's fix that.

There's a specific kind of silence that happens right after you deploy something real.

Not the silence of a bug you haven't found yet. Not the silence of waiting for the CI pipeline to clear. A different kind. The kind where you close your laptop, lean back, and just... sit with it.

If you've felt it, you know exactly what I mean.

If you haven't felt it yet, this article is for you.

It Doesn't Start With Excitement. It Starts With Dread.

Here's what nobody puts in their "I shipped a side project!" LinkedIn post:

The beginning is awful.

You open a blank index.html or a fresh one, and suddenly the weight of the idea feels crushing. You had a vision in your head. Fully formed. Beautiful. And then you look at a white screen with a blinking cursor, and the gap between what you imagined and what currently exists feels insurmountable.

This is the part people skip when they talk about building things. They show you the polished Figma mockup, the finished landing page, and the GitHub repo with 400 stars. They don't show you the three hours they spent just trying to decide on a folder structure.

The dread is real. The friction is real. And it's not a sign that you're doing it wrong — it's the price of entry for building something that actually matters to you.

The gap between your taste and your current ability is not a flaw in you. It's evidence that your taste is working.

This is a real thing. The people who never feel that gap are the people who don't have high standards for their own work.

The Middle: Where Most Things Go to Die

At some point in every project — usually around 40% of the way through — you will hate it.

Not mildly dislike it. Hate it. You'll look at what you've built and feel nothing but contempt. The colours feel wrong. The code feels messy. The whole concept suddenly seems embarrassing. You'll open Twitter, see someone ship something that looks better than yours, and quietly close your laptop.

This is the trough. Every creative person has a name for it:

Writers call it the 'saggy middle'.
Musicians call it 'demo-itis'.
Filmmakers call it the 'rough cut that makes the director cry'.

For developers, it's the moment you seriously consider scrapping everything and starting over. Or worse — just abandoning the project entirely and telling yourself you'll "come back to it later".

You won't come back to it. We both know that.

The only way out of the trough is through it.

Not around it. Not by pivoting to a new idea. Not by starting fresh. Through. Keep pushing. Ship something. Iterate. The feeling on the other side is worth it in a way that's almost impossible to describe until you've experienced it.

The Moment the Thing Comes Alive

And then—if you survive the trough—something shifts.

It's usually small. An animation finally feels right. Two components click together in a way you didn't plan. You load it in the browser, and for the first time it looks like the thing you imagined at the beginning. Not exactly. Better.

This is the moment developers don't talk about enough. When the project stops being a problem you're solving and starts being a thing that exists in the world. When you catch yourself using your own app and forgetting that you built it.

I've spoken to dozens of developers about this moment, and the words they reach for are almost always the same:

"It felt real."

Not finished. Real. There's a difference. Finished is when all the tasks are done. Real is when it stops feeling like a side project and starts feeling like software.

What Shipping Actually Feels Like

Here's the emotional sequence — as honestly as I can write it:

T-minus 1 hour: Quiet panic. You're finding small things to fix that don't need fixing. You're re-reading your README for the fifth time. You're refreshing your deployment preview.

T-minus 10 minutes: Resignation. You've accepted that it's not perfect. That there are still edge cases you haven't handled. That the mobile nav is slightly off on the iPhone SE. You hit deploy anyway.

T-zero: A strange calm. The kind that comes after a decision is made and can't be unmade.

T-plus 5 minutes: You share it somewhere. A tweet. A Discord. Submitting to dev.to. And then you close the tab immediately because you can't watch.

T-plus 20 minutes: You open the tab. Someone liked it. Someone actually looked at the thing you made. And something in your chest does a thing that's hard to describe — it's not quite pride, not quite relief. It's closer to vindication. Proof that the idea wasn't just in your head.

T-plus a few days: You look at it again, and you can see every flaw clearly. But you don't feel ashamed of them. You feel like a person who made a real thing and learned real things in the process of making it.

That's it. That's what shipping feels like.

The Thing About Being Proud of Your Work

Pride is a complicated word in developer culture. We're trained to be humble. To say "it's just a side project" is to minimise it. To pre-emptively apologise for the code quality before anyone even looks at it.

But there's a version of pride that has nothing to do with arrogance. It's the quiet satisfaction of knowing that something exists because you made it exist. That a year ago it was nothing, and now it is something. That if you didn't build it, it simply wouldn't be there.

That's not arrogance. That's a craft.

The developers I respect most aren't the ones with the cleanest code or the most GitHub stars. They're the ones who finish things. Who ships things? Who look at what they've built and – even knowing all the shortcuts they took and all the technical debt they accumulated – feel something?

Because code without feeling is just syntax. It's the feeling that makes it worth building.

What I've Learned From Building Things I'm Proud Of

A few things that are actually true, earned from time in the trough:

Constraints make you more creative, not less. The projects I'm most proud of weren't the ones with unlimited scope. They were the ones where I had a weekend, a weird idea, and no time to second-guess myself.

The version you ship will always feel unfinished. Ship it anyway. "Done and public" beats "perfect and private" every single time.

Other people's opinions of your work are data, not verdicts. When someone loves what you built, it tells you something useful. When someone doesn't, it also tells you something useful. Neither defines whether you should keep building.

The pride compounds. The first thing you ship feels terrifying. The second feels hard. By the tenth, shipping is just something you do. The fear never fully goes away — but it gets smaller relative to the satisfaction.

Building something you're proud of changes how you see yourself. Not in a dramatic way. In a quiet way. You start to think of yourself as someone who makes things. And that identity — builder, creator, maker — is one of the most useful identities a developer can carry.

A Question for You

What's the thing you've built that you're most proud of? Not the most technically impressive. Not the one with the most stars or the most users.

The one that made you feel something when you shipped it.

Drop it in the comments. I want to see what you've made.

If this resonated with you, follow along — I write about the craft and psychology of building things as a developer, not just the technical how-tos. Real talk, no fluff.

The Honest Windows Guide to OpenClaw: What I Learned After a Full Day of Errors

Tombri Bowei — Sun, 26 Apr 2026 21:25:25 +0000

This is a submission for the OpenClaw Writing Challenge

I'm going to be straight with you: I did not finish my OpenClaw project today.

I set out to build ClearView — an accessibility skill that would let blind and low-vision users describe their screen, read documents, and navigate their computer just by messaging a Telegram bot. Great idea. Real use case. I was excited.

What I actually spent my day doing was fighting Windows.

And I'm writing this post because when I was googling every error I hit, I found nothing useful. Every OpenClaw tutorial assumes you're on a Mac. Every setup guide breezes past the "install it and run it" step like it's nothing. For Windows users — especially those using nvm4w — it is very much not nothing.

So here's the guide I wish existed. The honest one. With the real errors and the real fixes.

What I Was Building

The idea was simple: a skill for blind and low-vision users that lets them message their bot and get back a plain-English description of whatever is on their screen, or have documents and images read aloud to them. No new apps to learn. No complex interface. Just Telegram, OpenClaw, and Claude's vision capability.

It's a real problem worth solving. Screen readers are expensive, rigid, and require training. Claude can describe a screenshot in plain language instantly. The gap between those two things is exactly what OpenClaw is built to bridge.

I didn't finish the skill. But I did get OpenClaw running on Windows — and that alone took most of the day. Here's everything I learned.

The Setup: What the Docs Say vs What Actually Happens

1. Node version matters — but so does how you installed it

The docs say you need Node 22 or 24. Fine. What they don't tell you is that if you installed Node via nvm4w (Node Version Manager for Windows), OpenClaw may not find it correctly.

When I first tried to launch the gateway, I got the following:

Error: failed to launch TUI: spawn C:\Program Files\nodejs\node.exe ENOENT

The problem: nvm4w stores Node at C:\nvm4w\nodejs\node.exe, not the default path OpenClaw expects. The fix is to run Command Prompt as Administrator — this ensures the path resolves correctly. Every single time. Don't skip this step.

2. The Telegram plugin EPERM error

When I first ran the gateway, I saw this buried in the logs:
[plugins] telegram failed during register: Error: EPERM: operation not permitted,
rename '....plugin-telegram-lubdRt\plugin' -> '...\telegram'

This is Windows blocking OpenClaw from renaming a temp folder during plugin setup. The fix is the same: run as Administrator. Once I did that, the error disappeared and Telegram loaded cleanly.

3. Setting your Telegram token — the right command

During onboarding I tried:
openclaw config set telegram.token "YOUR_TOKEN"

This gives you:
Error: Config validation failed: : Unrecognized key: "telegram"

The correct command is:
openclaw channels add --channel telegram --token "YOUR_TOKEN_HERE"

That's it. One line. Not in the getting started docs anywhere that I could find.

4. Setting your Claude API key

Similarly, trying to set the Anthropic key through config commands doesn't work intuitively. The way that actually worked for me was:
openclaw configure

Select Model from the sections list, choose Anthropic, and paste your sk-ant- key when prompted.

5. Starting the gateway — use `--force`

Plain openclaw gateway would start, reach the ready state, then crash with:
Unhandled promise rejection: CIAO PROBING CANCELLED

This is a bonjour/mDNS issue on Windows. The fix:
openclaw gateway run --force

This kills anything stuck on port 18789 first and starts clean. After running this as Administrator, my gateway finally stayed alive.

The Correct Setup Sequence for Windows

If you're on Windows and want to save yourself a day, here is the exact order of commands that works:

1. Open Command Prompt as Administrator

2. Install OpenClaw
npm install -g openclaw@latest

3. Add your Telegram bot token
openclaw channels add --channel telegram --token "YOUR_TELEGRAM_BOT_TOKEN"
(Get your token from @botfather on Telegram — send it /newbot and follow the steps)

4. Set your Claude API key
openclaw configure
Select Model → Anthropic → paste your sk-ant- key

5. Start the gateway
openclaw gateway run --force

6. Wait for this line:
[gateway] ready

That's it. You're running.

What I Actually Learned About OpenClaw

Here's the thing — even through all the frustration, I came away genuinely impressed by what OpenClaw is trying to do.

The skill system is clever. A SKILL.md file with plain-English instructions that the AI interprets at runtime — no complex APIs, no schema, just natural language. That's the right abstraction for this kind of tool. It means anyone can build a skill, not just developers.

The channel architecture is smart too. The same agent, the same skills, accessible through Telegram, WhatsApp, Discord — whatever messaging app you're already using. That's meaningful for accessibility specifically: you're not asking someone with a disability to learn a new interface. You're meeting them where they already are.

The Windows experience is rough right now. The docs assume Unix. The errors are cryptic. The setup is slower than it should be. But the core idea — a personal AI that lives on your own machine, uses your own API keys, and does exactly what you tell it — is genuinely different from everything else out there.

What ClearView Would Look Like (When I Finish It)

For anyone who wants to build the accessibility skill I was attempting, here's the SKILL.md I wrote — it just needs a working gateway underneath it:

---
name: clearview
description: Accessibility assistant. Describes images, reads text, narrates screen content for blind and low-vision users.
---

## ClearView

When the user sends an image or photo:
1. Describe everything visible in plain simple English
2. Read ALL text visible — buttons, menus, labels, errors
3. Describe layout — top, middle, bottom, left, right
4. Describe what buttons and icons do, not just what they look like
5. End with a one sentence summary

When the user sends a photo of a document, letter, or printed text:
1. Read all text from top to bottom
2. Note headings and structure
3. Summarise what it is about

When asked "what's on my screen?":
1. Take a screenshot
2. Describe it fully as above

Rules:
- Say "The screen shows..." not "I can see..."
- Always prioritise text over design descriptions
- If blurry or unclear, say so honestly

Drop that in ~/.openclaw/workspace/skills/clearview/SKILL.md and restart your gateway. That's the whole skill.

The Honest Take

Most OpenClaw posts you'll read this week are going to be polished success stories. Person builds thing, thing works, here are the screenshots.

This isn't that. I spent a full day on setup, hit six different errors, and didn't finish the project I set out to build.

But I think that's worth writing about too — because the Windows experience is a real gap, and the next person who hits CIAO PROBING CANCELLED at midnight deserves to find an answer.

OpenClaw has a lot of potential. The Windows setup needs work. Both things are true.

I'll finish ClearView. Just not today.

Have you built something for accessibility with OpenClaw? Or hit different errors on Windows? Drop them in the comments — I want to know what I missed.

I Built an App That Listens to Your Garden and Tells You What's Disappearing. 🌍

Tombri Bowei — Fri, 17 Apr 2026 23:03:13 +0000

I Built an App That Listens to Your Garden and Tells You What's Disappearing 🌍

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

I tested this, I pointed my mic at my garden one evening.

Gemini picked up a cricket, a crow, a frog, and a small passerine bird within ten seconds.

Every single one came back DD - Data Deficient.

Not endangered. Not safe. Just... unknown. The IUCN doesn't have enough data to even assign them a threat level. They exist. We just haven't studied them enough to know if they're okay.

That felt more unsettling than a red label would have.

Last Breath is a real-time acoustic biodiversity monitor that runs entirely in the browser. You press record, point your microphone at any outdoor environment for ten seconds, and it tells you:

Every species present in that soundscape — identified by acoustic signature alone using Google Gemini 2.5 Flash
The real IUCN Red List conservation status of each detected species
Whether their population is increasing, stable, or in freefall
For the ones that are falling — roughly how many breeding seasons remain in your region
A biodiversity health score from 0–100 for the soundscape you just recorded

Every sighting can be logged as a verified conservation record through Auth0 authentication and stored in a live global map shared across every user of the app in real time.

The world is going quiet. Most people have no idea it's happening outside their window. Last Breath makes it impossible to ignore.

Demo

🔴 Try it live → last-breadth.vercel.app

📹 [Watch the demo → https://www.youtube.com/watch?v=HkCItSU0nvs]

Best experienced outdoors or near an open window. Early morning gives the richest soundscapes.

Here's what a session looks like:

Press record — a live waveform visualises your soundscape in real time
Ten seconds. Gemini analyses every acoustic signature present
Species cards slide in one by one as IUCN data loads in parallel
One card turns red — Common Swift · Endangered · ↓ Decreasing · ~12 breeding seasons remaining in London
You log the sighting. It pins to the global map. Someone in Lagos, Tokyo, or São Paulo sees it.

Code

Boweii22 / LastBreadth

Last Breath

An acoustic biodiversity monitor that listens to the world and tells you what's disappearing.

Point a microphone at any outdoor environment — a garden, a forest edge, a park at dawn — and Last Breath identifies every species by sound, cross-references each one against the IUCN Red List, and gives you a real-time biodiversity health score for that place. Verified sightings are logged to a live global map shared across all users.

The Problem

We are living through the sixth mass extinction. Most people have no idea it is happening outside their window. Acoustic monitoring — listening for the species present in a soundscape — is one of the most sensitive and non-invasive ways to measure biodiversity. Field researchers have done this for decades with expensive equipment and months of manual analysis. Last Breath brings the same capability to anyone with a browser.

Demo

Record a 10-second clip…

View on GitHub

How I Built It

Why this exists

Apps like Merlin and BirdNET already identify birds by sound. But they stop at identification — they tell you what is there, not what it means. They don't show you that the species you just heard is in freefall. They don't give you a way to act on it. That gap is what Last Breath fills.

The audio pipeline

When you press record, two things happen simultaneously:

A MediaRecorder captures the audio stream as a blob
An AnalyserNode reads frequency data 60 times per second and draws a live waveform on canvas

After ten seconds the blob converts to base64 and hits /api/analyse — a Vercel serverless function that injects the Gemini API key server-side and forwards raw audio to Gemini 2.5 Flash with a bioacoustician system prompt. No preprocessing. No spectrograms. Raw audio in, structured conservation JSON out.

// Sending audio directly to Gemini — no preprocessing needed
{
  contents: [{
    parts: [
      { text: BIOACOUSTICIAN_PROMPT },
      { inline_data: { mime_type: 'audio/webm', data: base64Audio } }
    ]
  }],
  generationConfig: { temperature: 0.1 }
}

The conservation layer

For each detected species, two parallel IUCN API calls fire immediately — threat category + population trend, and habitat narrative. All lookups run with Promise.allSettled() so a failed lookup never blocks the others. Cards render progressively as each resolves.

The biodiversity health score is calculated from the threat categories present:

Status	Score impact
CR — Critically Endangered	−15
EN — Endangered	−10
VU — Vulnerable	−6
NT — Near Threatened	−3
LC — Least Concern	+2
DD — Data Deficient	0

LC is the only status that adds to the score — hearing healthy species is a positive signal. The score renders as an animated SVG ring gauge, colour-coded green above 70, amber 40–70, red below 40.

The extinction countdown

This was the hardest design decision. Showing "~12 breeding seasons remaining" is blunt. But abstract statistics about wildlife decline stop meaning anything after a while — they become wallpaper. A countdown attached to a sound you just heard outside your window in London is different. It's not about the Amazon. It's about your garden. That specificity is the whole point.

Security

Every external API call is proxied through three Vercel serverless functions:

api/analyse.js — injects GEMINI_API_KEY, handles 429/503 retries with automatic model fallback
api/iucn.js — injects IUCN_API_TOKEN, handles the two-step v4 taxa → assessment lookup
api/sightings.js — injects SUPABASE_SERVICE_KEY, validates all reads and writes

Open DevTools on the live app — you will not find a single API key anywhere in the browser.

The global map

Sightings live in Supabase PostgreSQL. Every user sees every other user's observations — not just their own. The map uses Leaflet with CartoDB Dark Matter tiles, markers colour-coded by IUCN status. The goal was a living document — a record of what the world still sounds like, built collaboratively by people who stopped and listened.

Tech stack

Layer	Technology
Frontend	Vanilla HTML, CSS, JS — zero frameworks
AI analysis	Google Gemini 2.5 Flash
Conservation data	IUCN Red List API v4
Authentication	Auth0 Universal Login
Database	Supabase (PostgreSQL)
Map	Leaflet.js + CartoDB Dark Matter
Hosting	Vercel (static + serverless functions)

Prize Categories

Best Use of Google Gemini

Gemini 2.5 Flash is the entire engine of this application. It receives raw audio — no preprocessing, no feature extraction — and identifies species by acoustic signature alone, returning structured conservation-ready JSON. I used the multimodal audio input capability via the generateContent API with an inline base64 audio blob. The bioacoustician system prompt was iterated across many real outdoor recordings to balance species recall with reliable output. The api/analyse.js function includes automatic retry logic and model fallback for overload responses.

Best Use of Auth0 for Agents

Auth0 Universal Login handles all authentication via the SPA SDK. The auth layer is the trust mechanism for the shared global map — only verified, authenticated users can write to Supabase. Every logged sighting stores the user's Auth0 sub ID and display name alongside the observation, making every map pin attributable to a real verified observer. This transforms the map from a database into a ledger of provable human action — which felt important for something intended to be taken seriously as a conservation record.

73% of the world's wildlife has disappeared since 1970. That number is so large it stops meaning anything.

Last Breath is an attempt to make it small again. Local. Personal. The size of a garden in London.

We are not going to solve the sixth mass extinction with a web app. But we might start building a record of what we still have. And records matter. Silence is harder to ignore when you've heard what it's replacing.

Point your mic at the world. Find out what's still there.

last-breadth.vercel.app

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. 🌍💙

DEV Community: Tombri Bowei

The Emotional Lifecycle of Every Side Project (A Map)

Phase 1: The Spark ⚡

Phase 2: The Setup High 🛠️

Phase 3: Early Momentum 🚀

Phase 4: The First Wall 🧱

Phase 5: The Trough 🕳️

Phase 6: The Quiet Rebuild 🔧

Phase 7: The Emergence 🌅

Phase 8: The Pre-Ship Spiral 🌀

Phase 9: The Deploy 🚢

Phase 10: The Aftermath 🌊

The Map Is Not the Territory

The Most Important Announcement at Google Cloud NEXT '26 That Nobody Is Talking About

What Even Is A2UI?

Why This Is Bigger Than It Looks

The Keynote Demo Undersold It

Where It Stands Right Now

What This Means for Frontend Developers

The Underrated Bet

What It Actually Feels Like to Build Something You're Proud Of

It Doesn't Start With Excitement. It Starts With Dread.

The Middle: Where Most Things Go to Die

The Moment the Thing Comes Alive

What Shipping Actually Feels Like

The Thing About Being Proud of Your Work

What I've Learned From Building Things I'm Proud Of

A Question for You

The Honest Windows Guide to OpenClaw: What I Learned After a Full Day of Errors

What I Was Building

The Setup: What the Docs Say vs What Actually Happens

1. Node version matters — but so does how you installed it

2. The Telegram plugin EPERM error

3. Setting your Telegram token — the right command

4. Setting your Claude API key

5. Starting the gateway — use --force

The Correct Setup Sequence for Windows

What I Actually Learned About OpenClaw

What ClearView Would Look Like (When I Finish It)

The Honest Take

I Built an App That Listens to Your Garden and Tells You What's Disappearing. 🌍

I Built an App That Listens to Your Garden and Tells You What's Disappearing 🌍

What I Built

Demo

Code

Boweii22 / LastBreadth

Last Breath

The Problem

Demo

How I Built It

Why this exists

The audio pipeline

The conservation layer

The extinction countdown

Security

The global map

Tech stack

Prize Categories

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

What I Built

Video Demo

Show us the code

How I Used Notion MCP

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

The Problem I Solved (For Myself)

The Honest Part

What Changed Everything

What I Learned

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

The Pattern

What I Learned

What I'm Curious About

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

What I Built

Video Demo

Show us the code

How I Used Notion MCP

The FullStack

What Notion MCP Actually Unlocked

What's Next

5. Starting the gateway — use `--force`