inkOrange Studios: Building a Suite of Science Apps as a Studio of One

The problem

I've had more ideas for science apps than one person could ever build. A planet you can shape and watch evolve over billions of years. A 3D solar system with real orbital mechanics. A chemistry set where you snap atoms together and an AI tutor explains what just happened. For most of my career, each of those would have needed a team, and I had a full-time job.

inkOrange Studios is how I stopped treating them as someday projects. It's my independent studio for educational and science software, and it runs on one idea: if every app shares the same foundation and the same way of working, one person directing AI agents can build and run a whole suite.

My role

I'm the founder and the only full-time person in the studio. I design the products, write the design documents (including gameplay design for games), do the visual and graphic design down to the logos, and direct the agentic development that builds them. On games, a few collaborators help build out gameplay. Everything else, from the product idea to the deploy, runs through me.

The suite

• TerraForge: a procedural planet builder grounded in NASA exoplanet data, the studio's flagship.
• Exoplanet Explorer: a native Android app that extends TerraForge (pre-release).
• Strata: a 3D earth science tool built to replace outdated classroom interactives.
• Molecular: a 3D chemistry tutor with an AI tutor built in.
• Solar System Propulsion Simulator: real orbital mechanics from NASA ephemeris data.
• Mission Control: a browser rocket-building game that teaches orbital mechanics.
• PitchTracker: 3D MLB pitch trajectories with a natural-language AI layer.
• SpaceUI: the open-source design system underneath the space apps.

Key decisions

Every app starts ahead. New projects don't start from a blank repo. They start on the same stack (Next.js, Three.js, Supabase, and Vercel), share accounts and infrastructure where it makes sense, and pull their interface from SpaceUI. That last one came straight out of TerraForge: once I had a second space app, I extracted the UI into a design system so every app after it would look like part of the same family and none would rebuild a button. It's the same thing I do for teams at work, applied to a studio of one.

Design first, then let the agents build. I run a plan-then-implement workflow with Claude Code. Each project starts with a design document I write: what it teaches, how it plays, what it should feel like. From there the work is broken into a plan, the agent implements it in steps, and I review every step before it lands. The design doc is what keeps an app coherent across many agent sessions.

Run agents in parallel, but never unsupervised. With several apps live at once, I often have multiple agent sessions working on different projects or tasks at the same time. That only works because tests, linting, and performance checks act as guardrails. On the 3D apps, frame rate is one of those checks. Agents are fast, and guardrails are what make fast safe.

Let agents run the studio, too. Building is only half the job. Agents also handle recurring work that would otherwise eat my evenings. TerraForge publishes a weekly Planet of the Week chosen and written by a scheduled agent task, and PitchTracker's highlights and weekly leaderboards are posted to X on a schedule. Promotion posts for launches are drafted by agents too. I review what goes out, and the agents do the repetitive part.

Pick the next app on purpose. I decide what to build next three ways: ideas I've wanted to build for years, what existing users ask for, and spinoffs from what's already working. Exoplanet Explorer exists because TerraForge found an audience. More control over planets is next because TerraForge's users keep asking for it.

What happened

• A suite of live science and education apps, all designed and directed by one person.
• TerraForge alone serves 6,000 to 7,000 people a day, with 250+ planets created daily, and the rest of the suite and my site add about 1,000 more visits a day.
• SpaceUI, extracted along the way, is an open-source package with 1,000+ npm downloads a month.
• A mobile app and native app-store presence are in development.

What I'd do next

The studio's next step is reach. The apps work on the web; now they need to be where people look for them, which means finishing the mobile app and building a real presence in the app stores. Underneath that, I want each new app to take less time to start than the last, by moving more of what the suite shares into SpaceUI and into reusable agent skills.