You already created the content.

That demo you recorded. Those notes. The AI agent log.

Now share it everywhere.

See it in action

Your content, restructured.

Raw input left. Polished draft right.

conference_talk.mp4

1 hour video

Swift Summit Conference Talk

Talking to Swift: Cutting Through the Hype to Build Voice UIs

Talking to computers is a classic sci-fi dream. I always think of Star Trek IV, "the one with the whales". The crew travels back to 1986 San Francisco to save the future. To do this, Scotty, the chief engineer, needs to explain the formula for transparent aluminum to a contemporary engineer.

Subject: Hello, Computer?

Hey there,

Remember that scene in Star Trek IV where Scotty, a man from 300 years in the future, tries to use a 1980s Macintosh? He picks up the mouse, holds it to his mouth, and says, "Hello, computer."

The joke back then was simple: of course you can’t talk to computers. But watching it today, the joke still works, just in a different way...

Remember in Star Trek IV when Scotty tries to talk to a 1980s computer by speaking into the mouse? The joke was, "you can’t talk to computers." Today, the joke has flipped.

Now it’s more like, "of course you can talk to computers, but you’ll probably want to use the keyboard anyway."

With all the hype around AI and bots, why is voice UI still so awkward? I decided to dig in.

I always think of that scene in Star Trek IV where Scotty, a man from the future, tries to use a 1980s computer. He picks up the mouse, holds it to his mouth, and says, "Hello, computer."

When the movie came out, the joke was on Scotty. Today, the joke has flipped. We can talk to our computers, but we often end up reaching for the keyboard anyway.

As a developer, I wanted to cut through the noise...

airdragon_demo.mp4

15 minute demo

Screen Recording

Introducing AirDragon: A UI Component Library Born on an Airplane

Inspiration strikes in strange places. For us, it was at 30,000 feet on a flight from Japan to the Philippines. Audrey and I started coding and by the time we landed, the first version of AirDragon was born.

AirDragon is a layout and component library for the Air web framework. We wanted a name that felt dynamic and airy. We were on an airplane, and dragons fly, so "AirDragon" just clicked.

Subject: Born at 30,000 Feet: A New Component Library for Air

Hey,

On a recent flight from Japan to the Philippines, Audrey and I had some time to kill. Instead of watching movies, we opened our laptops and started coding. The result is a new project we’re calling AirDragon.

We landed on the name because it felt dynamic and airy. Plus, we were on an airplane, and dragons fly. It just clicked.

AirDragon is a layout and component library for our web framework, Air. The goal is to give you sensible, good-looking defaults so you can build UIs faster...

1/ Some of the best ideas happen in unusual places. For us, it was on a plane from Japan to the Philippines. With a few hours to spare, we started coding what would become AirDragon: a new component library born at 30,000 feet.

2/ AirDragon is a layout and component library for the Air framework, designed to make building web UIs fast and easy. The goal is to provide sensible, good-looking defaults so you can build and ship faster.

3/ Components come with built-in styling via Tailwind CSS, so AD.H1 renders a nicely styled, responsive heading out of the box. But you’re not locked in. You can easily add your own classes to customize.

Some of the best ideas happen in unusual places. For us, one of those places was a plane flying from Japan to the Philippines. With a few hours to spare, Audrey and I started coding what would become AirDragon, a new layout and component library for the Air framework.

We landed on the name because it felt dynamic and airy. We were on an airplane, and dragons fly. It just clicked.

The goal is to provide an initial component library for Air, making it fast and easy to build web UIs with sensible defaults. We wanted to bring back the component-driven simplicity of early frameworks, where you think in terms of higher-level components like Cards, Buttons, and Headers.

voice_memo.txt

finally shipped that feature

took way longer than expected... kept adding edge cases

should have shipped the simple version first

also realized I was solving problems nobody asked for

next time: talk to users before building

the core thing works great though, people seem to like it

Ship the Simple Version First

I finally shipped a feature I’d been working on for weeks. It took twice as long as it should have, and I know exactly why.

I kept adding edge cases. Every time I thought I was done, I’d imagine another scenario and build for it. Most of those scenarios? Never came up.

Worse, some of the things I built solved problems nobody actually had. I was guessing instead of asking. Classic mistake.

Next time: ship the simple version, see what breaks, then fix that. In that order.

Subject: I Overbuilt Again

Hey,

Shipped a feature this week. Took forever. I kept adding edge cases that, in hindsight, nobody needed. You know the drill.

The pattern is familiar: I imagine a problem, build a solution, then discover the problem was hypothetical all along. Meanwhile, the simple version would have been fine.

