What building HeyQ with AI taught me about the invisible product work that disappears between sessions.
I started building HeyQ because I thought AI had made software development dramatically faster.
That part was true.
Cursor could scaffold a feature in minutes. Claude could help me rewrite a page, debug a broken flow, or think through a confusing UX decision faster than I could have done alone. The distance between idea and working thing collapsed.
But after a few weeks of building this way, the hard part was not writing code anymore.
The hard part was remembering what I had decided.
Not in some abstract, enterprise-knowledge-management way. In a very concrete founder-building-at-night way:
- What did I say v1 should include?
- Why did I postpone that feature?
- Which positioning line felt sharper yesterday?
- What did Cursor suggest for the next release?
- Why does this flow work this way?
- Did I already decide not to build this?
The code kept moving forward. The product memory did not.
That gap is the reason HeyQ exists.
The moment I noticed the problem
A typical AI build session does not feel like documentation.
It feels like motion.
You open Cursor, describe the thing you want, get a plan, push back on the plan, accept half of it, change your mind mid-way, find a bug, uncover a better approach, defer two ideas, ship one thing, and close the tab.
In that one session, you may have created more than code.
You may have created:
- A scope boundary
- A follow-up release plan
- A rejected architecture
- A better user flow
- A pricing idea
- A positioning sentence
- A decision about what the product is not
But unless you stop and manually extract all of that, it dies in the chat.
I kept seeing this happen while building HeyQ itself. Cursor would propose something useful for v1.0.1. I would think, yes, later. Then later never had a place to live. Claude would explain two possible approaches to a product decision. I would choose one, but the reasoning stayed in the conversation. A feature would ship slightly differently than intended, and a week later I had to reconstruct why.
The irony was obvious: I was building a tool for product truth while losing product truth in the process of building it.
AI builders do not have a planning problem
This is where the old PM-tool answer gets the diagnosis wrong.
If you tell a vibe coder, “you need to plan more”, they will ignore you - and often they should.
The magic of AI-assisted building is that the plan can emerge through the build. You do not always know the right shape before you start. Sometimes the first implementation is the research. Sometimes Cursor showing you a bad approach is what clarifies the good one.
So the problem is not that AI builders refuse to plan.
The problem is that the planning now happens inside the act of building, and the tools treat that thinking as disposable.
That is a different category of problem.
Traditional PM tools assume product knowledge is created before work begins. You write the brief, break it into tickets, assign the work, and execute.
AI-first development reverses that. Product knowledge is generated during the work:
- You discover what is possible while prompting.
- You discover what is too complex while implementing.
- You discover what matters while trying to explain it to the model.
- You discover what is out of scope when the AI tries to build too much.
In other words: the build process generates the product plan.
But if nothing captures it, the build process also deletes the product plan.
What I kept losing
The most painful losses were not tasks.
They were not things like “add settings page” or “fix OAuth callback.” Those are easy to recreate because the code or the bug usually points back to them.
The painful losses were the in-between thoughts - the things that explain why the product is becoming what it is.
1. The v1.0.1 plan
AI is very good at saying, “Here is what we should do next after this ships”. Those plans are often useful because they come from the current state of the product. But they appear at the end of a session, exactly when you are most likely to close the laptop.
2. The scope call
“Not teams yet.” “No billing in v1.” “This should stay single-player.” These decisions are small enough to make casually and important enough to haunt you when you forget them.
3. The alternative path
Sometimes Cursor proposes two approaches. You choose one. The unchosen path may still matter later, especially if the chosen approach starts to crack. But the reasoning disappears.
4. The accidental product insight
The best product ideas often show up while doing something else. You are debugging a webhook and suddenly realize the onboarding should be different. That insight is not a ticket yet. It is too early. But it is too valuable to lose.
5. The shipped reality
AI makes it easy to ship small changes quickly. That means the actual product can drift away from the remembered product. If shipped work does not flow back into the product record, the docs become fiction.
This is the work HeyQ is meant to do: catch the knowledge that appears while building, before it falls through the floor.
This is why we talk about product truth
For a while, I tried to describe HeyQ as a better PM tool for AI builders.
That was close, but not quite right.
The phrase “PM tool” makes people think of tickets, backlogs, prioritization, and process. But the thing I needed most while building was not a prettier backlog.
I needed a durable place for what was true about the product.
Product truth is the layer underneath the work:
- What the product is
- Who it is for
- What is in scope
- What is intentionally out
- What decisions have been made
- What has shipped
- What should happen later
- Why the current shape exists
That layer can produce tickets when you want tickets. It can produce changelogs when you ship. It can feed context to Cursor through MCP. It can help write landing copy. But it is not reducible to any one of those outputs.
The important thing is that it survives the session.
The workflow I actually want
The workflow I want is not “stop building and become a project manager”.
It is closer to this:
- Build in Cursor like normal.
- Let useful plans, decisions, and scope changes surface naturally.
- Have Q capture those moments as proposed updates.
- Review them instead of writing them from scratch.
- Let future AI sessions read from that living product truth.
That is the core loop.
Not plan → ticket → build.
Build → capture → reuse.
This is what I’ve started calling retroactive PM: the product gets managed as a side effect of building, not as a tax you pay before building.
When that loop works, the product starts compounding. Every build session leaves behind more than code. It leaves behind clearer scope, better decisions, sharper positioning, and more useful context for the next session.
The GitHub bot matters for the same reason
The GitHub Q Bot is not just an automation feature.
It exists because shipped work is one of the most reliable sources of product truth.
A merged PR says: this is now real. But GitHub alone does not know what that means for the product. It knows files changed. It does not know that a user flow changed, a scope boundary moved, or a changelog entry should exist.
The bot is our way of making shipped work flow back into the product record.
You merge. Q summarizes. Q links the work to missions, decisions, and changelog-ready updates. The product memory gets stronger because the product changed.
That is the opposite of how most docs work. Most docs decay when the product changes. HeyQ should improve when the product changes.
The bigger bet
The bigger bet behind HeyQ is simple:
AI-first builders do not need more process. They need memory.
They need a product layer that keeps up with the speed of the build. Something that can start from a messy idea, absorb what happens in Cursor, reflect what shipped in GitHub, and give the next AI session the context it needs without another copy-paste ritual.
Because the bottleneck is moving.
It used to be: can you build the thing?
Now it is: can you keep the thing coherent while AI helps you build it faster than your product memory can update?
That is the problem I ran into while building HeyQ.
And that is the problem HeyQ is here to solve.
Build fast. But do not let the build erase what it teaches you.
Start a HeyQ project from an idea, a doc, or an existing repo - and let your product truth keep up with your product.
