At Faire, we have a problem that many test engineers would envy: we have over 71,000 automated tests in our backend repository. But here’s the challenge — running all those tests on every pull request would bring development to a crawl. So we don’t. Instead, we skip about two-thirds of them.

In order to run the right tests at the right time, we use sets of deliberately simple strategies, each tailored to a specific testing context. (Internally, we talk about “test avoidance” rather than “test selection” — the goal isn’t to pick a few tests to run, but to confidently skip the ones we don’t need.)

Here’s how we approach test selection at Faire, and what we’ve learned along the way.

The friction point

Before diving into solutions, it’s worth understanding why this matters. Every pull request goes through several gates: local development, code review, merging to main, and eventually release to production. Each gate asks a question:

• Local development: Are my changes good enough to put up for review?
• Pull request: Are my changes good enough to merge?
• Main branch: Are my changes good enough to release?

The earlier we can answer these questions, the faster developers get feedback. But the more tests we run, the more friction and delay. Test selection helps us balance speed with confidence.

Faire’s current state

Let me ground this with some numbers from our backend monorepo:

• 71,000+ unique test cases (and growing)
• 67% test avoidance rate on pull requests (we define our test avoidance rate as the percentage of tests can we skip)
• 300+ engineers contributing to the codebase across all repos, either directly or through AI coding agents

The use of coding agents is accelerating our pace of development, and with it the rate of new pull requests. We need good test coverage to check that AI isn’t breaking anything unintentionally, but we also need to control testing costs and avoid bottlenecking development with limited compute resources.

We’re striving for the ideal test pyramid — lots of fast unit tests, fewer integration tests, minimal end-to-end tests. We’re not there yet, which makes test selection even more critical in the meantime.

How we choose which tests to run

Test selection isn’t one-size-fits-all. At Faire, our approach depends heavily on the context — what kind of tests we’re running and what constraints we’re working within. Here’s how we handle three different scenarios.

Backend integration tests: configuration-based avoidance

Our backend repository includes build graph analysis out of the box — Gradle understands which modules depend on each other. In theory, this should tell us exactly which tests to run when code changes.

The problem: Our largest backend service has integration tests that use real objects as much as possible, creating a web of interdependencies. Leveraging the build graph alone only allows us to skip about 30% of our tests on average, because nearly everything is connected to everything else.

Our solution: We layer a configuration-based approach on top of the build graph to filter dependency chains when choosing which tests to run. Engineers can define rules in their build.gradle.kts files that specify:

• Allowed triggers: “Only run tests for Project A if changes touch Projects A, B, or D”
• Allowed tests: Changes to a particular project can only be used to trigger a certain subset of projects’ tests. Useful for Protobuf projects, where most issues are caught through compilation errors instead of tests.
• Force run: “Always run tests for Project A when Project B changes” is useful when we’ve seen escaped regressions. Force run always overrides other test avoidance rules that may originate from upstream build files.

For example:

testAvoidance {
    skipTests {
		    // Allowed triggers:
        unlessTriggeredByProject(":service-A:subproject-B") { includeSubprojects = true }
        unlessTriggeredByProject(":core:subproject-C") { includeSubprojects = true }
        
        // Also break dependency chains for projects that depend on this one unless
        // one or more allowed triggering project changes.
		    avoidTriggeringDownstreamProjects = true  
    }
    
    runTests {
		    // Force run this project's tests when subproject-D has changes, regardless
		    // of test avoidance rules in other projects:
				whenTriggeredByProject(":service-A:subproject-D")
		}    
}

In practice, this means tests for this module are skipped unless changes touch one of the explicitly listed upstream projects.

The filtering rules we have in place today allow us to skip over twice as many tests as we would using build graphs alone.

What makes this work: The configuration lives in code, version-controlled alongside the application. When engineers change a module, they update its test avoidance rules in the same PR. Less potential for drift, as developers are accountable for maintaining these with their build files.

End-to-end tests with backend changes: product area tagging

For E2E tests, we ran into different constraints — every test depends on the system as a whole, and not some smaller subset, making build-graph approaches impossible. We also run E2E tests in parallel using a shared backend sandbox environment. This meant we couldn’t use code coverage analysis for backend changes — profiling would interfere with parallel test execution.

Our solution: Both backend code and E2E tests have already been tagged with product areas (Payments, Search, Orders, etc.). We also created mappings between related product areas — changes to Payments might affect Checkout tests, for example.

When a PR includes backend changes, we:

1. Identify which product areas the changed files belong to
2. Look up related product areas through our mappings
3. Run E2E tests tagged with those product areas

If a test is skipped that subsequently regresses in main branch due to the changes, then developers are encouraged to update the mappings when fixing forward after reverting.

The tradeoff: This requires discipline to keep tags and mappings accurate. But it gave us test selection for E2E tests when code coverage wasn’t an option.

End-to-end tests with frontend changes: from coverage to opt-in

For frontend changes, we initially used a code coverage-based approach. We’d profile which code each E2E test exercised, then run only the tests that covered the changed frontend code.

What changed: When we began using React Server Components with Next.js, we lost the ability to profile our tests effectively. The server-side rendering architecture made it impossible to get accurate coverage data.

Our current approach: E2E tests are now opt-in for pull requests. Engineers explicitly choose to run E2E tests when they believe their changes warrant it by adding a label to their pull requests. This isn’t ideal, but it’s honest about our current constraints while we explore better solutions.

This shifts responsibility onto engineers, which is a real risk. We mitigate it through strong code review norms, production monitoring, and by still running the full E2E suite on main. It’s not perfect — but it’s better than pretending we have signal when we don’t.

What we considered (but didn’t implement)

We didn’t arrive at our current solution without some detours along the way. Here are the other approaches we evaluated:

Predictive test selection with ML: Train a model (like XGBoost) on historical data — which files changed, which tests failed, code metrics, etc. — to predict which tests are likely to fail. In theory, powerful. In practice, when applied to our E2E tests, we couldn’t achieve a low test selection rate without also having a high escaped failure rate. Training was vulnerable to flaky failures, and we lacked strong “cross-features” to confidently measure the relationship between tests and changed code.

LLM-based selection: Could we use large language models to decide which tests to run? The non-determinism is a dealbreaker for CI. We need predictable, consistent behaviour. However, developers may still wish to ask coding agents to identify and run appropriate tests locally.

API endpoint mapping: Map tests to the API endpoints they exercise. Works great if your code is well-organized around API boundaries, but shared code and asynchronous job code will be more difficult to map in an automated fashion.

Putting test selection into practice at Faire

Having a technique is one thing. Making it work in production is another. Here’s Faire’s process:

Step 1: Define success metrics

Before implementing anything, we defined what “good” looks like:

• Test avoidance rate: What percentage of tests can we skip?
• Escape rate: What percentage of failures do we miss?
• Time savings: How much faster do PRs get through CI?

We set targets based on our risk tolerance. Missing a bug is costly, but so is slow developer feedback.

Step 2: Choose and configure the tool

For our backend monolith, we started with build graph analysis and source module mapping — proven approaches that matched our architecture.

Configuration happens in our build files, making it code-reviewed and version-controlled alongside the application code.

Step 3: Run in dry-run mode

This is critical: we didn’t just turn test selection on. First, we collected statistics:

• Which tests would have been skipped?
• Which tests would have run?
• Would we have missed any failures?

We compared dry-run results against our success metrics and iterated until we were confident.

Step 4: Turn it on (carefully)

Once dry-run metrics met our targets, we enabled test selection for real. But the work didn’t stop there.

Step 5: Monitor continuously

Your codebase changes every day. Test selection performance can drift because:

• New features may not fit existing patterns
• Refactoring can change dependency structures
• Technical debt accumulates

At Faire, we saw this firsthand when we introduced server-side rendering. Suddenly, a growing number of source files could no longer be profiled and mapped to tests. We had to adjust our configurations to adapt to the new architecture.

The key lesson: Test selection isn’t a set-it-and-forget-it solution. It requires ongoing monitoring and maintenance.

Results and lessons

Skipping 67% of tests on every PR has given our engineers faster feedback and reduced CI costs. But more importantly, we’ve learned:

1. Match the approach to your architecture. Build graphs work great for well-modularized code. API mappings work for service-oriented architectures. There’s no one-size-fits-all.
2. Simpler is often better. Predictive ML sounds exciting, but configuration-based approaches delivered good value without the complexity.
3. Configuration must live in code. When test selection configs are external, they drift. When they’re in version control and code-reviewed, they stay more accurate.
4. Always dry-run first. The cost of escaped failures is high. Measure twice, cut once.
5. Treat it as a living system. Your codebase evolves. Your test selection needs to evolve with it.

