Sophos Builder

01 / Returning to Familiar Ground

A tool that had fallen behind the business.

Proposal Generator was designed to help Sales Engineers prepare customer proposals.

Over time, its product catalogue and pricing information became outdated. Quotations could show inflated costs, making the application increasingly unreliable.

A redesign had already been proposed.

As we examined the business requirements during the synthesis stage, it became apparent that the work would extend beyond updating the interface.

The original Proposal Generator would remain as the legacy version. We were building its successor.

That successor became Sophos Builder.

I had worked on the original application when I first joined Sophos. Now I was responsible for designing and developing the frontend of what would replace it.

The experience was useful, but it didn’t mean the new application had to inherit the old one’s assumptions.

02 / Understanding the Actual Workflow

The best reference wasn’t the old application.

Because Proposal Generator had become unreliable, Sales Engineers had created an AI-assisted alternative to help prepare proposals.

We studied their tool and used it as an initial reference, developing the new application through several iterations.

I also examined the Salesforce quotation XML and the PowerPoint presentations Sales Engineers used with customers.

The XML showed how quotation information was structured. The presentations showed what eventually reached the customer.

Together, they revealed the relationship between product selection, pricing, and the finished proposal.

We weren’t simply building an interface that generated slides. We needed to account for how those slides were assembled, what commercial information they contained, and how different product selections changed the result.

Understanding that process also revealed something the existing tools had overlooked.

03 / Finding What Was Missing

The savings were there. The proposal wasn’t showing them.

While examining the Salesforce quotation XML, I noticed two figures: the Total MSRP and the Customer Extended Price Total.

Neither the Sales Engineers’ existing tool nor their PowerPoint presentations displayed the difference between them.

The information was available. It simply wasn’t being used.

I introduced a savings comparison into the quotation table, showing the difference between those totals and making the customer’s overall savings visible.

The Sales Engineers were enthusiastic about the addition.

It was a modest feature, but it illustrated something I find important about product work.

Sometimes the improvement isn’t another complicated capability. It’s recognizing the value of information that was already there.

04 / Designing the Experience

One application, several ways to build a proposal.

Sophos Builder supports two principal workflows: Proposal Builder and Unsolicited Proposal.

Proposal Builder generates templated presentations across the Sophos product catalogue. Its core content depends on whether the selected solution is MDR, XDR, or a configuration without either core product.

Different product selections introduce different requirements and dependencies.

The challenge was to make those relationships manageable without forcing Sales Engineers to understand every rule behind the interface.

I also introduced an additional materials feature.

Users can browse supporting slides organized into folders and categories, preview them as thumbnails or in a larger view, and arrange their selections beneath the core proposal slides.

The feature gives users more control over the resulting presentation.

It also inspired an idea for a separate Slide Deck Builder, where similar capabilities could support creating presentations independently of Proposal Builder.

Unsolicited Proposal serves a different purpose. Its initial concept supports four selectable products with user-defined pricing. I introduced a currency selector to accommodate different pricing contexts.

These additions came from considering what users might need beyond the immediate requirements.

Some improved existing workflows. Another suggested the possibility of an entirely new product.

05 / Choosing the Frontend Architecture

A familiar stack isn’t always the right one.

Our team had traditionally used Next.js for frontend development.

For Sophos Builder, I decided to use React with Vite instead.

Builder is primarily a client-driven internal application. Its workflows revolve around product configurations, quotation data, and communication with backend services.

There was no meaningful requirement for server-side rendering, and I saw little benefit in adopting the additional framework capabilities Next.js offered.

I also reconsidered state management.

Rather than continue using Redux, I chose Zustand for shared client-side state and TanStack Query for server-state management.

The distinction was useful.

Product selections and proposal configuration belonged to the application’s client state. Remote data fetching, caching, and synchronization were separate concerns.

I also adopted Bun for package management.

These decisions weren’t about introducing different technologies for their own sake. I wanted a frontend architecture suited to the application, without carrying complexity we had no clear reason to use.

06 / Improving How I Develop

Catching problems before they become somebody else’s.

We already had automated pull request checks on GitHub and a dedicated QA tester.

Still, I wanted to catch more problems before my changes reached either of them.

I introduced additional, self-imposed pre-commit checks using Husky and began writing unit tests with Vitest to verify application logic and guard against regressions.

I also strengthened form handling and validation with React Hook Form and Zod, alongside tighter validation across the frontend and backend.

These weren’t replacements for the team’s existing quality checks. They were additional safeguards I chose to introduce into my development process.

Builder handles product configurations, pricing, and quotation information. Mistakes in those areas can have consequences beyond an inconvenient interface.

I wanted more confidence in the changes I made, particularly as the application continued to grow.

It seemed preferable to discover a problem during development than to have somebody else discover it during testing.

07 / Looking Back, and Ahead

Returning to where I started.

Sophos Builder remains an active project.

A Salesforce integration is currently underway, and several fast-follow features are planned.

The application has moved beyond its origins as a replacement for Proposal Generator, but its development is far from finished.

Looking back, I’m struck by how different my responsibilities were when I returned to the project.

This time, I owned the experience design and frontend architecture. I could question our established technology choices, examine the requirements more critically, and propose capabilities that influenced future product ideas.

Some decisions were small, like making customer savings visible. Others involved rethinking how users assembled presentations or how the frontend should be structured.

They all required understanding the problem before deciding how to address it.

Proposal Generator was where my work at Sophos began. Builder has given me an opportunity to see how much that work has changed.

And there’s still more to do.