How a global consumer creative software platform launched data-informed creative experiences and unified its product analytics in under six months

Without rebuilding the product from scratch, without a separate data science team, and without disrupting live product operations.

Web3 platform delivered in under 6 months · ML-powered recommendations tailored to individual creative users · POC tested with 200-300 targeted creatives · 5 product teams moved to unified OKR reporting

The bridge. The company’s product teams were operating in silos, with no shared view of performance and a creative community increasingly curious about Web3 but with nowhere trustworthy to turn. Today, the company runs a unified analytics foundation tied directly to its OKRs, and its creative users have access to a platform that translates Web3 from hype into genuine value. That shift is the work.

The client is a global consumer creative software platform headquartered in Europe, built around the simple idea that sharing and producing creative work should be fast, beautiful, and human. It serves tens of millions of creative professionals globally, from independent artists to major studios. By the time SeidrLab became involved, the company was at a familiar crossroads for high-growth technology companies: the product had scale, the community had depth, but the internal operating machinery had not kept pace.

Two distinct problems were converging. Internally, five product teams were each working from their own reporting frameworks, with definitions and metrics that changed quarter to quarter. There was no shared view of how the portfolio performed against company OKRs, and reconciling the numbers across teams required manual effort every reporting cycle. Externally, the company’s creative audience was increasingly encountering Web3 and blockchain conversations in their industries, but without a trusted guide, most of that curiosity led nowhere useful.

The question the company brought to SeidrLab was both strategic and practical: could they expand their value proposition to creative users through a genuinely useful Web3 experience, while simultaneously getting their internal data house in order? Both tracks needed to move quickly, and they needed to reinforce each other rather than compete for attention.

How we built a Web3 platform that creative users could actually trust

The Web3 space in 2022 and 2023 was loud with speculation and short on substance. For a company whose reputation rests on clarity and craft, launching anything that felt promotional or shallow would have done more harm than good. So we approached the platform not as a marketing play but as a utility: something that helped creative users understand what was actually happening, filter signal from noise, and identify opportunities that were relevant to their work.

Working alongside the company’s Entrepreneur in Residence, we scoped a platform that combined curated Web3 content with intelligent recommendations driven by machine learning. The recommendation engine was trained on creative user behaviour patterns, meaning the platform could surface content and engagement opportunities that matched what individual users were actually interested in, rather than serving a generic feed. The result was a product that felt personal rather than broadcast.

We delivered the complete platform in under six months and released it to a targeted sample of 200-300 creatives within the company’s customer base. That scope was deliberate: rather than attempting to cover every corner of the Web3 landscape or rolling out at scale before the hypothesis was validated, we focused on building something excellent within clear boundaries and released it where signal could be gathered cleanly.

Key takeaway. The most valuable thing you can give a curious audience is clarity, not coverage. A platform that helps people understand a complex space well is more durable than one that tries to cover everything adequately.

How we unified product analytics across siloed teams

While the Web3 platform was being built, we were running a parallel track with the company’s Head of Data. The problem here was structural: each product team had developed its own way of measuring performance, which meant there was no single shared view of how the product portfolio was doing against company OKRs. When leadership asked questions that crossed team boundaries, the answers required manual reconciliation.

We designed and implemented a product analytics framework that treated reporting as a shared infrastructure problem rather than a per-team concern. This meant agreeing on canonical definitions for key metrics across all five product teams, replacing the rotating frameworks that had made quarter-on-quarter comparisons unreliable. Consistent tracking conventions were established across product surfaces, and the framework was connected directly to the company’s OKR structure so the link between what teams were building and what the company was trying to achieve was explicit and legible.

The work required as much organisational alignment as it did technical implementation. Getting teams to adopt shared definitions and common instrumentation means navigating the politics of measurement, where what gets counted can feel like a judgment on what matters. We approached this carefully, framing the framework as something that made everyone’s work more visible rather than more scrutinised.

Key takeaway. Shared data infrastructure requires shared definitions before shared tooling. The technical implementation is straightforward once teams agree on what they are actually measuring and why.

How we connected two parallel tracks into a coherent operating model

Running two distinct workstreams simultaneously creates a coordination risk that is easy to underestimate. The Web3 platform and the analytics strategy had different stakeholders, different timelines, and different success criteria. Without deliberate integration, they could have remained separate projects that happened to occur at the same time.

We designed both tracks with a shared architectural philosophy: data should flow cleanly, decisions should be traceable, and any output should be extensible rather than bespoke. This meant the analytics framework we were building internally could eventually inform the recommendation logic powering the consumer platform. The two workstreams were not just happening in parallel; they were being built to connect.

We held regular cross-track reviews that brought the Entrepreneur in Residence and the Head of Data into the same conversation. This was not process for its own sake. It was the mechanism that allowed us to catch dependencies early, avoid duplicating instrumentation work, and ensure both workstreams were moving toward the same version of what “good” looked like for the business.

Key takeaway. When running parallel workstreams, shared architectural principles do more to keep things coherent than shared project management. Build things the same way, and they will connect more naturally later.

How we delivered ML-powered recommendations without a dedicated data science function

One of the constraints of the engagement was that the company did not have a standalone data science team to hand off to. The recommendation engine needed to be designed for an organisation that would operate and extend it without deep machine learning expertise on staff.

We addressed this by making deliberate choices at every layer of the stack. The model architecture favoured interpretability and maintainability over raw sophistication. The training pipeline was documented thoroughly and designed so that retraining with new data did not require specialist intervention. The recommendation logic was exposed through clean interfaces that product engineers could work with directly.

This approach required resisting the temptation to build something impressive in ways that created long-term dependency. The measure of success was not whether the system was technically elegant in isolation, but whether the company’s team could confidently operate, evolve, and eventually own it.

Key takeaway. ML systems that cannot be maintained without their original builders are a liability, not an asset. Operational simplicity is a design requirement, not a compromise.

What changed

Before. Product teams reported performance independently using their own metrics and tooling, making it impossible to get a unified view of how the portfolio was performing against OKRs. The creative audience had growing curiosity about Web3 but no trusted platform to help them navigate it, and no product existed to meet that need.

After. The company has a unified product analytics framework where performance data across teams connects directly to company OKRs, enabling clear, consistent reporting without manual reconciliation. Its creative community has access to a Web3 platform with ML-powered recommendations tailored to individual user behaviour, delivered within a six-month timeline and built to extend as the space evolves.

---

---

Does this fit your situation?

If your product teams are measuring performance in silos and you cannot get a clean view of how your portfolio connects to company strategy, or if you want to expand your value proposition with a genuinely useful new product but do not have the internal resource to move fast, this is the kind of engagement we are built for.

Book a discovery call →