Building Comms Nexus: a local command center for all my chats
How I turned a broken Beeper extension into a local, cyberpunk command center that unifies all my chats — the decisions, the architecture, and the bugs that taught me the API.
TABLE OF CONTENTS
I have a rule for any new build: spend the time up front getting the brief right, then let the AI do the heavy lifting. For Clicker Foundry, that meant three hours writing a proper PRD before I asked Claude to build the first prototype.
I wanted to build a clicker fidget app that took any image and convert it into a ready to print STL file clicker keychain.
The approach was simple: Upload an image, choose the shape of your clicker, then generate for print.
The starting PRD approach helped. Instead of prompting my way into a vague software, I had a clear spec: upload an image, trace it into layers, pick a base shape and click mechanism, assign colours, preview in 3D, export print-ready files. When I finally handed it to Claude, the first result was not what I expected.
Where it got messy
The uploaded image worked. but I don’t know what tool it used to trace or the backbone of its code. The image tracing output was not clean enough. Some details were lost from the original and I don’t know why.
There was also confusion on my side about the errors made during the coding process so I burned up the usage limit. When you are the designer, the PM, and the tester all at once, it is easy to lose track of what you asked for versus what you got. I don’t have the technical chops to know with if the model really built the foundation properly.
That is a real lesson for anyone building with AI: the model builds what you describe, and when the result confuses you, the confusion usually started in the brief when you don’t define them about how it gets done.
This meant to me that I need to define steps much clearer.
The physical reality check
Because both the PRD and I had direction but lack technical guidance, Claude had to do a lot of trial and error along side my inputs. This felt like R&D and a necessary one that paved the way for the build to get better over the next few runs. I just ran with it.
The AI gave me test prints with little changes to see which switch would be a good fit with some slight tolerances. I also later on also gave other good examples of stl files online that others have already modelled for it to countercheck.
This ended up being the smartest part of the process. Software iterates in seconds, but a clicker either clicks or it does not. Getting physical parts in hand early told us more about tolerances and fit than any amount of on-screen previewing.
Borrowing inspiration
At the point where most people would call it a failed experiment, I got more determined. I had Claude compare my prototype against an existing clicker app, feature by feature, to see where mine fell short and where it could stand apart. That comparison reframed the whole thing. I stopped trying to fix a broken prototype and started designing a better one.
At this stage, things look really decent but nowhere near ready to ship.
Related Posts
Structure First, Then AI: Lessons From This Week's Notion AI Office Hour
A recap of this week's Notion AI Office Hour — the four levels of AI usage, why Notion is your memory layer, how MCP really works, and when a worker beats an agent.
I Built a Netflix for My Notion Talks — Here's the System Behind "Nasriflix"
How I turned a forgettable list of speaking gigs into a Netflix-style portfolio — with Notion as the single source of truth, AI doing the build, and a one-click path from page to live site.
Made with Bullet