Own Your Code: What Solo Gives Developers Control Of

If you can already code, the important question about an AI builder is not whether it can produce a first version. It is what happens when you disagree with the output, change the architecture, or want to leave.

Solo's answer is a repository you can own and push to, ordinary application code, and an operating layer that reads the changes without trying to reassert a generated template. Here is what that control includes, how the hybrid workflow behaves, and where the current limits are.

The repo is actually yours

Not "exportable." Yours.

When a business is created, its code initially lives in a Solo-owned repo and you're a read-only guest. Connecting moves it: the code lands at <your-github>/<your-business>, owned by your account, and the Solo-side repo keeps only CI/CD. After that you push to it like any other repo.

The move is fail-closed and ordered to preserve the code. Your repository receives it before anything is removed from Solo's side, so an interrupted move leaves two copies rather than none. Solo only adopts a repository it can verify as empty or marked as one it created. If a repository at that name already contains another project, Solo refuses instead of force-pushing.

What is in it is deliberately ordinary: Next.js, FastAPI, Postgres, Stripe, and AWS, with infrastructure defined as code. There is no proprietary runtime or Solo SDK in the application's import graph. An enforced layering rule keeps control-plane modules out of the assembled business code. If you leave, the repository remains a conventional application on a conventional stack.

What happens when you push

This is the part that distinguishes "you can export" from "you can actually work here."

You push to your repo. Then:

1. Solo fast-forwards its workdir to your latest and re-baselines the drift ledger, which records rendered files and their hashes. Your pushed tree becomes the new baseline.
2. It reads your diff and summarizes it into the business's state docs. This is the part that matters: the agents that operate your business now know what you changed. They're not working from a stale mental model of a codebase you've since rewritten.
3. It enqueues a deploy if the change warrants one.

Those last two legs are deliberately independent. The summary is best-effort context for the activity log. Shipping decisions use diff logic without an LLM in that path, so a failed summary does not block the deploy decision.

The result is a loop where hand-written code and agent-written code are the same kind of thing. You're not fighting a generator that wants to reassert itself.

Your edits don't get clobbered

Every file Solo renders is owned by a block that declares it, and the business records content hashes for all of them in .solo/checksums.json.

When you edit a generated file, the hash diverges and the system knows that file has drifted. It stops treating it as machine-owned. There's no silent overwrite on the next assembly, and no need for // DO NOT EDIT banners that everyone ignores anyway.

This is a direct consequence of the block architecture: because ownership is declared up front rather than inferred, "who owns this file and has it changed?" is a lookup rather than a guess.

Bring your own tools

Solo does not prescribe how you edit the code. Use your editor, agents, and models. Cursor, Claude Code, Zed, or Vim all work against the same Git repository.

Solo contributes context for whichever compatible agent you use. The repository ships with CLAUDE.md and AGENTS.md, cross-harness instructions that point coding agents toward the project's conventions, plus project skills and semantic code search. The goal is to keep architectural context in the repository instead of retyping it into every prompt.

The division of labour is the useful part: operations run continuously, builds run on demand. Monitoring, incident triage, and marketing keep going 24/7 whether or not you're around. Feature work you can hand over as a task, or just do yourself. Both paths land in the same repo, and neither one locks the other out.

The hybrid model in practice

ListMyCar used the workflow this article describes. Claude Code contributed product features and marketing assets in the application repository: VIN decoding, the listing flow, photo enhancement, price suggestions, public listing pages, marketplace export kits, and search-focused content.

Solo worked around that same repository. It turned owner goals into reviewed plans and tasks, operated recurring growth and reliability loops, dispatched the repository's existing GitHub Actions delivery workflow, followed the exact commit being released, and verified the result. A developer or coding agent could still push directly; accepted changes followed one delivery path.

That is a more useful definition of control than an export button. The team can choose the tool for the change, while the business keeps one codebase and one operating record. See the repository, delivery, and growth loops in the ListMyCar case study.

Where the limits are

Being straight about this, because discovering it later is worse.

The block catalog is finite. Today: Next.js and FastAPI, Postgres, Clerk for auth, Stripe for payments, PostHog for analytics, Postmark and SES for email, AWS for deployment. That's a coherent, production-grade stack, and it is not a choice of stacks. If you want Django, or Supabase instead of raw Postgres, or Paddle instead of Stripe, that's not available.

Custom blocks are not shipped. The block contract documents the manifest schema, block types, provides and requires, file ownership, and service interfaces. Existing manifests are working examples, but authoring and installing your own block is still a roadmap item. Broader stack choices are on the same roadmap.

Right now the honest extension path is: write ordinary code in your repo. That works, it deploys, and Solo reads it. It just isn't a block, so it doesn't participate in assembly, ownership, or swapping.

Importing an existing project isn't there yet. Solo creates businesses; it can't currently take a repo you already have and level it up. That's announced as coming, and it isn't here.

Mobile isn't there. Web only today.

A developer should evaluate these current limits before choosing the platform. Future work does not satisfy a stack requirement today.

Who this actually suits

A good fit if you want to own the product code while delegating routine operations. You can write features, review agent changes, and push directly when that is faster. The repository uses a standard stack, while Solo handles deploys, monitoring, incident triage, and scheduled marketing work.

A bad fit if you want a specific stack that isn't in the catalog, need to author your own blocks today, or are looking for something to adopt an existing codebase. Wait for those, or don't.

Also a bad fit if what you actually enjoy is the infrastructure. Some developers like running production. That's a legitimate preference, and Solo's whole value proposition is taking away a job you'd rather keep.

The underlying bet

The argument isn't that you can't build auth, billing, deploys, and monitoring. Obviously you can. It's that you've built them before, you'll build them again, and none of it is where your product wins.

What is scarce is not always the ability to do the operating work. It is the attention that work continues to consume after launch. Solo's bet is that delegating repeatable operations can justify accepting a fixed stack, provided the product code remains yours and direct edits remain possible.

Whether that trade is right depends on how much you value the stack choice. It's a real trade, and it's the one to think about.

A real repo, a standard stack, and direct edits that remain yours. Push code with the tools you prefer, while Solo keeps the recurring operations moving around it. Join the waitlist →