We talk a lot about shipping faster now, but I think the more interesting question is how fast we learn that we are building the wrong thing.
Most teams do get feedback. They do beta tests, they invite a few customers, they open a channel somewhere, and then they can say the feature was validated before GA. But if we are honest, a lot of the time the feedback comes after the important decisions are already made.
You work on something for six months. Architecture is decided, workflows are decided, the internal demo has gone well, the release date is starting to feel real. Then you run a beta for a couple of weeks, collect a handful of comments, fix the obvious bugs, maybe polish one screen, and ship. The beta was there, but it was too late to change the shape of the thing.
That pattern is everywhere. I have done it plenty of times. We call it feedback, but often it is closer to release insurance.
The problem is not that we do not ask
The problem is that we ask when the cost of listening is already too high.
When you are early, feedback is useful because you can still throw things away. When you are late, feedback becomes uncomfortable because every real answer implies rework. So we naturally start filtering for what can fit into the plan we already have.
This is why I am interested in feedback loops that happen while the idea is still soft. Not more surveys. Not more dashboards. Just faster contact with reality.
Before you spend months building the feature, can you show someone the workflow? Before you decide what needs documentation, can you watch where people get lost? Before you argue about what users will do, can you compare your guesses with a few real attempts?
That sounds obvious, but it is surprisingly hard in normal product work. The actual product is messy. The knowledge is split between PMs, designers, support, engineers, sales, and users. A lot of the discussion happens around screenshots, remembered demos, old tickets, and whatever someone can describe in a meeting.
Why I am building Cartographer
Cartographer started from a simple idea: show the system how an application works by using it, then let it build a map of screens, actions, and flows.
The AI part is useful when it can help us get to criticism earlier. Not friendly generic feedback like "this looks good, maybe improve onboarding", but more realistic reviews grounded in how the product actually works. What would a busy admin notice? Where would a new user get stuck? What would someone misunderstand because the current flow teaches the wrong thing?
That is different from asking a model to review a screenshot or a static mockup. If the system has seen the real product, the review can be about the product in context. It can see the screens before and after, the actions that are available, the paths people need to take, and the awkward places where the product says one thing but behaves like another.
This is also where I think it can be faster and in some ways more real than starting with a Figma prototype. Figma is great, and I want Cartographer to integrate with it, because teams already design and test there. But a Figma prototype often starts as an idealized version of the product. Cartographer starts from the actual thing users are already fighting with. The old flows, the weird naming, the missing empty states, the settings page nobody wants to touch. That context matters if you want critical feedback instead of design feedback only.
If a team can record the current product in a few minutes, they have something concrete to look at together. If they can generate a proposed flow or prototype from that map, they have something to review before committing months to it. If they can ask for critical persona reviews and then compare those expectations with real user feedback, the conversation becomes less about who sounds most convincing in the room.
I want the team to be able to say: this is how the product works today, this is the change we think matters, this is where different users are likely to struggle, this is what the AI review warned us about, and this is what actually happened when someone tried it.
Quality is not slow
When the tools get faster it is easy to just make more of everything. More prototypes, more docs, more tickets, more code, more ideas to look at. I get why that feels useful, and I do it too, but I do not think more output is the thing most teams are missing.
But I do not think quantity is the interesting part. A team drowning in half finished ideas does not need ten more. It needs a faster way to find the one thing that matters and a safer way to stop doing the rest.
For me, quality means the important problems are visible early. It means feedback is not a ceremony near the end, but part of how the work moves. It means you can ship a small slice, learn something real, and let that change the next slice.
It also means working more like a team. Not one person disappearing into Cursor for a week and coming back with a mountain of plausible code. More shared context, more discussion, more disagreement before the thing hardens.
That is the part I want Cartographer to help with. Not replace the people. Not automate the product judgement. Just make the thing in front of us concrete enough that we can talk about it properly.
What I want to test
The current version lets you record an application with a Chrome extension, build a map, edit it, generate documentation, create prototypes, run persona reviews, and collect real feedback from testers.
That is a lot of pieces, and some of them are rough. I am not trying to pretend this is a finished product. What I am trying to find out is whether this kind of workflow can make feedback feel closer to the work, instead of something that happens after everyone has already moved on.
The useful version of Cartographer is not the one with the longest feature list. It is the one where a team can look at the product as it is, try an idea early, get a critical read on it, and still have time to change direction.
I do not see this as competing with user testing based on Figma. I think it should connect to it. Sometimes the right thing is a Figma prototype and a structured user test. Sometimes the fastest useful thing is to record the existing product, generate a rough version of the change, and ask for criticism before design work gets too polished. The important part is not which artifact wins. The important part is that feedback happens while it can still change the work.
That is the direction I want to take it. If you try it, I would love to hear what feels useful, what feels like noise, and where this could fit into how your team already works.
Web app: cartographer-six.vercel.app | GitHub
