01. The beginning: "I like your illustrations."

It was 2017. I was just a designer posting illustrations on Dribbble, trying to make cool things and maybe get a few likes. One day, I got a message from a guy named Dylan. He said he liked my work and asked if I wanted to help him build something. I said yes.

The next day, we were clipping away on a project that would eventually become AssemblyAI, a now-series-C AI company that just raised $50 million in 2023. But back then? It was just the two of us. No team. No office. Just two people, a speech-to-text API (STT ADK), and a whole lot of caffeine.

It’s funny how things start sometimes. You post something online, and suddenly, you’re building the future of AI. Life’s weird like that.

02. Branding: Will Richard love this?

Although it turned into a B2B SaaS fairly quickly later, AssemblyAI was originally a B2C company built for hackers - the "I-woke-up-at-3-AM-to-build-a-script-that-automates-my-coffee-maker" kind. These were smart, nerdy, sometimes goofy people who loved solving problems but hated overpriced, overcomplicated tools.

On-shelf STT APIs at the time were a nightmare. They were expensive, clunky, and required a PhD in computer science just to get started. Our mission was simple: make speech-to-text (STT) easy, cheap, and customizable. With AssemblyAI, you could run a speech-to-text API with literally one line of code. It was pay-as-you-go, a fraction of the price of AWS or Google Cloud, and customizable enough to recognize specific words like your brand name.

At that time I was thinking a lot about Richard Hendricks, the chameleon-looking guy from Silicon Valley. That was our persona: smart, geeky, earnest, a bit awkward. For people like Richard to love a STT API, the branding should be:

• Simple: No fluff, no jargon, just straight-to-the-point goodness.
• Friendly: Approachable, like the cool TA who actually explains things.
• Earnest: We're here to transcribe your audio, not to sell you a dream.
• Playful: Because they are goofy. Because I'm goofy, too.

So, we went with a sans-serif font and flat colors—clean, modern, and easy on the eyes. And then there was the logo: a pyramid. Why a pyramid? Two reasons:

1. Reliable and stable: Pyramids are simple geometric architectures that have been standing for thousands of years. That's the kind of reliability we wanted to embody.
2. Built block by block: Pyramids are made of modular, carefully placed units. It's a metaphor for how we built our LLM token by token.
3. Timeless: Pyramids are iconic. They don't go out of style. Neither should our brand.

The pyramid wasn't just a logo; it was a promise. A promise that we were building something solid, something that would last. And for a bunch of hackers trying to turn speech into text, that was exactly what they needed.

03. MVP: Do things that don't scale

We built the MVP, launched our website, internally tested it and I was on my vacation to Hawaii, when I got a call form Dylan where in the call he screamed to me, "Holy shit dude we're in YC!!!".

Yeah, that happened. One minute, I was trying to pick the best water melon in a Chinese market in Honolulu, and the next, I was screaming into my phone about how we just got into the most prestigious accelerator in the world. Life comes at you fast.

The batch started soon after. We launched our website with a waitlist entry, Tech Crunch wrote about us and about 2,000 people joined our waitlist.

In the following month, we shipped the MVP and were ready to run a beta test. Our growth strategy? Manual. As. Hell. We sent out invite codes one by one so that they don't end up in spam folders. We wanted every invite to feel personal, like a golden ticket to Willy Wonka's chocolate factory. PG told you to do things that don't scale? Exactly that.

It was tedious. But it worked. About 600 people actually signed up. And we started to hear feedbacks from real human beings.

04. Pivoting: Gavin was right

In Silicon Valley, Gavin Belson mocked that all noob founders "wanna work on some consumer product". Consumer market is less predictable, the sales cycle is usually longer, and the margin is much lower. It's even harder when you sell to hackers, who are known for bring smart, finicky and price-sensitive.

On the other hand, YC fosters a thriving ecosystem of B2B SaaS companies—a built-in customer base where startups sell to each other. If you're building a developer tool like AssemblyAI, the logic is obvious: B2B SaaS is simply the better model.

Gavin Belson was right. Ouch.

Long story short, we pivoted. We became a B2B SaaS company, and it was the best decision we could've made. Frankly, YC has a way of turning every single tech company in its batch into a B2B SaaS, and in this case, they were spot on. We started serving small companies, and our new tagline became: Reliable. Cheap. Easy to use. Not just for developers— your PMs and admins should be able to use it, too.

With the pivot came a rebrand. Even when the core product stays the same, the brand's personality needs to shift. More professional, less playful. Still simple, but now sleek and practical. We replaced the goofy, friendly Bradon Text with sleek, modern Hurme Geometric Sans, and changed our color palette.

05. Iteration: On building a B2B SaaS

