Why I picked Expo for SpecStream

I am building SpecStream with Expo, and this is not a random experiment.

I already know this stack well. I have been working with React Native and Expo for years, and I have enough experience with both to say confidently that Expo is a very good solution for this kind of project.

That choice is not accidental, and it is not because I wanted the trendiest stack.

I picked Expo because I want to move toward three platforms at once: web, iOS, and Android, without creating three different product stories too early.

Why Expo makes sense here #

I already know React Native well, and I know how Expo behaves in real projects. That matters.

When I am exploring a product idea, I do not want to spend my energy fighting tooling just to prove that I can wire everything manually. I want to move fast, keep the code understandable, and still have a path to grow.

Expo gives me that.

The web story is also much more interesting now than it used to be.

Expo is no longer only “that thing for mobile prototypes”. It is getting closer to what people expect from serious full-platform frameworks: better routing, better platform convergence, better deployment tooling, and a much more practical story for shipping across surfaces.

No, it is not Next.js, and I do not need it to be.

But it is close enough in spirit that it becomes a very strong option when the same product needs to exist on mobile and web without splitting the team and the codebase too early.

Why this matters for SpecStream specifically #

SpecStream is exactly the kind of project where I want flexibility from day one.

I can see this idea living in the browser. I can also see it needing mobile access. I do not want to lock the product into one surface too early and then pay the rewrite tax later.

Expo lets me explore that product shape in a pragmatic way.

Also, the update story matters a lot.

Expo makes shipping and iterating much easier, and that is a real advantage when the product is still evolving. On top of that, Expo Application Services gives me a clean path for deployment and CI management, which is another reason I think it fits this stage very well.

The foundation I am using right now #

At this stage, I am intentionally keeping the stack focused.

• Expo because I want one strong cross-platform foundation.
• React Native because I know the framework well and trust its compositional model.
• NativeWind because I think it is stable enough now, and I like where the ecosystem is going.
• TanStack because I increasingly prefer that style of data handling over forcing everything into classic state-management habits.
• Jotai because I like its atom-based dependency graph much more for UI state, and I think it leads to fewer accidental re-render problems than heavier global-store approaches.
• Hotwire-inspired ideas and other pieces I will share later as the project grows.

The important point is not “look at this shiny stack”.

The point is that these choices give me reusable components, flexible UI composition, and enough abstraction power to keep the app clean without turning it into architectural theater.

Why NativeWind is in the mix #

I find NativeWind especially interesting for this project because I want speed, consistency, and reusable primitives without turning styling into a pile of inline objects and duplicated tokens.

I think it has crossed the line from “experimental curiosity” to “stable enough for a serious project like this”.

That does not mean it is perfect. It means the trade-off is now worth it.

Why I also like Jotai here #

For local and shared UI state, I find Jotai more natural than the usual “everything goes into one central store” mindset.

Its atom model fits very well with React because state dependencies stay much closer to the components that actually use them.

That usually leads to a better mental model and, in practice, helps avoid a lot of the common re-render mistakes teams run into with broader subscription patterns.

I am not saying other libraries are bad. Zustand, for example, is useful and popular for a reason.

But for this project, I prefer Jotai’s dependency-graph approach. It feels more precise, more composable, and more aligned with the kind of flexibility I want as SpecStream grows.

My opinionated take #

If I were building a pure web product with no serious mobile ambition, I would not automatically pick Expo.

But for something like SpecStream, where I want the option to grow across web, iOS, and Android from the same product direction, Expo is a very rational choice.

I would rather start from a framework I know deeply, with a deployment story I already trust, than burn time assembling a more fragmented setup just because it sounds more “custom”.

Too many teams confuse optional complexity with technical maturity.

I do not.

Right now I care more about shipping a clear product foundation than proving how many tools I can glue together.

More later #

This is only the beginning of the stack story.

I wanted to share the direction early because these foundation choices shape how the product evolves, but I will reveal more of the architecture, libraries, and trade-offs as SpecStream grows.