From one idea to
twelve apps.

My original plan was simple: build 100 Animals in multiple languages. That was it. One app, several versions. Nothing more ambitious than that.

Then I started asking the wrong question (the best kind). What if the structure I built for the first app could power a completely different one? What if iteration meant adding a column to a table instead of starting over?

I was building alone. No engineering team, no budget for one. The only way to scale was to make the architecture do the work.

So before I designed a single screen, I designed the data structure. That decision is why 12 apps exist instead of 3.

Parents using 100 Animals started saying things like: "my kid is learning a language." And I thought: no, they are not.

Knowing the word for capybara in Portuguese is not language learning. Capivara. Great word. Completely useless unless you are standing in a South American wetland. You need vocabulary in categories. Body parts. Food. Clothes. Words you actually use every day.

It required some additions to the database structure so that each app sees only what it needs.

I reused the Animals category and built five more around it: Food, Body, Vehicles, Toys, and Clothes. 6 categories, 25 words each, 6 languages. Same Airtable foundation. New content, new images, new audio. That became My First 150 Words.

That is when I understood what I had actually built. Not just an app, but a building system: a Figma component library for screens and launch videos, and an Airtable database where adding a new language meant adding columns, not rebuilding anything. Still manual. But fast.

The constraint made the method.

Building alone, without code, with limited time forced a discipline a bigger team might never have needed. Design the data structure first. Make sure each version takes a fraction of the time of the one before it.

Every hour I saved on the second app I invested in the next. Every pattern I reused freed up attention for the part that actually needed solving.

That is the principle I now teach: the first product is the template. Build it like one.

The intention behind all of this has not changed. If kids are going to have screens anyway, the screen should earn its place. These apps were built to support early literacy: learning to read, to speak, to understand.

The design choice to show both a simplified illustration and a real photograph of the same object is deliberate. Children learn through abstraction and recognition together. Simple icon, real image, real voice, real word. That is the whole experience.

This was built to be played alone or with a parent. Both work. Both matter.

The next version of these apps will be built with AI-assisted code. That means offline functionality, more interaction possibilities, better performance. No platform constraints in the way.

The asset pipeline could change too. Synthetic voice in any language, no voice actors required. AI-generated icons and images, possibly. Prompting to get the right result takes its own kind of time, and there is something worth keeping about crediting real photographers and artists. The Unsplash images in these apps each have a human behind them. That feels right for a product designed for children.

The honest trade-off: no-code is still better for design fidelity right now. I have tried building with AI-generated code and the tools are not yet able to receive design decisions at the level I work at. Pixel precision is still easier with no-code. That will change. The tools are catching up. But I will not ship a version I am not happy with just because the technology is available.

There is more to build here. AI makes the scope of what one person can create for children much larger. I intend to use it that way.