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 actually 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 will 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. For anything you’d make a decision on, that gap is the whole game.

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 is a constraint, not a tagline. A chatbot’s job is to produce a plausible answer. An analyst’s job is to produce a defensible one: connect to the real data, run actual statistical analysis, show the working, and only then state a conclusion. Committing to “analyst” meant hey anna had to do the unglamorous parts a chatbot skips: forecasts with confidence intervals, significance tests before claiming a change is real, segmentation that holds up, and themed analysis of verbatim text rather than vibes.

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 isn’t to be cheap; it’s to put a real analyst in reach of a business that could never justify hiring one. The price defines the customer: the operator who has the data and the questions but not the headcount.

The third decision was how to build it: solo and bootstrapped, with billing live as early as possible. Not as a constraint to apologise for, but as a forcing function. Charging from early means the product has to be worth paying for from early, which kills the temptation to build features nobody validated. Live billing is the honest gate: 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 - the actual statistical work that separates an answer from a guess. When hey anna says a number moved, it has tested whether the move is real before saying so.

On unstructured data: it themes verbatim text from reviews, surveys, and support tickets, so “what are customers unhappy about” gets a grounded answer drawn from what they actually wrote, not 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 toward 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 under contact: framing it as an analyst rather than a chatbot is what makes the statistical rigour a feature people will pay for instead of a detail they ignore. The sub-$1/day price puts it in front of the operators it was built for: businesses with the data and the questions but no analyst.

The number that matters most isn’t a metric yet; it’s that the gate is real. 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 toward 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 actually 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: 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 instead of 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.