What we learned shipping year one

A year ago we opened the public phase of PursuitAgent with a commitment to publish the way we work, not the way we wish we worked. Twelve months in, this is the post-mortem.

It is not a victory lap. We did not ship every feature on the roadmap, we did not hit every revenue target, and we have at least three decisions from the last year that I would make differently if I had them back. I want to write those down while I still remember exactly how they felt at the time, because founder memory is self-serving and the honest version degrades fast.

This post has four parts. What worked and why. What did not work and why. The counterfactuals I think about. And a short preview of what we are betting on in year two. It leans heavily on earlier posts — this is a hub more than an essay, and the value is mostly in the links. If you are new to the blog, the three posts to read first are still the launch note, the Grounded-AI Pledge post, and the 8-stage RFP pipeline.

What worked

Publishing pricing publicly

The single highest-leverage editorial decision we made in year one was putting a price on the website. At launch the competitive norm in the proposal-software category was quote-only: a contact-sales funnel, a sales-qualified discovery call, a custom proposal, and a seat-floor commitment disclosed late in the cycle. We published three tiers with numbers on them.

I wrote about the ninety-day read on that bet in pricing in public, ninety days in. The short version is that the inbound quality went up, the cycle length went down, and the discovery calls got shorter because the buyer had already self-qualified against the price. The longer version is that publishing the price also disciplined the product: every pricing tier had to correspond to something a customer could understand without a sales rep explaining it. That constraint was healthy.

The part that surprised me, a full year in, is that the published price became a recruiting tool. More than one engineer cited it in their offer-accept note. The thing candidates said, almost verbatim, was that the price told them the company was not going to be a sales-engineering shop dressed up as a product company. I did not see that second-order effect coming.

Treating grounded retrieval as a contract, not a feature

We shipped the Grounded-AI Pledge in week two. The pledge is four commitments: every drafted paragraph cites the KB chunk it was drawn from, ungrounded questions produce an explicit refusal rather than a confident guess, the refusal surface tells the user what to do, and the enforcement is in the code path rather than in a prompt. That fourth point is the one that did the work.

Prompt-level guardrails are a feature. A code-path enforcement is a contract. The difference shows up in how customers buy. Regulated-industry buyers — healthcare, finance, public sector — will not take a prompt-level guarantee as a compliance answer. They need to see the check in the request pipeline, with a test around it and a metric on the dashboard. We built it that way from the first week, and it turned out to be the single most-cited differentiator in year-one deals against the incumbent vendors.

A thing I did not fully internalize until about month six: the pledge also constrained what we could credibly ship. Every new drafting feature had to pass the grounded check or ship behind a flag. That slowed us down in obvious ways and made the roadmap cleaner in non-obvious ways. A feature that cannot cite its sources does not make it into the default path. Full stop. That rule forced us to reject some features we otherwise would have shipped, which I will come back to below.

Composite bylines with disclosure

The fourth byline decision, which I thought was going to be controversial and turned out not to be, was to publish proposal-craft posts under a composite pseudonym — Sarah Smith — with an explicit composite-author disclaimer on every post. I described the reasoning in the launch note: we wanted the craft voice to be coherent week to week, we did not want to misrepresent a real person, and we did not want to pretend an AI was a human.

The feedback I expected was “you are pretending there is a person.” The feedback I actually got, about forty posts in, was that the disclosed-composite framing read as honest. Readers said the footer note made the rest of the blog feel more trustworthy, not less. Several reached out to ask for the footer text verbatim so they could use it on their own publications.

The lesson I am taking from that: in a category where vendor blogs are mostly ghostwritten and undisclosed, saying the quiet part out loud is a differentiator even when the quiet part is mundane.

What did not work

The thing the Q1 retrospective already called out

I wrote the Q1 retrospective at the ninety-day mark and named five things we got wrong: under-investing in in-product onboarding, letting the refusal surface land as a dead end rather than a branching point, miscalibrating the free tier, publishing a roadmap we could not hold, and over-indexing on federal-sector buyers in the first sales motion. All five of those were fair calls at the time. Four are now closed. One — the roadmap — is not. See below.

Shipping the roadmap page was a mistake I have not fully unwound

