My role
This project was done entirely by me, from visual design to development.
Cursor was used as my main development tool, with lots of aid from my mighty assistants Claude and Gemini :)
If you’re interested, read my full process over here.
If you’re tight on time, this article is a snippet of the ‘why’ behind my idea 😊
Mission
Vibe coding the perfect note taking tool for myself
I’ve never been a naturally organised note‑taker. My work notes lived in random Notion pages, meeting docs, and screenshots. When I needed a customer insight or a detail from a previous meeting, it felt like a scavenger hunt.
Notion worked well for long‑form docs like case studies and planning, but not for the quick, messy notes I take during the day. My notes would pile up in one endless page and become impossible to scan.
Ideas
I prioritised speed over structure in my notes
Most of my notes were short bullet points. captured mid-meeting or on the fly, where structure matters less than speed.
A Twitter-style UX felt like the right fit: lightweight, concise, no friction deciding where things live in Notion.
I also borrowed from Raycast — a global shortcut that surfaces a small input window, so I can log a thought without switching apps or breaking focus.
Process and learnings
From product thinking to hands on learning
Vibe coding isn't magic. Before touching any code, I stepped into a PM mindset - writing a lightweight PRD to map out backend behaviour, frontend features, and key considerations upfront.
While building, I leaned into trial and error, using AI not just to fix bugs but to actually understand why and how.
Most of the bugs I run into are on the front end — things like scrolling issues, broken interactions, or UI quirks. In many cases, simply describing the problem in plain language is surprisingly effective.
When I notice a bug, I:
- Clearly describe what’s happening → what the ideal outcome should be.
- Specify class names if they are known. Fortunately, cursor allows you to pinpoint the exact component from its app browser.
That said, there are times when words aren’t enough, or the issue is hard to explain in text. What has worked almost magically for me is uploading a screenshot to Gemini (Or your ask mode on cursor) and ask to generate a prompt for Cursor to fix the problem.
- In more complex cases, I can ask it to suggest several possible root causes for the issue. Instead of burning Cursor credits debugging an unknown issue where the fix might not be guaranteed, you can step back and evaluate which explanation is most valid before diving into code.
- It can generate really amazing cursor prompts with technical keyword and details. In the case where its fix doesn’t work, it can also suggest you debug commands
Branding
I called it “Zap” - because the app centres on quick notes — fast and immediate, like a lightning flash.
❤️ Key features
Shift + Command + X brings up quick notes panel for adding in notes and to do.
Typing in “To do:” automatically adds items to the to-do list. This way I can add in notes on the fly, especially during meetings.
Tags to filter through posts, separated into 3 categories for easier search
Theme switching
Sometimes, change is good
Learnings
1️⃣ Look for open source libraries as much as possible to help speed up development
I originally built core features like post input and search entirely from scratch using Cursor. However, this required significant time and credit allocation to handle complex edge cases. In hindsight, as a friend pointed out, using open-source libraries would have been more efficient, as they offer robust solutions with edge cases taken care of.
2️⃣ Build a more solid coding knowledge base
For many non technical folks, vibes sound fun, but coding doesn’t 🥲 I started off wanting to not touch code at all, but the harsh truth is — building a basic foundation of front and backend development would save so much time and and frustration in the process. I would recommend:
- Document all learnings from each debug
- Ask the LLM to walk you through the causes of bugs, try understanding what’s happening.
3️⃣ Give better context to the LLM so it can build better
As I start building more using AI, I have realised the more detailed context and journey flow you can provide to the AI, the better it executes. Things like user journey, edge cases and design systems it should follow, can be documented in a markdown file so it executes better.