What’s next for test selection at Faire

We’re not done. As we continue breaking down our monolith backend service into services and modularizing our frontend code, we’re exploring:

• Service-level smoke tests: As we extract services and frontends, which smoke tests should run?
• Finer-grained selection: Can we get more specific than module-level?
• Developer- and coding-agent-facing test recommendations: Which tests should be run locally before opening a pull request?

The goal remains the same: run the right tests at the right time, giving engineers fast, reliable feedback without sacrificing quality.

Scalable test coverage: How Faire selects which tests (not) to run was originally published in The Craft on Medium, where people are continuing the conversation by highlighting and responding to this story.

Written by Divya Sudhakar and Julian Pettit

How do you communicate the right message to the right users at the right time? At Faire, the Engineering team grappled with this challenge as our product and company grew. Different teams were adding banners, nudges, modals, and alerts throughout the app to promote and upsell their various programs. Without a unified system, the result was often fragmented with duplicated logic and inconsistent user experiences. On some of our highest impact pages like the checkout page, a retailer might have encountered up to five different banners at once. These were controlled by disparate client code paths and often looked entirely different, with no common design language. In short, we were shipping our org chart.

In addition to our product looking chaotic, this made it arduous for engineers to add or modify messages since the display rules were scattered across codebases. We needed a better way to coordinate customer-facing messages that would streamline development and ensure a polished experience for our users.

Our answer was Conductor, an internal platform that now serves as a one-stop shop for creating and managing any in-app message we show to retailers. Conductor lets us define what message to show and when to show it using a low-code UI, and takes care of delivering that message to all eligible users across web and mobile platforms. Having all our promotional messages flow through Conductor also lets us prioritize which messages to show and create hyper-personalized content to ensure that users are seeing the most relevant and engaging messages.

In this post, we’ll share how Conductor works, why we built it, and how it successfully powered a major refactor of our checkout page banners. We’ll discuss the technical approach and use of server-driven UI components, and the impact we’ve seen: dramatic drops in bugs and a boost in developer velocity.

The challenge and our approach

By late 2024, our approach to in-product messaging was hitting its limits. Each product team would implement their own banners or modals, often hard-coded into the frontend (more on this later). These banners were not consistently organized; an audit of the checkout surface found this code spread across multiple frontend packages, with no single source of truth for when each should appear. This led to several pain points:

• Engineering complexity: Adding or updating a banner required digging through various code paths to find the right place to insert logic. Removing an outdated banner was equally slow, since it was not immediately clear what other components might interact with it.
• An outdated mobile experience: This client-centric engineering approach meant teams required one or more frontend, Android, and iOS engineers to build any given feature. In practice, if all the client engineers were not available simultaneously, the feature would launch on the web first. Mobile updates would often be delayed. The mobile experience tended to lag behind the web experience resulting in fragmentation and lack of cohesion for clients who use the apps and the web.
• No global coordination: Because each banner’s logic was isolated, nothing prevented five different teams’ banners from showing all at once. We saw instances of many banners stacking on the same page, cluttering the UI and potentially confusing users.
• Inconsistent design and UX: With each team building banners independently, styling and placement varied. Some banners used templated designs, others were one-offs, leading to a jarring experience and more work for our design and engineering teams to review each time we implemented them.

We built Conductor to address these challenges with a focus on:

• Self-serve configuration: Messages are configured via a low-code admin UI, with no code deployment needed for new or modified messages.
• Standardized and opinionated presentation: All messages use pre-built server-driven UI (SDUI) components from our internal design system.
• Centralized coordination: With full knowledge of all the messages that can be shown to a user, Conductor determines what message to show. Indeed, this aspect of “conducting” the messages was so important that we named the platform after this capability.

This turned our previously scattered banner logic into a coordinated, declarative system that improved both developer velocity and user experience.

Architecture and terminology overview

Conductor runs as a backend service that delivers server-driven UI (SDUI) components (for example: banners and modals) to eligible users.

A campaign defines a messaging theme or goal — such as a promotional push or a failed payment alert — and can include multiple components across different parts of the app. Each campaign encapsulates targeting rules and priority. Components use standard UI templates from our design system, Slate.

Users are enrolled in these campaigns through async events we call triggers. For example, a trigger might fire when a user receives a promotion, enrolling them in the corresponding Conductor campaign to display relevant messages. Campaigns can also target all users globally, as we often do during our biannual Market events.

Runtime flow

• Client request: When a page loads (e.g., checkout), it calls Conductor with user context and surface (e.g., CHECKOUT_PAGE_TOP).
• Eligibility evaluation: Conductor filters active campaigns by audience, triggers, and enrollment status to determine whether or not a user is eligible to receive messaging.
• Prioritization: If multiple campaigns qualify, it returns only the highest-priority ones within configured limits. Prioritization ensures that only a specified number of campaigns display per surface.
• Rendering: The client renders messages using our SDUI framework, which can be displayed directly as provided.
• Analytics: Conductor natively logs every impression and interaction with components. This gives us high quality data on what messages users are receiving and which ones are resonating with them we can use to debug issues and train our model. These guardrails allow product teams to experiment and iterate quickly without compromising user experience.

This system keeps client code simple. Campaign logic, targeting, and presentation live on the backend, while clients just render the result.

Showing the right message at the right time

While Phase 1 of Conductor focused on improving developer velocity and design cohesion, Phase 2 centered on “intelligence.” As more campaigns migrated to Conductor, prioritization became one of its most valuable features. We also saw growing concern about “banner blindness,” prompting requests for guardrails to prevent showing the same message repeatedly to users who weren’t engaging with them. A central repository for messages — with a system to govern it — enabled us to build intelligence and capabilities that individual teams couldn’t achieve on their own, especially when banner development was just incidental work for them.

Closely related is personalization. We’ve always recognized the value of tailoring extremely personal experiences for our users. But having one central system made it easier to plug in all the data we have on our retailers and use it to pick the right copy and creative to meet retailers where they are.

Together, prioritization and personalization transform Conductor from a delivery mechanism into an intelligence layer for in‑product messaging, ensuring that retailers see fewer — but more relevant and engaging — messages.

Case study: migrating checkout banners with Conductor

Checkout was a prime candidate for Conductor: a critical surface filled with conflicting, hard-coded banners. We migrated these banners to Conductor with the following steps:

• Audit and standardization: We consolidated 11 banner types into only two standardized components, improving our visual consistency and adherence to Faire’s design principles.
• Triggering logic: Legacy conditions governing when and where components should be displayed were moved into Conductor campaigns. The triggering events automatically enroll users into the right campaigns when conditions are met to receive messaging.
• Determining priority: We limited checkout to show at most one banner at a time. Each campaign was assigned a priority which is enforced by Conductor at runtime so the most prominent message is always being shown to retailers.
• Integration and rollout: We phased out our client-side banners, replacing them with calls by checkout services to Conductor as part of page generation. Once the rollout completed we were able to clean up and greatly simplify the frontend checkout messaging code.

Results

Conductor delivered strong results across multiple dimensions:

• Velocity: Campaigns that previously took days to design, implement, and deploy to production now launch in minutes, saving days of effort and delay. The self-serve model and low-code tooling enabled faster feedback loops during the checkout banner migration, letting engineers and QA adjust configurations without writing new code. It’s also reduced engineering overhead by an estimated 30–40 hours per month.
• Quality: Checkout banner bugs dropped 43% the quarter after the migration, reducing engineering maintenance effort. The largest class of defects related to incorrect web banner interactions was eliminated altogether.
• User experience: Users see fewer, more relevant messages. Banners no longer stack or compete unintentionally, and design is no longer made more complex on surfaces that already feature many potential messages.
• Performance: Conductor API calls are fast (~25ms) and run concurrently with page loads, keeping the user experience snappy and responsive.

Scaling a platform: adoption lessons

Driving Conductor adoption has looked very different at different stages.

Early (provisional) stage

Adoption was relatively straightforward. We treated Conductor like a product and approached adoption as a search for product-market fit. We partnered closely with a small set of sophisticated application teams, designing the platform alongside them and iterating based on candid feedback. These teams were willing to invest in us, and our role was to stay just ahead of their roadmaps — delivering clear value without slowing them down.

Operational stage

As the platform matured and adoption shifted from Erratic to Extrinsic Push (from the Platform Engineering Maturity Model), the nature of the problem changed. We were no longer working with a handful of aligned early adopters. Instead, we were asking many teams across the company to change how they built, shipped, and operated messaging. Each team had different incentives, constraints, and success metrics.

