Building a product for developers

I’m starting to work on a new product.

This one feels different. I’m a little scared. A little excited. A little unsure. More than I usually am when starting on a new product.

What’s different this time?

Building for developers is different.

The fact that this is my first product to be sold exclusively to a developer audience is one thing that’s new.

Talk about imposter syndrome.

I don’t know why, but even though I’ve been a professional developer (and designer) since 2005, somehow 20 years later I still feel like noob.

I never have chops as good as the next gal or guy. I never got my CS degree. There’s always a new technology or technique I haven’t learned yet.

But imposter syndrome comes with the territory. I can get over that, just like I have on all my products before.

It’s the approach that this product requires is what really feels different.

The Kool Aid strategy

If you’ve been hacking on bootstrapping software products in the past decade or so, then you’ve probably had the “MVP” mindset drilled into you, like I have.

Minimum viable product. Build something just barely good enough to test whether or not customers will pay. If not, ditch it and move on (a.k.a. “Fail fast!”).

But when it comes to building a product for developers, I think success hinges on… whatever the opposite of the MVP mindset is.

It has to be really good. Different. New. Opinionated. Immensely useful. It has to flip a thorny problem on its head and attack a solution in a novel way.

When I think about some of my favorite developer tools, they seemingly came out of nowhere. Because they did!

One person had an itch that they kept scratching and scratching until finally they ripped the wound wide open and screamed, “I’m fixing this once and for all!”

The best developer products don’t care about how other devs have always done it. This way is new and better. Get onboard or don’t.

The best developer products don’t need flaming hot marketing funnels. Their documentation (how it works) is all their idea needs to spread.

Like every great product, the best developer products feed off of customer feedback. But while most products for “normies” are happy to pivot to where their market takes them, developer products stay true to the founder’s vision and feed off the growing community of devs who drink the Kool Aid.

The obvious solution

This particular corner of the developer products ecosystem (by the way, it’s a components library for Ruby on Rails developers, with some twists) is a space where I play and build and itch every day.

As a designer turned full stack developer, I’m constantly frustrated by the overcomplication of software design.

As a result, I find myself building my apps and approaching my craft quite differently than many of my peers. I value readability, maintainability, flexibility, and simplicity over obsessive optimization.

It’s why I love the ethos of the Ruby programming language and Rails. It exists to make developers feel happy and creative in their craft.

But even the Rails ecosystem isn’t immune from the forces of over complication and abstracting away the things that make designing the web fun and productive.

I have ideas. Some of them seem obvious. We’ll see if my peers agree.

If I can gather the nerve to put it out there.