How Form Factory Gets Stakeholders to the Launch Line with Qase

Inside Mateus and Gelo's approach to QA as a coordination problem, not just a testing one

Form Factory is a Shopify Hydrogen agency. They build headless storefronts for enterprise retail brands like Spanx, Chubbies, and Turtle Beach. These aren't standard Shopify theme builds: they're fully custom React applications that give brands complete control over their frontend experience, at the cost of owning every pixel, every interaction, every edge case.

Mateus is a Product Engineer at Form Factory. His work sits between the client and the dev team; translating what the client wants into something the team can build, running discovery, writing specs, coordinating QA, and joining weekly client syncs.

"The bottleneck on these projects has never been building; we have strong engineers," says Mateus. "The bottleneck is definition and clarity: the translation from 'client says this' to 'team builds that.' That's where most projects fail, and that's where my work lives."

On enterprise e-commerce builds, the pressure is structural. Launch dates don't move. Marketing campaigns are scheduled, retail partnerships are tied to the date. When you're launching a major brand's storefront, the room asking "are we good to ship?" has a lot of people in it, from a lot of different organizations.

Getting all of them to the same answer is what Form Factory uses Qase to do.

In a headless build, you own everything

With a standard Shopify theme, you're testing within known constraints. Shopify handles the checkout, the cart, the account pages. The surface area is manageable.

In a headless build, there's no Shopify fallback. If Form Factory doesn't build it and test it, it doesn't exist. That means every page, every state (loading, error, empty, logged in, logged out, mobile, desktop) and every locale has to be validated. On top of the raw surface area, there's complexity from integrations: an enterprise headless site connects to Shopify, a CMS, a product data platform, a search tool, plus loyalty, reviews, and analytics. Each has its own quirks and edge cases.

On one build — a full Shopify Hydrogen migration for a major apparel brand — that complexity added up to more than 600 test cases. A single feature illustrates why: a product can be on sale because of a site-wide promotion, a category markdown, or a product-specific discount, and each type displays differently in the buy box. Then add localization: the client had US and Canada stores with different currencies, different size charts, and region-appropriate cross-sells. A product on sale, in the Canadian locale, viewed on mobile is a specific state that needs to work. Multiply that across every section of the site, and 600+ test cases starts to make sense.

The real problem isn't technical, it's organizational

The surface area is the technical challenge. The organizational challenge is harder.

Enterprise clients don't come alone. That build involved Form Factory, the client's internal team, a large group of developers from an external staffing agency, a third-party QA group the client brought in, integration vendors, and stakeholders and leadership on multiple sides.

"On enterprise builds, you're coordinating across multiple organizations," says Mateus. "You're not coordinating across two; you're coordinating across many."

Information fragments fast. Requirements live in Confluence. Discussions happen in Slack. Decisions get made verbally in meetings that may or may not have been documented. Test cases end up in spreadsheets... or in someone's head. The result: you're in a meeting asking "didn't we decide X?" and nobody can point to where that decision lives.

Then there's what Mateus calls the bystander effect in development. "Everyone sees a bug and thinks 'somebody must know about that,'" he says. "Very often, nobody does." Small issues accumulate (a wrong favicon, placeholder text, an incorrect product image) and suddenly the client feels like the site is further from done than it actually is, even though the engineering is solid. That perception gap erodes trust faster than actual bugs.

New stakeholders compound the problem. On this project, Mateus joined after the initial kickoff. New project managers came on board mid-project on both Form Factory's side and the client's. Every new person costs the team time (meetings run longer, decisions that were obvious to the original team have to be re-justified) unless there's a single source of truth by which they can orient themselves.

Before Qase, the answer was always subjective

On some projects, test cases were tracked in Notion tables or Confluence pages. The problem wasn't the tool; it was that those formats are static. A table with 200 test cases doesn't tell you which ones have been executed, which are passing, which are blocked. You'd end up in a meeting asking "did anyone test the Canadian checkout flow?" and getting silence, because the answer was buried somewhere nobody had recently checked.

When the client's QA team found a bug, it went into Slack or Teams. And when leadership asked the question that always comes before launch — "are we good to ship?" — the only honest answer was subjective. "We feel good." "We're pretty confident." That doesn't hold up in a room with senior stakeholders accountable for a major brand's e-commerce revenue.

A single source of truth for the whole room

On that engagement, Form Factory introduced Qase as the backbone of their QA strategy. The project was a full Hydrogen migration. Massive scope, multiple organizations, a launch date that couldn't move. They needed a way to define the full scope of what the site should do and then systematically verify it was doing those things.

