Dog fooding and vibe coding

Every few weeks, I'm on support at Plain. We always rota one technical person + one non-technical person. We answer questions, help people get unstuck, deal with bugs. But more than that, we're actually using the product we built. Not just testing it, but living in it like real users.

And with that comes spotting all the tiny papercuts: UI nits, copy that feels off, workflow gaps, oversights where we just missed something.

Here's what usually happens: I'd create a ticket in Linear or drop a message in Slack, hoping someone from engineering would pick it up. Most never get fixed. Not because we don't care, we do, a lot. But, because bigger work always wins the prioritization fight.

This week, I tried something different: What if I just fixed them instead of logging them?

The experiment

I fired up Cursor and started working through issues as I found them:

• Added a keyboard shortcut to Escalations (and updated our shortcuts cheat sheet).
• Made our links actually look like links.
• Added the Teams icon as an option for Views. Something we'd simply missed.
• Adjusted main nav items so they feel like main navigation.
• Fixed inline code blocks so the monospace font aligns nicely with our body text.
• Updated icons and copy to make settings easier to navigate. Fixed cursor types that were just wrong for the content you were interacting with.

None would survive a prioritization matrix or even a luke warm discussion about what we should work on. But done in the moment? Quick, painless wins that made the product immediately better.

The real problem isn't capability

Here's my take: Most people are underselling themselves.

You don't need to be "technical" to fix most quality issues. Tools like Cursor mean almost anyone can jump in and handle small improvements. The barrier isn't skill, it's habit.

We've trained ourselves to be problem reporters instead of problem solvers. See an issue? Log it. Hope someone else fixes it. Move on. But that someone else is drowning in bigger priorities, so your small fix dies in a backlog somewhere.

Quality isn't a just design problem or an engineering problem. It's a complacency problem.

Everyone using the product sees the rough edges. Some even raise them. Almost nobody fixes them. We've created a culture where logging problems feels like solving them.

##Making it a habit This isn't about shipping features during support rotations. It's about tiny, obvious improvements that compound over time. Each fix is maybe 1% better. Done consistently over a year, they raise baseline quality in ways no roadmap item ever could.

Here's what worked:

1. Fix in the moment. When you spot something that bugs you, don't log it. Fix it if you can. The context switch of "I'll do this later" means most small items often never get logged let alone fixed.
2. Keep a running list. Not for planning meetings, but for focus. When you have 20 minutes between what you're doing, having fixes ready means you'll actually use that time.
3. Stay small. The moment you're building new features instead of polishing existing ones, you've probably gone too far.

The compound effect of everyone who regularly uses the product actually fixing what they find? That's how you build something that feels great, not just functional.