From bug bounties to an AI product, and its first 30 customers
Team. Product, engineering and a data analyst I worked alongside directly on the engagement work.
Immunefi sold bug-bounty programmes. The company moved to an AI security offer, which meant designing a conversational assistant and an AI pull-request reviewer for people who had never bought software that answers back.
A count of conversions, not a rate. I do not have the denominator to publish, and the figure predates any holdout group.
The situation
Immunefi ran bug bounties: companies post a programme, researchers find the vulnerabilities, Immunefi takes a cut. The company decided to sell software instead.
That is not a feature change, it is a different business. A marketplace earns a percentage of something that already happened. Software earns a subscription for something that might. Same buyer, but you are now asking them to trust a product rather than a process. And the people on the other side are security researchers, whose job is to distrust any claim that arrives without its working shown.
That split is why the work was prioritised the way it was. The AI products serve the companies, who pay. The engagement work serves the researchers, who do not. Both had to improve at once: a marketplace with no researchers has nothing to sell, and a pivot that loses the existing business pays for nothing.
I owned end-to-end delivery for two products in that shift: a conversational AI assistant and an AI pull-request reviewer. In parallel I worked on the existing platform, because a company mid-pivot still has to keep the business it has.
What I decided
Treat reputation as the engagement problem, not the flows
The flows did need work and I did it. But researchers on a bounty platform are not optimising for clicks, they are building a professional reputation they carry between programmes. Making that reputation visible and worth cultivating changes the reason to come back.
I worked directly with a data analyst rather than designing against assumptions, which is the only reason I will attach a number to it at all.
- Instead of
- Optimising the critical flows alone, which is where the roadmap and the funnel analysis both pointed.
- What it cost
- A much larger surface, and a public profile is permanent: once people have built standing on it you cannot take it back.
Kill the bespoke programme page, including the part that was my job
Every programme page that needed a designer was a page that did not ship until a designer was free. That is a queue, and it was growing exactly when the company needed to be somewhere else.
So I killed the service and replaced it with a system. A self-serve surface on a custom CMS made page quality a property of the thing rather than of whoever had capacity that week. Arguing to design yourself out of a recurring request is uncomfortable, and it is the piece that kept paying after I moved to the AI products.
- Instead of
- Keeping each bounty programme page as a design and build request per customer.
- What it cost
- A constrained surface, so a customer cannot have exactly the page they imagine. And less design work for designers.
Put research in one place the whole team could read
I introduced structured research documentation in Dovetail and got the team using it. The least visually interesting thing here, and probably the longest-lived: findings that are searchable stop being re-discovered, and an argument about users becomes checkable rather than remembered.
- Instead of
- Research living in the deck or the document that happened to need it.
- What it cost
- Discipline that has to be maintained, and a tool the team had to be persuaded to adopt.
What shipped
A programme page, the explore surface, and the researcher profile that carried the engagement work.
The old programme page led with a full-bleed brand gradient and four loose facts. The redesign gives the same screen a dark ground, a structured reward table by threat level, and the vault figures a researcher actually decides on.
Explore is the surface the whole marketplace runs through. 279 programmes, sorted on the figures that decide where a researcher spends their time, rather than on brand prominence.
The profile is the reputation argument made visible. Rank, lifetime earnings, programmes secured, skills, and a leaderboard position. This is the piece the engagement number came from.
What the numbers are, and are not
30+ customers moved onto the AI portfolio. A count of conversions during the shift, and the figure the company used. I have no denominator I can publish, so it tells you the offer landed, not how efficiently.
Engagement on the main product roughly doubled after the flow work and the public profile shipped. The analysis was done with a data analyst rather than by me reading a dashboard, which I trust more. What I cannot separate is how much came from the flows and how much from the profiles: they went out together, with no holdout.
If a figure here matters to a decision you are making, ask, and I will tell you how it was measured and where it is soft.
The failure I was designing against
An AI security tool that is confidently wrong is worse than no tool at all.
Most products can afford to be a bit wrong. This one cannot, and the asymmetry runs both ways. Miss a real vulnerability and the product has made a company less safe, because somebody stopped looking. Raise one that is not there and you have burned the time of the most sceptical audience available.
That audience matters more than the accuracy rate. Researchers are paid to find what is wrong, and they will test the assistant adversarially within a day. A tool that asserts confidently and is caught once does not get a second look.
So the hard question was never the interface. It was how much of its own uncertainty the system should show, and where showing it reads as honesty rather than weakness. I do not think we fully answered it.
What I would do differently
Shipping the flow improvements and the reputation profiles in the same window made the result unattributable. A few weeks apart would have cost almost nothing and told us which half was doing the lifting. That matters beyond credit: the next team to invest here cannot tell from our result where to put the money.
On the uncertainty question I started too late and in the wrong room. What a model can honestly say about its own confidence is a technical fact before it is a design one, so a designer deciding it alone is a designer guessing. I would now open that with engineering in week one, and treat the answer as a constraint on the interface rather than something the interface chooses.