The road expands before me

Is a never-ending roadmap a prioritization problem? Or a sales problem?

Credit to Aaron Francis for this one. He said it on a recent podcast episode and it really stuck with me. He was talking about his business that no matter how much he gets done there’s always more to do.

I’m feeling the same with Ruby Native right now.

Ruby Native is my productized serve that gets your Rails business into the app stores without a single line of native code.

Aaron’s point is that the list of things to build never ends. But the part he didn’t get into is that reaching the end was never the goal. Knowing what to skip is.

Last week I signed a Concierge client to take their Rails website to mobile. I’m in charge of everything, from setting up Ruby Native to tweaking their design to work better on mobile, to adding native components when it makes sense, to submitting to the App Store and dealing with App Store review. Essentially, they are paying me to do 100% of the “get us in the App Store” work.

This isn’t too different than what I’ve been doing for 6+ years for Hotwire Native. With those clients, they’d have the exact same need: get in the App Store. But back then, every single client was a unique, bespoke build. If they wanted specific native components, then those would be built on the fly, just for them.

Sometimes I could abstract or borrow from my bridge component library, but oftentimes they were just different enough that I had to build something from scratch. But as always, the code was never the hard part. It’s always about the other stuff: what to build, where to integrate it, and how to get it live (App Store approval is still no joke!).

Seeing this client go through the process, and me slowly tweaking their app to look and feel better (which I can’t wait to share as a case study when they go live!), has expanded the Ruby Native roadmap even more. From just three days of working with them I’ve noticed some common patterns that would make their app feel so much more native. And could easily be abstracted to work with other customer apps.

But every one of those patterns I abstract is one more thing to build. As I work with more folks, and as more developers get their hands on the Ruby Native apps, the feature requests and obvious niceties are growing. My public roadmap hasn’t shrunk since I announced it. 😅

There’s a point where Ruby Native can do almost the entire native stack, entirely driven by HTML. The decision stops being “is this custom enough to go Hotwire Native?” and becomes, just go Ruby Native, it will (almost) always be enough.

And maybe that’s OK! Sure, it gives me a bit of anxiety to never close out a todo list. But it also means there’s always something new and exciting to work on. And with AI? It makes the what even more important. I could technically build every little thing a (potential) customer asks for. But at what point does it start to dilute the primary purpose of Ruby Native? At what point does it become such a complicated tool that it’s hard to add new code? Or worse, that it becomes confusing to the developer trying to build with it?

That’s a tough call. And a lot of folks online will say it’s where someone’s taste comes into play.

I like that word, but I also think it’s a bit loaded. I prefer to think of it as a solid product vision. Knowing exactly what your product or service does is almost as important as actually doing it. For me, that means having a north star that I build everything around: making it easier for Rails developers to get in the app stores.

Following this for every new feature almost makes the decisions easier. Someone recently asked if Ruby Native could be a package, like Hotwire Native, that you drop into your own codebase. It’s a fair question, but it runs against the whole point of Ruby Native: I never want a Rails developer to have to touch native code.

But a new API just dropped on iOS that makes it easier to do something? Obvious yes! Wire it up to some HTML-powered API and boom, every Ruby Native developer gets it for free the next time they deploy.

Perhaps the expanding road isn’t the problem I made it out to be. The north star doesn’t make the list shorter, it tells me which items to ignore. And that, as a solo-run business, is the most important thing.

But there’s one question the north star can’t answer. Building new features doesn’t bring in customers. I know this and every developer “knows” this. The north star tells me what to build, but it can’t tell me when to build it. Or when to write a case study, or when to do cold outreach, or when to start paid advertising, or... well you get the idea: sales and marketing!

So, if the road expands before me, is that good? Is that bad?

If you know, please tell me. Because I sure don’t know yet!