Let's get one thing straight: B2C and B2B are two entirely different beasts. B2C is all about feels. You're building an experience that becomes part of your user's life, making them feel smarter, cooler, or more connected. B2B SaaS, on the other hand, is all about numbers. Not "I feel smarter when I drink Soylent" but "this API saves my company hundreds of man-hours by automating this process".

So, when we pivoted to B2B, our design goals had to shift too. Here's how we approached it:

1. Shorten the sales cycle (because we couldn't afford two months)

Here's the thing about B2B software: decision-making layers are the enemy. In most cases, the person who decides to buy your product isn't the one actually using it. It usually goes like this:

1. A PM stumbles across your product.
2. They send it to a developer to benchmark.
3. The developer tests it, writes a report, and sends it back to the PM.
4. The PM forwards it to the decision-maker.
5. The decision-maker finally says yes (or no).

By the time this bureaucratic Rube Goldberg machine spits out an answer, it's been two months. As an early-stage startup, we didn't have two months. We needed to close deals in two weeks. So, we made the product so simple that even the decision-maker could see the value without needing a developer to explain it.

• One line of curl? Not simple enough.
• Use it in your browser? Better.
• Test it directly on the landing page? Now we're talking.

The goal was to eliminate as many steps as possible. If the decision-maker could see the magic happen right in front of them, they'd be more likely to say yes. And faster.

To facilitate this process, we add a side-by-side comparison between our model and mainstream STT models in our landing page, and our users could test our model directly by uploading their own audio files and toggle between different models.

This design was a hit. Our conversion rate went up, and our sales cycle went down. We were closing deals in weeks, even days.

2. Better onboarding (because CAC hurts)

In B2B, customer acquisition costs (CAC) are high. Like, "maybe we should've just stuck with B2C" high. So, once you've got someone through the door, you can't afford to lose them. That's where onboarding comes in.

Our philosophy? One step at a time. No overwhelming dashboards, no walls of text, no "here's everything you need to know in 47 easy steps", just one clear, actionable step. We don't expect our users to go through a tutorial and remember everything. Instead, we take their hands, guide them in baby steps and slowly build their confidence.

We designed a bunch of actionable cards, each carries only two pieces of information: a confirmation of what you've done and a clear next step. And we show only one card at a time. Reduced cognitive load, increased day 1 retention.

3. Better documentation (because customer success needs to come earlier)

We knew one thing: nobody pays for a software without testing it first. They had to try it, see how easy it was, and then they'd be hooked. Simple, right?

Not quite if your product is a STT API.

Here's what usually happens: they hit "Try it out," but—wait. They don't have an audio file on hand. They could record one, but what format does it need to be? Oh, and what about the sample rate? Before they even bother to find one or create one audio, they drop.

Around this time, I was moving, which meant one thing: IKEA furniture. When I was assembling my Hemnes bookcase, one question came to my mind: How does IKEA make it so that literally anyone—even someone who's never held a screwdriver—can put together a bookshelf?

Turns out, IKEA does these things brilliantly:

1. It tells you what to expect upfront. This builds up your expectation and gives you a goal.
2. It tells you what you need before you start, so that no surprises come halfway through.
3. It guides you step by step—no branches, no "if this, then that."
4. It makes each step stupid easy. No overwhelming walls of text. Just small, bite-sized actions.

So, We stole it and developed our Assembly Instruction (yes, you get the pun 😉).

1. Set expectations upfront
   Our landing page didn't just say "Try our STT API." It said, "Test us against Google and AWS. See the results yourself."
2. Give users everything they need
   We provided a sample API token, a sample audio file, some pre-written sample customized words so users could plug and play without setting anything up.
3. Make it idiot-proof
   Copy this. Paste it. Hit enter. Done.

The result? Almost 100% of our early clients successfully ran a test within minutes. Even non-engineers could try the product on their own—which meant no drop-off, no friction, no waiting for a developer to get involved.

06. Learning: same product, different designs

At its core, AssemblyAI didn't change. It was always a simple, powerful speech-to-text API. The product stayed the same, but how we designed it—how we framed, onboarded, and sold it—evolved massively.

When we started, we built for hackers—the kind of people who live on Hacker News and write Python scripts just to save five seconds on a daily task. The design reflected that: playful, casual, geared toward someone who'd get excited by the words "one-line API call."

Then we pivoted to B2B, and suddenly, our audience wasn't a solo hacker at 2 AM—it was a company. The decision-maker wasn't the user, the buyer wasn't the developer, and if the product wasn't intuitive for everyone, we'd lose the sale.

The same API, rebuilt for different minds:

AssemblyAI was the same product, but as the business evolved, the design had to evolve with it. It's not just about making a product look good—it's about making it work for the right people, in the right way, at the right time.

That's the real job of a designer.

- end -