James Quinlan
eng @ trove, and a mediocre woodworker
Richmond, VA
eng @ trove, and a mediocre woodworker
Richmond, VA
Validated traits
Artifacts
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.
Testimonials
Software Engineer
Venture Partner - Co-founder at Marvin VC
Work history
Trove
Postscript
leerly.io
Robin
Yesware
Think of Us
Mind Your Design
JAN 2026 - PRESENT · 9 months
Founding Engineer
JAN 2026 - PRESENT · 9 months
FEB 2022 - NOV 2025 · 3.8 years
Senior Software Engineer
FEB 2022 - NOV 2025 · 3.8 years
I started my time working on the Flow Builder team, and then after a couple years, I transitioned to the Acquisition team to lead a large project.
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.
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.
NOV 2020 - JUN 2023 · 2.7 years
Founder
NOV 2020 - JUN 2023 · 2.7 years
leerly was a web app for teaching Spanish via comprehensible input. It was a small team of four folks, two of which were our writers who created our teaching content. We aimed to make reading Spanish for non-native speakers as painless as possible, and experimented with augmenting the reading experience with visual and auditory context, to help learners develop a more well-rounded understanding of the language.
SEP 2019 - FEB 2022 · 2.5 years
Senior Software Engineer
AUG 2021 - FEB 2022 · 7 months
Software Engineer
SEP 2019 - AUG 2021 · 2 years
JUN 2017 - AUG 2019 · 2.3 years
Software Engineer
JUN 2017 - AUG 2019 · 2.3 years
Complete responsibility for design, building, testing, and shipment of features. Regularly contributed to technical meetings for new features across a variety of microservices, and implemented them on both front and back ends.
Junior Software Engineer
JUN 2017 - MAR 2018 · 10 months
AUG 2015 - MAY 2016 · 10 months
Engineer
AUG 2015 - MAY 2016 · 10 months
Lead engineer for the first phase of the non-profits life, while finishing my undergraduate degree. We prototyped web-based tools to help young adults transition out of foster care.
JUL 2015 - MAY 2016 · 11 months
Front End Developer
JUL 2015 - MAY 2016 · 11 months
I worked as a front end developer for a small development and design firm on various client projects. I introduced build tools like Gulp to our websites, and helped make the use of responsive designs standard in our company's projects.
Verified on Trove - Your career capital, authenticated