hey anna: founding an analyst, not a chatbot

Context

Most businesses sit on the data that would answer their questions and can’t get to the answer.

The numbers live in Stripe, HubSpot, GA4, Mailchimp, and a long tail of social and finance tools. The questions are ordinary: why did revenue dip last week, which segment is really growing, is this campaign working or just noisy, what are customers complaining about. Answering them properly means joining sources, running real statistics, and writing it up so a decision-maker can act. That is an analyst’s job, and a good analyst costs upwards of $400 a month if you can find one, well out of reach for most of the businesses that need one most.

The market’s answer in 2026 is the chatbot: ask a question, get a confident paragraph. The problem is that a chatbot guesses. It’ll tell you revenue is up because of a campaign without running a significance test, segmenting the cohort, or checking whether the move is even outside normal variance. It sounds like an analyst and does none of the work, which matters the moment you’d make a decision on it.

I started hey anna in January 2026 to close it.

Decision

The positioning decision came first, and everything else followed from it: analyst, not chatbot.

That’s a constraint rather than a tagline. A chatbot produces a plausible answer. An analyst produces a defensible one: connect to the real data, run the statistics, show the working, then state a conclusion. Committing to analyst meant hey anna had to do the unglamorous parts a chatbot skips, so forecasts with confidence intervals, significance tests before claiming a change is real, segmentation that holds up, and themed analysis of verbatim text.

The pricing decision came second and reinforced the first. hey anna is priced under $1 a day, against analyst alternatives that start north of $400 a month. The point is putting a real analyst within reach of a business that could never justify hiring one, rather than being cheap, and the price defines the customer: an operator who has the data and the questions but no headcount.

The third decision was how to build it, which was solo and bootstrapped, with billing live as early as possible. Charging early means the product has to be worth paying for early, which kills the temptation to build features nobody asked for. Either someone pays for the analysis or they don’t.

What I built

hey anna connects to Stripe, HubSpot, GA4, Mailchimp, and 25+ social, marketing, and finance tools, runs real statistical analysis on what it pulls, and writes it up as an exec-ready report. The work splits three ways: get the data, do the analysis properly, deliver it in a form someone will read.

On the analysis: forecasts, significance tests and segmentation, which is the statistical work that separates an answer from a guess. When hey anna says a number moved, it has already tested whether the move is real.

On unstructured data: it themes verbatim text from reviews, surveys and support tickets, so “what are customers unhappy about” gets answered from what they wrote rather than from a summary of a summary.

Across the product, 13 core features have shipped, including:

• AI Formulas. An =AI() function that runs analysis inline, in the place people already think in rows and columns.
• Smart Columns. Columns that compute themselves from a description of what you want.
• AI Memory. Context that persists across analyses, so hey anna learns your business rather than starting cold every session.
• Public Reports. Shareable, exec-ready outputs that go to a stakeholder without a login.

The stack is chosen to let one person ship and operate a real product: React on the front end; Cloudflare for the platform (Workers for compute, D1 for data, R2 for storage); Anthropic’s Claude as the primary model, with Google and OpenAI available; Paddle for billing; PostHog for analytics. The constraint of building solo pushed every choice towards managed, edge-native infrastructure that doesn’t need a team to keep alive.

Outcome

hey anna went from zero to a paid, billing-enabled product in under six months, solo and bootstrapped. It is live, with billing enabled and customers paying.

Thirteen core features shipped in that window, by one person, on infrastructure one person can run. The positioning held up on contact with customers: framing it as an analyst is what makes the statistical rigour something people will pay for rather than a detail they skip past. The sub-$1/day price puts it in front of the operators it was built for, meaning businesses with the data and the questions but nobody to answer them.

There isn’t a headline metric worth quoting yet. What there is: the product charges money and people pay it.

Pricing and unit economics

Pricing is the decision I think about hardest, and for a one-person AI product the usual playbook doesn’t quite fit. The model is seats plus usage, with overage built in. That’s the direction Microsoft has taken with Copilot, and for the same reason: a tool used by both people and agents can’t be priced as if only people touch it. An agent can do a day’s work in a minute, so a flat per-seat price either over-charges the light user or hands the heavy one a loss. Usage tracks the thing that actually costs money.

Underneath the price is a cost I own rather than pass on. The biggest variable cost is model inference, and the lever that moves it most is cache hit rate: Anthropic charges a premium to write to the prompt cache and a fraction of that to read from it, so the gap between a well-structured request and a naive one is most of the margin. Maximising cache hits is one of the numbers I watch most closely, and it’s deliberately an internal one. A customer shouldn’t pay more because I haven’t done my engineering; the cost of my own inefficiency is mine to fix, not theirs to carry.

Usage-based pricing is good because it ties what a customer pays to what they use. The ideal goes one step further and ties price to the outcome. The clearest examples are in support, where an agent’s action maps onto a result the business already prices: if a ticket costs a company $30 to handle and an agent resolves or deflects it for $9, the trade is obvious, the risk is low, and you can charge for the result rather than the tokens. That is the cleanest version of cost aligned to value there is. hey anna’s outcomes are harder to count than a deflected ticket, so I’m not there yet, but it’s where the value-alignment argument points and where I want the pricing to head as the signal sharpens.

All of this matters more because I’m bootstrapped. There’s no venture money behind hey anna to buy market share or prop up a price that doesn’t work, and I’m not running paid ads yet; growth is meant to be sustainable, which is a polite way of saying slower, with fewer eyeballs on the product. A funded competitor can underprice for years and make it up later. I can’t, so the price has to earn its keep from the first customer, and getting it roughly right matters more for me than it would for someone growing on someone else’s money.

And the honest part: hey anna sits at under $1 a day, which is roughly the $29 consumer default I’ve argued against in writing, and the exact default I killed at Brand Ninja. I’m aware of the irony, and I think the product is worth well more than that. I’m charging it anyway, on purpose. Right now the opportunity cost of an empty room is higher than the revenue I’m leaving on the table: I’d rather have customers teach me what hey anna is worth than a higher number protect a value nobody has paid yet. I’m optimising for learning. The floor is a decision I’ve parked deliberately, and I’ll raise it once the customers have shown me where it belongs.

What I’d do differently

I scoped early features before I’d watched enough people use the product, and a few of the 13 were built ahead of the demand for them. Shipping fast solo is an advantage, but it’s also how you accumulate surface area that has to be maintained whether or not it earns its keep. I’d hold more features at the idea stage until a paying customer pulled them out of me.

I was also slower to turn billing on than the “live billing as a forcing function” principle deserved. I believed it in the abstract before I acted on it; there’s a stretch where I was building towards a paid product rather than running one. The lesson is that the forcing function only works once it’s switched on; until then it’s a plan, and a plan doesn’t tell you what people will pay for.

And being both the entire product team and the entire go-to-market team means the two compete for the same hours. I’ve defaulted to building, because building is what I’m fastest at, which means distribution has lagged the product. For the next stretch the harder, more valuable work is getting hey anna in front of the operators it was made for, not adding to what it can already do.

Live billing was one forcing function. Shipping before it feels ready is the other, and it’s the one I find hardest to apply to my own work. When I build for a business or a team I ship rough on purpose, because the work serves a goal, shipping fast is how you learn fast, and my ego isn’t in the file. My own product represents me more directly than anything I’ve delivered inside a company, so I feel the pull to polish past the point that earns its keep and to hold it to a personal standard rather than a commercial one. The discipline I’m practising on myself is the one I’d apply without hesitation to someone else’s roadmap: ship before it feels ready, because ready is a feeling and only the customer can tell you the truth.