Background
Some stories begin with a blank canvas. Others begin in the middle of momentum.
This one began at speed.
A fast growing global company, recognised on national high growth lists and expanding rapidly across international markets, found itself at a turning point. Demand was increasing. The community was growing. Product complexity was multiplying. What had once worked was no longer enough.
At the same time, they lost their internal CTO.
With that departure went not just leadership, but architectural continuity. Decisions stalled. Development velocity slowed. Confidence in scalability weakened. Marketing ideas were queued behind technical bottlenecks. Every new landing page required deployment. Every change carried risk. Every integration felt fragile.
The business was global, but the systems were not ready to be.
Their website, databases and supporting platforms needed to evolve from something functional into something foundational. It had to scale. It had to integrate cleanly with multiple systems through APIs. It had to support automatic content translation via external localisation software. It had to give the marketing team control, so they could build and launch pages instantly without waiting for developers or deployments.
Most importantly, it had to grow with the company instead of slowing it down.
They came to us through someone who had worked with us before. Someone who knew that we do not operate as ticket takers. We operate as problem solvers. As web special forces. As people who integrate deeply with teams and take responsibility beyond the brief.
Because this was not a simple website rebuild.
It was about restoring momentum, rebuilding technical confidence and creating an ecosystem that could support global scale without losing creative agility.
Due to strict NDA obligations, we cannot name the client. What we can share is the journey of inventing the future together.
Preparations
Before writing a single line of code, we listened.
The project began with workshops, discovery sessions and a full technical and marketing audit. We were given access to repositories, analytics, infrastructure and internal tools. We reviewed GitHub history, deployment patterns, performance data, content workflows and API behaviour. Nothing was assumed. Everything was inspected.
From day one, we operated less like an external agency and more like an embedded team. We spent time in their office. We met marketing, product, operations and leadership. We asked uncomfortable questions. We mapped internal processes. We traced how ideas moved from concept to live release and where they slowed down. Understanding the human system was as important as understanding the technical one.
The project was split into two major pillars.
The first was the public facing website. The second was the product database platform, along with an internal product management database and CMS. They were separate systems, built on different technologies, but to the outside world, they had to feel like one seamless experience. The website needed to appear tightly connected to the product database in real time, even though under the surface, they lived in different stacks.
That meant going deep into product relationships. Variants. Hierarchies. Metadata. Dependencies. Naming conventions. Edge cases. We needed to understand not just how products were stored, but how they behaved, how they evolved and how they were used across regions and languages.
At the same time, there was pressure.
Design was critical to this company’s identity. Quality was non negotiable. Approvals were careful. Iterations were deliberate. The brand prided itself on visual excellence, and rightly so. But perfection takes time.
Development deadlines did not move.
So we faced an early strategic decision. Do we wait for final designs before building, or do we begin development in parallel, knowing that changes may come and scope may shift?
To protect timelines, we started building earlier than comfort would normally allow. Architecture began while certain design elements were still evolving. It kept momentum alive. It also introduced risk.
That decision would come back to test us later.
But at this stage, the goal was clear. Build foundations strong enough to support global scale, while preserving creative excellence and giving marketing real autonomy.
Preparation was not about documentation. It was about alignment.
Team, Roles and Design
At peak, more than ten people were actively working on the project.
We structured the team deliberately. This was not a single stream of work. It was multiple parallel tracks that needed to move fast without drifting apart. Architecture, product database, frontend catalogue, website, CMS, infrastructure. Each had its own rhythm, but all had to land together.
All design was done in house, led by our Creative Director, Dan. Every screen, every interaction, every component was crafted in Figma. There were many iterations. Discussions were constant. Adjustments were frequent. This was not a one round approval process. It was collaborative, detailed and, at times, intense.
On the client side, they appointed a full time coordinator who became central to the success of the project. As much work as we were doing technically and creatively, they were doing just as much internally. Aligning stakeholders. Managing expectations. Handling approvals. Protecting timelines. Under the kind of pressure that comes with a fast growing global company. It is important to say this clearly. Projects like this do not succeed without someone holding it together internally. They did that.
Technically, the teams were split for efficiency.
Our Python developers focused on building the product database platform. This was the core system that defined product structure, relationships and data integrity. Frontend developers built the headless product catalogue in React, responsible for performance, flexibility and the seamless user experience that connected back to the database via API. In parallel, our WordPress team built the public website and CMS layer, focused on giving marketing complete control over content creation without deployments.
All of this had to integrate cleanly.
Design was delivered in phases. Once certain key templates were approved, development began while other sections were still evolving. On paper, this maintained momentum. In reality, it introduced tension.
As new ideas emerged in later design phases, they often influenced earlier pages. A product page concept would inspire a better homepage layout. A new content interaction would require structural adjustments elsewhere. What had been built sometimes needed to be reworked. Scope shifted. Decisions evolved. Under a short timeline, this created pressure on both sides.
The scope change became one of the hardest battles of the project.
And yet, integration remained non negotiable.
For example, marketing needed to insert product driven content blocks directly inside WordPress pages. That meant no copy paste, no manual duplication. Editors would simply reference a product, and the block would dynamically pull live data from the product database via API. Beautiful presentation, powered by structured data, controlled by non technical users.
To achieve that, backend, frontend and CMS teams had to coordinate constantly. Separate systems. Different technologies. One experience.
This was not three projects running in parallel. It was one ecosystem being built in pieces, under pressure, with design excellence and marketing autonomy as non negotiable outcomes.
Development, Architecture and Integration
By the time development was fully underway, this had evolved into a distributed ecosystem rather than a single platform build.
Three core layers had to operate independently while feeling completely unified to the end user.
The first was a custom product management system built in Python, using a heavily tailored admin interface. It had no public frontend. Its sole purpose was to manage structured product data and expose it cleanly via API.
The second was a headless product catalogue frontend built in React. This layer consumed the API and rendered a high performance, dynamic user experience.
The third was the public marketing website, built on WordPress, extended with custom React blocks and styled using Tailwind. This allowed marketing to build flexible, design driven pages while embedding live product data dynamically.
Underneath, the infrastructure was engineered for scale.
Core Technology Stack
| Layer | Technology | Purpose |
|---|---|---|
| Product Management System | Python, PostgreSQL | Structured product data management, API delivery |
| Headless Frontend | React | Public facing product catalogue |
| Marketing Website | WordPress, React blocks, Tailwind, MySQL | Content control and dynamic product integration |
| Caching Layer | Redis | Performance optimisation and reduced DB load |
| Infrastructure | AWS ECS Fargate, Load Balancers | Containerised scalability and traffic distribution |
| CDN | Global CDN distribution | Performance and global content delivery |
| Infrastructure as Code | Terraform | Reproducible and controlled deployments |
Everything ran in containers. Everything was scalable. Everything was version controlled.
And then real world traffic arrived.
During PR cycles and product launches, concurrent traffic surged sharply. At peak moments, over 2,000 users were active simultaneously. For a fast growing global brand, that level of engagement was a strong signal of market traction. It also stress tested scaling behaviour in ways that theoretical projections never fully capture.
ECS was configured to auto scale horizontally. In practice, rapid bursts revealed that reactive scaling needed reinforcement. Containers require time to spin up. In those short windows, pressure accumulated. We adjusted the strategy by increasing baseline capacity to absorb launch spikes, while maintaining auto scaling for sustained growth.
The architecture held. It simply needed tuning to match success that was accelerating faster than expected.
Translation introduced a different kind of challenge.
The full localisation workflow integrated with external translation software. Content had to move out of the CMS, through translation systems, and back again without breaking structure or relational integrity. Some API flows behaved perfectly. Others failed inconsistently.
Rather than treating it as a black box integration issue, we went deeper. We studied how translators actually used the system. We examined payload formats, workflow expectations and content handling. Even though we are not translators, we learned their process in order to stabilise the integration.
Because solving the technical layer alone was not enough. We needed to understand the operational layer around it.
Throughout this phase, development, staging and production environments ran in parallel. Infrastructure was managed through Terraform. APIs were tested independently and under integrated load. As real data entered staging, database structures were refined and optimised.
Multiple stacks. Multiple databases. Multiple teams.
One connected platform.
And pressure was building.
Stress, Scope Shifts and Partial Releases
Large projects evolve. That is not a flaw. It is reality.
As design matured and deeper understanding emerged, new ideas surfaced. Not cosmetic tweaks, but meaningful improvements that elevated the final product.
Two of those changes were substantial.
The first was a fully custom product preview experience with advanced search logic and layered animations. It was ambitious and visually striking. It required additional backend logic, frontend interaction work and performance considerations that had not existed in the original scope.
The second was a complex distributor search system. This was not a simple list with filters. It involved geolocation, interactive maps, dynamic search behaviour and detailed distributor profiles rendered contextually. It required careful data structuring and frontend performance optimisation.
Neither change was unnecessary. Both made the platform stronger.
But both shifted timelines.
Deadlines moved twice as a result of these large scope additions. Stress grew on both sides. Not because of conflict, but because expectations were high and the ambition level kept rising.
To ground ourselves in the real world context of what we were building, we attended one of the client’s major events. We wanted to see how staff operated. How customers interacted. How the product was experienced physically and digitally. Ralf and Tarei travelled to Singapore to attend. They observed. They asked questions. They used the product themselves.
That immersion changed the conversation. It aligned everyone around what actually mattered.
At the same time, the largest global industry conference was approaching. Marketing needed assets ready.
Two critical pages had to go live before the full system launch. An enterprise page and a major product landing page.
The enterprise page was delivered in under two weeks. Focused. Clear. Purpose driven.
The landing page was built in less than a week. It was extracted from work already in progress and deployed on a subdomain so it would not interfere with ongoing systems. It acted as a teaser to the community. A signal of what was coming, without destabilising the core build.
All of this happened while the main deadline remained in sight.
Pressure intensified. Long hours became normal. Weekends blurred into weekdays. Coordination complexity increased as design adjustments, infrastructure tuning and feature development continued in parallel.
One of the most valuable lessons came not from a technical issue, but from leadership maturity.
In hindsight, there were moments where saying no earlier would have protected timelines better. That reflection was shared openly on both sides. Their internal coordinator said the same. Scope expansion is exciting. Discipline is harder. We learned that together.
What helped was trust.
In Singapore, before flying back to New Zealand together, there was one evening when conversations were not about tickets or timelines. It was about alignment. About ambition. About partnership.
Then everyone got on the same plane and returned to full speed.
The platform was not built in calm conditions. It was built under rising expectation, public visibility and real commercial deadlines.
And it kept moving forward.
Deployment and Go Live
The final stretch began with one more decision.
We moved the launch date by a week. The last shift.
It was not dramatic. It was organisational. That extra week gave us space to resolve a wave of late surfaced issues and refine details that would have otherwise shipped imperfectly.
In the final days before the original deadline, reporting discipline on the client side understandably broke down under pressure. Instead of structured bug reporting throughout the testing phase, over one hundred issues were logged in a single day. At the same time, translation delivery was running behind schedule.
It was clear that pushing forward would create unnecessary instability. So we paused for one more week.
Then everyone accelerated.
Every team member jumped into refinement mode. Bugs were triaged and fixed rapidly. Edges were polished. Translations were validated. Content was cleaned.
Inside FutureLab, we even ran an internal content migration competition. Every team member, including developers, helped migrate product content into the new structured format. It became a race. Who could migrate faster. Who could catch inconsistencies. Who could improve structure. (Congratulations to Valentina who won!)
It was not just about speed. It was about empathy. We wanted every person on our team to experience the system the way editors would. To feel the friction. To understand the workflow. To learn.
Then the switch happened.
DNS was updated. Traffic redirected. The new platform went live.
As expected, the first moments were intense.
The website felt slow. The database was immediately under load. Caches were cold. Large numbers of users arrived at once, eager to explore the new experience. Infrastructure absorbed the pressure, but initial response times reflected real traffic behaviour rather than test simulations.
There was stress in those minutes.
But we were prepared.
Within a short time, systems were tuned. Caches warmed. Baseline capacity adjusted. Response times stabilised. The platform found its rhythm under live traffic.
And then something shifted.
Feedback started appearing publicly. On Reddit. On X. Users praised the navigation. The visual experience. The improved structure. The feel of the platform.
That is when tension turns into relief.
Launch day is never calm. It is controlled chaos followed by quiet validation.
And this time, the validation was immediate.
Success Metrics and What Changed
The real measure of a platform is not launch day. It is what happens after.
In the first month following release, user growth increased by 12 percent. Four months later, growth reached 14 percent. In that short window, the ecosystem was serving close to 400,000 active users.
Traffic stabilised at scale. The combined product catalogue and marketing website now handle close to two million page views per month. Launch spikes no longer create uncertainty. Infrastructure absorbs them as part of normal operation.
But numbers only tell part of the story.
Marketing gained true autonomy. They stopped asking developers to create pages. They stopped waiting for deployments. They build, adjust and publish independently. The CMS became a tool, not a bottleneck.
Translation became invisible. No more conversations about exporting and deploying PO files. No more last minute scrambling to sync languages. The integration simply works, which is exactly how it should feel.
Internally, confidence returned.
The company moved from reacting to technical limitations to planning growth strategically. They began hiring internal IT to expand their capabilities further. Not because the platform was unstable, but because it was finally strong enough to build on.
We transitioned into an ongoing extension of their team. Supporting, advising, training and strengthening their internal capability. Partnership did not end at launch. It matured.
The most significant change was not technical.
Before, systems constrained ambition. After, systems enabled it.
Teams operate differently now. Marketing experiments faster. Product data flows cleanly. Launches feel controlled rather than risky. Internal conversations focus on growth rather than limitations.
When we titled this case study Inventing the Future Under Pressure, it was not just about surviving deadlines.
It was about building foundations strong enough that pressure becomes opportunity.
Closing Thoughts
Some projects test architecture.
Some test patience.
Some test partnership.
This one tested all three.
It began with uncertainty. A leadership gap. Systems that could not keep up with ambition. Marketing constrained by deployment cycles. Growth happening faster than infrastructure could support.
It moved through workshops, evolving design, parallel development tracks, scope shifts, late night pushes and real world stress at launch.
It ended with scale. Confidence. Autonomy. Momentum.
But the real outcome was partnership.
We do not pretend to get everything perfect on the first attempt. Large systems rarely allow that. Ideas evolve. Assumptions get challenged. Real users behave differently than expected. Traffic grows faster than projections. Integrations behave unpredictably. In moments like that, what matters is not perfection. What matters is presence.
We stay.
We adjust.
We learn.
We improve.
We take responsibility alongside our clients, not at arm’s length.
In this project, there were moments we should have pushed back harder. Moments where scope could have been managed differently. Moments where pressure ran high. And we learned from them together. That is what long term partnership looks like. Not blame. Not distance. Growth.
The company behind this case study is operating at global scale. They now hire internally with confidence because their foundations are strong. We continue to support them on retainer as an extension of their team. Not as vendors. As collaborators invested in their success.
We cannot publicly name the client due to strict NDA obligations.
If you are seriously considering working with us and want to understand the depth of this project, contact us. In a private meeting, we are happy to walk you through the platform, the architecture and the decisions in detail.
We believe in transparency. We just respect confidentiality.
When growth outruns infrastructure, you do not need more tickets.
You need alignment.
You need architecture.
You need people willing to sit in the tension with you.
We do not just build systems.
We partner in outcomes.
We invent the future with friends.
