Moments of impact from James Quinlan's career
leerly.io · FounderAfter a year living in Spain and immersing myself daily in Spanish lessons, I recognized a gap in how language learning tools helped people build genuine fluency. Drawing on the Comprehensible Input methodology popularized by Spanish-teaching YouTubers, in which students focus primarily on reading and listening to their target language, I co-founded leerly.io to build software that made this research-backed approach accessible and consistent for learners outside a classroom. As founder and sole engineer, I built the entire platform while simultaneously managing two language teachers (Violeta and Ali) who wrote articles and recorded audio, and while coordinating with advisors and early-stage VCs alongside my co-founder Ulrik, who led business development. The core technical challenge wasn't algorithmic complexity but UX experimentation: syncing audio narration with word-by-word visual highlighting, embedding contextual imagery for vocabulary, and passively tracking each user's exposure to specific verb conjugations and vocabulary over time, all while sourcing and structuring a usable corpus of Spanish language data. Because comprehensible input intentionally exposes learners to material slightly above their level, I had to balance helpful cues against distraction, relying heavily on my own experience as the platform's ideal user to guide design decisions before testing with others. Over roughly a year and a half of building this alongside full-time work, leerly.io grew to a few hundred users across free and paid tiers, reaching around $400 in monthly recurring revenue. This was enough at points to largely cover our writers' pay from article-based revenue alone. We landed our first paying customer, a milestone that made the business feel real, and saw unexpected organic traction internationally, with one of our teachers even being interviewed on Galician television about the platform. Many of our paying users turned out to be based in Europe rather than the U.S., a surprising signal about where interest was strongest. Ultimately, we made the call to spin down the company after about two years, as scaling further would have required a full-time 50-hour-a-week commitment that wasn't viable given our day jobs. The timing also aligned with GPT-3's release, which was about to reshape the entire language-learning landscape anyway. We migrated all users to a free plan, and while the platform remains live, it's no longer actively maintained or monetized. The experience validated that the core product resonated with real users, even though we didn't operate long enough to fully separate high natural churn in language learning from our specific product decisions. I love leerly, as it was my first failed business, which is a badge I carry with pride. And it will always remind me of my time living in Spain and the friends I made there.
Postscript · Senior Software EngineerAs 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.
PostscriptI 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.