Driving adoption at this stage was messy and required a multi‑pronged approach. We had to rethink both the problem we were solving and the promise we were making, meeting teams where they were while still guiding the organization toward a shared platform. A single mandate or narrative would have been ineffective and, in some cases, counterproductive. Conductor’s strength was that it offered value along multiple dimensions — velocity, design consistency, prioritization, personalization, and long‑term maintainability — which gave us flexibility in how we framed that value. In parallel, we invested in identifying advocates who could speak to Conductor’s impact from different perspectives and act as internal partners, creating pockets of high adoption.

These advocates weren’t just engineers. Designers were especially helpful in surfacing gaps and unblock adoption early, motivated by a shared design language and cohesive user experience.

Ultimately, platform adoption isn’t just a technical problem. It’s a socio‑technical one — sitting at the intersection of product strategy, incentives, workflows, and culture — and it requires patience, empathy, and a shared commitment to craft.

What’s next

Looking ahead, we see Conductor as the execution layer in a larger ecosystem.

By integrating Conductor with our customer data platform — powered by a knowledge graph — we’re working to unlock deeper personalization and smarter prioritization. This sets the stage for messaging that is increasingly contextual, adaptive, and relevant to each retailer.

As Conductor continues to lower the cost of launching campaigns, we’re investing in stronger guardrails and cooldowns to ensure retailers aren’t bombarded with messages. In parallel, we’re continuing to improve Conductor’s tooling as adoption expands and we undertake what is effectively a large rewrite of messaging across our site and apps.

Conductor started as a way to ship faster. Now, it’s becoming a foundation for consistent design, intelligent messaging, and scalable growth across Faire.

Acknowledgments

Thanks to Jake Buller, Justin Li, Praviin Premsankar, Emily Cai, Eric Ding, Zachary Sweigart, Zachary Radford, Pedro Almeida, Gordon Winch, Birol Senturk, and Emily Thompson for their contributions in building Conductor.

Thanks to Emily O’Leary, Sumit Somani, Fabio Carmo, Brandon Dang, Yao Wang, and Derek Gleeson for their contributions migrating the Checkout page banners onto Conductor and also to our many many client teams for their work and patience.

Thanks to Luthfur Chowdhury, Alexa Weiser, Jeff Hodnett, Jessica Karle, Amy Talus, and Taichi Hoshino for their leadership and support throughout the last year of building Conductor and driving adoption.

Interested in the kinds of problems we tackle at Faire? We’re hiring engineers and data scientists who want to solve unique marketplace challenges and combine cutting-edge tech with real-world impact. Join us.

Conductor: Faire’s platform for orchestrating in-app messages was originally published in The Craft on Medium, where people are continuing the conversation by highlighting and responding to this story.

On November 27, 2025, we welcomed Toronto’s tech community into our office for a Tech Talk dedicated to how Faire engineers build. Across six talks, from discovery and fulfillment to mobile, CRM, and experimentation, our speakers shared how Faire engineers have built out solutions shaped by interviews, experiments, and customer behavior, delivering real value for the brands and retailers we serve.

You can watch a video recording of the event. Here are some of the highlights!

Powering discovery on the Faire homepage

The evening opened with Juno Zhu and Nakul Pathak from the Inspire pod, who shared the multi-iteration journey of building a real-time homepage feed. Retailers had repeatedly told us the page felt stale, with recommendations that refreshed too slowly. The team needed to rethink the experience without rebuilding the entire discovery stack.

Their first iteration reused the visually similar product engine already powering product-page recommendations. With a vertical grid and live ranking, they shipped an MVP in a week. Homepage views rose 1.5×, and retailers immediately noticed how responsive it felt. Building on the success, the team broadened the signals powering the feed, from cart activity and long-term embeddings to complementary categories and bestsellers. This led to a 110% increase in products added to cart compared to the old carousel model.

As usage grew, they tackled content fatigue by filtering out products already viewed, deprioritizing brands a retailer never orders from, and avoiding repeats across surfaces.

Looking ahead, the team is exploring tailored experiences for new retailers with sparse signals and new layout types designed for inspiration rather than pure relevance.

Building Fulfilled by Faire as a lean pilot

Chinmaya Nathany from the Fulfilled by Faire pod shared how we launched a centralized fulfillment service in just five months. Fulfillment typically accounts for 10–15 percent of a brand’s order value, and retailers face fragmented experiences when each brand ships separately.

We saw an opportunity to consolidate shipments by storing participating brands’ inventory in a Faire-operated warehouse and fulfilling orders on their behalf. Retailers benefit from a single minimum and consistent delivery, while brands offload the operational burden.

Chinmaya described building the pilot while also playing the roles of product and design. The team visited warehouses, prioritized requirements into clear buckets, partnered with a tech-forward 3PL, and built the integrations needed to sync products, orders, shipments, and inventory. They rolled out gradually to a small set of invited brands.

Within six months, the pilot processed more than 15,000 orders for 41 brands. Early partners reported major time savings during peak seasons, and the initiative has now grown into two full engineering pods focused on scaling the service and improving the multi-brand checkout experience.

Bringing Faire to iPad with a small but impactful redesign

Next, Spencer Edgecombe, an iOS engineer from the Brand team, shared how reframing a single metric revealed an overlooked opportunity. iPad users appeared to drive only 2% of order volume, but a deeper look showed that the 6% of retailers who used iPad generated 11% of total order volume and spent more than twice as much as non-iPad users. It was a small but highly valuable segment we weren’t serving well. Spencer’s investigation ultimately led to the greenlight for the iPad project.

To accelerate delivery, the team avoided building a separate app and instead introduced a split-view navigation model that reused most iPhone layouts while giving root screens a wider, more intuitive iPad experience. They also produced new App Store visuals, localized them across nine languages, and partnered with teams to ship the redesign.

Following the launch, order volume from iPad retailers increased 11%, iPad’s contribution to total volume rose by 1.5 percentage points, and over 4,000 more retailers adopted the native app. The project also helped accelerate the team’s broader shift toward SwiftUI and modern concurrency.

Rebuilding Brand CRM for speed and scale

Ege Akkaya from the Relationship Growth pod shared how Faire migrated Brand CRM to Elasticsearch to resolve major performance challenges.

CRM powers the targeted campaigns brands send through Faire, around 2.5 million emails per day. Queries for large brands had become increasingly slow or prone to timeouts as datasets grew, and our relational setup had reached its limits. The customer table held more than 135 million rows, and maintaining indexes for every filter combination was no longer feasible. Alternatives like distributed SQL or DynamoDB carried their own constraints. The team decided to leverage Elasticsearch after a detailed technical investigation. With its inverted index and horizontal scalability, Elasticsearch was a great fit for CRM’s flexible filtering needs.

The team migrated incrementally, starting with a proof of concept, then enabling read and write paths, and finally validating correctness through shadow reads in production. They separated order-history into its own index, tuned refresh intervals, and used partial updates to keep documents lightweight and fast.

By October, CRM traffic was fully migrated. Queries that previously took seconds now completed in under 100 milliseconds, and P99 latencies dropped more than eightfold, transforming the experience for some of our highest-volume brands.

Evolving experimentation for faster learning

Alier Hu closed the engineering talks by describing how we accelerated both experiment setup and experiment learning across Faire. Previously, even simple A/B tests could require weeks of configuration and engineering support. To improve speed, the team introduced Builder.io, a codeless CMS (Content Management System) integrated with Faire’s component system.

Designers and PMs can now make layout and content adjustments directly, supported by a Figma plugin that converts design components into production-ready structures. Since adoption, 12 teams have shipped 37 experiments and features through Builder without writing bespoke frontend code.

To improve the pace of learning, the team implemented multi-armed bandits alongside traditional experimentation. Instead of splitting traffic evenly until significance, bandits gradually route more users to higher-performing variants, reducing the time it takes to converge on strong ideas and minimizing user exposure to weaker ones.

Looking ahead, the team is exploring AI-assisted variant generation and more automated experimentation loops.

What’s next

Conversations continued well into the networking session as guests connected with engineers, hiring managers, and our talent team. The talks only scratched the surface of the work happening across Engineering to deliver value to the brands and retailers who rely on Faire. If you’re interested in making an impact on millions of small businesses around the world, we’d love to meet you. We’re hiring across backend, frontend, mobile, data, and engineering management, explore open roles at faire.com/careers.

You can also keep an eye on faire.tech/events for upcoming tech talks. We look forward to seeing you at the next one.

A big thank-you to our speakers — Juno Zhu, Nakul Pathak, Chinmaya Nathany, Spencer Edgecombe, Ege Akkaya, and Alier Hu — and to the organizers Jeff Hodnett, Sandra Campos, Trevor Omoto, Jasmine Fernandes, Becky Laufer, Angela Trieu, Ava Quinn, Carolyn Nolan, Leandre Martinez, Sabrina Fong, Brock Jenken, Ed Yakabosky and Cheuk-man Kong for making the night possible.

