By: Kate Sarmiento
A crash that would’ve been a Tuesday afternoon fix in beta becomes a headline once a product hits real scale. A missing translation string that nobody noticed on a 500-person waitlist becomes a support queue with thousands of angry tickets in three languages. This is the strange, unglamorous truth about growth. It doesn’t just multiply your users; it multiplies every single mistake right alongside them. Redwerk, a software development company that’s been in the trenches building and stress-testing products since 2005, has watched this play out from a front-row seat more than once, and one story in particular says more about quality assurance at scale than any textbook could.
That story starts with an app called Unfold. It’s a design tool that lets creators build Instagram stories and social content without needing a design degree. QAwerk, Redwerk’s sister QA agency, got involved when Unfold was still in beta, still small, still figuring out who it was going to be. Squarespace acquired the platform in October 2019, and the growth kept compounding long after the deal closed, until Unfold was serving roughly a billion users a month. And the man who watched that whole arc unfold (pun very much intended) is Konstantin Klyagin, founder of both Redwerk and QAwerk, who’s been building software and hunting down the flaws in it since 2005. What he learned along the way isn’t really about Unfold specifically, but what happens to testing philosophy once a product stops being small and starts being everywhere.
Why One Bug at Scale Is a Thousand Bugs in Disguise
Small products get a kind of mercy that big ones don’t. If your app has 800 users and one of them hits a rare edge case, you patch it, apologize maybe, move on. Nobody’s writing a think piece about it. But once you’re operating at the scale Unfold eventually reached, that same rare edge case isn’t rare anymore. It’s happening to thousands of people simultaneously, at the exact same moment, probably while several of them are recording video for it.
Konstantin has talked about how the testing mindset had to evolve as Unfold grew, moving from testing more to testing differently. Early on, QA at a startup is often reactive: find bugs, file them, verify the fix, repeat. At scale, that reactive posture becomes a liability because the feedback loop is too slow. A regression that ships to a billion-user base doesn’t wait around for someone to notice it in a bug tracker. It’s already trending on social media by the time anyone opens a ticket.
The financial stakes back this up in ways that are honestly a little unsettling. Software failures cost the U.S. economy an estimated $2.41 trillion a year, and a huge chunk of that comes down to defects that could’ve been caught earlier in the process (Source: CISQ, 2022). Companies generally understand that testing matters. What catches them off guard is timing, since the cost of skipping it doesn’t show up until later, once it’s harder to trace and far more expensive to fix.
The Localization Trap Nobody Budgets For
Localization behaves like a revenue problem dressed up as a translation issue, which is catching many growing brands off guard. A billion users don’t all speak English, and they definitely don’t all use currency formats, date structures, or right-to-left text the same way. Get it wrong and paying customers start drifting toward a competitor whose app doesn’t feel like it was built somewhere else and shipped to them as an afterthought.
QAwerk’s work on Unfold had to account for this as the user base diversified geographically, and the testing strategy had to expand well past “does the button work” into “does the button make sense in every market we’re now live in.” This is where a lot of QA processes quietly fall apart. Teams build thorough functional test suites and completely underinvest in localization QA, treating it like a checkbox instead of a genuine product risk. Mobile users, in particular, don’t forgive this kind of friction. Nearly a quarter of users abandon an app after using it just once, and a poorly localized interface reads as exactly that kind of dead-on-arrival experience, even when the underlying functionality is fine (Source: Localytics, 2016).
There’s also a compliance layer that gets ignored until it’s a legal problem. Accessibility isn’t a nice-to-have feature you bolt on for goodwill points. In the U.S. alone, plaintiffs filed over 4,600 ADA-related digital accessibility lawsuits in a single year, and plenty of those cases target apps and platforms that assumed accessibility was someone else’s department (Source: UsableNet, 2023). At a billion users, statistically, a meaningful chunk of your audience relies on screen readers, voice navigation, or high-contrast modes to use your product at all. Once you’ve reached that kind of scale, accessibility testing works like a legal insurance policy that also happens to improve the product for everyone, and it belongs in the standing scope of work handled by a dedicated software testing agency.
What Growing Products Need From a Software Development Company at This Level
Ask Konstantin what changed in QAwerk’s relationship with Unfold as it grew, and the answer isn’t “we hired more testers,” though that happened too. The bigger shift was in how testing got woven into the product’s rhythm. At a small scale, QA can afford to be a phase: build, then test, then ship. At the billion-user scale, QA has to be continuous, embedded, almost invisible until something’s wrong.
This tracks with a broader pattern the industry has documented for years. Fixing a bug found during testing can cost roughly 15 times more than catching it during the design phase, and that multiplier only grows as the codebase and user base expand (Source: Black Duck, 2017). The gap is stark, the difference between a small internal fix and a full incident response involving customer support, PR, and sometimes legal. What growing products actually need, then, is a partner who understands the product’s trajectory and tests for where it’s going as much as where it currently sits. Redwerk’s own approach to this reflects that same philosophy across its broader development work. The company’s expertise spans frontend, backend, QA, AI, and DevOps, which means testing strategy doesn’t get siloed off from the actual architecture decisions being made. A QA team that only shows up at the end of a sprint, disconnected from what’s being built and why, will always be playing catch-up. One that’s embedded from the start, the way QAwerk was with Unfold from its beta days onward, is positioned to shape the product’s resilience in real time and to surface problems earlier than a bolt-on review would.
There’s a quieter lesson buried in the Unfold-to-Squarespace arc too, and it’s one that founders preparing for acquisition should sit with for a second. What acquirers really buy is confidence, specifically that the codebase underneath those user numbers won’t collapse under continued growth or fall apart during due diligence. A product with a documented, disciplined testing history is a fundamentally different acquisition target than one that scaled by luck and duct tape. Testing discipline, in other words, factors directly into how sellable a product actually is.
Testing Isn’t the Finish Line, It’s the Infrastructure
The takeaway from watching a product grow from beta to a billion users under the same QA lens is messier and more practical than any tidy inspirational quote about quality. Testing strategy has to grow up alongside the product, shifting from reactive bug-hunting to something closer to continuous risk management, covering everything from localization to accessibility to the kind of regressions that used to be minor annoyances and are now existential threats. Companies chasing real scale don’t need a QA vendor who shows up occasionally to run a checklist. They need a partner who’s already thinking about problems the product hasn’t hit yet.
The pattern running through the whole Unfold arc, from a scrappy Android beta through the Squarespace acquisition and the years of growth that followed, is that testing functioned as infrastructure rather than as a final gate. Redwerk and QAwerk have documented that work in public case studies. For teams aiming at real scale, the more useful question is not whether QA happens but when it enters the process. What your product will need from testing at the stage it is headed toward rarely matches what it needs today.
