How Boldare works as a strategic design partner for scale-ups

Why design at scale is a business decision, not an aesthetic one

Scaling a product forces a company to answer questions that have nothing to do with visual polish. What gets standardized across markets or squads, and what stays flexible? At what point does inconsistent UI start costing more in support tickets and onboarding friction than a formal design system would cost to build? How does a growing number of product teams avoid losing shared context about who the user actually is?

These are business decisions with a P&L impact. They get made whether or not a designer is in the room. The question worth asking is whether they get made deliberately, before the brief is written, or whether they get made by default, after direction and budget are already locked. That’s the gap a strategic design partner for scale-ups is meant to close. The three cases below show what closing it looks like.

Case study #1: Polco - one relationship, three stages

Polco’s founding team came out of the US Air Force, molecular biology labs, Google, and Amazon. They had a clear mission: a civic platform for real-time citizen polling and validated analytics. What they didn’t have was an in-house product team, or the months it would have taken to build one before starting to test the idea.

Boldare was chosen after Polco’s COO, Alex Pedersen, evaluated several vendors on process rather than portfolio. That choice set the tone for everything that followed:

“We liked their style and design but what’s been awesome is the process that they go through. There is an unbelievable amount of transparency and organization.” — Alex Pedersen, COO, Polco.us

That process started with Product Vision Workshops to pin down the two features that actually mattered (voting and commenting) before any screen was designed, moved through moodboards to align on visual direction cheaply, and continued into wireframes and iterative UI changes driven by real usage data. Harvard students tested the early MVP for two months; Austin, Texas served as the first live market. Each round of feedback fed back into design decisions, not just bug fixes.

This wasn’t three separate projects. It was one relationship that moved through prototype, MVP, and a scalable product without resetting context at each stage. Polco now runs in 46 active communities covering over 13.6 million people, a result the case study ties directly to the discipline of shipping one key feature at a time rather than a feature-complete product. By the end of the engagement, Polco had built its own in-house design and development team to carry the product forward, using the foundation Boldare had put in place.

Read the full Polco case study →

Case study #2: BlaBlaCar - the same model at higher complexity

When BlaBlaCar approached Boldare, the carpooling platform had around 24 million users and roughly a year to expand into 27 markets before competitors caught up. Each market carried its own legal requirements and cultural expectations, meaning the product couldn’t simply be translated. It had to be adapted market by market while staying recognizably one product.

Every new product line started the same way: a Product Vision Workshop with the full team and the client to define the core audience and features, followed by service architecture mapping, moodboards, and wireframes, with designers and developers working in parallel rather than in sequence. That parallel structure meant graphic design and coding happened together, so feedback loops stayed short even as the number of markets grew. Boldare has since written more about that way of working in Figma to code: keeping design and development in sync at scale.

Over 18 months, the collaboration produced 10 new products, from a dedicated blog service to a EURO 2016 microsite to a redesigned payments flow, while BlaBlaCar’s user base grew from 24 to 35 million. BlaBlaCar is also one of the client logos already featured on Boldare’s Outcome-Driven Design Partnership page, which gives this case study a direct line to the service this article is building toward.

Read the full BlaBlaCar case study →

Case study #3: holaspirit - smaller scale, same logic

Not every version of this relationship involves a unicorn. Holaspirit, a French SaaS platform for self-managed organizations, had a five-person development team and a growing backlog of feature requests it couldn’t keep up with. Its CEO, Philippe Pinault, wasn’t looking for a vendor to execute a spec. He wanted a partner who understood the product category itself:

“We were looking for companies that understand software, SaaS and digital transformation.” — Philippe Pinault, CEO, holaspirit

Boldare’s dedicated team for the engagement included a product designer, two frontend developers, and a scrum master, so design sat inside the team from day one rather than being brought in separately later for the redesign phase.

The engagement was structured in two deliberate stages. The first focused on stabilizing the platform: fixing bugs, improving performance, and shipping features sourced directly from customer conversations and a public feedback board. Only once that was under control did the second stage begin: rebuilding the platform’s engine from AngularJS to React and designing a new UI from scratch.

That two-stage structure mattered. It let holaspirit’s team build trust in the working relationship on smaller, lower-risk changes before handing over something as consequential as a full technology and design overhaul. By the end of the engagement, the in-house team had full access to the new codebase and design materials, giving them what they needed to take the rebuilt platform forward on their own.

Read the full holaspirit case study →

What connects these three cases

None of these engagements started with a finished brief. Design entered while the problem was still being defined: which feature to build first, which markets to prioritize, which parts of the platform to rebuild before which. That’s a different entry point than most agency relationships, where design is handed a scope that’s already been decided elsewhere.

In each case, the client also ended up owning the outcome, not renting it. Polco built its own design and development team. BlaBlaCar recruited and onboarded its own Warsaw hub. Holaspirit received the full codebase and design system to continue independently. Boldare’s own language for this on the Outcome-Driven Design Partnership page is “you own it from day one,” and each of these three cases predates that phrasing by years. The same page also commits to a clear handoff of decision-making once a build ships, so the client, not Boldare, controls what happens next.

This is where a strategic design partner for scale-ups earns the label: not by staying involved forever, but by building something the client can run without it.

Where this leads

If any of this sounds familiar, if design keeps arriving after the scope is already fixed, or if every new design engagement starts from zero, that’s the specific problem Boldare’s Outcome-Driven Design Partnership is built to solve.

FAQ

How long does this kind of design relationship take before it shows business results? It varies by engagement type. Polco’s first meaningful signal came within seven sprints of MVP work. BlaBlaCar’s 27-market expansion ran over 18 months. Boldare’s current audit-first model is designed to surface direction within one to two weeks, with measurable outcomes typically visible within the first quarter of an embedded partnership.

What happens to the relationship once the main phase of work wraps up? In each of the three cases, ownership moved to the client. Polco built its own in-house design and development team and took the product forward independently. BlaBlaCar recruited and onboarded 20 developers for its own Warsaw hub. Holaspirit received full access to the rebuilt codebase and design materials so its internal team could continue the work alone. None of these relationships were structured to require ongoing external involvement.

Does this model only work for large, multi-year contracts, or does it fit smaller engagements too? Both. Holaspirit ran a six-month engagement with a five-person development team on the client side, split into two focused stages. BlaBlaCar ran an 18-month engagement across 27 markets with a much larger scope. The structure scales down as easily as it scales up: what stays constant is design entering early, not the size of the contract.