The fix is obvious. Talk to users before building. Ship the basic thing. See what actually breaks. I know this, and I keep forgetting anyway.

1/ Finally shipped that feature. Took way longer than it should have, and I know exactly why: I kept adding edge cases nobody asked for.

2/ Half the things I built solved hypothetical problems. The simple version would have been fine. Classic.

3/ Note to self: ship the basic thing first. See what actually breaks. Then fix that. In that order.

Shipped a feature this week that took twice as long as planned. Looking back, most of the extra time went to edge cases that never came up.

I kept imagining problems and building solutions for them. Turns out, most of those problems were hypothetical. The simple version would have worked just fine.

Lesson I keep relearning: ship the basic thing first, see what breaks, then fix that. Talk to users before building. I know this, and I keep forgetting anyway.

chat_session.md

User: Help me plan a product launch for next month

Agent: I can help with that. What’s the product and who’s your target audience?

User: It’s a productivity app for freelancers

Agent: Great. For freelancers, I’d suggest focusing on communities where they hang out: Twitter, indie hacker forums, and relevant Slack groups.

Agent: You’ll want a landing page ready 2 weeks before, early access signups, and a launch day thread. Want me to draft a timeline?

User: Yes please!

How to Launch a Product to Freelancers

Freelancers live on Twitter, in Slack communities, and on indie hacker forums. That’s where your launch needs to happen.

Start with a landing page two weeks before launch. Collect early access emails so you have an audience ready on day one.

On launch day, post a thread explaining what you built and why. Freelancers appreciate transparency about the journey.

The key: show up where your audience already is instead of waiting for them to find you.

Subject: The Freelancer Launch Playbook

Hey,

I’ve been planning a launch for a productivity app aimed at freelancers. Asked an AI to help me think through it. The conversation clarified a few things.

Freelancers spend time in specific corners of the internet: Twitter, Slack communities, indie hacker forums. That’s where the launch needs to happen. A landing page goes up two weeks before. Early access signups build the list. Then a launch day thread tells the story.

The thread matters. Freelancers want to know who built this and why. They respond to honesty about the journey, not polished marketing copy.

1/ Planning a launch for freelancers. Here’s the playbook I landed on after thinking it through.

2/ Freelancers hang out in specific places: Twitter, Slack communities, indie hacker forums. The launch happens there. Landing page two weeks early. Build the email list. Launch day thread.

3/ The thread matters most. Tell them who you are and why you built it. Freelancers respond to the real story.

I’ve been planning a product launch aimed at freelancers. After mapping it out, a few things became clear.

Freelancers spend their time in specific communities: Twitter, Slack groups, indie hacker forums. The launch strategy follows from that. Put up a landing page two weeks before. Collect early access emails. On launch day, post a thread explaining what you built and why.

The "why" matters. Freelancers respond to founders who share the real story behind the product. Polish matters less than honesty.

highlighted passage

Multi-vector search is more powerful because it uses more contextual data from the inputs. The architecture stores a separate embedding for each word in a document, rather than the traditional approach of storing an entire document (or chunk) in a single embedding. This gives multi-vector approaches a more detailed understanding of the content, but it also means there’s a lot more embeddings.

Generated Diagram

highlighted passage

RAG works by first taking the user’s query and searching through your document store. The retrieval system ranks documents by relevance, then feeds the top results to the LLM as context. This way the model can answer questions using your actual data instead of just its training knowledge.

Generated Diagram

Why I built this

I kept hitting the same wall: I’d finish recording a demo, have a great chat, or untangle a tricky logic problem. The hard work was done. The dopamine was there.

I knew I should turn that win into a blog post. Then format and insert screenshots. Then rewrite it for a Twitter thread. Then rewrite it again for LinkedIn. Then rewrite it again for my newsletter. Blech.

"I’ll write this up this weekend."

In reality, I’d just move on and lament my lack of discipline for not posting more content.

The problem wasn’t the idea or even the core material. It was the slog of reformatting stuff I already had.

The fix is Raw2Draft.

I realized the tedious part is just data transformation. The work is done, I just needed it shaped into something others could read. Mostly just style transfer, not creation.

That’s what this does. Dump in your rough notes or raw transcripts, and it extracts drafts that actually sound like you, formatted for the platforms where your friends are.

Review → Tweak → Publish

No more lost mental notes.

The hard part is having something to say.

You did that already. Now let’s get it published.

Stop starting. Start finishing.

Turn your next recording into 4 pieces of content.