Inspiration
We kept watching the same failure mode at build sprints and hackathons: teams don’t usually fail because they lack ideas. They fail because they pick a problem that is too broad, can’t name a specific user, and burn the first day arguing about scope instead of shipping. We wanted a tool that forces the three questions the Build North brief asks—Who is the user, specifically? What is the value-add, plainly? Is there a credible path to production?—into a single artifact a team can actually use.
ClarityCard started as a simple internal note: “paste messy project notes, get a one-page action card.” That felt small enough to ship in a week and useful enough that we would use it ourselves.
What it does
ClarityCard turns unstructured project notes into a structured, shareable action card:
Specific user — not “everyone,” but a named person, team, or workflow
Plain value-add — one sentence describing what is better because the project exists
Next 3 steps — the smallest shippable sequence
Top risks — including scope risk
Credible path to production — a short justification judges or teammates can evaluate
Users paste notes, a transcript, or a rough idea. The app returns a card in under a minute, saves it to their account, and lets them revisit past cards. We also compute a lightweight Scope Risk Score to flag over-scoped ideas:
How we built it
We built ClarityCard as a web app using Next.js and React, deployed on Vercel. The core flow is:
User signs in with Clerk.
They paste notes into a text area.
A server route sends the notes to an LLM with a strict structured-output schema.
The response is validated, scored, and rendered as a card.
The card and a compact preference summary are stored using SurrealDB Agent Memory.
We used Clerk for authentication and session management rather than building auth from scratch. Clerk also gave us user profiles and protected routes quickly, which mattered during a one-week sprint.
We used SurrealDB Agent Memory so the agent can remember prior cards and user preferences—for example, “this user tends to over-scope mobile apps” or “they prefer three steps, not ten.” On each new card, we retrieve relevant memories and include a short context block in the prompt. That made the second and third cards noticeably more tailored than the first.
We also framed the card generator as an agent and used Era by Eon early access to run a small set of test cases and compare prompt variants. We did not claim a category prize for Eon unless we could show evidence it materially shaped the build; we used it to benchmark consistency and catch schema failures.
We started from a blank Next.js scaffold. All product logic, prompts, schema, scoring, and UI were built during Build Week.
Challenges we ran into
Structured output reliability. Early prompts produced beautiful prose and unusable JSON. We fixed this by moving to a strict schema, validating on the server, and adding a repair pass when validation failed. The biggest lesson was that “ask nicely for JSON” is not a strategy.
Memory that helps instead of hurts. SurrealDB Agent Memory is powerful, but naive retrieval injected irrelevant history into the prompt. We had to define what to store—short preference summaries, not full cards—and retrieve only the top few relevant memories. This was the difference between “creepy and noisy” and “helpful.”
Scope Risk Score tuning. Our first formula punished any project with more than one user segment. We adjusted it with clipping and weights so it flags obvious over-scoping without being moralistic. The formula is intentionally simple and explainable; judges and users should be able to see why a card scored high.
Time. A one-week sprint means every integration competes with core UX. We prioritized the paste-to-card flow, then auth, then memory, then benchmarking. We deliberately did not build a mobile app or browser extension
Accomplishments that we're proud of
A working end-to-end flow: sign in with Clerk, paste notes, get a validated card, save it, and see it again later.
A memory layer that makes later cards better, not just longer.
A demo that is easy to understand in under two minutes.
A scope-risk signal that is simple enough to explain in one sentence and useful enough to change a team’s next step.
We shipped something real in a week without over-scoping it—which is exactly the behavior ClarityCard is meant to encourage.
What we learned
We learned that structured outputs are a product decision, not just an engineering one. The schema is the product: if the card has the wrong fields, the tool is useless no matter how good the model is.
We also learned that memory needs curation. More context is not better context. A small, relevant memory block beat a large history every time.
Finally, we learned to apply our own tool to ourselves. When we ran our early notes through ClarityCard, the Scope Risk Score flagged our first plan—mobile app, browser extension, team collaboration, and analytics—as over-scoped. We cut it to the web flow and shipped. That was the most convincing demo of the product we could have asked for.
What's next for ClarityCard
Team cards: shared cards with comments so a team can agree on the user and next steps before writing code.
Export: Markdown and PDF export for Devpost pages, pitch decks, and mentor check-ins.
Templates: lightweight presets for common Build North categories—AI agent, mobile app with Expo, auth-heavy app with Clerk.
Better benchmarking: a larger evaluation set run through Era by Eon to measure schema reliability and card usefulness across prompt versions.
Optional mobile companion: if we build one, it will be with Expo’s React Native tooling and ship via EAS Build or Update—but only if it materially improves the core flow.
Memory controls: a user-facing view of what ClarityCard remembers, with edit and delete, so the memory layer stays trustworthy.
Built With
- anthropic
- github
- next.js
- react
- surrealdb
- tailwindcss
- typescript
- vercel

Log in or sign up for Devpost to join the conversation.