This is how I start a new project in Expo (maybe you’ll like it too)

I build a lot of React Native apps, and sometimes I switch between three or four of them in a single day. Every one of them used to start the same way: spend two or three days (sometimes more) getting the basic shape before writing anything real. Routing, auth, API layer, types, error handling, theme, responsive UI. None of it is hard, but it's slow, and every project came out slightly different. So I made a template, expo-starter-pack, and most of my apps now start from it. The whole idea is this: you clone it, set the environment and project config by following the instructions, and you start coding. That's it. Nothing else stands between you and the actual app. What's already configured Typing. an openapi-fetch client with request and response types generated from the OpenAPI spec. No more typing by hand. Data layer. TanStack Query with a resource-based custom hook pattern, plus shared conventions and helpers (response unwrapping, pagination, error handling) already wired into the app. Global error handling and logging. One error type, one error store and toasts, with per-request flags to opt out. Auth and role-based routing. Public, auth-protected, and dashboard groups for role-based navigation, all configured and structured to expand. Theme and UI kit. A global theme with dark and light mode, plus a small responsive UI library built on react-native-size-matters. A mock server. A local mock backend generated from the OpenAPI contract, so you can build and test screens, including login and the dashboard, before the real backend exists. You write code into the architecture instead of spending days building it. Why architecture matters more later Architecture doesn't look like a big deal while you're building because you're moving fast and everything is fresh. It gets painful when you start maintaining. Say you open an app six months from now to fix an error. If everything lives in a known place, you go straight to where the fix belongs. If every project was set up differently, you spend the first hour playing hide and seek with some random decisions that you, your AI agent, or your dev buddy made six months ago and nobody remembers. Who wrote this? Why is it done like this? Where does this call even go? The same thing happens when the backend developer changes a key without telling anyone. In a large app with no clear structure, you end up running around a pile of API layers, interfaces, and clients, trying to work out what's going to break. With one typed client and a generated schema, I re-run one command and TypeScript points at every call that no longer matches. For me it's a defined grid. Most of my projects use the same one (a few with unusual requirements are the exception), so every app is built the same way. I switch between apps all day, and I can open any of them and already know where things are. The small conveniences The mock server is the one I like most. You build your screens against it without waiting for the real backend or hardcoding some static mess. It's like having the tools laid out before you start painting. The theme and the small UI library work the same way, none of that is a headache anymore. I figure we developers often run into similar problems, so other people might find it useful too. How I use it gh repo create my-app --template amirazerani-gif/expo-starter-pack --clone --private Then I follow the README: set the env and config, point it at my API (or the mock), regenerate the types, and replace the demo resources with my real ones. Then I start coding. Before you use it It's opinionated. It assumes a Laravel-style JSON API, because that's what most of my backends look like. If yours differs, no worries, the README lists the files to change. It's on Expo SDK 57 right now, and SDK 58 is on the way. Free and MIT licensed: github.com/amirazerani-gif/expo-starter-pack If you end up using it, let me know how it goes. Open an issue, drop a comment, or leave a star if you liked it.