76 ideas, 53 working tools: one developer’s year of vibecoding
D’Arcy Norman asked Claude Code Opus 5 to analyze a year’s worth of vibecoding project history on his laptop. The model processed for almost an hour. What came back: 76 ideas tried, 53 working pieces of software, 172,486 lines of code, and 11 sketches that graduated into tracked projects.
Norman is preparing a presentation on vibecoding in higher education and used that output as a single slide. The numbers are a useful anchor for anyone wondering what a serious, sustained practice of AI-assisted prototyping actually produces.
️ What Vibecoding Actually Means Here
Norman’s frame is deliberately narrow. Vibecoding, in his usage, is not a replacement for software development. It’s a way to build custom tools that wouldn’t otherwise get built, many of which get thrown away after testing. His 30-plus years of involvement in software development, across several roles, is what he credits for making the approach work. His read: the real superpower is being able to articulate what you want clearly enough that the output is useful. Without that, you’re typing into a box and hoping.
He’s direct that professional software developers will remain the core of how actual software is built and maintained. The tools he vibecoded are mostly for himself, running on a personal sandbox server, not shipped as products with support obligations.
What Got Built
The projects fall into a few distinct categories. Most are personal infrastructure tools that solve real daily friction.
Blog tooling
Norman describes his Hugo-based website tools as the closest thing he has to mission-critical vibecoded software. The stack includes a custom PHP/SQLite comments system, a SQLite-backed search tool, a Python script that generates a content history visualization, and a fully vibecoded blog theme. He also built tag synonym support for Hugo, so content tagged with any of brightspace, d2l, or desire2learn surfaces under a single canonical tag.
Two macOS applications handle photo publishing: one resizes and converts photos to .webp, calls the Anthropic API to generate captions, creates markdown files, and drops everything into the right Hugo directories. A second sits in the menu bar and lets him run the Hugo publish process without touching Terminal.
The reMarkable integration
After picking up a reMarkable Paper Pure eInk tablet, Norman found the software pushed hard toward keeping notes on the device. His notes live in Obsidian. So he built a macOS application that connects to the tablet over USB (no sync subscription required), accepts files including images and PDFs, sends them through the Anthropic API for transcription (with no server retention and no use in training, enforced via the API integration), converts them to markdown, and moves them into his Obsidian vault. He’s used this process for 76 notes so far.
Obsidian plugins
Norman built multiple plugins for Obsidian, none of which he plans to publish. Two provide database functionality on top of his vault: a lightweight CRM-style People view and a lightweight personal encyclopedia called Topics. He also built 2D and 3D graph visualization plugins, which he later turned off because the graph looked interesting but didn’t actually do anything useful. A third plugin used a local LLM via Ollama to index every note and surface related content in a sidebar based on emergent similarities. He built it, tested it, and never actually used it. The explicit linking and CRM/Topics views turned out to be more useful in practice.
Office display dashboard
A Raspberry Pi connected to a display in his office runs a browser in fullscreen pointed at a vibecoded Dashboard web page. An admin panel lets him add, remove, and reorder pages (images, URLs) that cycle on the display. It has since grown to support syncing multiple displays.
The One That Got Real: Jellyboard
When Google shut down Jamboard, Norman built Jellyboard as a self-hosted replacement. The design constraint was deliberate: no containers, just PHP, JavaScript, CSS, and SQLite, runnable on commodity webspace. It shipped with infinite canvas, grouping, connections, multiple pages, collaborative editing, starred notes, dotmocracy, a mini-map, and QR code joining.
The first real test was a conference session. Norman registered the jellyboard.ca domain to make it easy to access. DNS propagated everywhere on earth except the university campus where the conference was held. The session reverted to physical whiteboards. DNS finally resolved to the campus network about an hour after the session ended.
Jellyboard is the most-used thing he’s built. It’s apparently popular in Thailand and with financial advisors, which Norman describes as something he has no explanation for. He decided not to open-source the code and offers it free without support, to avoid the ongoing maintenance burden of a public project.
The Experimental Interfaces That Didn’t Graduate
Three projects explored new interface ideas and none made it to production. Norman is explicit that this wasn’t failure.
- A collaboration-first LMS prototype: What would an online course platform look like if it prioritized connection over grades? The prototype worked and was described as super interesting. Turning it into a real product would have required the team to drop everything for months.
- An alternative RSS reader interface: Built on top of the NetNewsWire SQLite database. Worked well, but Norman was too entrenched in the existing NetNewsWire UI to switch.
- A Brightspace Course Coach: Integrated with Brightspace via LTI 1.3 to give students a different way to engage with course content, including a chatbot interface. Worked, was interesting, and ran out of runway to become a real product.
His read on these: they weren’t a waste. If the only new interfaces came from vendors shipping finished products, the problem space would be limited to what’s marketable. Prototypes let you explore what might be interesting or useful, separate from what’s saleable.
The Honest Verdict
Norman compares vibecoding as a prototyping tool to HyperCard, then walks it back: HyperCard was more significant because it was genuinely new and required no coding experience. His actual position is that genAI vibecoding platforms are the most powerful prototyping tools he’s encountered in a very long time, and that their value is in building custom tools for individual needs and testing ideas before committing to full development.
What vibecoding is not, in his framing: a reason to stop hiring software developers. AI tools will enhance development processes, automating audits, templating structures, validating functionality. They won’t replace the people who understand how systems actually work and maintain them over time.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
