There's a moment on every product team when the smallest change is the one that waits longest. A line of copy reads wrong. An empty state says nothing useful. A form is missing a field that support has asked about four times this month. The person who noticed writes a ticket, and the ticket joins a queue behind work that genuinely matters more.
Base Code changes where that change gets made. It's a shared cloud development environment for the codebase your engineers already built, and it opens that codebase to the rest of the team.
TL;DR: what Base Code does
Base Code gives your existing codebase a shared cloud development environment. Product, design, QA and marketing can make changes directly on the product, see them running in a live preview, and send each one back to engineering as a standard pull request.
| What | Detail |
|---|---|
| What it is | A shared cloud development environment for a codebase your team already has |
| Who it's for | Product, design, QA and marketing, plus the engineers who own the codebase |
| How a change lands | On an isolated branch, with a live preview, then a standard pull request |
| What doesn't change | Branch protections, required checks, reviewers and who approves the merge |
Base Code: what's new
Your engineers already made the decisions that matter. The stack, the structure, the review process, the standards that keep the product coherent. Base Code doesn't ask you to revisit any of it. It takes the codebase as it stands and gives everyone else a way in.
Key capabilities at a glance
-
Your existing codebase, in the cloud: the environment is set up once and shared across the team.
-
Live previews, always available: every branch gets its own running preview of the real product.
-
The whole team gets access to build: product, design, QA and marketing work directly, not through a ticket.
01. Your existing codebase, in the cloud
Connect the codebase your engineers already use and Base Code builds the cloud environment around it, end to end. The agent reads the codebase first, so it works with the patterns already there rather than inventing its own.
Setup happens once. After that, everyone on the team works in the same environment, and nobody installs anything to get started.
02. Live previews, always available
Every branch gets its own preview of the running product, not a mockup and not a static render. You make a change and you watch it happen in the thing your customers actually use.
The agent checks its own work in a real browser before handing anything back, which catches the class of problems that only show up once a page is loaded. It's still worth clicking through the preview yourself, the same way you would review any change before asking someone else to look at it.
03. The whole team gets access to build
Product, design, QA and marketing describe what they want in plain language and build it directly on the product. A product manager adjusts a flow. A designer fixes a layout that only breaks at one width. QA turns a bug they found into a change instead of a second ticket. Marketing updates the words on a page without booking anyone's afternoon.
Branches are visible across the team, so you can see who is working on what and jump into any branch and its environment to take a look. Each person still works on their own isolated branch, so nobody is editing on top of anyone else.
What this looks like when a change reaches engineering
A change built by someone who isn't an engineer arrives exactly the way any other change arrives.
-
A standard pull request: no custom review surface to learn, and no separate queue to remember.
-
Isolated branches: each change is built on its own branch, and nothing is committed to your default branch.
-
Standard diffs: you read the change in the format you already read every day.
-
Your existing rules: branch protections and reviewer requirements apply as they always have.
-
Your required checks: CI runs the way it runs for everyone else.
-
Engineering approval: nothing merges until a person on your team approves it.
A new era of collaboration
For developers, Base Code makes it easy to see and collaborate on work as it happens. See every teammate's session and live preview in one place, see who's working right now, and jump straight into their branch. Open a teammate's actual session to see what they're building, share progress, pick up where they left off, and review changes as they happen.
For everyone else, Base Code opens up a way to contribute directly to the product without learning to code or setting up a development environment. Product, Design, QA, Marketing, and other teammates can describe what they want to change, make the update, see it running live, and continue working with the team.
Developers get deeper visibility and control over the development workflow. Everyone else gets a simple way to contribute directly to the product.
Best practices for opening a codebase to your team
01. Start with the work that already waits on engineering
Copy changes, empty states, a missing form field, a layout that breaks on one screen size. These are the changes that never quite reach the top of a sprint, and they're the ones where the person who noticed the problem also knows exactly what the fix should be.
02. Keep the first few changes small enough to review quickly
A pull request an engineer can read in a minute builds confidence faster than a large one that proves more. Reviewers form their opinion of the whole idea from the first few changes they see, so make those easy to say yes to.
03. Agree who opens pull requests before anyone starts
Because opening a pull request needs write access, decide early whether that sits with a specific engineer, a rota, or the team lead. Teams that skip this conversation hit it mid-change, which is the least useful moment to have it.
How to get started
- Connect the codebase your engineers already use.
- Pick one change that's been waiting, and keep it small.
- Describe it in plain language and let Base Code build it on a branch.
- Open the live preview and check it in the running product.
- Send it to engineering as a pull request and let your normal review run.
Base Code FAQ
Base Code is a browser-based development environment for your existing codebase. It lets product, design, QA, marketing and engineering build directly on the software you already have.
Yes. You connect the codebase your engineers already use and work on it as it stands, with no migration and no new stack. The project needs to be a web application that runs from the root of the codebase.
No. Base Code runs in the browser, so you can build without cloning the codebase, installing dependencies or setting anything up locally.
Yes. Team members describe changes in plain language and build on an isolated branch. Opening a pull request still requires write access to the codebase.
Base Code gives your team a shared cloud environment to work directly on the same codebase. See what teammates are working on, open their live previews, jump into branches, and contribute directly to the product.
Every change arrives as a standard pull request. Your branch protections, required checks and review rules stay in place, and engineering decides what gets merged.
No. Base Code works inside the workflow you already have. It widens who can contribute while engineering keeps ownership of the codebase and of what ships.