From RockoAI to RepoGo: Building the Product I Wanted to Use

RepoGo did not begin as a mobile IDE.

It began as RockoAI, a vibe-coding project I started in the spring of 2025. At the time, AI application builders were taking off. Lovable, Bolt, and v0 were showing how quickly an idea could become a working interface, and I wanted to explore that space for myself.

RockoAI became a real product surprisingly fast. It had AI chat, a code editor, a file browser, live application previews, project generation, authentication, subscriptions, and hosted development environments. It could take a prompt and turn it into an application.

Technically, it worked. That did not mean I had found the right product.

The difficult economics of vibe coding#

The first problem was not whether I could build RockoAI. It was whether I could turn it into a sustainable business.

Every generated application came with real costs. Model tokens cost money. Sandbox compute cost money. Storage, builds, and streaming infrastructure cost money. I kept returning to the same question: what could I honestly include in a $20 subscription without losing money?

That question became harder when I looked at the companies I would be competing against. The largest AI companies could subsidize usage, bundle their own models, and spread infrastructure costs across enormous businesses. Other vibe-coding products had raised significant capital and were moving quickly.

As a solo developer, I could build the experience. I could not pretend the economics were the same.

I tried to find a better angle inside the same world.

One prompt, multiple models#

One of those experiments was a multi-model code-generation benchmark.

You could enter one prompt, send it to several models at the same time, and watch each model build its version in parallel. Every result had its own live preview, which made the differences immediately visible. It was not a benchmark made from abstract scores. You could see which model actually produced the better application.

The most important part was how access worked. Users could bring their own model access through Vercel AI Gateway and OpenRouter. I did not need to hide an unpredictable token bill inside a flat subscription, and developers could use the providers they already preferred.

That idea would later become much more important to RepoGo.

Around the same time, I also built an Open Graph image generator using Vercel OG. It gave you a real-time preview of the generated graphic in the browser and let you shape the image visually instead of repeatedly changing code and refreshing a route.

Both tools were useful. Both were interesting to build. Neither answered the more important question.

Would I keep using this myself?

The honest answer was no.

That realization is uncomfortable when a product already works. It is tempting to confuse the amount of effort invested with evidence that the idea deserves more effort. But I did not want to spend years convincing myself to use my own product.

So I stopped.

Repos on your phone#

The pivot to RepoGo started with a much simpler idea: repos on your phone.

I wanted to explore a part of developer tooling that still felt open. What would coding look like if the phone were treated as a real development surface instead of a place to approve a pull request or glance at a deployment?

I had experienced the moments this could serve. An idea arrives while you are away from your desk. A small bug needs attention. An agent finishes a task and you want to review the changes. You want to keep working from the couch, a coffee shop, or anywhere else without opening a laptop.

The phone was always with me, but my development environment was not.

That was a product I could imagine using.

RepoGo initially focused on making repositories accessible on iPhone: browse files, edit code, work with Git, talk to an AI agent, and preview the result. It was a narrower idea than RockoAI, but it was pointed at a problem I actually felt.

Then the idea kept expanding.

The agents arrived earlier than I remembered#

When I first tried to reconstruct RepoGo's history from memory, I associated the multi-agent work with the native Swift rewrite in March 2026. The Git history tells a slightly different story.

RepoGo had background-agent interfaces by early January. On January 22, I committed a sandbox agent layer that could install, configure, and run Claude Code, Codex, Cursor, GitHub Copilot, and Gemini against a project. The implementations already accounted for provider-specific models, credentials, resumable sessions, MCP servers, and command execution.

Within days, RepoGo also had an agent-selection screen on mobile. I was building stream transformers and tool mappings so output from different CLIs could be presented as one coherent chat experience. Some of that early work was rolled back and simplified before being rebuilt, but the product direction was already clear: RepoGo would not be tied to a single AI provider.

March is still an important marker. That is when agent chat, model selection, message rendering, and the rest of the mobile experience began moving into the native Swift application. The idea did not begin in March; it became part of the new native foundation in March.

That distinction matters because multi-agent support was not a feature added after RepoGo became a mobile IDE. It was part of the product's identity before the largest technical rewrite began.

A mobile app became a workspace#

It became clear that mobile coding could not be solved by shrinking a desktop editor onto a smaller screen.

A phone has different constraints, different interactions, and different strengths. Navigation has to be touch-first. Context switching has to be deliberate. The editor, chat, terminal, browser, simulator, and file tree all have to share limited space without making the experience feel like a cramped desktop imitation.

RepoGo began in Expo, which let me move quickly and reuse what I already knew. As the product grew, however, I kept running into the edges of what I wanted the experience to feel like. In March 2026, I committed to rebuilding the iPhone app natively in Swift.

That was not a cosmetic rewrite. It changed how I thought about the entire product.

The core abstraction became the workspace. A workspace might be a repository running directly on the iPhone, a project on a Mac, or a remote environment in the cloud. The interface should not need to care where it lives. It should be able to open files, run commands, inspect Git changes, talk to agents, and show previews through the same set of capabilities.

RepoGo Host grew out of that idea, giving the iPhone a secure connection to the development environment on a Mac. Remote environments followed the same model. The project evolved from “repos on your phone” into a distributed coding workspace that could follow you across devices.

That architecture took far more work than the original pitch suggested. File events had to remain consistent. Agent output had to survive disconnects. A terminal could be running on a Mac while its interface was on an iPhone. A preview might be produced in a cloud workspace, routed through another service, and displayed on a device that had just returned from the background. Commands, previews, terminals, and Git state all had to move between devices without making the user think about the transport underneath them.

