/
/
First Time Shipping with Cursor
What worked, what didn’t, and what I’ll do differently next time.
15 June 2025
Outline
(video)
I attempted to ship a new feature using Cursor, hoping to accelerate the build–test–iterate cycle with real users. I didn’t fully succeed — but I learned a lot about where LLMs shine (and where they don’t), and what it really takes for a designer to ship production-ready code. Here’s a behind-the-scenes look at the experiment and what I’d change next time.
Why I Tried This
I wanted to speed up feature development at Rey by using Cursor. My goal: implement a new building block faster and test it directly with real users.
Even though I missed the deadline and needed developer help in the end, the process was full of insights — especially about how AI can (and can’t) support real-world shipping.
Building with customers
During our Closed Beta, we reviewed waitlist submissions weekly and picked one or two customers to co-build with based on shared needs. For this cycle, we focused on LLM-powered chat apps.
The domains ranged from wellness to education, but we chose two highly motivated customers who were ready to validate their MVPs. One of them was Edge — a founder with a clear vision and strong interest in testing Rey’s potential.
In just one week, we integrated an LLM chatbot using the Flutter AI Toolkit. Two weeks later, Edge received her first TestFlight build — I still remember the excitement on her face when she opened it for the first time.
What I Tried to Ship
In our second weekly sync, Edge asked if the chatbot could learn from users’ onboarding data. At that time, we had already connected the chatbot to Rey’s data tables, which could collect values from form blocks. But the input types were limited: only text, number, boolean, and date.
So the top priority became obvious: add a multiple choice input block.
Confident this was manageable, I decided to implement it myself — without asking our developers — using Cursor.
Instead of jumping into Figma, I looked at how tools like Notion and Tally handle multiple choice inputs. Then I wrote a PRD and handed it over to Cursor to generate code.
Three Failures, One Lesson
I Assumed It Would Just Work
I expected Cursor to give me copy–paste-ready code that I could test right away. Instead, I ran into countless build errors.
What I missed:
Understanding how our three main codebases (app-builder, app-core, backend) actually fit together
Breaking the task into clearly defined steps for the agent
Cursor didn’t fail — I just misunderstood how to work with it. The real magic wasn’t in one prompt, but in dozens of small, iterative ones. Even though I had no prior Flutter or Dart experience, I still made progress — and that felt empowering.
(image - how the project structured)
There Was No Shared Mental Model
I didn’t want to burden our developers, so I tried to learn how our system worked on my own — reading README files, exploring commit histories, guessing how things fit together.
But without the ability to read Dart fluently, I couldn’t confidently make decisions. I became overly reliant on the agent’s output and got trapped in a loop of prompts, without knowing how to verify if the code was truly right.Third Failure — Just a Prototype, Not the Real Goal
I Built a Prototype — Not a Shippable Feature
My goal was to ship something real, test it with users, and iterate. What I got was a demo: a working concept that I could style and share, but not something ready for production.
The code was helpful for prototyping UI ideas — but still needed a developer to refactor it before shipping. So while I made progress in applying standard patterns to our builder, I didn’t hit my original goal: independent shipping.
Self-Retrospect
Even though I missed the mark, this attempt helped me clarify what “shipping” actually means — and how to do it better next time.
Here’s what I learned:
LLM-generated code is useful for proof-of-concept UI and isolated components. According to our developers, about 50% of what I built could be reused — but it wasn’t structured for production. Larger scopes (architecture, data flow, conventions) still require human understanding and refactoring.
Writing code is not the hardest part. Understanding the problem, the system constraints, and how to make good decisions that won’t break later — that’s where the real challenge lies.
What’s next
(image - UX improvement list)
I still don’t need to become a full-fledged engineer — but I do want to become someone who ships. That’s the fastest path to learning from users and delivering value.
Designing in Figma doesn’t guarantee business impact. Until it’s in users’ hands, it’s all just a hypothesis.
For my next steps:
I’ll focus on smaller, more focused tasks I can own end-to-end
I’ll continue studying Dart and Flutter so I can reason through implementation trade-offs
I’ve collected customer feedback that could be solved with lightweight features — and I’ll use those as practice tickets
Let’s see how it goes next time.