Atlas
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 Talk to us

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

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 →
Live network · storefront · 13 DRIs
PAtalking to you
Architectureidle
Backendidle
Code reviewidle
Securityidle
Build & deployidle
Documentationidle
Dependenciesidle
Performanceidle
Browser QAidle
Testingidle
UI designidle
UI developmentidle
backend → PA · the contract for POST /orders is ready for review

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.
Your Claude, used well

Your own Claude Code account. No API credits burned.

  1. Your Claude planPro or Max — the one you already pay for
  2. Claude Code, in the terminalsigned in once with your account
  3. Every engineer is a sessioneach with its own role and its own workspace
  4. Tuned per rolethe model and effort each job needs — your plan goes further
No API keys to manageNo per-token API billUsage 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 → PARun unattended and make decisions for me, don’t wait.
PA → youUnderstood. I’ll keep the team moving and make the routine calls myself, each one logged for you. The five that are always yours 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 nighton your company’s server
  1. Laptop closedthe team carries on, on the server
  2. 3 branches landone batch · your suite green
  3. A stall, picked uplease expired → task taken back
  4. Review: releasable2 fixes filed to their builder
  5. Asleepthe rest waits on one answer
  6. Your morning1 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-livesSpending moneyDeleting real dataSending to third partiesDropping scope Daily budget · warns 50% · 80% · pauses 100% The five it 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.

Proposercommits to the best approach
Skeptictries to break it
Judgerules, 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.

Recordedfrom finished work, given to the next engineers
Controlledone lesson held back from each start
Retiredevery six hours, the ones tracking worse results or higher cost
Shareda 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. Researchthe best in your category, the gaps nobody fills
  2. Proposea slate of improvements
  3. Buildonly what you approve
  4. Measurethen 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 PAthe goal, and the answers to its questions
  • PRDs, specs and notesshared with PA — the more you share, the sharper the cases
  • The code itselfwhat Atlas built, or a system you already have
  • Your own test casesa spreadsheet, Word or PDF you upload
The case library
steps · data · expectedtagged by techniqueexisting · gap · new
  • Unit tests
  • Functional testsin a real browser
  • Your listrun on its own

  1. Designed

    A test plan first — scenario, data, expected — tagged by technique.

    RiskPartitionsBoundariesDecision tablesStatesPairsError guessing

  2. Unit tests

    Property-based first, then examples and edges. Test-first goals go red, then green.

    red → greenno weakening tests

  3. Functional tests

    A real browser drives every screen, for every role, with a screenshot at each step.

    Playwrightconsole & network checked

  4. Landed

    Your own suite runs on every batch. Production waits until everything passes.

    fresh test databaseno faked AI calls
Not only for what Atlas builds

Existing systems too

  1. Reads your codebasemaps every file, function and how they connect
  2. Works out what it is meant to dofrom the code, from what it knows of products like yours, and from any docs you share
  3. Sorts what is theretests that exist · behaviour no test covers yet
  4. Writes the missing casesunit 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 listany sheet, Word or PDF — your column names
  2. Atlas checks the code against each caseis it built? — with the files as evidence — and what your docs say
TC-LOGIN-001Locked after 5 wrong passwords✓ built
TC-CART-014A coupon expires at midnight◐ partly
TC-PAY-022Refund within 14 days✗ not builtFix it
  1. Fixes what's missing, if you say sofix tasks go to the builders, one per gap
  2. Writes and runs your listthen follow just your cases, on their own
Tests · storefront (example) Run all tests
  • PASSTC-CHK-03[state] a guest checks out without an account4.2s
  • PASSTC-QTY-01[BVA] quantity 0 is refused0.3s
  • FAILTC-CPN-04[decision-table] coupon and member price: the larger applies2.8s
  • PASSTC-ORD-02[security] another customer’s order is invisible1.1s
  • PASSTC-PAY-07[error-guess] the card is declined twice3.6s
Explain why, in plain words

Both discounts were applied. The product is wrong, not the test — a fix is filed to backend.

▶ Replay the stepsStep 5 of 7 · Click “Pay”
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

TalkRecordShare

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 + voicevideoaudiotranscript

  2. Issues listed

    Transcribed on your own machine. Every issue raised is picked out, along with who it's for.

    issuesdecisionsopen 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 changesyour 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
Recordings · checkout walkthrough (example) Approve and fix

05:40“…see here — I add a second one and the total doesn't change.”

  • 02:14An expired coupon code is acceptedAtlas fixes
  • 05:40The total doesn't change with the quantityAtlas fixes
  • 08:03The Pay button should show the amountAtlas fixes
  • 11:27Who signs off the new refund wording?For you
