Postscript

Rearchitected Flow Builder's Frontend for Scale and Extensibility

As one of the engineers owning the frontend of Postscript's Flow Builder, I participated in, then eventually led, a gradual, ongoing rebuild of the tool over roughly two and a half years — a "Ship of Theseus" style transformation where nearly every core piece of the architecture was replaced and improved while the product remained in continuous production use. The challenge wasn't a single crisis but a persistent scaling problem: our customer base ranged from small businesses to large enterprises, and the directed-graph-based flow editor needed to support increasingly complex automation logic without the engineering team having to build custom solutions for every large customer or drowning in tech debt. To solve this, my teammates and I took on several major architectural projects: we designed a new layout algorithm to efficiently compute positioning for large directed graphs, redesigned the rendering pipeline to handle graphs with hundreds of nodes performantly, and reworked how individual nodes (actions) were represented so the graph structure could support more complex conditional branching logic at arbitrary depths. Each of these changes had to preserve backwards compatibility with every existing customer flow, and we held a strict team standard of never trading feature velocity for tech debt — instead treating new feature work as an opportunity to actively simplify the codebase. While we often used various high-level metrics and KPI's to track our impact — like the volume of messages sent via flows — our focus was on finding the right level of abstraction so the platform could serve the full spectrum of customers simultaneously, from simple use cases to the most demanding enterprise workflows, without disproportionate engineering investment in any one segment. The result was a tool that could support enterprise-scale, high-complexity flows (hundreds of nodes, deep conditional logic) that previously would have pushed customers toward competing tools, while keeping the codebase cleaner and more maintainable than when we started. I consider this one of the best examples I've seen of a team successfully expanding product functionality while simplifying — rather than bloating — the underlying implementation. This was one of the best teams I have ever worked on, and the sense of ownership I had over this complex frontend was profoundly important to me.

Validated by 2

GDMM

James QuinlanSenior Software Engineer

March 2024

Rebuilt Postscript's Popup Editor to Double Opt-In Rates and Increase GMV Adoption

I led the technical design and development of a complete rebuild of Postscript's popup editor, replacing a legacy tool that had become a significant customer pain point. The original editor had been in use since the company's founding and had scaled far beyond its intended capacity—its extremely limited feature set made anything beyond basic customization nearly impossible, forcing customers to pay for third-party popup solutions. This resulted in churn and lost deals. The technical challenge was clear: we needed a modern, flexible tool that would maintain the performance standards critical to our SDK, which was being loaded hundreds of millions of times per month on our customers' Shopify sites. I began by prototyping different rendering technologies on my own time to navigate known technical constraints. Our SDK needed to remain lightweight to avoid degrading site performance, which meant minimizing bundle size while maximizing configurability. After testing both Lit and a React/Preact dual pipeline approach, I validated that Lit would meet our needs without unnecessary complexity. With the rendering backend decided, I designed the underlying data structures for popup representation, drawing inspiration from Notion's block architecture. I wanted to create an arbitrarily composable system using block-like primitives that would map to HTML elements—headers, form inputs, media—while remaining efficient to transmit and render. After about a month of experimentation, I validated that the system could support complete configurability without sacrificing performance. The most critical design challenge was abstracting the complexity of HTML and CSS into intuitive, user-friendly controls that didn't require customers to learn web development to create effective popups. Once the project was sufficiently de-risked, additional team members were brought on, and I continued building large portions of the rendering code while overseeing the editor's development. I served as the primary interface with Product and Design throughout the project, ensuring all stakeholders remained aligned. The results were significant: in the first full quarter after releasing to early customers, we saw a 2x increase in opt-in rates and a measurable jump in GMV adoption. Because our popups serve as the top of Postscript's subscriber funnel, we leveraged existing analytics pipelines to gain full visibility into these improvements. The new editor eliminated the need for third-party solutions, reduced customer churn, and dramatically expanded the customization capabilities available to Postscript's customers. Some data: Increased aggregate opt-in rate by 2x, going from ~2% to ~4% on the new editor. Increased adoption of PS popups from ~45% of merchant GMV to ~70% of merchant GMV.

Validated by 2

KAJW