Building beyond code: Faire’s product mindset in engineering was originally published in The Craft on Medium, where people are continuing the conversation by highlighting and responding to this story.

On a cool, early November week in Chicago Illinois, over 25,000 people gathered to champion diversity in tech at the Grace Hopper Celebration (GHC). As first time attendees, the experience was nothing but remarkable for our small group of data scientists, engineers, product managers, recruiters, and communications and marketing team members coming from Faire. We enjoyed meeting attendees at the Faire booth, learning from speakers on a plethora of topics, and getting to connect with a diverse group of largely underrepresented talent within tech and hear about their experiences. What made it even more special was to be able to speak so proudly about Faire’s mission. At Faire, we’re focused on empowering brands and retailers to succeed through our marketplace and operations tools, which has a major impact on helping women-owned businesses launch and thrive. Overall, it was an awe-inspiring experience. In this blog post, we’ll share some of the most interesting and impactful moments from our time at GHC this year.

Making connections at the booth

The Grace Hopper experience was especially meaningful this year as Faire hosted the conference’s first ever Small Business Marketplace, featuring eight women-owned brands local to Chicago. It was an incredible chance to showcase our mission and how Faire supports independent entrepreneurs. At our booth, we had a constant flow of individuals interested in hearing more about what we do. As a B2B company, it’s not uncommon to field many questions about our platform, mission, and our impact on customers; however, we found that a lot of the people we talked with could easily resonate with what Faire stands for: supporting local.

One of the highlights was getting to share projects we’ve worked on. (For example, I was able to proudly show off a homepage upgrade that my team built!) Our group was able to form connections with those who have utilized platforms similar to Faire.

We were also approached by many individuals who had used Faire for themselves, or had witnessed Faire’s impact on friends or family. It was incredible getting to hear directly from brands about how our work has impacted their sales, their business, and their lives as a whole.

The power of connection

One of the best parts of attending GHC was the people we met — both at our booth and on the floor. The audience was diverse, both in their roles and career stages. We met early career engineers and provided advice on landing that first internship; we chatted with senior staff designers about doing work that leaves a positive impact on the world; and we also connected with product managers looking to expand out of their current field. From the technical side, we connected on stacks and infrastructure, for example, discussing server-driven user interfaces and their limitations, or comparing approaches on when to best utilize certain AWS databases over others.

Although we all came from different cities, industries, roles, or even countries, we shared common experiences and aligned in ways one might not expect: a yearning to create a positive impact through our work, a passion for the evolution of diversity in technology, and, unfortunately, bruised hearts from years of micro-aggressions faced in grade school, university, and many of our workplaces.

That said, hearing our collective experiences reinforced the gratitude I have for the coworkers and community that I’m a part of at Faire. I was able to share that even in my first few months as a (fairly lost) new grad engineer, I was never belittled or made to feel less than for asking a question from anyone at Faire. Though it may seem like a low bar, that was almost shocking for many of the individuals I spoke with. Moreover, I shared that my team is majority women: three of four backend engineers and two of four frontend/client engineers are women, a rarity in tech. I’ve also had the privilege of being on leadership for both our Femmes (women+ focused) employee resource group, and our Femmes Code (women+ in technical roles) subchapter, where we organize events and opportunities to both uplift women in their careers and lives, and educate allies on how to better support, sponsor, and elevate those around them.

Although Faire’s culture stands out, equitable treatment is something everyone should experience, no matter our background. Events like GHC help us to share our experiences, understand what’s possible and what we should be aiming for, and feel more united in asking for what we deserve.

Learning from other leaders

We were able to learn from the vast selection of talks organized by GHC. A favorite was a presentation titled The Fire You Carry: What Female Rage Can Teach Tech, which shared how women can harness their rage to their advantage in the workplace. Anger is a call for long-term action, and not something to dismiss as being “too emotional” or “too sensitive” as we often do.

Other Faire attendees sat in on talks like The Manager’s Edge: Unlock Your Mentoring Superpowers, which shared how to empower people by matching the intervention to the need — teach to close skill gaps, coach to shift mindset, and advise selectively when guidance is explicitly needed. Other notable talks included Emotional Intelligence For Success and Well-Being, which discussed how emotional intelligence significantly impacts performance by improving self-awareness, communication, and stress management, which leads to better decision-making and higher productivity.

Throughout these talks, we were able to learn from a primarily female lens, rather than translating these topics through our own set of glasses, as we often do. That alone was an impactful shift compared to what we are used to and emphasized the importance of different voices in our industry.

Feeling a sense of belonging

Outside of the Faire booth, we were able to connect and explore beyond even the bounds of the conference. From the minute I stepped off of the plane until the minute I arrived back on Canadian soil, I felt like the tech landscape had flipped on its head. As I stepped into the elevator in Chicago, headed to the taxi area, women’s luggage tags and backpacks were labelled with logos from many large tech companies. Even the evening before the conference, sitting at a restaurant bar, I asked the woman next to me what brought her to Chicago. I’m sure the smile on my face proved just how excited I was that she was also there for GHC. We chatted about what we do, our experiences, and what we were most looking forward to. Even on my flight home, my entire row was filled with women in tech.

Though small, having an intersection of my identity be the majority not only within a room or conference, but what felt like the entire city, is an experience I will never forget. Despite having had largely positive experiences as a woman in tech, it was the first time that I felt like I belonged without caveats or qualifiers: nothing to adjust, prove or soften, just me.

Reflecting on the experience

Arriving home, though exhausted, we felt inspired by all of the conversations, presentations and moments surrounded by and celebrating minorities in tech. Hearing about others’ experiences in their workplaces both inspired us and also emphasized just how lucky we are to do what we do. Being reminded about the impact we have every day at Faire (through the brands that had sold out of many of their products during the conference) emphasized the power we have to help small businesses thrive even more.

The theme of GHC 2025 was “Unbound,” meant to represent releasing preconceived notions of what we can or can’t do, releasing limitations we’ve placed on ourselves and leading as we are. Both personally, and for Faire as a whole, I think we really took the theme to heart. In a time where many companies feel the need to fit into a mold, by embracing diversity and doing all we can to build a team that best represents our customers, Faire is becoming unbound from the traditional tech landscape. Our success has occurred not in spite of our diverse team, but because of it. Although we, like most companies, still have a ways to go, I walked away feeling very proud to say I work at Faire, a company that truly cares.

Unbound belonging: Faire’s experience at the 2025 Grace Hopper Celebration was originally published in The Craft on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Faire, we have a very robust Kotlin backend service infrastructure that we’ve carefully honed over the years, powered by a collection of established libraries and frameworks used by the broader open-source community, all coupled with some special Faire glue to make it all work. And as many within the JVM world, for ease of database access without writing and mapping SQL queries to models by hand, we use Apache Hibernate. The Hibernate ORM is probably the most famous (infamous?) ORM framework of all time, and it has set the standard — and many of the pain points — for ORMs in general for several decades (yep, I know — feeling old yet?). It’s a polarizing topic. The discourse is often that people hate it but still use it, which leads me to compare it with that old democracy adage: it’s the worst way to do things, except for all of those other ways that have been tried from time to time.

It’s undeniable how easy Hibernate can make setting up basic database access, especially for smaller CRUD applications, by directly mapping tables to your POJOs, requiring very little boilerplate and glue. But it can lead to many issues that lead a lot of people to choose alternatives. But we’re not here today to talk about those, or discuss how to do ORMs or DB access in general (I leave that for the philosophers in the comments). Instead, I wanted to share a small way in which we made our usage of Hibernate, specifically the legacy Criteria API that we still use, a little bit better at Faire — taming one of its pain points with a creative solution. Hint: it will involve type-safety and KSP ;)

The Criteria API

The Criteria API is a legacy way of building queries. There are newer alternatives on newer Hibernate versions, including some that aim to fix this exact pain point we’re going to talk about. But if you’re in a large codebase that has evolved and adapted around the Criteria API, you might find newer alternatives can actually be more verbose, or require a bigger paradigm shift or migration that your team might not be ready or willing to accept. In which case, you will probably be familiar with your code for building queries currently looking something like:

criteria.add(Restrictions.eq("column", value))

If that looks anything familiar — this article is for you. Now, at Faire, we already had, for quite a while, a wrapper over this to make it nicer to use with Kotlin:

session.query<Book>
	.addEq("name", "Lord of the Rings")
	.list() // returns a List<Book>

That is a very thin wrapper we’ve been using and maintaining internally for years. However, it always bothered us that while we get back a fully typed List<Book>, consistent with the full-type-safety we know and expect in Kotlin, the actual arguments to the query were, let’s say, not ideal.