They built close to 600 requirements mapped to test cases, organized into suites by site area: dynamic variant handling, buy box states, fit and length, cart flow, checkout, localization. Then they created test plans for specific milestones: a Critical Paths plan covering 151 test cases for the core purchase flow, a Smoke Test plan with 32 cases, and separate plans for the US and Canadian stores.

The workspace extended across every organization with a stake in the outcome; not just active testers, but developers tracking failures, PMs monitoring progress, and client stakeholders checking readiness.

The roles divided clearly. Form Factory created the test cases, organized them into suites and plans, and defined what "pass" looks like. The client's product team validated the test cases against the requirements; are we testing the right thing? The client's QA team executed: running through steps, recording results, filing defects. Their PMs and leadership consumed the reports.

"When a test case fails and generates a defect, all teams see it simultaneously," says Mateus. "There's no telephone game where a bug gets reported in one channel, lost in a thread, and rediscovered two weeks later."

From "we think we're ready" to "here's the proof"

Approaching production launch, the question came from every direction: "Are we good?"

With Qase, the answer wasn't a feeling anymore. The Critical Paths test plan came back at 100% pass rate on US Production. "That wasn't a feeling, it was evidence," says Mateus. Canadian Production showed specific failures; Form Factory could point to exactly what was failing, why, and what the fix timeline looked like.

The shared dashboard unified the room in a way that pre-Qase status updates never could. A developer knew which failures were their responsibility. A PM knew which to escalate. A new VP who'd joined a month earlier could see the trajectory without needing three meetings of context.

Without that shared visibility, the fracture was predictable: developers think they're close because their PRs are merged; the QA team thinks they're behind because the defect count is climbing; the client thinks nothing is happening because the staging site still has placeholder content. That disconnect is where trust breaks down.

"That shift, from 'we think we're ready' to 'here's the proof,' changed the launch conversation entirely," says Mateus. "It gave leadership on all sides the confidence to commit to the date, and it gave the teams a clear punch list of what still needed attention."

The pattern holds beyond the launch

After that launch, Form Factory rolled Qase out across their other client accounts. The tool proved as useful for ongoing work as it had been for a one-time launch push.

Chubbies is a live storefront with a continuous release cadence; Form Factory runs it as the product team. Every production release gets validated against a full smoke suite in Qase, plus a dedicated test plan for a recent Account Hub redesign tied to a loyalty platform migration. The client's product lead runs UAT directly in Qase, executing test cases, filing defects, leaving comments on specific cases.

When integration partners need to QA their piece before going live, Form Factory adds them to the workspace and scopes a test run to their integration. On the recent loyalty migration, the Rivo team's QA lead was onboarded, executed her plan, and flagged bugs directly inside the tool, not through a Slack thread that might have gotten lost.

"On that build, the value was 'prove the site is ready to launch,'" says Gelo. "On Chubbies, it's 'prove this week's release didn't break anything, and the feature we just built matches what the client approved.' Same shared-workspace pattern, different cadence."

The strongest endorsement was that the client purchased their own Qase account after the engagement — they had been using a different test management tool before, and after working inside Qase throughout the build, they adopted it permanently. "The system outlived our engagement," says Gelo.

What comes next

Form Factory is already building toward tighter integration between Qase and the rest of their toolchain.

On that build, they connected Custom GPTs to the Qase API and their project documents (meeting transcripts, requirements, design files). A team member could paste a requirement, discuss it with the AI, and have it create test cases directly in Qase through the API. That's how they reached 600+ test cases efficiently: AI drafting, humans reviewing.

The next step is connecting automated tests so that regression suites run automatically and results feed into the same dashboard. Manual QA would stay focused on the things that are hard to automate, like visual review, real-user flows. The repetitive regression work would run on its own.

Longer term, they're building shared test suites that can be duplicated and customized across client workspaces. The core purchase flow test cases are about 80% the same across every Shopify site Form Factory builds. Standardizing means regression testing for common features stops being rebuilt from scratch every engagement.

The principle that drives it all

There's a principle Mateus returns to when explaining why Form Factory invests as heavily in QA as they do.

"You can ship with known flaws; every launch has them," he says. "But unknown flaws destroy trust. The moment a client finds something your team didn't know about, the confidence gap is very hard to recover from."

It's not about perfection. It's about knowing exactly where you stand, and being able to prove it to the developer, to the PM, to the new VP, to the client's leadership, and to the third-party QA group executing in the same workspace. That's what a structured QA system makes possible.