Turning a scattered-prompt problem into a full-stack AI product experiment

At the end of 2024, browser-based coding agents were beginning to make working software accessible to people outside traditional engineering roles. Lovable and v0 were entering the market, and among the tools I evaluated, Databutton was the first to give me both Google authentication and a Supabase integration out of the box.

I used that opening to pursue two questions at once: whether a model-agnostic prompt workspace could solve a recurring user problem, and how far I could take a product by learning the technical systems behind it. What began as a small prompt-library prototype became a year-long product and engineering project.

Prompt work rarely stays inside one model. People move among ChatGPT, Claude, Gemini, and specialized tools as they compare outputs, refine instructions, and build automations. That experimentation is useful, but it scatters prompts across chats, documents, notes, and product-specific histories.

The result is a fragmented workflow. Prompts are difficult to find, compare, reuse, and share. Their history and rationale disappear through copy and paste, and what should become a durable library remains tied to whichever model or tool happened to be used last.

I initiated and led Pasta as a side project, owning the product direction, interaction design, prototyping, and delivery. I also used it as a deliberate technical apprenticeship: learning authentication, data modeling and backend infrastructure with Supabase, deployment with Vercel, editor serialization, AI streaming, and the integrations required to operate a real product.

As the scope grew, I worked directly with members of the Plate.js team on the editor foundation and managed two offshore developers. I remained responsible for defining the product model, resolving interaction and technical tradeoffs, and maintaining quality across the experience.

Databutton made the first prototype possible, but its visual and interaction output did not meet the standard I wanted for the product. I experimented with several development environments before moving to VS Code with Cline and Figma’s experimental MCP server. That workflow let me connect design intent to implementation more directly while building my own fluency in the codebase.

The product evolved from a simple library with no markdown support into a full writing and prompt-engineering environment. The hardest work was not an isolated screen. It was designing a coherent system across editor state, markdown serialization, streaming AI responses, structured prompt metadata, and an assistant that could safely act on the document itself.

The editor became the center of the product. Working with Plate.js gave me a deeper understanding of rich-text architecture, including how editor state is serialized, how markdown moves into and out of the system, and how AI output can stream inline without disrupting the user’s workflow.

I designed a multi-mode assistant to support different stages of prompt development. Users could explore an early idea, refine its structure and constraints, then prepare it for repeated or production use. Instead of returning suggestions in a separate chat, the assistant could make targeted edits directly on the editor canvas while keeping the user in control of the document.

I shipped an opinionated prompt-management product that brought prompts, outputs, and supporting context into one workspace. Users could organize work through libraries and tags, track token usage, share prompts, and develop them inside a markdown-capable editor with a purpose-built AI assistant.

The most meaningful delivery was the distance between the first and final versions. Pasta moved from a constrained prototype into a deployed, end-to-end application with a custom editor experience, working infrastructure, and an interaction model that treated prompt engineering as a process rather than a single chat exchange.

As a technical project, Pasta achieved what I set out to learn. I took a product from concept to production, developed fluency across the frontend, backend, deployment, and AI interaction layers, and learned how to collaborate with maintainers and developers on technically complex product behavior.

As a product, the result was more mixed. Pasta generated interest and curiosity, but that initial attention did not become sustained use over a longer horizon. The product demonstrated that the experience could be built; it did not prove that prompt management was a strong enough recurring need to become a lasting habit.

The most important lesson was not about serialization, authentication, or AI streaming. I invested heavily in proving the solution before establishing how often the problem occurred, what repeat behavior would indicate value, and whether users would return without being prompted by a new feature.

My own frustration was real, but it was not sufficient evidence of a durable market. Interest and curiosity were encouraging signals, not retention. By the time that distinction became clear, the technical ambition of the product had already outpaced the evidence supporting it.

I would approach the project differently now: define the repeat-use behavior and retention threshold first, test the smallest workflow that could produce that behavior, and expand the product only when those signals held. Pasta made me a more capable builder, but its most valuable outcome was sharper product judgment. Proving that I could build the system was different from proving that the system deserved to become a product.