Raffle AI · Focused product case study
Making a Rebuild Worth Funding
Combining an architectural rebuild with the redesign and features the business could see
Raffle’s chat and search widgets sit on customers’ own websites, and they had become expensive to change. The architecture needed rebuilding, and a quarter of foundation work could not compete for approval on its own. I combined the rebuild with the visual redesign and the backlog features the business was already asking for, split it into two sequential parts, and ran the discovery for the second part inside the first part’s engineering time. Both halves shipped, around half of all instances have migrated voluntarily since release, and the project took closer to four quarters against a two-quarter estimate.
I decided what the project was, how it was structured, and what the new architecture had to be true of. The implementing developer owned the technical design and built it, the product designer led ideation and prototyping, and customer success brokered customer access and owned the migration message.
Context and responsibility
Raffle AI’s instances are the chat and search widgets that customers install on their own websites. Each one carries an extensive set of configurable options — logos, colours, feature toggles, text-label overrides — because customers expect the widget to look like their site rather than like ours.
Three problems had converged by the time the project was decided. The request backlog for the widgets was long and much of it was old. The widgets had aged next to what competitors were shipping. And the cost of the smallest change was out of proportion to the change: adding a single new colour override meant updating several branches of an architecture designed years earlier, for a much less evolved product.
My responsibility was deciding what the team would build and getting it approved. I owned the scope, the requirements, the prioritisation, and the release sequence. The CTO retained authority over engineering resources and the CEO agreed the quarterly commitments.
Problem and evidence
The demand for a rebuild did not originate with me. Engineering had been asking for it, and the argument was well made. What it lacked was a shape the company could approve: a quarter spent on foundation work has nothing an outside reader can see, and it has to compete with everything on the roadmap that does.
The customer-facing evidence pointed the same way, and some of it was specific. The overlay version of the widget needed an onclick handler on a button inside the customer’s page, and many customers cannot edit their own markup. A lot of content management systems expose a custom HTML slot in the document head but not in the body, which left some customers — WordPress ones in particular — unable to use the overlay at all. That was an installation problem living in the architecture, not a feature gap.
One inherited commitment also sat across this work. A customer had been told to expect a separate new product that was, in substance, the natural evolution of the widgets they already had. I decided not to build it as a separate product. Instead, the requirements behind it became inputs to this project, and the customer agreed to become one of the design partners in it.
Options and decision
| Option | What it optimised for | Decision |
|---|---|---|
| Ship the architectural rebuild on its own | The cleanest technical outcome | Rejected. A quarter of foundation work with no visible result attached could not compete with the rest of the roadmap, so in practice it would not have happened. |
| Ship the redesign and the backlog features on their own | Visible progress in the shortest time | Rejected. It would have put a new surface on the architecture that made every later change expensive, and spent the case for a rebuild for years. |
| One project, two sequential partsChosen | A single approval that pays for the foundation and the visible result | Part 1 rebuilt the foundation. Part 2 delivered the new layouts, the wider customisation surface, and a prioritised selection of backlog features. |
The sequencing was part of the decision rather than an implementation detail. Discovery and definition for Part 2 ran in parallel with Part 1’s engineering, so the design work occupied time the rebuild needed anyway instead of adding to the schedule.
The framing was deliberate too. Inside the company everyone knew the foundation was the point; from outside, only the new look and the new features were legible. One project satisfied both readings, and it closed accessibility and security exposure that neither half would have justified on its own.
What the new architecture had to be true of
I am not an engineer, and the technical discovery was not mine to run. I assigned it to the implementing developer, to be reviewed with the dev team, and constrained it with four written requirements.
- Safe deploy and backward compatibility. The rebuild must not break existing customers. Legacy widgets keep working until a customer chooses to upgrade, and old and new run side by side.
- Accessibility. The new version has to improve accessibility against WCAG standards.
- Prepare for future features — enable, do not deliver. Six capabilities the architecture had to make possible without committing us to build them: unifying chat and search under shared layouts; shared session state across layouts; visibility of which instances are live and where; theming and templates for widgets that share options; simpler installation; and a wider customisation surface, including mobile options, borders, shadows, and labels.
- Isolation. The widget must not affect the customer’s website, and the customer’s website must not affect the widget.
The third requirement carries the deliberate line. Enabling six future capabilities costs something now and commits us to none of them. Delivering them would have made the project larger than the one I had just argued was the right size.
Trade-offs
The bundle is the trade-off. Combining a rebuild with a redesign and a feature set is what made the project approvable, and it is also what made it hard to size. It ran late, and the two facts are not independent.
Requirement 1 chose a long dual-running migration over a forced cutover. That is what made a staged, reversible rollout possible. It is also why two implementations are still being carried, and why the deprecation date is still ahead of us.
Execution
Discovery
Ideation ran with the product designer and the customer success manager while Part 1 was being built. I supplied competitor analysis, a selection from the request backlog, and the opportunities I had identified. The designer led ideation and code-prototyped almost all of the candidates, so what reached customers was already polished.
I then organised nine one-hour sessions with key customers, some in their own offices and some online. Coverage was designed on two axes: the two main instance types, and the three target segments. Each session tried to validate a feature before showing it, then tested whether the design was understood without telling the participant what they were looking at. Every session was documented and transcribed, and each customer was routed to the parts where they had most to give and most to gain.
This was a validation structure more than open discovery, and prototyping before validating front-loads sunk cost. What kept it honest was the comprehension test, and using the sessions to discard solutions rather than only to refine them.
Prioritisation
Discovery produced more candidates than could be built on top of the baseline redesign, so I scored them with RICE and defined a rubric for each term rather than scoring by feel.
- Reach — a ten-point lookup table keyed on how many tools a feature touched and how much of the customer base it reached, from all tools and all customers at 10 down to one tool and part of the SME base at 1, with the ICP and SME bands in between.
- Impact — 1 to 3 against the project’s own stated goals: better look, customisation, more usage, better UX, nudge contact.
- Confidence — three defined bands. 100% for strong evidence: requested by people, a good prototype, a clear problem. 80% for “we believe it”: few requests, a promising but unvalidated prototype, good signals mixed with intuition. 50% for assumptions: no requests, new territory, opinion.
- Effort — 1 to 5, estimated by the developers rather than assigned by me.
Then I added the human back to it. Once the model produced an order, I moved the cut line and swapped one feature for another, and left the rest of the ranking as scored.
Migration
Replacing a product that lives on other people’s websites means nobody can be forced to move. The new code lived in a new repository, and the rollout ran in stages.
A toggle in the web app — the surface where customers configure their instances — switched an individual instance to the new version. It was visible to admins only at first, which let us test internally and enable it for customers who asked to try it. I tested the new instances against roughly 30 to 40 different customer configurations myself, and that is where the bugs were found, with logs and error reporting watched alongside. When the instances were solid we exposed the toggle to customers and communicated the change, including directly through the customer success manager. That was deliberate: some of the new features were built to support upselling.
A six-month migration period is running now, and the intention is to deprecate the old instances by the end of 2026.
Result and limits
Both halves shipped. One approval bought the new architecture, the accessibility work, vulnerability fixes, a new look, and new features. Around half of all instances have migrated part-way through a six-month window in which migrating is voluntary. Partners are the most positive group: they have already moved all of their hundreds of sub-customer sites, and are using a small number of features built for them to drive conversion on those sites. Customer reaction ranged from almost neutral to very astonished, with a lot of feedback, and Sales report that the new look is materially better for demonstrating to prospects.
That count is of instances, not customers, and the limit is what it means. Voluntary adoption of a free upgrade is evidence that the upgrade is wanted, not that it earned anything. There is no satisfaction score, no support-volume comparison, no renewal or revenue effect, and the partner-side conversion features have no measured conversion result. The reactions are reported, not measured.
The schedule
The project was estimated at two quarters and took closer to four. The foundation landed in Q4 2025, the new layouts and features in Q2 2026, and the last of the three instance types is being finalised in August 2026.
The estimate was the problem, not the execution. A project that bundles an architectural rebuild with a redesign and a new feature set is hard to size, and I accepted a two-quarter figure for it — then accepted a second estimate that was also wrong. There was no capacity to add engineers, so once it slipped the only lever I had was scope. I used it: features were cut, some things were deliberately done the cheap way, and a few grew because discovery found problems worth solving.
What I would do differently is not the estimate itself. It is that I had no way of telling early whether the second estimate was any better than the first — no checkpoint that would have surfaced the slip while there was still time to change the plan instead of only the scope. That is the thing I would build in.
Learning
The question I actually had to answer was not whether the rebuild was needed. Everyone inside the company knew it was. It was what would make it approvable, and the answer was to stop asking for the foundation and start proposing a project that contained it. A technical investment that cannot be justified on its own terms can often be justified as part of something the business can see.
The cost sits in the same sentence. What made the project approvable is what made it hard to size, and I cannot separate the two.
The checkpoint I said I would build is the one I went on to build. In my current role I introduced a quarterly roadmap and the delivery conventions that go with it, partly for this reason, and the team moved from completing 4 of 14 roadmap projects in their promised quarter to 9 of 10. That story is in Making Product Commitments Dependable.
Evidence note
This case study uses verified interview evidence covering the funding decision, the architectural requirements, the discovery and prioritisation method, the delivery dates, the migration mechanism, and adoption. No customer, partner, or colleague is identifiable, and no customer is described. It contains no internal document, ticket, screenshot, or commercial figure. The RICE rubrics are my own model, reproduced as they were written at the time.
Related work
Read Owning Product at Raffle AI for the company context and my wider Product Manager scope, or Scaling a Partner Channel for a focused example of turning commercial needs into reusable product infrastructure.