Here's a scene that plays out a thousand times a day, all over the world. A developer is standing at a playground. Their kid is on the swings. And in that exact moment, the fix to a bug they've been chasing for two days crystallizes in their head. Three lines. They can see the file. They can see the function. The solution is right there.
They pull out their phone. They open a notes app. They type something like fix null check in UserList line 47. They tell themselves they'll remember the context when they get home.
They won't. Nobody ever does.
The Idea Graveyard
Every developer has one. It's the folder in your notes app filled with half-thoughts, pseudocode, and architecture sketches drawn in plaintext. It sits between your grocery list and a phone number you don't recognize. Most of it will never become code.
This is the gap. Not a technology gap. A timing gap. The moment you have the idea is not the moment you have the tools. And by the time you have the tools, you no longer have the idea.
We lived in this gap for years. We kept thinking someone would build the tool that closed it. Nobody did.
Everything That Exists Is Wrong
That's a strong claim. Let me defend it.
We tried every mobile code editor on every app store. They all fall into one of two traps:
Trap 1: The toy editor. It gives you syntax highlighting and a file tree. Maybe a dark theme. You can look at code, and technically you can edit it. But you can't run it. You can't test it. You can't git push it. It's a text editor wearing an IDE costume. It's like giving someone a steering wheel and calling it a car.
Trap 2: The SSH tunnel. It gives you a full Linux environment through an SSH client or browser-based terminal. This actually works — if you have a 27-inch monitor. On a phone, it's a 9-point font on a 6-inch screen. No file tree. No code intelligence. No way to see your code and terminal at the same time. It's a desktop experience crammed into a phone and it's miserable.
Both traps share the same root cause: the builders started with an existing paradigm and tried to shrink it. Nobody started from the question that actually matters.
The Answer Is Four Things
When we stripped away assumptions and asked what a developer genuinely needs to go from idea to deployed code, the list was surprisingly short:
1. A real editor. Not a textarea. Monaco — the same engine inside VS Code. Syntax highlighting, multi-cursor, find-and-replace, minimap, code folding. The phone keyboard is bad enough. The editor has to be flawless.
2. A real terminal. Not a simulation. A Linux container with bash, where npm install actually installs packages, node server.js actually starts a server, and python3 test.py actually runs Python. If you can't run your code, you can't ship your code.
3. Real Git. Clone, branch, stage, commit, push. Not through CLI-only (though that works too) — through a visual interface designed for thumbs. Stage a file with a tap. See your diff. Write a commit message. Push to main.
4. An AI that does the typing. This is the insight that changed everything. On a phone, your bottleneck isn't your brain. It's your keyboard. You can architect a system in your head just as easily at a playground as at a desk. What you can't do is type 200 lines of boilerplate with your thumbs. So don't. Tell an AI agent what you want and let it write the code, run the tests, and fix the errors. You do the thinking. It does the typing.
The Expensive Decision That Made It Real
Here's where we had to make a hard call. The architecture decision that made PropelCode actually work is also the one that makes it expensive to operate.
Every user gets their own Linux container.
Not a shared sandbox. Not a simulated environment. A real, isolated container running Node.js 22 on Railway, with its own filesystem, its own processes, its own network stack. When you open the terminal in PropelCode, you're connected to a real Linux machine over WebSocket. You can install anything. You can run anything. Because it's real.
This decision is operationally complex. Every new signup means a new container to provision and manage. But there's no way around it. If you want npm start to actually start a server, you need a real server. Sandboxes can't do that. Simulations can't do that. Only a container can.
The AI Agent Changes the Physics
Mobile development has a physics problem. The input bandwidth on a phone is roughly 40 words per minute. On a laptop with a keyboard, it's 80-120. You're working at half speed or worse. That math doesn't work for writing code.
Unless you change who does the writing.
The PropelCode AI agent isn't autocomplete. It's a collaborator that operates inside your container. You say: "Add a /users endpoint that returns paginated results with filtering by role." The agent reads your codebase, understands your patterns, creates the file, writes the function, adds error handling, and runs the tests. You review the diff and tap approve.
When something breaks, the agent reads the terminal output, identifies the error, finds the relevant file, proposes a fix, and applies it when you approve. The whole cycle — error, diagnosis, fix, verification — takes seconds.
This isn't about replacing developers. Kevin Hale talks about how the best products make their users feel smart. That's exactly what happens when you describe a feature in plain language and watch it materialize in real code, running in a real container, on your phone. You feel like you have superpowers.
The Product You Build When You're the User
Here's the thing about PropelCode that's different from most developer tools: we don't use it because we built it. We built it because we needed it. Every feature exists because we ran into its absence while trying to code on our phones.
The swipeable three-panel layout? That exists because we tried split-screen on a phone and it was unusable. The smart toolbar with coding characters? That exists because typing { } => || on a phone keyboard is infuriating. The AI-generated commit messages? That exists because writing meaningful commit messages with your thumbs is slow enough to break your flow.
Every decision came from the same place: personal frustration, solved with the simplest thing that could work.
That's why we built PropelCode. Not because the world needed another IDE. Because developers needed the ability to ship code from anywhere, and nobody was giving it to them.
The playground. The bus. The waiting room. 2 AM when you can't sleep and the architecture for that new feature suddenly makes perfect sense. Those moments matter. And now there's a tool that lets you act on them.