The column names are just String, and, even worse, the values are Any (that is from our Kotlin wrapper; the underlying Java API is just Object of course). If you make an incorrect assumption about your table, the best case-scenario is only catching that later on with unit tests (and that is the best scenario). After seeing again and again bugs and developer productivity hits, we had a dream of making this better.

But, as you can imagine, it was never a priority on top of other much-needed infrastructure improvements we’re always doing. Well, that all changed during one of our glorious Hack Weeks (an internal annual hackathon where everyone at Faire can participate and form teams to work on whatever projects their heart desires). And you can bet just what our heart desired.

So, during that pivotal Hack Week, we built a functional prototype of what would eventually replace our wrapper; a brand-new Hibernate Criteria API wrapper, with basically the same syntax we already knew and loved, minimally amended to provide one key benefit: full type-safety.

And over the course of the following 2 years (!!), we, slowly, whenever we had some spare time, migrated 61% of all queries across the entire codebase to the new infrastructure. As of now, we’re happy to say more than 11 of our production services are fully migrated. Given that, alongside the fact that all new queries are type-safe, we were able to reduce the number of magic-string induced incidents (and associated developer frustration only caught during tests) to zero.

As we rolled out this migration, we had to add support for different types of queries, refining the code-generation to power it, fixing bugs, listening to internal feedback, and thus homing in on what we now call, and are happy to introduce: Project Yawn.

Introducing: Project Yawn

This is what a Yawn query looks like:

session.query(BookTable) { books ->
	addEq(books.name, "Lord of the Rings")
}

That’s right! You get an object representing your Hibernate entity (BookTable), with all its fields. That means you get auto-complete, intellisense, and compile-time checks. But that’s not all—Yawn also knows the types of your columns, so it makes sure that the name column on the books table expects a String, and nothing else.

“But that is not going to cut it”, you might say, “I need complex queries!” Yawn has you covered — basically any query that can be written with Hibernate’s Criteria API can be written with Yawn, including complex and nested joins, projections, etc.

For example, here are the e-mails of all authors in the database whose favourite book is their own writing:

val emails = session.project(PersonTable) { people ->
	val favoriteBooks = join(people.favoriteBook)
	val favoriteBooksAuthors = join(favoriteBooks.author)
	addIn(people.name, authors)
	addEq(people.name, favoriteBooksAuthors.name)

	project(people.email)
}.list()

And we support much more: projection to data classes, sub-queries (detached and correlated), join references, and much more.

And that was all thanks to…

The magic of KSP

In order to power the creation of the meta-model representations of our tables based on our Hibernate entities, we use the power of Kotlin Symbol Processing, the official meta-programming framework in Kotlin. That means we hook up compilations steps to the compiler itself — no external tools, no scripts. It is pure Kotlin code that is automatically run when you add the Yawn dependency, and integrates well with IntelliJ or your preferred editor (references and go to definition all work out-of-the-box).

We have generators that scan through any entities Foo annotated with @YawnEntity on our Gradle module and generate a FooTable definition to be used for queries, maintaining the same visibility modifiers as the original class. It has references to columns and relationships, allowing for type-safe joins, and works with all Hibernate use-cases we had so far in our vast codebase (the hardest technical challenges were settling the exact shape and design of our APIs to support these edge cases such as embedded entities, composite keys, references with different foreign keys, etc).

After a period of tweaking the interfaces to be more ergonomic, fighting with the underlying Hibernate implementations, and wrangling some complex generics, the generators are now just plain Kotlin code, so they’re easily amendable by the entire team if there’s any feature missing.

We’ve tinkered with and refined it as we added to more usages and more complex use cases. But we wanted more — we wanted to share what we did with the community, in case other projects using Hibernate could benefit (and contribute!) to Yawn. So… we did.

OSS

We are thrilled to announce that we are officially fully open-sourcing Project Yawn under the MIT license! We believe in the power and community of open source, and while we use many tools and libraries, we want to contribute back with something we could share from our work.

You can check out the repository at github.com/faire/yawn for instructions on how to get started. We also welcome contributions and constructive feedback, and would love if you could give us a star!

And that’s not all — this is just one of a few pieces we’re happy to announce as part of a broader company-wide commitment to open-source and the developer community. We’ve started to build a dedicated public-facing OSS page at faire.tech/open-source where we aim to collect and catalogue projects we have (or have yet to) publish, as well as other contributions we’ve made over the years to existing and established libraries and tools we use every day.

If you’re interested in our other projects, I’d recommend checking out our faire-detekt-rules, a curated and opinionated collection of custom Detekt rules and configs that we use on our Kotlin modules. You can opt in many of the rules that help us catch bugs early on, standardize best practices, and just keep our code looking pristine.

If you’re looking to write more complex queries that Hibernate and Yawn can’t support, we highly recommend sqldelight (which, fun fact, also uses KSP under the hood), in which case you might want to check out the CRDB connector we open-sourced a while ago.

This is just the beginning of how we think Faire can contribute to the broader OSS community — stay tuned for new additions very soon as we work to extract other pieces of our codebase and infrastructure.

Many thanks to everyone at Faire and elsewhere that has helped us along the way, including, but not limited to, Adriel Martinez, Emily O’Leary, Jean Yang, Kevin Brightwell, Micah Beech, Oren Kislev, Quinn Budan, Stas Novosad, and Zhiping Cai.

How we tamed Hibernate ORM in Kotlin with Project Yawn was originally published in The Craft on Medium, where people are continuing the conversation by highlighting and responding to this story.

Going from zero to one in six months

At Faire, we’re building a marketplace that connects independent brands with retailers around the world. Two years ago, we saw an opportunity to help brands grow even faster by building an in-house Ads System — one that would give them effective, targeted ways to reach the right retailers at the right time. The result? Our Ads System has become one of the key drivers of new brand-retailer connections on the platform. In this post, we’ll share how we built Faire’s Ads System from the ground up and our key learnings along the way.

The challenge and our approach

Building the Ads System for Faire’s wholesale marketplace presented unique challenges shaped by how brands and retailers do business together: small businesses needing simplicity, brands seeking lasting retailer relationships, and extended purchase cycles. Here’s how we addressed each challenge:

• Serve small and medium businesses with simplicity: Many of our brands are small businesses without dedicated marketing teams or advertising expertise. Rather than requiring brands to manage complex campaigns, we built auto-targeting and auto-bidding systems that handle optimization automatically. Brands simply set a monthly budget, and our system takes care of the rest — identifying relevant retailers, adjusting bids based on conversion probability, and pacing spend throughout the month to maximize results.
• Optimize for long-term brand-retailer relationships: In wholesale, acquiring a new customer means establishing a relationship that can last years with high lifetime value. We built prediction models to identify the most relevant brand-retailer matches, optimizing for actual orders rather than just clicks, accounting for the extended timelines where orders can take days or weeks as retailers carefully evaluate products. To quantify whether ads actually drive incremental value in these long-term relationships, we implemented holdout groups that compare outcomes with and without ads over extended time horizons, capturing the full impact on retailer behavior that may take months to materialize. Our reporting provides an estimated one-year ROAS (return on ad spend), giving brands the long-term perspective needed to make informed budget allocation decisions.
• Ship an MVP in six months: Building advertising for wholesale marketplaces meant venturing into uncharted territory — we didn’t know what we didn’t know. The best way to learn was to get a working product in front of real users as quickly as possible. We set an aggressive six-month timeline to go from zero to a working pilot, allowing us to rapidly validate hypotheses with real brands and retailers. We delivered by ruthlessly prioritizing and leveraging existing infrastructure — piggybacking on our organic search system rather than building from scratch, which saved development time and benefited from battle-tested systems.

These challenges shaped our technical requirements and informed the architecture we built.

Faire’s Ads System

Our Ads System consists of three major components:

1. The brand-facing Ads Manager tools, which allow brands to create campaigns and view results.
2. The retailer-facing Ads Delivery flow, which determines which ads to show for a given retailer action (like a search query).
3. The foundational data systems that log events, attribute outcomes, and power the entire platform.

Ads Delivery

When a retailer performs a search on Faire, a request is sent to our Ads System to retrieve promoted results. The system processes this request through several stages to determine which ads to show and in what order:

• Retrieval and targeting: We retrieve an initial pool of eligible ad candidates based on the incoming request, applying ad-specific filters for campaign budget and targeting rules. We initially reused our existing search framework for this step — using a mix of text- and embedding-based methods — a pragmatic choice that let us ship faster while leveraging battle-tested infrastructure.
• Prediction and ranking: For each candidate ad, we use machine learning models to predict pCTR (predicted click-through rate) and pCTO (predicted click-to-order rate). We calibrate these probabilities using historical data to ensure fair billing. Ads are then ranked by combining their predicted click-through rate with their bid, prioritizing ads with the highest expected value. This means a highly relevant ad with a moderate bid can outrank a higher bid with lower relevance, keeping results useful for retailers.
• Auto-bidding and budget pacing: While brands pay per click, our system automatically optimizes for actual orders by using the predicted click-to-order rate to dynamically set appropriate click bids. The system adjusts bids based on each campaign’s performance — increasing them when conversions are efficient, reducing them when costs run high. Meanwhile, budget tracking aggregates spend for each campaign, pacing delivery throughout the month to respect budget constraints.
• Quality controls and display: We perform final checks to ensure ads meet minimum relevance thresholds before display, maintaining the high-quality browsing experience our retailers expect. We then log impressions and track any clicks or orders for analytics and model training.

Ads Manager

We built a self-serve Ads Manager interface where brands can create and manage campaigns with minimal complexity:

• Campaign setup and monitoring: Brands create campaigns by setting monthly budgets and basic targeting criteria. Performance dashboards display key metrics — impressions, clicks, orders, click-through rate, and spend. To help brands understand the long-term value of new relationships, we provide an estimated one-year ROAS that accounts for the extended value of wholesale customer acquisition.
• Billing and payments: We integrated with Faire’s existing billing infrastructure. Brands are billed monthly and only pay when retailers click on their ads. Our prediction calibration ensures fair billing — if our model overestimates conversion likelihood, advertisers could overpay. Accuracy and fairness in billing were top priorities.
• Forecasting and recommendations: We provide personalized monthly spending recommendations based on each brand’s past sales performance. These recommendations appear during campaign setup and when adjusting budgets. Active advertisers also receive prompts to increase budgets when they consistently approach their spending limit, helping brands understand when to scale their campaigns.

Ads Foundation

Building the real-time delivery flow and user-facing features was only part of the story. We also invested heavily in the data foundation supporting the Ads System:

• Unified event logging: We established rigorous logging for all ads events — impressions, clicks, and conversions — standardizing definitions across web, iOS, and Android. This company-wide alignment ensured consistent measurement and reliable data for model training.
• Click and order attribution: We built a click attribution service that connects retailer clicks to eventual orders across the extended timelines typical in wholesale. Accurate attribution was critical for fair billing and measuring campaign effectiveness.
• Experimentation framework: Holdout groups without ads let us compare outcomes and quantify incremental value. We also designed a budget-balanced experimentation framework to run A/B tests without effects leaking between control and treatment groups through shared budgets, ensuring we could iterate and improve the system with confidence.

Key learnings from our journey

Building Faire’s Ads System from scratch taught us lessons that shaped our entire approach to product development:

• Set ambitious goals, then execute pragmatically: We gave ourselves a bold six-month target to launch a functional pilot, creating urgency and focus. This forced pragmatic choices — reusing existing search infrastructure, simplified auction mechanics, static ad load — allowing us to hit the deadline without getting bogged down in perfection. Ambitious timelines drive creative problem-solving when you’re willing to start simple. There’s always time to add complexity later.
• Define success early and invest in foundations: We defined clear success metrics from the outset — N brands actively using ads, minimal impact on retailer experience (conversion rates couldn’t drop more than X%), and system scalability. But we also knew that without a solid data foundation, none of those metrics would matter. We standardized tracking definitions across platforms, built robust attribution systems, and implemented comprehensive monitoring. This dual investment in both clear targets and reliable measurement paid off, allowing us to catch issues early and giving us confidence in our results.
• Protect the experience with guardrails: Introducing ads carries risks to both user experience and brand satisfaction. We implemented safeguards at multiple levels: capping ads per page, de-duplicating repeat clicks, and setting minimum predicted conversion rate thresholds below which ads won’t display, regardless of bid amount. These guardrails ensured positive outcomes for all parties and maintained the marketplace quality our community expects.

Impact

Since launch, we’ve seen strong adoption and results. Brands using ads have seen, on average, a 25% increase in new customers compared to what they acquired organically, with some brands like Cheese Brothers seeing a 49% lift in customer acquisition. “Promoted Listings is about as easy as it can get,” says Eric Ludy from Cheese Brothers. “It’s literally just setting a budget. With Faire’s Promoted Listings, our customer base keeps growing, and they’re good customers. They keep coming back. In terms of customer acquisition costs versus lifetime revenue, it blows everything else out of the water.”

Looking ahead

Building Faire’s Ads System has been challenging but rewarding. We started with a clear mission: help brands connect with more retailers in a way that empowers small businesses. By focusing on simplicity, robust data foundations, and protecting the experience for both sides of our marketplace, we went from zero to a fully operational ads platform in six months — one that’s now driving significant incremental value for our community.

This is just the beginning, with even more significant opportunities to come; whether it’s expansion opportunities to new surfaces and geographies, iterating on our still-nascent models and optimization strategies, or rethinking system components such as auction design and pacing, the opportunity for impact has never been bigger. If you’re curious about how ads fit into our larger vision for Discovery at Faire, we recently hosted a tech talk covering our Discovery & Intelligence platform (see the blog post and video). If you enjoy tackling problems at the intersection of machine learning and marketplace dynamics, we’d love to hear from you.

This work would not have been possible without the dedication and contributions of Aditya Jayaprakash, Andrew Voorhees, Ani Borah, Arthur Che, Brian de Luna, Ben Thompson, Chris Farrell, Danyao Wang, Eliza Worcester, Etienne Lamoureux, Geoff Beresford, Ian Spear, Jai Mankoo, Jane Hur, Jean Yang, Jessica Schwarz, Kevin Aloisi, Kevin Benscheidt, Korosh Ahangar, Kyle McAndrews, Le Nguyen, Luan Nico, Marc Kelechava, Michael Yen, Qinyu Wang, Paul Duchesne, Paul Nunez, Pavel Konkin, Pedro Sales De Bruin, Perth Silvers, Rafiu Hossain, Shannon Broekhoven, Sophie Jorasch, Ziqi Zhang, and many talented individuals across Faire.

Building Faire’s Ads System from scratch was originally published in The Craft on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Faire, we’re always asking: How can we deliver value to our customers faster?

Our apps are at the heart of how small businesses discover products and build the unique character of their communities. Every release includes new features, bug fixes, and performance improvements that directly shape our customers’ experiences — and our ability to learn quickly from experiments and customer feedback.

Until recently, the path from “code merged” to “in customer hands” regularly took more than two weeks. That delay slowed down our feedback loops and our pace of iteration. The Engineering team set out to fix that without compromising our stability or customer trust.

By rethinking our mobile release process and leveraging Runway, we cut our release cycle from 14 days to 3 days — a 80% improvement — while maintaining our 99.99% crash-free rate.

The challenge: a two-week journey for every update

Before these changes, the release process for Faire’s mobile apps looked like:

• Friday midnight: Cut the release branch.
• Monday–Tuesday: QA and App Store submission.
• Wednesday–Thursday: App review and approval.
• Next week: Phased rollout (1% → 2% → 5% → 10% → 20% → 50% → 100%).
• A few days later: 80% of customers had the new version.

Altogether, it took about 14 days from branch cut to full adoption!

Each step prioritized caution over speed. These defaults had served us well for years, but our pace and scale had outgrown them. Customers might wait two weeks to see a new feature. By the time we learned from an experiment, we were already planning the next release — slowing our ability to act on what we’d learned.

The insight: risk wasn’t the bottleneck

When we looked at our metrics, a few patterns stood out:

• Crash-free rate had held steady above 99% for six months.
• No hotfixes in 18 months.
• Most risk already mitigated through feature flags and experiment rollouts.

In short: our process was over-optimized for safety. Our real bottleneck was delivery speed, not reliability. So we asked: What if we could move faster and keep the same level of confidence?

The solution: process + platform + tooling

Before diving into the changes, here are the tools that power our pipeline:

• Runway: Orchestrates every stage of our mobile release — from branch cut and smoke testing to submission, approval, and rollout — in a single automated flow.
• Embrace: Our mobile observability platform, integrated with Runway to monitor crash-free sessions, error rates, and rollout stability in real time.

Together, these tools give us the visibility and guardrails to move faster without sacrificing reliability.

Step 1: changing when we cut

We moved our release branch cut from Friday midnight to Thursday afternoon. That small shift removed two wasted weekend days and tightened our feedback loop.

This change also let us compress QA from two days to one — a major win for our remote QA team across time zones.

Many teams hesitate to launch over weekends, but Runway’s safeguards gave us confidence. If crash-free rates drop below a threshold, rollouts pause automatically, no weekend monitoring required.