4 issues · 3 for Atlas · 1 for you6 screenshots keptNothing is fixed until someone approves
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
Awakesomeone 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 sessionRead every terminalRemember the orderReview when you canOne sessionand you, as the glueMerge, and fix mainRemember the backupStart from nothingWatch the money

You carry everything around the session.

With Atlas
Specialists in parallelA board that remembersGates and dependencies“Done” enforcedPAone question at a time, to youEvery build reviewedThe landing trainEight-step releasesLessons 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
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.

  • Planarchitecture, research and design — building waits until the design is approved
  • Buildbackend and screens, each on its own branch
  • Provetests, a real browser, and load against your targets
  • Guardcode review of every build, and security when you consent
  • Shipthe running app, and releases that can be put back
  • Keep healthydocumentation and dependencies
The interchange
Plan
Build
Prove
Guard
Ship
Keep healthy

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 overOne message per reply, milestones with their evidence, and a message for each feature that reaches main.
NeverWrites 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 overThe design as a document with diagrams, for your approval.
NeverLets 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 overComparison 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 overMockups 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 overWorking code on its branch, reviewed the moment it finishes.
NeverWeakens 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 overA screenshot of the live screen.
NeverFakes 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 overThe 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 overCases 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 overRuns with screenshots. Completion is refused without them.
NeverFixes 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 overMeasurements against your targets, and the first bottleneck.
NeverPoints 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 overFindings 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 overA score out of 10 and a verdict: ship, revise or block.
NeverAgrees 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 overThe 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 overThe app running, and the deployment document updated.
NeverHand-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 overWork 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 overDocuments 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 overEvery 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. GOALIntakePA confirms the scope once, with measurable criteria
  2. PENDINGPlantasks that depend on each other; API contracts first
  3. SCHEDULEDDeliverydue when its dependencies finish; gates checked
  4. RUNNINGClaim and worka 45-minute lease; checkpoints as it goes
  5. RED → GREENTeststest-first: failing tests release the builder
  6. COMPLETEDComplete, if it really ison main or queued; cases, screenshots, rules pass
  7. RELEASABLEReviewreviewed as it finishes, or fixes filed
  8. ON MAINLandthe train brings it whole; browser QA drives it
  9. METYou're toldmerged 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
Departures · storefront
Refund endpoint — POST /refundsRUNNING
[BVA] quantity limits — 12 casesCOMPLETED
Checkout screen · waits for /ordersSCHEDULED
ADR — queue or cron for refundsPENDING
Review — fix/roundingRELEASABLE

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
Tests · storefront
94%214 cases · 201 pass · 9 fail · 4 skip
TC-ORD-02 another customer's order is invisible [security]PASS
TC-QTY-01 quantity 0 is refused with 400 [BVA]PASS
TC-CPN-04 coupon and member price: the larger applies [decision-table]FAIL
Did
Signed in as a member, added a 10% coupon to a 15%-off item
Expected
15% off, one discount
Actual
both applied — fix filed to backend

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
Security · coverage ledger
auth58/58 orders41/52 payments30/47 admin12/39 uploads2/33
Order IDs could be guessed on GET /orders/:idFIXED · RE-TESTED

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
Performance · p95 response time
0200400 050100150200 people signed in target 300 ms
First bottleneck: order search — no index on created_at~160

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
Code map · nodes, edges, communities

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.

Meetings · review call
Scene 4 · the checkout screen, shared12:41
Decision: guests can check out without an accountDECIDED
Action: email receipt for guest orders — backendTASK
Action: "make this button bigger" — UI developmentTASK

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.

Documents · Architecture v3
Refunds — architecture, v3AWAITING YOU
Choice
A queue with retries, not a nightly cron
Cost
one more worker, about the size of the API
Rejected
cron: refunds wait up to a day
v2 — reviewed by the critic: revise (6/10)HISTORY

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 onceFinished branches are merged into one batch, and your project's checks run once on the result.
Red is split, not shippedA failing batch is split until the branch that broke it is found; it goes back to its builder by name.
Main stays honestMain'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 backthe live version tagged; the previous release noted
  2. Back up the datarestored into a scratch copy and counted, table by table
  3. Prove what shipsthe tests that ran on exactly this version, cited
  4. Rehearse the changesdatabase changes run first on the restored copy
  5. Change the databasein order — anything that deletes data waits for your yes
  6. Releaseexactly what was tested goes out
  7. Check it is really livenew version answers, main flows work, counts match
  8. Put it back if notthe 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
15roles, each with its deliverable and the evidence it must produce
26.1 hof work in 10.6 h on the clock — specialists in parallel, on our own projects
162attack classes on the security coverage ledger
6finished 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 versionYour standards, decisions, linters and checks
Pluginevery rule cites its source
Your rolesYour rules, on every changeHard 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
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
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

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 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 Talk to us

For Macs with Apple silicon · one project free on your Mac · sign in with your email