Over time, the product gained a native editor, terminal sessions, live browser previews, simulator access, background agents, durable chat, device pairing, on-device repositories, and remote workspaces.

The simple mobile app had become a system.

Making unreliable devices feel like one workspace#

In the spring of 2026, much of my attention moved below the interface.

The iPhone, Mac host, cloud environments, web client, and backend needed a shared language. I worked through typed RPC contracts, bidirectional gRPC streams, WebSockets, and eventually a persistent TLS transport with durable, ordered delivery.

This was not technology switching for its own sake. RepoGo had several different communication problems hiding behind one interface:

Reading a file or checking Git status behaves like a normal request.
Terminal output and agent responses are continuous streams.
Presence and live logs are temporary.
File changes, agent turns, and approvals may need to survive a disconnect.

The hardest question was no longer, “Can an iPhone edit code?” It was, “Can several unreliable devices and execution environments behave like one coherent workspace?”

Solving that required device authentication, secure pairing, presence, reconnection, ordering, replay, and clear ownership of state. The infrastructure became much larger than the screen a user could see.

That invisible complexity is now one of RepoGo's most important pieces. The interface can stay simple precisely because the workspace underneath it knows how to reconnect and continue.

The business model shaped the agent architecture#

The product had changed, but the business question from RockoAI had not disappeared.

How do you create an attractive, profitable offer for developers when the AI companies themselves are subsidizing usage inside tools like Claude Code and Codex?

If RepoGo paid retail model prices and resold every token inside a subscription, I would be back in the same position as before: promising predictable pricing on top of unpredictable costs while competing with the companies that own the models.

The answer was already hiding inside the RockoAI benchmark.

Instead of forcing developers to buy another pool of AI credits, RepoGo could connect to the coding agents they already use. The early CLI-agent experiments gave that idea a concrete form, and the economics gave me a reason to make it central.

Today, Claude Code, Codex, Cursor, and GitHub Copilot are first-class coding agents in RepoGo. Developers can use their existing subscriptions and credentials while RepoGo provides the mobile interface, workspace, connectivity, approvals, and continuity around those agents.

This is more than a billing decision. It is also a product decision.

Developers have preferences. They trust different agents for different kinds of work, and those preferences change quickly. RepoGo does not need to declare one model the permanent winner. It can become the place where the tools a developer already chose remain available when they leave their desk.

Voice is another way into the workspace#

As the agent system matured, voice became another interface to the same workspace rather than a separate product.

A voice agent should not only answer questions. It should be able to inspect a repository, start a service, run a command, modify a file, and explain what happened. Those actions need the same tools, permissions, approvals, and history as a typed conversation.

That led me to experiment with real-time voice models and a provider-neutral tool layer. A fast voice model can handle the conversation while a stronger model validates intent or fills in exact parameters before a sensitive tool is run. The person remains in control, but the interface no longer has to begin with a keyboard.

The broader lesson is that agents should not be trapped inside one chat window. The workspace is the durable object. Chat, voice, the iPhone, the web, and the Mac are different ways to reach it.

Following the product instead of the original idea#

Looking back, the path from RockoAI to RepoGo does not feel like a clean series of startup pivots. It feels more like following a signal.

RockoAI taught me how much infrastructure sits behind the apparent magic of generating an application. The benchmark taught me that developers wanted choice and that bringing existing model access could produce healthier economics. The Open Graph generator reminded me that a technically satisfying tool is not automatically a product I want to pursue.

RepoGo brought those lessons together around a problem that felt personal.

The code history reflects that evolution. The first RockoAI repository appeared in April 2025. By October, much of that foundation had moved into the first RepoGo monorepo. By January 2026, RepoGo was already experimenting with several CLI coding agents. March brought the move to native Swift. May and June brought the Mac host, remote procedure calls, device pairing, and the persistent TLS transport the whole system now centers on. In July, those pieces were consolidated into the current RepoGo codebase.

The names and repositories changed, but this was not a restart. Each version carried useful parts of the previous one forward.

What I have learned#

The biggest lesson is that building something impressive and building the right thing are different achievements.

RockoAI was not a failure because I moved on from it. It gave me the editor, preview, agent, sandbox, and streaming foundations that RepoGo inherited. More importantly, it forced me to confront two questions early:

Would I use this product?
Can this product become sustainable?

Those questions now guide my decisions more than the excitement of a new feature.

I also learned that a pivot does not have to mean throwing everything away. Sometimes the technology is sound but the product around it is wrong. The best move is not to protect the original pitch. It is to reuse what is valuable in service of a better one.

And I learned that distribution and timing still matter. As of July 2026, more mobile coding products are beginning to appear. I like to think RepoGo is still a little ahead in some areas, especially in how deeply the mobile app, existing CLI agents, local machines, and remote workspaces fit together.

But a technical head start is not product-market fit. It is only time, and time has to be used well.

Where RepoGo is now#

RepoGo is no longer just a way to view a repository from an iPhone. It is becoming a place to continue real development work from anywhere.

The goal is not to replace the laptop or claim that every programming task belongs on a six-inch screen. The goal is to remove the desk as a hard boundary. Your projects and agents should not become unreachable just because you closed your computer.

There is still plenty to figure out: the right offer, the clearest audience, the workflows that matter most, and how to explain a product that has grown beyond its original one-line pitch.

But I know one thing now that I did not know when I started RockoAI.

I would use this.

I thought I was pivoting away from an AI application builder. In reality, I was moving closer to the product I actually wanted to use.

RepoGo is available at repogo.app. If you are building from your phone—or want to—I would love to hear what that workflow looks like for you.