Step 2: replacing phased rollouts with experiment controls

Next, we rethought how we roll out to customers. Rather than disabling phased rollouts entirely, we now use them adaptively. With real-time stability data from Embrace, we ramp to 100% after three days above 95% crash-free sessions.

For most new features, our experiment and feature-flag framework controls exposure:

• 5% → 10% → 50% → 100% experiment rollout sequence.
• Instant rollback for problematic features.
• P0 hotfix protocol if a client-side fix is required.

For app-wide or non-flagged changes, Runway and Embrace manage rollout pacing automatically. Since nearly all customers have automatic updates enabled, we now reach 80% adoption within two days of full rollout, which means faster insights with no added risk.

Step 3: automating the flow with Runway

Runway unifies our mobile release workflows and provides real-time visibility across teams. It lets us:

• Automate the entire release timeline: Branch cuts, smoke tests, screenshot approvals, and App Store submissions all happen in a single coordinated flow.
• Monitor release health in real time: Runway pauses or resumes rollouts automatically if metrics cross a threshold.
• Enable safe weekend automation: Runway halts rollouts if crash-free sessions dip, giving engineers time to diagnose before more customers are affected.

Before Runway, we relied on checklists, Slack messages, and manual handoffs to manage our releases. Now everything is accessible in a shared dashboard, which serves as the one source of truth for everyone from QA to on-call. Releases are now predictable and nearly frictionless, freeing up valuable engineering hours.

The impact on our customers and our team

Now, the time from branch cut to app store availability is down to about 3 days. Reaching full adoption still depends on update behaviour, but with adaptive rollout monitoring, most customers (>80%) are now on the latest version within about 5 days, down from 10–14.

That 3x speed-up means:

• Better customer experience: Fixes and improvements reach customers in days, not weeks.
• Faster experimentation: We can release and learn weekly instead of biweekly.
• More engaged engineers: Releases are predictable, visible, and stress-free.

What’s next: continuous acceleration

With faster version adoption, we’re now exploring:

• Reducing the 12-week support window through automated deprecations.
• Removing the need to foreground the app for Experiment or setting updates via instant configuration delivery.
• Keeping builds small to maximize over-the-air (OTA) update success and speed.
• Enabling continuous delivery, where every successful build could automatically become a release candidate.

Lessons learned

Looking to speed up your own mobile release cycle? Here are some of our biggest lessons from the process:

1. Measure before you optimize: Data showed we were stable enough to move faster.
2. Automate confidence, not caution: Tooling like Runway replaces human hesitation with visibility and guardrails.
3. Treat the release process like a product: We iterated, tested, and improved it — just like any customer-facing feature.
4. The wins are compounding. With the right culture, process, and tools, you can move fast and stay safe — and ultimately serve your customers better.

Special thanks to the Mobile Growth and Mobile Platform teams for their partnership, and our friends at Runway for making this possible.

Interested in building systems that help small businesses move faster? Check out our open roles at Faire.

Accelerating mobile releases at Faire with 80% faster deployment lead times was originally published in The Craft on Medium, where people are continuing the conversation by highlighting and responding to this story.

At our recent San Francisco Tech Talk, AI scientists, machine learning engineers, and infra engineers gathered to share how AI and machine learning are revolutionizing product discovery across our marketplace. From semantic search to graph neural networks, from large language models (LLMs) to next-generation infrastructure, the evening showcased how Faire is building intelligent systems that empower brands and retailers worldwide.

You can watch a video of the event or read the highlights below!

The evolution of discovery at Faire

More than 60% of Faire’s order volume is driven by search. As Jason Xu, Senior Manager of Search, explained, discovery at Faire has evolved dramatically:

• From keywords to semantic retrieval: We’re moving beyond literal word matches to embeddings that capture meaning.
• From text to multimodal understanding: We’re incorporating product images and visual similarity for richer results.
• From isolated queries to graph-based personalization: We’re modeling relationships between retailers, brands, and categories to surface better matches.

Looking ahead, Jason highlighted the promise of generative search, where retrieval and ranking merge into a single intelligent model that aligns more closely with user intent.

Tackling cold-start and personalization with LLMs

Hoshun Yang, Principal Data Scientist, explored how LLMs are unlocking new ways to address the retailer cold-start problem — when new users arrive without a history of engagement. By leveraging rich retailer content (like websites, POS data, and social presence), Faire can:

• Bootstrap recommendations using clustering and entity resolution
• Consolidate brands across POS and Faire catalogs
• Introduce an AI business coach, turning complex data into actionable insights for retailers

The goal is not just to recommend products, but to help retailers up-level their businesses as soon as they land on Faire.

Behind the homepage feed: unified retrieval and ranking

Personalization isn’t limited to search. Juno Zhu, Engineer on Inspire, and Kevin Aloisi, Staff Engineer on Discovery Infrastructure, shared how we’ve transformed the Faire homepage feed into a real-time, scrollable grid.

Previously, homepage content relied on static carousels generated offline — a system with latency and accuracy trade-offs. Today, Faire’s unified retrieval and ranking platform powers a dynamic feed that blends multiple retrieval types, integrates ranking layers, and allows product teams to A/B test experiences through a declarative domain-specific language (DSL).

This evolution has already driven meaningful lifts in engagement and orders, while laying the groundwork for more adaptive, LLM-powered personalization.

Graph neural networks for smarter recommendations

Finding the right product among 20M+ SKUs is a massive challenge. Data Scientist Li Tian introduced how graph neural networks (GNNs) help Faire model the deep relationships between retailers, products, and their interactions.

In our system, retailers and products are represented as nodes connected by weighted engagement edges (clicks, carts, and orders). Retailer nodes include store type and metadata, while product nodes capture descriptions, brands, and categories, etc. This transforms raw engagement logs into structured relational graphs, where each node learns not only from its own features but also from its neighbors.

We train these representations using a two-tower GNN architecture: one tower for retailers and one for products. Each tower starts with pre-trained text and ID embeddings, refined through a Graph Attention Network (GATConv) layer that aggregates signals from related nodes. The outputs are then passed through MLP layers to produce final embeddings in a shared space.

This design allows Faire to capture both direct and indirect affinities across our marketplace, powering more personalized and context-aware recommendations.

From ranking to revenue: Faire’s ads engine

Discovery drives commerce, and Faire’s ads platform connects retailer intent with brand visibility. As Brian de Luna, Staff Data Scientist & Tech Lead Manager for Ads, explained, promoted listings appear within Faire’s search results and run on a cost-per-click model. Brands bid to reach relevant retailers where they might not appear organically, optimizing toward a “target cost-per-action” (tCPA) that links ad spend directly to conversions.

Behind the scenes, Faire’s ad system blends search-style retrieval and ranking with auction design and pacing optimization. Models like “pCTO” (probability of click-to-order) predict conversion likelihood, while tCPA acts as a control lever to balance efficiency and volume. Budgets are paced through a feedback loop: bids rise or fall as spend and conversion rates shift, ensuring budget utilization at the best possible price for brands.

Under the hood, Faire’s advertising ecosystem spans three integrated layers that work together.

• Ads Manager: brand-facing tools to launch, monitor, and configure campaigns.
• Ads Foundation: shared ML and data infrastructure powering measurement and optimization.
• Ads Delivery: the real-time serving layer determining which ads appear to which retailers.

Only two years in, Faire’s ads program already drives significant material value for brands — and it’s expanding fast. Upcoming priorities, in addition to further innovation on all modeling components, include new placements like the homepage feed, international launches in Europe and Canada, and “off-site” ads that use Faire’s first-party conversion data to help brands optimize campaigns across external advertising platforms.

The hidden engine: scaling ML infrastructure

Behind every discovery model lies the infrastructure that powers it. Manoj Krishnan, Sr. Staff ML Platform Engineer, shared how Faire’s AI Platform team builds the foundation that keeps our machine learning systems fast, reliable, and scalable.

To handle 2.2 trillion rows of data annually, the team redesigned its pipelines to log only lightweight identifiers and timestamps, generating features offline instead of online. This shift cut serving costs dramatically while allowing new features to be added without production overhead.

To maintain feature consistency, Faire repurposed TensorFlow’s static DAG engine for versioning, encoding each feature as an immutable protobuf stored in S3 — creating a single, reliable interface between Python-based offline workflows and Kotlin-based online inference.

Finally, by migrating GPU workloads to Kubernetes with RunAI, the team gained containerization, elasticity, and isolation — eliminating instability from the earlier shared cluster.

Looking ahead, the platform team is investing in agentic infrastructure, a unified LLM gateway, and deeper GPU-level optimization to accelerate training and inference across Faire’s next generation of AI systems.

Fine-tuning LLMs at Faire

