ConvergePilot was my AI conversion-rate audit product. It combined LLM-generated audits with subscription plans, model access rules and AI cost analytics. I built it with Express, React, TypeScript, PostgreSQL, Drizzle and Stripe, and deployed the application with Docker and CapRover.
The product is currently paused. The engineering work remains useful because it exposed a familiar gap: generating a plausible report is a small part of delivering a service that someone can understand, pay for and use responsibly.
An audit needs an explicit scope
A conversion audit can discuss navigation, product presentation, trust signals or checkout friction. Those categories sound straightforward until the report starts implying knowledge it does not have. A visible page does not reveal an entire customer journey, and a design observation does not establish why revenue changed.
The distinction I care about is between an observation, a hypothesis and an experiment. “The delivery information is hard to locate” is an observation if the reviewed material supports it. “That uncertainty may discourage a purchase” is a hypothesis. Moving the information and measuring the effect is a proposed experiment.
This is the standard I use to assess an AI audit’s usefulness. A recommendation should connect to evidence, explain its expected mechanism and say what would need validation. Confident wording cannot turn a guess into a measured result.
The plan controls a real execution choice
ConvergePilot included model gating by subscription plan. That creates an engineering relationship between billing and generation: the product must determine which execution options an account is entitled to use before it starts the expensive work.
A disabled button is only a presentation choice. For any paid AI feature, I want the server to resolve the account, its entitlement and the permitted model. An arbitrary model name from a browser request should never become the authority for access. The same principle applies when a saved request is retried later.
It is also useful to retain the execution context with an audit. If model behavior changes, the report should remain understandable as an artifact produced under a particular set of options. Otherwise support conversations become arguments about an output that nobody can reconstruct.
Cost belongs to the product model
AI cost analytics were part of ConvergePilot’s implementation. That matters because a subscription price and a generation cost describe different things. A monthly plan can be predictable for the customer while its internal workload varies with the number and complexity of audits.
For a product like this, I review the complete execution, including unsuccessful attempts and retries. A failed report can still consume provider resources. The useful question is therefore the cost of delivering an acceptable result, rather than the cost of the last successful model call alone.
This perspective also changes error handling. A retry action should communicate what will happen, retain enough context to diagnose a failure, and avoid accidentally turning repeated clicks into unrelated paid work.
The report must support a next step
A long list of suggestions can create more work without improving a decision. My preferred audit structure groups findings by the customer task they affect, separates evidence from assumptions, and makes the next action small enough to assign. A recommendation to “improve trust” is vague; identifying the missing information and where a shopper needs it is actionable.
ConvergePilot brought billing, generation, cost visibility and reporting into one application. I do not present the existence of that application as proof of conversion uplift. Its engineering value was in making the whole service concrete, including the questions that a model cannot answer from page content alone.
That experience continues to shape my AI work: define the deliverable, constrain the execution, preserve context and make the output useful to the person who must act on it.
Updated 26 September 2026.