Harvey
AI could already reason about my projects. It couldn't see them. So I built the half that was missing.
- Status
- In BetaWeb + iOSSolo-built
- Metrics
- 9paying users30daily actives
- Stack
- Next.js · TypeScript · Supabase · Anthropic API · Stripe
A 40-second look at the idea. Real screens below.
02 — The Insight
AI could already reason about my projects. It just couldn't see them — and neither could I.
I was already using Claude as a project manager. Every evening I'd paste in where each project stood, what I'd finished, what was blocking me, and ask what to do next. The advice was genuinely good. The process was exhausting — the context lived in my head, and I rebuilt it from scratch every session.
The deeper problem was the format. A conversation is a bad place to hold state: everything is text, in sequence, and twenty messages in you're scrolling to find the plan you agreed on ten minutes ago. I couldn't open it and see, in two minutes, where I stood.
Meanwhile the tools that were visual didn't think. My work was spread across Notion, a calendar and paper, and none of it knew about the rest.
Harvey is those two halves put together. Chat, because people already know how to talk to an AI — but every answer lands on a surface people already read: a calendar, a task list, project cards. And because I now do the work inside Harvey, moving a task or checking one off is the context update. I stopped writing status reports to my own assistant.
03 — What I Built
An AI coach that keeps the state of your work where you can see it.
You talk to Harvey the way you'd talk to any assistant, and it answers by changing what's on screen: the week fills in, a task moves, a project card updates. It knows what you finished yesterday because you checked it off in the same place you asked the question — so nobody has to explain the situation first.
This page is about the decisions behind it. If you want the product itself — what it does, what it costs, how to get in — withharvey.com is where it lives, and where you can request beta access.
Rescheduling is one sentence. What comes back isn't a paragraph explaining a new plan — it's the plan, redrawn.
Harvey on iOS
Capture a task, check one off, see the day — same account, same data as the web app. The coaching stays where you actually sit down to work. View on the App Store
04 — The Hard Parts
The memory is the product. Everything else is scheduling.
Memory without a vector database
Harvey carries a profile summary plus at most five notes — never more. When a user reaches the fifth note, the summary is rewritten from the previous summary plus those notes, and the notes archive. The summary itself is length-capped, so the prompt is the same size on day one and on day four hundred.
The trade-off is deliberate: summarizing a summary loses a little precision every time, and after long enough the early detail is gone. At this scale it was still the right call — simple, cheap, and shipped. Retrieval is what replaces it.
Teaching the extractor what not to learn
The extractor never sees a flat transcript. It sees a labelled exchange — this was Harvey's question, this was the user's answer — because without that split it starts storing its own coaching advice back as facts about the user. And the bar to write anything is high on purpose: a note has to be something still true in three months about the person or the project, not how they happened to feel on a Tuesday.
What I'd build next: retrieval
Compaction is bounded, not lossless. Each rewrite trades a little detail for a fixed prompt size. Retrieval fixes the loss rather than the cost — and the shape is already there: the notes are short, atomic, timestamped and de-duplicated, so they are clean chunks. The part of RAG that usually goes wrong is already solved.
Embed each note, store the vectors in pgvector inside the Postgres I already run, and on each turn retrieve the notes that actually match the message — scoped by user and project, weighted toward recent ones. The fixed slice of five becomes a relevance query, and the archive stops being write-only.
Why the mobile app stays small
The iOS app shares the database, not the memory — and that is a scope decision. Mobile is where you follow the day, tick something off, add a task before you forget it. The thinking happens on the web app, where you actually sit down to work.
Rebuilding the full coaching context a second time would have cost weeks and handed the user two places to hold the same conversation. Memory reaches mobile once retrieval lands, because at that point personalization is a query rather than a second copy of the context-assembly logic.
05 — Signals
30 people use Harvey every day. 9 of them pay for it.
Paying from day one
The first version was barely polished. It was enough — every beta user paid immediately, €20 for three months. The problem was real enough that people didn't wait for a finished product.
Used every day
30 people open Harvey daily, including me. Daily use — not signups — is the number I optimize, because a coach you check weekly isn't a coach.
Solo, in production
Auth, onboarding, AI coaching, scheduling, per-task chat, Stripe, and the iOS app — built alone, evenings and weekends, while working full time.
06 — What's Next
The next layer is deeper pattern recognition — Harvey noticing how you actually work over time and adapting proactively, not just tracking what you tell it. The goal is a tool that gets meaningfully smarter the longer you use it.
The longer vision is bigger: not just helping builders execute, but helping them decide what to build at all. The hardest problem for builders isn't execution — it's knowing which direction to execute in. That's the problem I want Harvey to eventually solve.
Get in Touch