# Atlas — an AI software team built on Claude Code > Atlas's home page. Atlas is a Mac app that runs a software team of AI engineers on your own Claude Code account: you talk to PA in plain words, and specialists design, build, test, review and release the work, on your Mac or on your company's own DigitalOcean server. The page covers how the team works, testing, recordings turned into fixes, where it runs and the decisions it never makes for you. Canonical: https://bridge-terminal.com/atlas/ Last updated: 2026-10-26 An engineering team built from Claude Code ## Say what you want built. _A team builds it._ Atlas is a software team made of AI engineers. You talk to one of them — **PA**, your project assistant — in plain words. PA shares the work out to specialists who design it, build it, test it and check it is safe, and when you say so, it goes live. [Download for Mac](https://downloads.bridge-terminal.com/mac/Atlas-latest-arm64.dmg) [Talk to us](mailto:atlas@bridge-terminal.com?subject=Atlas) For Macs with Apple silicon · needs your own Claude account with Claude Code · one project free on your Mac · 30 days free on your server · [pricing](https://bridge-terminal.com/atlas/pricing.html) [**Bring your own Claude Code.** Atlas runs in Claude Code’s terminal mode, signed in with your own Claude plan — no API keys, no per-token API bill. _Do more with less →_](https://bridge-terminal.com/atlas/#your-claude) _An illustration of the live network: PA in the middle, each engineer around it, the busy ones showing what they are doing, and engineers also messaging each other directly_ ### You talk. It gets built. 1. **Say it the way you would say it to a person.** “I want a booking site for my salon, where customers pick a time and pay a deposit.” No forms, no jargon. 2. **PA asks what it needs to know.** Who it is for and what matters most — then it writes the plan down, so nothing is guessed. 3. **The team shares out the work.** A designer draws the screens, builders write the code, testers try to break it and a security engineer looks for holes — at the same time, as in the picture above. 4. **You see proof, not promises.** Nothing counts as finished until it is tested and clicked through in a real browser, with screenshots you can open. When the team needs a decision, PA asks you, one question at a time. ### Say the word. It goes live. 1. **Start on your Mac.** The team works inside the Atlas app while you try things out. One project in development at a time is free. 2. **Move the team to your company’s server when you like.** Sign in with DigitalOcean once and Atlas sets up a server in your own account. The project moves across in one click — its code, its history, its passwords — and the team keeps working with your laptop closed. 3. **Tell PA to release it.** “Put it on the test site.” “Release it to production.” PA hands it to the team’s build & deploy engineer. 4. **Every release can be put back.** Atlas marks the way back, the team backs up your data and proves the backup by restoring it, tries the database changes on that copy first, releases, and checks it is really live — [the same eight steps every time](https://bridge-terminal.com/atlas/#release). Your Claude, used well ### Your own Claude Code account. No API credits burned. 1. **Your Claude plan** · Pro or Max — the one you already pay for 2. **Claude Code, in the terminal** · signed in once with your account 3. **Every engineer is a session** · each with its own role and its own workspace 4. **Tuned per role** · the model and effort each job needs — your plan goes further No API keys to manage · No per-token API bill · Usage counts against your Claude plan Several engineers at once use a plan’s limits faster — Max gives the team the most room. Atlas’s price never includes Claude. Unattended, end to end ### Set the goal and walk away. Tested software comes back. No re-prompting stalled agents, no checking whether a test really ran. The team handles that — you get the decisions that are yours. Before you leave, just say the word You → PA · Run unattended and make decisions for me, don’t wait. PA → you · Understood. I’ll keep the team moving and make the routine calls myself, each one logged for you. [The five that are always yours](https://bridge-terminal.com/atlas/#never-decides) still wait for you, unless you say so and override it. Coming soon **Run unattended** One switch in Atlas will do the same — on when you leave, off when you’re back. An example night · on your company’s server 1. 19:04 · **Laptop closed** · the team carries on, on the server 2. 21:40 · **3 branches land** · one batch · your suite green 3. 23:15 · **A stall, picked up** · lease expired → task taken back 4. 01:30 · **Review: releasable** · 2 fixes filed to their builder 5. 04:50 · **Asleep** · the rest waits on one answer 6. 08:55 · **Your morning** · 1 question · 2 buttons · tested work #### Works with the laptop closed On your company’s server — overnight, at weekends. Sleeps when only you can unblock it. #### Stalls are caught Every task has an owner and a lease. Quiet work is picked up; a restart resumes. #### Done means done No “finished” without its tests, screenshots and your product’s rules passing. #### Tested together Work lands in batches through your own suite. A red batch is traced, never shipped. #### Reviewed twice Every build as it lands, and everything again before production. #### Asks only what’s yours One question, with buttons. Routine calls you’ve made the same way, it makes. **Always yours** Production go-lives · Spending money · Deleting real data · Sending to third parties · Dropping scope Daily budget · warns 50% · 80% · pauses 100% [The five it never decides →](https://bridge-terminal.com/atlas/#never-decides) The judgement layer ### Most AI tools execute. Atlas exercises judgement. It allocates thought by stakes, attacks its own big decisions before building them, earns the right to decide for you, and gets better with every project. It knows when to stop #### Five things it never decides for you However well it knows you. Everything else runs without interrupting you — routine work fast, irreversible or money-touching work with more thought. Production go-lives Spending money Deleting real data Sending to third parties Dropping scope you asked for It argues with itself #### Every big decision is attacked before it is built Three minds on one decision: one proposes, one tries to break it, one rules. You get the decision and its reasoning, on record. **Proposer** · commits to the best approach **Skeptic** · tries to break it **Judge** · rules, critique addressed ADR It earns autonomy #### It asks — until it has earned the right not to It learns from your answers, kind by kind. In unattended mode it decides a kind only once you have answered it the same way — every decision audited. The five above still always ask. It learns #### Every project makes the next one better Lessons from finished work reach future engineers — and are measured, not trusted. **Recorded** · from finished work, given to the next engineers **Controlled** · one lesson held back from each start **Retired** · every six hours, the ones tracking worse results or higher cost **Shared** · a lesson that recurs on two projects applies to all Evolve mode · only when you start it #### A product that improves itself, until you say stop 1. **Research** · the best in your category, the gaps nobody fills 2. **Propose** · a slate of improvements 3. **Build** · only what you approve 4. **Measure** · then round again Stopping never kills it: the cycle finishes cleanly, is tagged, and you get a report. A flaw Atlas finds in itself is fixed only with your approval. Testing ### Every case designed, run and proved — screenshots you can replay. From what you share, the code and your own lists — for systems Atlas builds and the ones you already have. Where test cases come from - **What you tell PA** · the goal, and the answers to its questions - **PRDs, specs and notes** · shared with PA — the more you share, the sharper the cases - **The code itself** · what Atlas built, or a system you already have - **Your own test cases** · a spreadsheet, Word or PDF you upload **The case library** steps · data · expected · tagged by technique · existing · gap · new - **Unit tests** - **Functional tests** · in a real browser - **Your list** · run on its own 1. **Designed** A test plan first — scenario, data, expected — tagged by technique. Risk · Partitions · Boundaries · Decision tables · States · Pairs · Error guessing 2. **Unit tests** Property-based first, then examples and edges. Test-first goals go red, then green. red → green · no weakening tests 3. **Functional tests** A real browser drives every screen, for every role, with a screenshot at each step. Playwright · console & network checked 4. **Landed** Your own suite runs on every batch. Production waits until everything passes. fresh test database · no faked AI calls Not only for what Atlas builds #### Existing systems too 1. **Reads your codebase** · maps every file, function and how they connect 2. **Works out what it is meant to do** · from the code, from what it knows of products like yours, and from any docs you share 3. **Sorts what is there** · tests that exist · behaviour no test covers yet 4. **Writes the missing cases** · unit and functional, then runs them Functional docs aren't required — they make the cases more solid. Bring your own test cases #### Match → fix → test 1. **Upload your list** · any sheet, Word or PDF — your column names 2. **Atlas checks the code against each case** · is it built? — with the files as evidence — and what your docs say _Example: three uploaded cases checked against the code_ 1. **Fixes what's missing, if you say so** · fix tasks go to the builders, one per gap 2. **Writes and runs your list** · then follow just your cases, on their own _An example of the Tests page: a run, a failing case explained, its screenshot and the step-by-step replay_ **Run all tests** — screenshots and a trace of every step **Upload your own list** — spreadsheet, Word or PDF; checked, then run **Ask in plain words** — add, change or remove cases **Where test time goes** — the slowest files, sped up on request **Download** — cases and runs as PDF or Excel Recordings ### No more issue lists. Talk it through, record, share. Walk through your app on a call, or record yourself showing what's wrong. Atlas lists every issue raised, each with a screenshot from the moment it was shown, and fixes them once a person approves. The old way 1. Type up each issue 2. Grab the screenshots 3. Paste them into a tracker 4. Explain it all again With Atlas Talk · Record · Share A client call, a walkthrough by your testers, or two minutes of you on your own. 1. **Record or upload** Start Atlas's recorder while you're on the call — Zoom, Meet, Teams, any app — or drop in a recording you already have. screen + voice · video · audio · transcript 2. **Issues listed** Transcribed on your own machine. Every issue raised is picked out, along with who it's for. issues · decisions · open questions 3. **Screenshots taken** From the moments the screen changes, or someone says “look at this”. Add your own from the replay. “see here” · screen changes · your picks 4. **A person approves** A quick review: edit the list, drop what isn't wanted, approve. Nothing is fixed before that. Approve and fix 5. **Fixed and tested** Each issue becomes a task on the board — a GitLab issue too, if connected — then built, tested and landed. tested before landing _An example of the Recordings screen: a walkthrough, the moments issues were raised, and the issues found with their screenshots_ Where it runs ### The same team on your Mac, or in your company's cloud. Start on your Mac. Move to your company's own server when the project grows — in one click, from the same app. #### On your Mac Available now - **One tab per project** — a team works while its tab is open - **Pauses with a fresh checkpoint** — closing the tab or quitting pauses it - **Opens paused after a restart** — nothing starts behind your back - **Sized to your Mac's memory** — how many engineers at once **One click** Settings → move to the server: code, history and passwords Atlas suggests it — once a day — when your Mac is what slows the team #### In your company's cloud Available now - **Your own account** — DigitalOcean today, signed in once; code and records stay there - **Laptop closed, team working** — each project sleeps after 30 idle, unwatched minutes - **A database per environment** — UAT, testing, production, when you say so - **A monthly budget cap** — warns at 80%, everything sleeps at 100% - **The setter-up's Claude account** — hand the project over and it's theirs **Awake** · someone has the project open, or the team is working Your cloud bill Awake · about $40 a month Asleep · about $5 + each project, only while it's awake The whole server sleeps when nothing runs — after 30 min · 1 h · 4 h · never, your choice — and wakes when someone opens a project. Why not just Claude Code? ### Claude Code is a superb engineer. Atlas is the team around it. Everything Atlas does runs on Claude Code sessions. It adds what a team adds around a good engineer — so good practice happens **every time, without anyone watching over it**. Claude Code on its own Drive every session · Read every terminal · Remember the order · Review when you can · **One session · and you, as the glue** · Merge, and fix main · Remember the backup · Start from nothing · Watch the money You carry everything around the session. With Atlas Specialists in parallel · A board that remembers · Gates and dependencies · “Done” enforced · **PA · one question at a time, to you** · Every build reviewed · The landing train · Eight-step releases · Lessons kept The team carries it — you answer PA. | What changes | Claude Code on its own | With Atlas | | --- | --- | --- | | Who you talk to | You drive every session and read every terminal. | **One PA.** Engineers escalate to it; you get one question at a time, with buttons. | | How many engineers | One session, or as many terminals as you can juggle. | **Specialists in parallel,** each its own Claude Code session — 26.1 h of work in 10.6 h on our own projects. | | What remembers the work | The session's context. Close the laptop or hit a crash and the thread is gone. | **A board in a database** — 45-minute leases, re-pings, checkpoints; a restart resumes. | | What "done" means | Done when the model says it is. | **Completion is refused** until it is on main, a screen has its cases and screenshots, and your rules pass. | | What waits for what | You remember the order and enforce it yourself. | **A dependency plan** — architecture, design and failing tests first; a screen waits for its API. | | Review | You review it, when you have time. | **Every build reviewed as it finishes** — releasable, or fixes filed to its builder. | | Getting onto main | You merge branches, and fix main when they collide. | **The landing train** — six at a time through your checks; a red batch is split, never shipped. | | Releasing | You remember to back up, test the database changes and keep a way back — or you don't. | **Eight steps every time** — way back marked, backup proven, changes rehearsed, checked. [How](https://bridge-terminal.com/atlas/#release) | | Getting better | Every session starts from nothing. | **Lessons passed on**, measured against a control, retired when they don't help. | | Money, secrets, the irreversible | Whatever the session is allowed to do. | **Never decided for you:** production go-lives, spending, deleting data, sending outside and dropping scope. A daily budget can pause at 100%; pasted secrets go to a secret store first. | | Evidence you can open | A terminal transcript. | **Screens built for proof** — Tests with replay, Security, Performance. | The team ### Every engineer owns a line, and the line ends in evidence. Each role is its own Claude Code session with a written job — what it does, hands over and must never do. Specialists beyond the standard roles are proposed by PA and approved by you. _The Atlas line map: goals leave the PA along six coloured lines — plan, build, prove, guard, ship and keep healthy — pass their checkpoints, meet at the gate where your checks run, and ride the landing train into main._ - **Plan** · architecture, research and design — building waits until the design is approved - **Build** · backend and screens, each on its own branch - **Prove** · tests, a real browser, and load against your targets - **Guard** · code review of every build, and security when you consent - **Ship** · the running app, and releases that can be put back - **Keep healthy** · documentation and dependencies #### PA, the one you talk to The interchange · every line starts here The single point of contact between you and every engineer. It routes, coordinates, escalates and reports — and never builds anything itself. ##### How it works 1. Works out whether you want to **discuss, plan or have something built**, and asks when it can't tell. You reach it in the app, by voice, or from Slack or Telegram. 2. Confirms the scope once, then lays the whole plan as **tasks that depend on each other**, API contracts first. 3. Sets goals with **measurable criteria** and opens the gates that apply: architecture, design, test-first. 4. Answers the engineers' questions, or brings them to you **one at a time, with buttons**. A burst of messages arrives as one. 5. Reports as it goes: milestones with their evidence, and **estimates only from the forecast**. **Hands over** · One message per reply, milestones with their evidence, and a message for each feature that reaches main. **Never** · Writes code. Approves production, spending, deleting data or a change of scope. Says "done" while a goal is below 100%. #### Architecture Plan line · the architecture gate System design and technical direction, written down before anything is built. ##### How it works 1. Holds **backend, UI and integration work** until the design is decided — the architecture gate. 2. Writes the design with **real choices and numbers**: topology, infrastructure, callers, cost, alternatives. 3. Picks the right diagram for each concern — component maps, request flows over time, the data model, state machines — and renders them into the document. 4. On an existing codebase, **maps it into the team's shared memory** before proposing anything. "Use real choices and numbers, not 'TBD'." **Hands over** · The design as a document with diagrams, for your approval. **Never** · Lets building start on a system decision you haven't reviewed. #### Research & gap analysis Plan line Finds the unknowns before they become rework. ##### How it works 1. Researches and **compares technologies**, with web access. 2. Measures the **gap between what is required and what is built**. 3. Runs **small proofs of concept** and surfaces the unknown unknowns. **Hands over** · Comparison tables and diagrams. Open research holds the release. #### UI design Plan line · the design gate The actual design — screens you can open and see, not a spec about the design. ##### How it works 1. Renders **every screen**, including its loading, empty and error states, with real tokens and realistic content. 2. Maps **every value on a screen to a real field** in the API. 3. Finishes **screen by screen**, so building can start on the first one. "A finished design task is not approval; the operator's sign-off is." **Hands over** · Mockups for your sign-off. Building waits until you give it. #### Backend development Build line The server side: APIs, the data model, the business logic. ##### How it works 1. Proposes the **API contract before implementing it**; changing an agreed shape is refused. 2. Reads the **project's code map** to know what a change will touch, instead of searching blind. 3. Proves each feature on **new inputs, one for every variant**. 4. Builds **against the failing tests** when the project works test-first. **Hands over** · Working code on its branch, reviewed the moment it finishes. **Never** · Weakens a test to make it pass. #### UI development Build line · checked against the design The real, running screen: the approved design, built faithfully, wired to live data. ##### How it works 1. Builds **every component the mockup shows**, with no hard-coded numbers or placeholder text. 2. Checks the agreed API shapes and **uses the generated types**. 3. Passes a **visual check** that scores the live screen against the design and catches reskins. "A reskin of the old screen is NOT a build." **Hands over** · A screenshot of the live screen. **Never** · Fakes data. A missing endpoint becomes a fix task for backend. #### Specialists Build line · made for your project Domain experts created for one project, with a set boundary, skills and a reason to exist. ##### How it works 1. Proposed by PA; **a new kind of role starts only with your approval** — the team grows only with your consent. 2. Writes the **contract first** and never weakens a test. 3. **Product plugins** (Salesforce, for example) bring their own specialists named for the roles your people recognise, and the platform's rules and gates — checked on every change. "Done means the REQUIREMENT works on real inputs." **Hands over** · The requirement working on real inputs. #### Testing Prove line · the test-first gate Owns the quality of the tests themselves. ##### How it works 1. Risk-ranks first, then walks the classic techniques — **equivalence classes, boundaries, decision tables, state transitions** — and tags every case with the technique that produced it. 2. Writes and shares the cases **before running anything**; property-based tests first where they fit. 3. Test-first: its failing tests turn the gate **red, which releases the builder**; green releases the release. 4. Grades its own tests with **mutation testing** — the number that says the assertions catch bugs. "Test the CAPABILITY, not the cache." **Hands over** · Cases and runs in the Tests screen. A claim without an artifact doesn't count. #### Browser QA Prove line · the end-to-end gate Proves the app works by driving it in a real browser against the running app. ##### How it works 1. Drives the **core user flows with new inputs**; any console or network error is a fail. 2. Writes specs for **every screen and every role**, unasked. 3. Backs up the design check **route by route**. "'Unit tests pass' is NOT your bar." **Hands over** · Runs with screenshots. Completion is refused without them. **Never** · Fixes the app. It verifies; the builders fix. #### Performance Prove line Answers whether the system takes the load you expect, and where it chokes first. ##### How it works 1. Turns the load model drafted from the code into **your terms**: orders per hour, people signed in. 2. Writes load scenarios: **a tenth of the load locally**, the full numbers on a server. 3. Reviews the code against the **published performance rule sets** that apply to the project. **Hands over** · Measurements against your targets, and the first bottleneck. **Never** · Points anything at production. #### Code review Guard line · on every build Quality, patterns and standards, on every build as it finishes. ##### How it works 1. Picks up the review Atlas **files automatically** for each finished build. 2. Treats **every rule line as blocking**, and files fixes to the builder by name. 3. Checks the designed feature is **really wired** — no silent downgrades, no falsely green tests. **Hands over** · Findings by file and line, and a verdict: RELEASABLE or not. Reviews hold the release, not the builder. #### Critic Guard line · when you want a second opinion An adversarial reviewer whose only job is to find what is wrong with plans and claims. ##### How it works 1. Checks a plan against the project's **constraints, goals, decisions and blockers**. 2. Names the **unstated assumptions** and the revisions the plan needs. 3. Scores honestly: **8 or more ships**, 5 to 7 is sent back to revise, 4 or less blocks. "You exist because Claude is congenitally agreeable." **Hands over** · A score out of 10 and a verdict: ship, revise or block. **Never** · Agrees out of politeness, or invents a flaw to seem useful. #### Security Guard line · with your consent Vulnerabilities, threat modelling and secure code — from a ledger rather than a hunch. ##### How it works 1. Works through **every module against 162 named attack classes** in 11 families. 2. Closes a unit **only with evidence**; a finding counts as fixed only after a re-test. 3. Asks before it runs: **now, at the next build, or hold** — and batches into one pass per build unless you say now. "'Looks fine' is not a result." **Hands over** · The coverage ledger and verified findings, in the Security screen. #### Build & deploy Ship line The running app — because a green test suite is not a running app. ##### How it works 1. Waits until **no build, review or fix is open**, and the train is idle. 2. Starts the frontend and API **on free ports** and hands the address to browser QA. 3. Treats a designed component that isn't attached as **a blocker**. Going live is always your decision. **Hands over** · The app running, and the deployment document updated. **Never** · Hand-fixes application code. #### The landing train Ship line · run by Atlas itself Not an engineer but the engine: it brings finished branches to main, tested together. ##### How it works 1. Merges **up to six finished branches** into one batch. 2. Runs **your project's own checks once** on the result. 3. Splits a red batch **until the branch that broke it is found**, and sends it back to its builder. 4. Main's history is **never rewritten**. **Hands over** · Work on main, and a message saying what arrived. #### Documentation Keep-healthy line Keeps the documents in step with the code. ##### How it works 1. **READMEs, API documents, the changelog** and decision records. 2. Runs **after testing and before the release**. 3. Renders documents **with their diagrams**, kept with a version history. **Hands over** · Documents in the app's Documentation tab. #### Dependency management Keep-healthy line Keeps the project's dependencies healthy. ##### How it works 1. Versions, outdated packages, and **the breaking changes that come with upgrades**. 2. **Licence compliance** and lock-file integrity. 3. Takes the dependency and vulnerability fixes the other engineers **route to it**. **Hands over** · Every package with its current version, the latest, any advisory, and the action. One goal, end to end ### What happens between "build me this" and main. The real sequence, as the engine runs it — the states are the ones on the board. 1. GOAL · **Intake** · PA confirms the scope once, with measurable criteria 2. PENDING · **Plan** · tasks that depend on each other; API contracts first 3. SCHEDULED · **Delivery** · due when its dependencies finish; gates checked 4. RUNNING · **Claim and work** · a 45-minute lease; checkpoints as it goes 5. RED → GREEN · **Tests** · test-first: failing tests release the builder 6. COMPLETED · **Complete, if it really is** · on main or queued; cases, screenshots, rules pass 7. RELEASABLE · **Review** · reviewed as it finishes, or fixes filed 8. ON MAIN · **Land** · the train brings it whole; browser QA drives it 9. MET · **You're told** · merged and tagged only if its suite is green Proof, not promises ### Evidence you can open. Each line ends in something you can open — a board, a test case, a ledger, a measurement, a map, a decision. #### Every task has an owner, a line and a state The board lives in a database, not in a conversation. Close the laptop, crash, restart: the tasks, their leases and the checkpoints are still there, and each engineer resumes where it stopped. - Dependencies, so a screen waits for the API it calls - Leases and re-pings, so nothing is quietly dropped - Every row links to its task, its owner and its evidence _Illustration of the board_ #### A reason for every case Each test case says what it did, what data it used, what it expected and what actually happened — evidence, not a pass/fail badge. Runs keep their screenshots and a step-by-step replay. - Cases tagged by the technique that produced them - Test-first goals go red, then green - Add or change cases by asking, in plain words _Illustration of the Tests screen_ #### Coverage, not a rubber stamp The Security screen leads with what has never been reviewed. Every module crossed with every attack class that applies, closed only with evidence; findings fixed only after a re-test. - 162 named attack classes, 11 families - Runs now, at the next build, or held — you choose - A clean result is a real result, recorded as one _Illustration of the security coverage ledger_ #### Load against your targets Performance turns a load model drafted from the code into your terms — orders an hour, people signed in — measures against your targets, and names the first thing to choke. - A tenth of the load on your Mac; the full numbers on a server - Never pointed at production _Illustration: response time rises with load and crosses the 300 millisecond target at about 160 people_ #### It maps the codebase before it changes it Every engineer reads the project's code map — files, functions and how they connect, clustered into communities — instead of searching blind. It is how a change knows what it will touch. - Kept current as the code changes - Existing projects are mapped on arrival _Illustration of the code map_ #### It watches the recording, not just the transcript Bring a recorded call. Atlas breaks the screen-share into scenes and reads what was on screen at each moment, so "this one" means the thing on the screen — then pulls out decisions, owners and action items as tracked work. _Illustration of a meeting summary_ #### Documents your team can approve Designs, decisions and reports arrive as rendered documents with diagrams and a version history. Where a document decides something, building waits for your approval. _Illustration of a document awaiting approval_ Illustrations with example data. In the app, these are your project's live screens. The landing train ### Finished work reaches main tested together. Branches that pass alone can still break each other. So Atlas lands them in batches, through your own checks, and never lets a red batch reach main. Waiting for finished branches… **Up to six at once** · Finished branches are merged into one batch, and your project's checks run once on the result. **Red is split, not shipped** · A failing batch is split until the branch that broke it is found; it goes back to its builder by name. **Main stays honest** · Main's history is never rewritten, and you get a message saying what arrived. Releasing ### Every release can be put back. Anywhere beyond your Mac, the same eight steps every time — and a release can't be called done without a record of each. 1. **Mark the way back** · the live version tagged; the previous release noted 2. **Back up the data** · restored into a scratch copy and counted, table by table 3. **Prove what ships** · the tests that ran on exactly this version, cited 4. **Rehearse the changes** · database changes run first on the restored copy 5. **Change the database** · in order — anything that deletes data waits for your yes 6. **Release** · exactly what was tested goes out 7. **Check it is really live** · new version answers, main flows work, counts match 8. **Put it back if not** · the previous version at once; data only with your yes What a release leaves behind, kept with the project (an example) - **rollback point** — release/production/before-2026-10-11 · previous deployment kept - **backup** — 578 MB · restored into a scratch copy · 33 tables, counts match - **tests** — this exact version, tested as it landed · full suite green - **rehearsal** — 4 database changes run on the restored copy · no rows lost - **migrations** — 4 applied in order · none deletes data - **release** — deployed - **verify** — passed · new version live · sign-in and checkout work - **way back** — redeploy the previous version · restore the backup only with your yes **15** · roles, each with its deliverable and the evidence it must produce **26.1 h** · of work in 10.6 h on the clock — specialists in parallel, on our own projects **162** · attack classes on the security coverage ledger **6** · finished branches per landing-train batch, tested together Coming soon · Plugins ### A team that already knows how your software is built. A plugin teaches the whole team how a platform — or your own product — is really built. The vendor's official docs, version by version · Your standards, decisions, linters and checks **Plugin** · every rule cites its source Your roles · Your rules, on every change · Hard stops — no one talks past them Platforms you build on #### Salesforce is built. More platforms after it. Made from the vendor's own documentation — accurate and current, never guessed. Your own software #### Atlas learns the product you already have A new feature reads as if the people who wrote the rest of it wrote it too. It speaks your roles #### The team becomes a Salesforce team Administrator, Apex Developer, LWC Developer — roles your people recognise. It catches the classics #### The mistakes that break production Queries in loops, hard-coded IDs, missing sharing rules — caught on every change. It won't ship below the bar #### Salesforce needs 75% test coverage. So does Atlas. The platform's release rules become a hard stop — for every engineer, every deadline. Plans ### One project in development free on your Mac. A licence for each on your server. Keep as many projects as you like. Every team gets 30 days free, including one project in development on its server. Free One on your Mac for everyone, with no limit on people - Your Atlas team works on one project at a time on your Mac - The whole team, every screen - Releases that can be put back, every time - Updates arrive by themselves [Download for Mac](https://downloads.bridge-terminal.com/mac/Atlas-latest-arm64.dmg) Licences $50 / month for each project in development at the same time · 30 days free - Each project in development on your company's server needs one - On a Mac, one lets the team work on a second project at once - A paused project, or one asleep on the server, doesn't count - Your admin assigns them; a licence can move once a month [See pricing](https://bridge-terminal.com/atlas/pricing.html) Your organisation Your people formed by itself, from your email domain - Colleagues at your company's domain join it when they sign in - Whoever sets up its server becomes its admin, and everyone is told - The admin sees everyone, adds people and assigns licences - Freelancers on a personal address can be added too What “a project” means A project here means software your Atlas team is working on. What it produces — your app or website — is yours: it runs live on your own hosting, for as many users as you like, and Atlas never charges for that. A paused project, or one asleep on the server, costs nothing. #### Sign in with your email. No password. A six-digit code and a link arrive by email — either signs you in, on your Mac or your phone. New to Atlas? That is also how you sign up. After that it works offline for up to a week. #### Your code stays with you Atlas works on your Mac or in your own cloud account. Your code, your chat with PA and your documents are not sent to us. What Atlas's service does see is on the [Privacy](https://bridge-terminal.com/atlas/privacy.html) page. #### Updates by themselves Atlas shows what's new and updates with one click — now, tonight, or later. Your teams pause with their work saved, and resume after. Server updates are one click too, with everyone told first. #### Secrets stay secret Credentials pasted into chat go to the secret store before PA sees them, are handed to a tool only when it needs them, and are masked in every log and report. Bring the goal ### Set a goal. Watch a team build it. Atlas brings the team, the judgement, and the line to main. [Download for Mac](https://downloads.bridge-terminal.com/mac/Atlas-latest-arm64.dmg) [Talk to us](mailto:atlas@bridge-terminal.com?subject=Atlas) For Macs with Apple silicon · one project free on your Mac · sign in with your email ## Related - [Atlas Pricing — Free on Your Mac, $50 per Project in Development](https://bridge-terminal.com/atlas/pricing.html) - [The Atlas blog](https://bridge-terminal.com/atlas/blog/)