Something extraordinary has happened to making software.
A person can describe an idea before breakfast and be testing a working product by lunch. Authentication, payments, onboarding, polished empty states—all there, all plausible.
The distance between intention and interface has collapsed.
The distance between an interface and the life it enters has not.
The product still meets a person. Someone finishing a form between school pickup and dinner. Someone deciding whether to trust a new company with their card details. Someone who has already explained a problem twice and has just been handed to a support bot.
AI can generate a convincing interface. It cannot know, merely by generating it, whether that person understands it, trusts it or can use it.
Analytics does not close the gap by itself. A funnel can show that people leave at the third step. It cannot tell you whether they were confused, unconvinced, interrupted or making a sensible decision. A shorter checkout can improve conversion while creating more regret. A support bot can reduce response time while increasing the time it takes to feel helped.
The numbers may improve while the experience gets worse.
This is the gap Sightspool exists to work on.
Product judgement cannot end at the ship
In product and UX work, I have come to distrust two things: insights detached from decisions, and decisions detached from outcomes.
A research finding lands in a presentation. Someone changes the onboarding. Three months later, the team remembers that there was “some evidence” behind the change, but not what it was, what else it might have meant or what result they expected.
The artefacts survive. The reasoning disappears.
UX, at its best, is the capacity to notice consequential uncertainty, choose the right way to investigate it, change what the team does and return to learn from the result.
Solo builders and small teams have rarely had access to that continuous function. They do not need a miniature enterprise department. They need the discipline without the ceremony: a way to see their assumptions, use the evidence they already have and carry what they learn into the next build.
That is what I mean by product intelligence.
Start with the assumption
Every product decision contains an idea about human behaviour.
A mandatory integration step assumes people will connect a source before experiencing any value. An empty dashboard assumes a new customer knows what belongs there. A pricing boundary assumes the builder has located the moment willingness to pay begins.
Code can implement any of these perfectly. That does not make the underlying assumption true.
One real product I reviewed had designed its public boards as a growth loop. Every shared board was meant to carry the product into the world through a linked footer attribution. The strategy was in the documentation. Public-by-default behaviour was in the code. The footer appeared in the product.
It was plain text.
There was no link and never had been. The growth loop was not underperforming; it was structurally impossible. No analytics dashboard could diagnose the click-through rate because there was nothing to click. The problem became visible only when product intent, repository history and the implemented experience were read together.
This is the kind of work Sightspool is built to do.
It begins with a real product question. It examines the product and its repository for the assumptions already being made. It connects approved evidence—behaviour, product changes, customer voice, research and commercial context—without pretending those sources all prove the same thing.
It distinguishes between nobody did this and we never measured this. It refuses to turn seven people into a reliable percentage when the declared minimum is fifty. Every finding keeps its evidence, limitations and strongest alternative explanation attached.
No proof, no post.
When behaviour cannot explain itself, Sightspool can prepare a bounded survey or moderated interview. When the evidence is thin or the consequences are material, it can bring in senior UX judgement.
It then proposes an action. The client decides whether to accept, amend, challenge or dismiss it. The client owns implementation. Sightspool returns afterwards to record what happened and carry that learning into the next question.
The point is not to produce more insight. It is to keep the line from assumption to evidence, decision, action and outcome intact.
The human is not a row in the evidence table
When Sightspool says “user”, I want it to mean a person, not merely a distinct ID.
A person invited into research should know why they are there. If an interview offers voice, text must remain a genuine choice. Permission to participate is not automatically permission to record. A cohort should not be targeted simply because an agent found a convenient segment.
The client’s customers retain agency. The client retains the final product decision. The agent retains its uncertainty. A senior practitioner enters where the system has not earned the right to bluff.
The software is our object of work. The person relying on the service is the subject.
My assumptions, in the open
Sightspool is also built on assumptions.
I am assuming builders would rather receive a small, honest answer than a sweeping, synthetic one. That one consequential question can be more useful than another dashboard. That solo founders want product and UX discipline inside the tools they already use. That senior expertise can concentrate around ambiguity and consequence while software handles the repeatable work. And that teams will return after implementation, even when the result proves the original recommendation wrong.
I am also assuming that “product intelligence” is a useful name for this responsibility: not analytics alone, not an AI pretending to be a customer, and not consultancy hidden behind a chat interface.
Any of these assumptions may be wrong. They should be exposed to use, not protected by founder conviction.
That is why Sightspool’s founding beta is open for 30 days. Bring one real product question. Try the software before I step in. Founding participants receive one focused senior UX review in exchange for candid feedback.
I care whether Sightspool changes a real action, whether people return with another question, which reads they challenge and how much human judgement the difficult work requires.
Praise is welcome. Changed action is better evidence.
Build with AI. Learn from reality.
I am not building Sightspool to impersonate an entire UX department.
I am building it to preserve what the best product and UX practice contributes: the question beneath the feature, the evidence behind the recommendation, the human consequence behind the metric and the humility to return after shipping and discover that we were wrong.
AI gives today’s smallest teams astonishing productive power. The next generation of products will not be distinguished simply by how much AI helped to make them. That will become ordinary.
They will be distinguished by how well they remain in contact with reality—and how seriously they take the people whose reality it is.
There is always a person at the other end of the build.
Sightspool is for keeping them there.