At launch we put a roadmap page on the marketing site with quarterly commitments and dates. The idea was that a product that publishes its prices should also publish its plans. That is a coherent position. It is also a position that survives poorly when a quarter of your estimates turn out to be wrong, which is what happened in quarters two and three.

The honest failure mode: a public roadmap creates a forcing function that leans against shipping the right thing. You end up shipping the roadmap instead of the product. Twice in year one we shipped a feature on schedule because it was on the page, knowing we were going to rewrite it the quarter after because the architecture was wrong. Both times, the rewrite cost more than the original ship would have if we had just delayed.

We pulled the quarterly commitments off the roadmap page in month eight and replaced them with directional themes — “this quarter we are investing in X” rather than “this feature ships on Y date.” That softened the forcing function. It did not fully unwind the damage, because the old page had been cited by half a dozen customers in their internal procurement documents. Those customers were reasonable about the change. I still feel bad about it.

The enterprise gate we built and did not use

About six months in, under pressure from a specific enterprise deal cycle, we built an enterprise-tier feature gate: SSO, audit logs, admin RBAC roles, a security-and-compliance dashboard, a per-company encryption key option. The build took about eight weeks of engineering time.

The deal closed. The customer uses SSO and the audit log. The other features have been touched by roughly three customers combined in six months. The gate itself — the paywall that gates those features behind an enterprise plan — has generated almost no upsell pressure. The features are useful to the customers who asked for them. The gate is not doing the work we wanted it to do.

The mistake was treating the gate as a revenue mechanism rather than a capability mechanism. Enterprise gates work when the enterprise buyer is shopping against a list of required features and the gate is where those features sit. They do not work when the buyer is shopping against a core capability — grounded retrieval, in our case — and the enterprise features are ancillary. We shipped an enterprise product when we should have shipped enterprise support for the core product.

What we are doing about it: the feature gate is coming down in Q1 2026. SSO and audit logs are moving into the standard tier. The security-and-compliance dashboard stays on the enterprise tier because it is genuinely enterprise-shaped. Per-company encryption keys stay too, for a narrower reason (the operational cost of running them is real). The rest flattens.

What we would do differently

Three counterfactuals I think about.

Ship the in-product onboarding before the self-serve pricing. We published the price in week one. We shipped the guided onboarding in month four. If I had those four months back, I would swap the order. The price was the interesting decision and I was impatient to get it live; the onboarding was the boring-but-necessary follow-through. Putting the interesting decision in front of the boring decision cost us three months of onboarding-related churn that we did not need to eat. Classic founder mistake.

Hire the first proposal-industry hire earlier. We hired our first senior person with direct proposal-shop experience in month seven. She had been advising us for the prior four months. In hindsight I should have brought her on at month two. There are categories where a strong engineering team can reason its way to the domain, and there are categories where they cannot. Proposal work is the second kind. I was slow to accept that.

Write the “what we will not build” post earlier. The post I wrote this week about the roadmap bet we rejected is a version of a post I should have written in month three. We had customers asking for a feature that would have been a strategic error — a change-management explanation, basically. I did not write the explanation because I did not want to say no to the customers in public. When I finally wrote it this week, the response was that customers appreciated knowing where we were drawing the line. I could have had that conversation a year ago.

What we are betting on in year two

Four themes. I will write posts on each over the next six weeks, so this is the preview rather than the argument.

First, we are betting that the grounded-AI category will pull in a regulatory tailwind — DORA in Europe, new procurement-side AI disclosure rules in several US states — that rewards vendors who can point to enforcement in code. We want to be the default answer when a regulated buyer asks how the AI is controlled.

Second, we are betting that the proposal-software category is about to bifurcate. One branch stays in the document-repository lineage and grafts on AI features. The other branch — the one we are in — treats AI-native drafting as the product and the repository as the substrate. Those two branches will not share a price envelope for long.

Third, we are betting that the procurement side of the market is going to start evaluating AI proposal output the way they evaluate human proposal output: with a compliance matrix, a scoring rubric, and a traceability requirement. That is good for us and bad for anyone who ships confident hallucinations.

Fourth, we are betting the team will double in year two and that the hiring decisions we make this quarter are the most important decisions in the company right now. Sarah is writing the staffing playbook that closes January. I am writing the one on the team we hired in year one later this month. If you are reading this and the word “proposal engineer” means anything to you, our careers page is the most honest document on the site.

Here we go again.