A leading sportswear and equipment brand was building out a global mobile shopping app and needed a Backend for Frontend (BFF) layer to unify data from multiple services, deliver personalized product feeds, and keep checkout fast and reliable, all without exposing the app to the same instability risk as their web backend. Getting a mobile release wrong is expensive: app store approval cycles mean a bad update can sit broken for days or weeks before a fix reaches users.
Tuix embedded a team of up to six developers directly into the client's engineering organization over four years: four senior full-stack developers and two mid-to-senior developers, one of whom also worked as a software architect supporting key technical decisions. One developer worked in the same time zone as the client's core team, sitting in on the client's planning and architecture discussions directly and relaying decisions back to the rest of the embedded team, giving the client a single, consistent point of contact for day-to-day alignment. The remaining five developers worked from Colombia and Argentina; because the U.S. market was the client's priority. That Tuix flexibility gave the client effective coverage across regions and decisions without asking any one engineer to stretch across every hour of the day, while still getting the full bandwidth of a six-person team.
The engagement started with a two-person embedded team. From there, the relationship didn't end at launch: as the client's engineering organization found more adjacent needs worth solving, Tuix gradually scaled the embed up to six developers, growing headcount alongside the scope of work. While part of the team kept building and supporting the BFF itself, others took on an application to track shipments and goods via RFID, warehouse systems for creating and managing product records, and synchronization of materials and information coming in from suppliers. Rather than one project handed off at the end of a contract, it was a team that grew and stayed embedded for as long as the client kept finding new needs worth solving together.
While the mobile app itself was built separately by the client's own developers in Flutter, the Tuix team worked in close, ongoing collaboration with them: resolving integration challenges together, fine-tuning API responses to fit the frontend's actual needs, and keeping backend compatibility intact as the frontend continued to evolve. That close coordination across the two teams was as much a part of the engagement as the backend work itself.
Backend for Frontend (BFF) Core At the heart of the solution was a NestJS GraphQL BFF, acting as the single gateway for the mobile app. It aggregated data from multiple backend services, applied business logic, and returned only the required information reducing payload size and optimizing performance for mobile users.
Speed Through Caching A Redis caching layer accelerated frequent queries, cutting response times and reducing load on backend services.
Smart Search Experience Algolia powered instant, relevant search results, ensuring a smooth and responsive product discovery process.
Proactive Monitoring We integrated New Relic and Amplitude for deep performance and usage monitoring, enabling quick detection and resolution of potential issues before they impacted end users.
Close Collaboration with Frontend Teams While the mobile frontend was developed separately in Flutter, we partnered closely with the client's developers to resolve integration challenges, fine-tune API responses, and ensure backend compatibility with evolving frontend needs.
Backend
NestJS (TypeScript) GraphQL API (BFF layer) Redis High-speed caching layer Kubernetes Container orchestration for scalable deployments AWS Hosting, storage, and infrastructure services
Integrations
Algolia Instant, relevant search functionality Amplitude & New Relic Real-time monitoring and performance tracking Firebase Notifications and real-time updates E-Commerce Services Product, order, and user management built on the existing web application backend, enhanced through the BFF to optimize performance and tailor responses for the mobile experience.
NestJS's GraphQL API gave the mobile app tailored, flexible data delivery, letting it fetch exactly the fields it needed per view instead of overfetching, while the BFF pattern kept mobile-specific needs cleanly separated from backend complexity, making future updates easier. Redis caching cut response times and backend load for frequently accessed and near-static data, Algolia delivered sub-second, typo-tolerant search with faceted filtering, and New Relic paired with Amplitude gave full visibility into both system health and user behavior, so issues could be caught early and the experience kept improving. AWS and Kubernetes rounded out a highly available, self-healing infrastructure built to scale. Because the embedded team stayed on for four years rather than handing off after launch, these choices were made with that full lifespan in mind, favoring a stack the team itself would still be maintaining and extending years later.
Real-time performance tracking via New Relic; all monitoring and logging pipelines were designed with data obfuscation to ensure no sensitive customer information or personally identifiable data was ever exposed.; usage and traffic insights segmented by time zone, device, and region; incident alerts via Slack; incident playbooks and post-mortems; hourly automated end-to-end tests; CI/CD quality gates (unit, integration, E2E, SonarCloud); a GraphQL schema checker to catch breaking changes before they reached the app store's slower release cycle. Keeping this level of discipline in place for four straight years was only realistic because it was the same embedded team enforcing it the whole time, rather than practices that faded each time a vendor rotated off the project.
Safeguarding against frontend risks
Publishing updates to the iOS App Store and Google Play Store involves a long approval process, so a key reason for adopting a BFF layer, rather than exposing the same backend used by the retail website, was to stop mobile-specific dependencies on unstable or experimental website frontend code. Any frontend bug that slipped through could have caused real downtime or user frustration, made worse by how slow app store fixes are to ship. The BFF acted as a safety buffer, delivering only stable, mobile- optimized data to the app.Backward compatibility without friction
Unlike web apps, mobile users can stay on older app versions for weeks or months, so forcing an update every sprint would have created unnecessary friction. The BFF adapted services on the fly to stay backward-compatible with older versions, keeping the experience smooth without disruptive forced updates.
Optimized Mobile Data Delivery Backend tailored for mobile devices to minimize payloads and boost speed. High-Speed Search Algolia integration delivering instant product discovery. Performance-Driven Architecture Redis caching and Kubernetes orchestration for stability and scalability. Seamless E-Commerce Integration Connection to existing product, inventory, and order systems. Backend-Frontend Collaboration Ongoing support and bug resolution to ensure smooth integration with the Flutter app.
The hardest part of this engagement wasn't the code, it was staying tightly synced with an external Flutter team we didn't manage, on a short initial delivery window, while building something meant to last well beyond launch. That meant constant communication and fast iteration to keep both sides moving together, strict prioritization to hit the deadline without cutting corners on the foundation, and architecture decisions made with four years of future features in mind rather than just the first release. Adopting New Relic early paid off the same way the rest of the embed did: catching problems before they reached users instead of after.
