This is a guest post from Oscar Leche - a developer based in the Netherlands and currently working at Recharge.
I built Samio for my son.
Language didn't come easily to him. And because so much of early maths is really language, word problems, instructions, the vocabulary of comparison and sequence, his reading challenges spread into subjects that looked unrelated on the surface. We tried a lot of approaches at home. When I looked at what was available as software, I didn't like what I found: subscriptions for a child who might use the app twice, or free apps paid for by advertising aimed at six-year-olds. I wasn't willing to sign us up for either.
I'm a Staff Engineer by day, originally from Guatemala, now living in a small town outside Amsterdam. After enough evenings of trying other people's tools, I went back to the one thing I'm actually good at and started building.
The design followed directly from what he needed. Everything is read aloud, so a child who can't read yet, or reads slowly, can work independently instead of waiting for an adult. Difficulty follows demonstrated mastery, not age, because a child can be ahead in one area and behind in another and shouldn't be sorted by birthday. It works in the language the family actually speaks: ours moves between Spanish, Dutch and English. The app is a one time purchase of about a euro, no ads and no subscription, because a child who needs extra practice shouldn't be a recurring revenue stream.
I put it on the App Store so his cousins and my friends with children could install it. Then other parents bought it. With no ad budget at all, Samio reached #2 in paid Education on the Netherlands App Store, parents finding it and telling other parents. Then teachers started asking whether there was a classroom version. So I built that too.
I wrote every line of the platform myself, but Samio isn't a one-person story in every sense. My wife Olga is my co-founder. She ran the earliest versions with our children and told me plainly what wasn't working, and a lot of what changed between those first iterations and what shipped came from her. She runs the brand and social side of Samio. I build it.
What Samio is, and what people like about it
Samio is a learning app for children aged 4 to 12: phonics and reading, maths from counting through fractions, spelling and grammar, telling the time, science, physics, logic puzzles, and coding. Younger children snap blocks together to guide a robot through puzzles. Older ones read real Python and JavaScript to solve cases.
Three things come up again and again from parents and teachers.
It talks. Every menu, instruction and exercise is read aloud in the child's own language. That single decision is what lets pre-readers play independently, and it's what parents mention most.
It adapts to mastery, not age. Children move through a six-stage progression based on what they've demonstrated, not what birthday they've had.
It doesn't want anything from you. One purchase, no subscription, no ads, no in-app purchases, and it works offline: on a plane, in a car, or in a classroom with unreliable wifi.
It's live in seven languages with spoken guidance in each. Around it there's now a schools platform where teachers manage classes, assign work and track progress, running on the same codebase. That's where Expo stops being a convenience and becomes the reason any of this exists.
Why I chose Expo
The honest version: because I'm one person, and I'm not a native mobile developer.
My background is full-stack web. React, Node, MongoDB. If shipping to iOS and Android had meant Swift and Kotlin, two codebases, and my own build infrastructure, Samio would have stayed a project that ran on one tablet in my living room. That's not rhetoric. That's just the truth. I’m sure a lot of you can relate.
Expo removed the entire category of work I had no hours for. I've never had to work in Xcode. eas build produces the binaries across development, preview and production profiles, eas submit puts them in front of Apple and Google, and I go back to writing features. Signing, provisioning, certificates, build machines: I don’t think about any of that.
The second reason matters more as the product has grown. One codebase, five surfaces. The children's app runs on iOS and Android. The teacher dashboard runs in the browser from the same React Native codebase via react-native-web. For a solo developer selling into schools that's decisive. Schools run Chromebooks, iPads and whatever else is in the cupboard, and I can meet all of them without maintaining separate products.
Making one person move like a team
The app runs Expo SDK 55 on React Native 0.83 and React 19. Keeping a production app on recent versions is usually a team's job. With Expo's upgrade path it's something one person can actually keep up with.
Underneath that sits a real CI and test setup, which sounds absurd for a team of one and is exactly why I have one. Three Expo Build profiles (development, preview, production), Expo Submit to both stores, Jest with jest-expo and Testing Library for unit tests, and end-to-end flows in Maestro covering both the consumer app and the schools product. TypeScript throughout. The tests are what let me ship fast without breaking a product that children use in classrooms.
Then there's the daily friction. I wrote two development scripts, dev-ios.sh and dev-android.sh, that take "get this variant running on that device" down to one command. Both are variant-aware. They read the app name, slug and bundle identifier straight out of app.config.js, so --variant schools runs the teacher app instead of the children's one with no other changes.
On Android the script resolves the target device itself. It lists what adb can see, prefers a physically connected phone over a running emulator so plugging in a device just works, supports wireless debugging, and sets up adb reverse automatically so Metro is reachable from a real phone over USB. On iOS it queries simctl and picks the newest available iPhone simulator by parsing model numbers and tiers, so it keeps working as Xcode ships new hardware instead of breaking on a hardcoded device name.
Both have a --no-build fast path that skips compilation and just reinstalls and relaunches the existing binary. That's what I use most, because when you're testing on real classroom hardware you iterate on JavaScript far more often than you touch native code. They also clean the Gradle caches that quietly accumulate inside node_modules, which is several gigabytes if you leave them alone.
None of this is glamorous. But every one of those steps was a small tax I was paying multiple times a night, and removing them is a large part of why a person with a full-time job could ship this at all.
Releasing is one line:
That runs expo prebuild --clean for the right variant, injects the Firebase credentials from base64 env vars so nothing sensitive lives in the repo, reads the current version state from Expo with build:version:get, patches Info.plist and build.gradle to match, builds locally with eas build --local, submits with eas submit, and then writes the incremented version back into the correct variant block of app.config.js so the next build starts from the right number. It cleans the Metro and Gradle caches on the way out.
Getting there took some care. Expo's local build plugin occasionally exits non-zero on a temp-directory cleanup issue even when the artifact is fine, so the script checks for the output file rather than trusting the exit code. But the result is that shipping either app to either store is a single line I can run at 11 pm without thinking about it. For one person maintaining four store listings, that's the difference between shipping monthly and shipping weekly.
Five surfaces, one place to fix a bug
The children's app and “Samio for Schools” ship as separate listings on both stores, but they're the same repository. A dynamic app.config.js keyed on an APP_VARIANT switch resolves the slug, bundle IDs, icons, splash screens, and Firebase configuration per variant, with matching Expo Build profiles for each. The teacher dashboard is the same codebase again via react-native-web.
That's the children's app on iOS and Android, the schools app on iOS and Android, and the web dashboard. Five surfaces, one place to fix a bug.
Assets are the one place I pay for that. Children look at these screens for hours, so the illustrations and audio are kept at full quality in the repo and compressed as part of the build rather than degraded at source. The trade-off is a heavy project: 300+ hand-styled illustrations plus pre-recorded voice audio in seven languages. That's why I moved from Expo Build cloud builds to eas build --local. The upload became impractical, but the pipeline didn't change at all. Same Expo commands, same profiles, same submit step. It just runs on my machine now.
The parts that were actually hard
Everything above is plumbing. These are the problems I spent real evenings on.
Audio-first design. The voice layer uses expo-audio alongside react-native-audio-api, with pre-recorded natural voices rather than device TTS, so pronunciation is right in every language. Keeping audio, text, and interaction in sync across seven locales, and working offline, was the hardest interaction problem in the app and the part I'm proudest of.
Letter tracing with real feedback. Children trace letters with a finger and get per-letter, per-stroke validation, so the app distinguishes a correctly formed letter from a shape that merely looks similar. Built on react-native-svg with react-native-gesture-handler.
A drawing studio that feels native. Creative Studio does pinch-to-zoom, pan, and a full tool palette using react-native-reanimated with worklets, plus react-native-view-shot so children can save and share what they make.
Offline-first. react-native-mmkv for fast local persistence and expo-file-system for assets, so exercises and the coding module work with no connection at all. Schools were the forcing function. You cannot depend on classroom wifi.
If you're the only developer on your product
I built Samio by myself in the evenings and now the apps are used in schools in the Netherlands, the United States and Guatemala. Ten years ago that would have required a full team. The tooling is just so good now, you can go really far on your own with Expo.
If you have an idea for an app and want to get it to the stores I think you should consider these three decisions:
- Use a single codebase across iOS, Android and web from day one, rather than porting later.
- Put the release pipeline in a script before you need it, so shipping never competes with building.
- Write the end-to-end tests, even alone. They're what let you ship on a weeknight.
If you're starting something like this, create an Expo account and run your first eas build. It takes about the length of a coffee. And if you want to see what Samio turned into, it's on the App Store and Google Play.
