Most SaaS and technical founders hire design the wrong way. Not because they don't care about design - they do. But because the options they're comparing are the wrong ones.
The real question isn't "agency or freelancer?" It's: what kind of design relationship can actually keep up with a company that's growing?
I've been doing this for 15 years. We've worked with companies that got acquired by Google, raised Series B, landed Mastercard as an investor. I'm not saying design was the reason. But I can say we were in the room while it happened, and I have a pretty clear picture of what made those engagements work versus the ones that fell apart.
The short version: a design partner who can grow with you doesn't look like most agencies. They look more like a senior person embedded in your team - someone who understands your product context, communicates directly, and builds systems that hold up after they leave.
Here's how to find one.
The three options - and why two of them usually fail
When a technical founder realizes their product needs serious design work, they typically consider three paths. The choosing the right SaaS design agency question comes up constantly, and the framing of that question shapes the answer you get. Each has a version that works and a version that quietly kills momentum.
The big agency
You get a polished process, a dedicated account manager, and a deck that looks great in a board meeting. What you don't get is direct access to the people actually designing your product. The senior designer who pitched you is often not the one building your screens. Timelines stretch. Feedback loops run through three people before anything changes. By the time the deliverables land, your product has already moved.
For a pre-Series A startup, this model is almost always wrong. The pace doesn't match. The overhead doesn't match. And the output is often optimized for looking impressive rather than being extensible.
The freelancer
Fast, flexible, affordable. Works well for a specific task with a clear scope. The problem comes when the scope grows - or when the freelancer leaves. You end up with a collection of design decisions that nobody fully understands, made by someone who's no longer around to explain them.
Most technical founders who've hired freelancers have a version of this story: "We had good work done, then they moved on, and now nobody on the team can extend it consistently." Also, a lot of freelancers are working in a visual style that can be only scaled if they are part of your team. That also makes you look like the other clients they worked with, as some of the freelancers pursue a specific aesthetics. You can just see white backgrounds, dark icons, isometrics. If they've done it for everyone, they will also do it for you.
The embedded senior partner
This is the model that actually scales. Not an agency with layers, not a freelancer with no continuity — something closer to a small senior team that works inside your Slack, understands your product, and builds systems designed to outlast the engagement.
The distinction matters because of what you're really buying. You're not buying screens. You're buying a design logic that your team can carry forward.
Five things worth evaluating before you sign anything
Not every studio that calls itself a "partner" operates like one. Here's what actually separates a design partner who can grow with you from one who can't.
1. Who are you actually talking to?
In most agencies, the person on the sales call is not the person doing the work. That gap matters more than founders realize. When you're building a product, design decisions happen fast and require context that's hard to document. If the person doing the work wasn't in the conversation where the context was established, you lose something every time.
Ask directly: who will be on Slack with me day-to-day? If the answer involves account managers or project coordinators as the primary interface, that's a signal. It is fine if some of the designers are not super happy speaking to you on a direct call or just jumping on a call. The main thing is that they're accessible through Slack, through Figma, through Looms. At heartbeat, we have our CEO doing most of the project communication and being the product owner inside heartbeat team.
2. Can they explain why, not just what?
Any competent studio can show you polished screens. What you need is someone who can explain the logic behind every decision - why this typeface, why this spacing system, why this hierarchy. Because your team will need to extend the system after the sprint ends, and they'll need that logic to do it consistently.
Ask for a walkthrough of a past project. Not the visuals - the reasoning. If they can't articulate it, your team won't be able to carry it forward.
3. Do they build for handoff?
A design system that lives only in a Figma file is not a design system. It's a reference document that will be ignored six months after the engagement ends.
A real design partner thinks about implementation from day one: how will your frontend team use this? What happens when you add a new feature type? What's the naming convention for components, and why? These aren't aesthetic questions - they're engineering questions, and the best design partners think in both languages. A good sign is when they ask you to add front-end developers to the conversation as early as possible, as they will be the ones who will implement things. And being sure that they get the work is one of the most important things of this process.
4. Have they worked with companies at your stage?
Early-stage and growth-stage design are genuinely different disciplines. A studio that specializes in rebranding established companies is not necessarily equipped to build a scalable identity from scratch for a 12-person startup. And vice versa.
Look for evidence of work at your stage: pre-seed to Series A, products that were still evolving, teams that were still figuring out what they were building. The best signal isn't the biggest client name in their portfolio - it's the most similar situation.
5. What happens after the sprint?
This is the question most founders forget to ask. You get the deliverables. Then what?
A design partner worth keeping will have an answer that goes beyond "we're available for follow-up work." They'll describe how they structure ongoing relationships, how they stay close to the product as it evolves, and what it looks like when the engagement transitions from sprint to retainer - or ends cleanly with a system your team can own.
The right answer isn't "we'll be here if you need us." It's a clear model for what continuity looks like.
The two ways design partnerships actually break down
I've seen a lot of engagements go sideways. Almost every failure traces back to one of two root causes.
No design advocate inside the team
You can deliver a perfect system and watch it dissolve in three months if nobody inside the company is willing to defend it.
We had a project where we built a solid set of guidelines - component library, type scale, color system, the works. Before wrapping, we said: start with your marketing materials. Get comfortable with the system there before touching the product. Simple enough.
One month later, they hadn't bought the fonts. Their internal team had started making their own versions of our designs - close enough to look like the system, different enough to break it. When I asked why, it wasn't a resources problem. It was that nobody in the building cared enough to push back when someone went off-piste.
The design advocate is the person who says "that's not in the system" when a PM tries to ship a one-off component. Without that person, even the best-designed system becomes decoration.
Before starting any serious design engagement, a founder should be honest about whether this person exists on their team. If not, that's a conversation worth having before the sprint begins - not after.
No organizational will
Building a design system during a period of growth is entirely doable. It's not a moonshot. But it requires the whole organization to actually want it.
In marketing, this is usually manageable. The surface area is smaller, the dependencies are fewer, and changes don't cascade into the codebase. In product, it's harder - every design decision touches frontend, which touches engineering, which touches sprints and timelines. The system has to be negotiated, not just delivered.
The founders I've seen make this work have one thing in common: they treat design consistency as a product requirement, not a nice-to-have. They push back when a developer ships a component that doesn't match the system. They ask in design reviews whether new features are extending the existing logic or creating new ones.
The ones who don't make it work usually have good intentions and no follow-through. The sprint ends, the files land, and three months later the product looks like it was designed by six different people.
Building a design system is a decision you make every day, not once at the end of a sprint.
Companies we've worked with - and what happened next
I want to be direct about what this section is and isn't. It's not a claim that design caused any of these outcomes. Building a company that raises a Series B or gets acquired by Google involves a thousand decisions that have nothing to do with us.
What I can say is that we were in the room early, sometimes years before these milestones happened, and that the design work was part of a product that investors, acquirers, and users eventually took seriously.
Dataform - acquired by Google Cloud
Dataform was a UK startup building what they described as an "operating system for data warehouses." YC alumni, small team, technical product. We worked with them on identity and product design while they were still early.
In December 2020, Google Cloud acquired Dataform. The product became part of BigQuery and was made available for free to all users. It's now used by data teams across the world.
BibliU - Series A, then Series B
BibliU is a British edtech startup building a digital textbook platform for universities. We started working with them in 2019, before the pandemic reshaped the market for digital learning.
They raised a $10M Series A in 2020, then followed with a Series B of $15M plus an additional £4.7M in 2022. The platform now operates across the UK, US, and Australia, and has become one of the leading digital courseware providers for higher education.
CapIntel - Series A backed by FinTech Collective
CapIntel is a Canadian fintech building presentation and analytics tools for wealth management advisors. When we worked with them, they were early-stage with a clear product thesis but a brand that hadn't caught up to it.
They raised an $11M Series A in 2022, led by FinTech Collective in New York. Today, more than 10,000 financial advisors use the platform, including teams at three of Canada's five largest banks.
WeMoney - Series A with Mastercard as investor
WeMoney is an Australian open banking fintech focused on financial wellness. Their product sits at the intersection of Consumer Data Right regulation and personal finance — a technically complex product that needed a clear, trustworthy interface.
They closed an A$12M Series A in 2025, with Mastercard among the investors.
Caplena - ETH Zurich spinoff, $10M seed
Caplena is a Swiss AI SaaS platform for customer feedback analysis, spun out of ETH Zurich. They raised a seed round at a $10M valuation in 2022. The platform now serves more than 100 clients across 15 countries, including enterprise customers like DHL, FlixBus, and Lufthansa — as documented in heartbeat's Caplena case study.
HYROS - full rebrand, 3,000+ businesses on platform
HYROS is an AI ad tracking and attribution platform founded by Alex Becker. The product catches conversions that standard pixels miss and feeds that data back to ad platform algorithms for sharper targeting. Client roster includes Tony Robbins, Playboy, Alex Hormozi, and Whop, with over 3,000 businesses on the platform. We handled a full rebrand and website build in six weeks, then moved into an ongoing monthly retainer covering marketing, product, and website as the platform grows.
Corti - Series B AI healthtech, $100M raised
Corti is a specialized AI lab for healthcare, founded in Copenhagen in 2016. The company builds foundation models and APIs that power clinical and administrative workflows for EHR vendors, virtual care platforms, and health systems including the NHS. Over 100 companies build on Corti's infrastructure, reaching more than 100 million patient interactions annually. We ran a one-month visual sprint with their design and marketing teams - tuning the logo, resolving inconsistencies, and preparing the visual language for the next phase of the company. $100M raised to date.
Sway - full design system for a Bay Area civic tech platform
Sway is a nonpartisan voting platform, registered as a Public Benefit Corporation, that lets groups vote as a bloc and prove mathematically when their turnout decided a race. Active in Texas, California, and Illinois, and featured on Andrew Yang's Forward podcast. We built a full design system for the web application: 200+ components, 80 icons, 30 screens, plus motion guidelines - structured so the Sway team can extend it independently as new features ship.
None of these companies hired us because they had money to spend on design. They hired us because they were building something real and needed a design foundation that could keep up. The engagements that worked well had a common thread: the founders were deeply involved, they understood what they were asking for, and they were willing to share enough context for the work to be genuinely useful.
That's the version of the relationship that produces something worth keeping.
What the partnership model actually looks like in practice
There are two modes we work in, and being honest about the difference matters.
The first is a sprint: a defined scope, a fixed timeline (10-30 business days), a clear deliverable. Identity foundation, component system, implementation guidelines. You get the files, you own them, the engagement ends. This works well when the scope is clear and the team is ready to take over.
The second is an ongoing engagement. This is where the "partner" framing actually applies. We're in your Slack. We're in your Figma. When a new feature gets scoped, we're part of the conversation before anyone opens a design file. When your marketing team wants to run a campaign, they're working from templates we built together. When your frontend team asks "which component should I use here," there's a system that answers that question.
The practical difference:
Sprint: Direct Slack and Figma access throughout. All communication goes to the designers doing the work, not through account layers. Dima is personally involved in every engagement.
Ongoing: Same access model, but continuous. We stay close to the product as it evolves, extend the system as new feature types emerge, and flag when something is drifting from the design logic.
We're a small team by choice. That means we run a small number of engagements at once, which is also why each one gets real attention. We're not the right fit for every company. But for a technical founder who wants a design relationship that actually scales with the product, the model is worth understanding before you default to hiring in-house or spinning up another freelancer contract.
The questions worth asking yourself first
Before you start evaluating design partners, it's worth being honest about your own situation. The best engagement in the world won't stick if the conditions inside your company aren't right.
Ask yourself:
Is there someone on my team who will defend the design system? Not just appreciate it — actively push back when someone goes off-script. If the answer is no, that's a conversation to have before the sprint starts.
Am I willing to treat design consistency as a product requirement? Not a preference. A requirement. Something that gets tracked, reviewed, and enforced the same way you'd enforce a code style guide.
Do I have enough context to share? The best design work comes from deep understanding of the product. If you're not willing to bring a design partner into the real conversations — the product debates, the roadmap discussions, the "what are we actually building" moments — you'll get good-looking files. Not a system.
What does success look like in 18 months? Not at the end of the sprint. Eighteen months out. If you can answer that question clearly, a design partner can build toward it. If you can't, that's the first problem to solve.
The right design partner will ask you these questions before taking the work. If they don't, that's a signal too.
Finding a design partner you can grow with isn't complicated. But it requires being honest about what you actually need — not just a set of deliverables, but a relationship that holds up when the product changes, the team grows, and the design system gets stress-tested by reality.
The companies that make it work share one quality: they treat design as something that belongs to the whole organization, not just the sprint that produced it. That's not something a design partner can install. It has to already exist, or at least be something the founder is willing to build.
If it does exist - or if you're ready to build it - the right partner will notice. And the work will show it.