Large language models (LLMs) unlock new ways to understand product meaning, match intent, and streamline operations at Faire. Wayne Zhang, Principal Data Scientist, and Quentin Hsu, Senior Data Scientist on Search, shared how the team uses fine-tuned domain-specific models to deliver real business impact.

For many domain specific use cases, zero-shot or few-shot prompting of chat based LLM models is not enough to achieve usable performance. Fine-tuning is necessary to teach LLMs Faire specific context to be used in our applications.

At Faire, we built a shared fine-tuning infrastructure on top of our dedicated GPU cluster. We created a custom faire_llm package that abstracts different fine-tuning optimizations like LoRA and quantization to enable rapid iteration and reliable production serving.

We shared 2 production uses cases of these fine-tuned models at Faire:

• Search relevance: We fine-tuned a Llama 3 8b “teacher” model to understand our definition of query product relevance, classifying each pair into exact, substitute, complement, or irrelevant. To serve in real-time within Faire’s search stack, we distilled the relevance model into a lightweight two-tower “student” model. Online experiment results showed significant reduction in egregious irrelevance and resulted in an increase in new retailer orders by 10%.
• Taxonomy classification: We trained a multimodal model on text and images to assign new products to one of over 3,000 Faire-specific product taxonomies. We reached 95% accuracy, which outperforms human tagging and cuts down onboarding time + manual corrections dramatically.

Together, these systems bring more semantic understanding and precision to Faire’s discovery experience, helping retailers find the right products faster and brands reach the right customers with ease.

Fireside chat with Faire’s Discovery leadership

Yvonne Luo, Head of Discovery Engineering, hosted a fireside chat with CTO Thuan Pham and Head of Discovery ML Wenhao Liu, offering a behind-the-scenes look at how AI is reshaping how we work at Faire.

Thuan shared how Faire’s marketplace impact and exceptional people drew him back into leadership, while Wenhao described the company as a place where curiosity meets purpose. Both emphasized that discovery is the “heart of the marketplace,” with AI enabling more intelligent, personalized retail experiences. They discussed challenges like low data density and multi-objective optimization, and how these drive innovation in fine-tuned LLMs, hybrid models, and agentic systems. Closing on an optimistic note, Thuan urged teams to embrace the AI wave with adaptability and action — echoed by Wenhao’s reminder that experimentation and learning are the surest paths to progress.

Join us to build the future of wholesale!

From embeddings to GNNs, from LLM-powered personalization to resilient ML infrastructure, Faire is building the systems that help wholesale retailers and brands grow.

And we’re just getting started. Interested in joining us? Explore open roles at faire.com/careers.

Discovery intelligence at Faire: highlights from our San Francisco Tech Talk was originally published in The Craft on Medium, where people are continuing the conversation by highlighting and responding to this story.

Protecting customer data is one of our highest priorities. Today, we’re proud to share a milestone in that journey: Faire is now ISO 27001 certified.

What is ISO 27001

ISO 27001 is the globally recognized standard for building and governing an information security management system (ISMS). It promotes a holistic and risk-based approach to keeping information secure and considers people, policies, and technology. In short, ISO 27001 is about how a company designs, operates, and continuously improves the system that protects data. For customers, this means greater assurance that their data is protected by a globally recognized framework.

Our certification was issued by an independent, accredited auditor after a rigorous review of our security management system and supporting controls. The result gives customers a clear and comparable bar for security maturity across vendors.

Why this matters for our customers

• Greater assurance that Faire’s security controls are designed and governed according to an international standard for information security management.
• Our program is built on risk management across people, process, and technology, not only on tools.
• We are committed to transparency and third party validation, a practice followed by many leaders in our industry when they announce similar milestones.
• This certificate isn’t just about checking boxes, it helps ensure safer transactions, trust, and reliability for Faire customers.

How Faire achieved certification

Over the past year, we’ve built, strengthened, and audited the key building blocks of our ISMS. This included asset and access management, secure software development practices, vulnerability management, vendor risk management, incident response, and business continuity. These controls are documented, measured, and improved on an ongoing basis so that our security posture keeps getting stronger.

Our commitment going forward

We will continue to invest in our security program and to evolve our controls as standards and customer expectations change. ISO 27001 emphasizes continual improvement, and we take that obligation seriously. This continued investment means a safer, more reliable Faire experience for brands and retailers, and greater confidence that everyone’s data is protected at every step.

Faire is now ISO 27001 certified was originally published in The Craft on Medium, where people are continuing the conversation by highlighting and responding to this story.

On September 9, 2025, we opened our doors at Faire Waterloo for a two-part evening during Waterloo Tech Week: a fireside chat with two of our senior engineering leaders, followed by a series of lightning tech talks from the teams building AI into our marketplace.

You can watch a recording, and here are the highlights!

AI north star: solving real customer challenges

Faire’s mission is to empower brands and retailers to strengthen the unique character of local communities. That mission comes alive when we solve real, tractable problems our customers face. AI is one tool in our toolkit. Some key ways it can help are:

• Helping retailers find unique products: Buyers want to discover differentiated brands that fit their shop’s vibe, without needing to guess the right keywords.
• Providing personalized recommendations: Retailers expect curated assortments and insights tailored to their business.
• Delivering more value to all of our customers: Wholesale often depends on manual workflows and multiple tools — there’s an opportunity to simplify and create a smoother experience.

These needs shape our roadmap and where we apply AI — both externally for our customers, and internally to improve our systems and processes that ultimately serve our customers.

Supercharging developer productivity with AI tooling

If you’ve read our Toronto Tech Week recap, you know we believe AI augments engineers. In Waterloo, our speakers dug into what that looks like in practice:

Agentic development

Luke Bjerring shared how background coding agents take on well-scoped tasks (creating pull requests, writing tests, refactoring), so engineers can focus on harder problems. We walked through how we invoke GitHub Copilot programmatically, tailor instructions and setup, and wire in MCP servers to internal systems.

Project Cyberpunk

George Jacob presented our in‑house agentic development stack, aka Project Cyberpunk: pre‑warmed workspaces, a lightweight orchestrator that breaks work into reliable prompts, and a library of focused sub‑agents (e.g., settings cleanup, test authoring). Early usage patterns show steady adoption and meaningful offload on repetitive work.

Practical tips for mobile and more

Megan Bosiljevac presented real cases, from an Android UI color accessibility fix to scaffolding an 800‑line Server‑Driven UI screen in hours instead of days, and a reminder that prompting is a skill, experimentation compounds, and humans remain owners of the code.

Transforming discovery for retailers

There are several ways we’re applying AI to transform discovery for retailers, including:

Natural‑language search: Tom Ma explained that buyers should be able to ask for what they want on our platform, similar to how they would speak to a rep: “Find me dresses made in Paris, under $100, and not sold on Amazon.” Our system parses the phrase into structured filters under the hood and returns relevant products without the filter‑guessing game.

Image search: Inspiration often starts with a photo. Upload an image and see visually similar products on Faire, turning a vibe into a shoppable result, especially on mobile.

Together, these capabilities reduce the distance between intent and discovery for Retailers saving them time and helping them stock their stores.

Service architecture evolution to support AI agents

Luan Nico shared Project Burrito: a hybrid architecture that pairs Python‑powered AI agents with our Kotlin macroservice “wrapper” to plan multi‑step buying flows for account managers (and many other agentic AI flows to serve our brands and retailers in the future). Instead of a one‑off search, an agent composes a coherent, purchasable assortment that fits a retailer’s profile, then iterates.

Fireside chat with Marcelo Cortes and Yvonne Luo

Similar to our Toronto Tech Week event, we ended with a fireside chat. This time, Co‑Founder & Chief Architect Marcelo Cortes was joined by Head of Engineering, Discovery, Yvonne Luo. The conversation took the following shape:

• AI as a new abstraction layer: Like cloud and mobile before it, AI changes what it means to be a product or infra team: it’s about interfaces that reason, not just route requests.
• Humans‑in‑the‑loop by design: Guardrails, observability, and explicit failure modes matter, especially when agents touch customer‑facing systems.
• Audience Q&A: We took questions from the crowd about Faire’s security stance, growth strategy, and culture.

Thank you, Waterloo 💙

We loved hosting builders, students, and community partners at our Waterloo office. A huge thanks to everyone who helped make the evening happen, and to our guests for the thoughtful questions during Q&A. If you didn’t catch us this time, we hope to see you at a future event at our Waterloo, Toronto, or San Francisco office!

Want to build with us? Explore roles at faire.com/careers and follow along on The Craft.

Transforming wholesale with AI: the sequel (now with more agents) was originally published in The Craft on Medium, where people are continuing the conversation by highlighting and responding to this story.