Explore repeat lookups.
FREE, OPEN-SOURCE MAC APP FOR AGENT-BUILT SOFTWARE
Your agent builds the app.
You keep the controls.
Your IDE once kept Run, Stop, logs, and tests close to the code. With coding agents, those controls get scattered across chats and terminals. OpenBuildRoom brings them back with your data and product plan in one local workspace.
Apple Silicon preview Runs locally on your Mac MIT licensed
ONE CONTROL SURFACE · SEPARATE LOCAL PROCESSES
ATLAS REPOSITORY · INTERACTIVE SIMULATIONOne control surface for your local stack.
Your Web app, API, MCP server, and database run as separate parts. OpenBuildRoom lets you start and inspect them from one place.
OpenBuildRoomATLAS WORKSPACE
RUN & VERIFY / SERVICES
Run your project.
Start and inspect each local process from one place.
▣Web appStopped
⌁API serviceStopped
⬡MCP serverStopped
0 / 3 runningTests · Logs · Data ↗
Understand the systemThen take the controls
INTERACTIVE WORKSPACE TOUR
See the whole workspace. Then try it.
Follow a product from its plan through the connected services, data, and tests. Play the story or open any view yourself.
OVERVIEW / ATLAS WORKSPACE
OverviewEverything at a glance.
One starting point for product progress and the running app.
RUNNING SERVICES0 / 3Web · API · MCP
RECORDED CHECKS0 / 4Last simulated run
OPEN BACKLOG03Stored with the repo
SPEC KIT TASKS3 / 4Order lookup feature
DEVELOPMENT ENVIRONMENT
▷Web appStopped
▷API serviceStopped
⬡MCP serverStopped
NEXT TO REVIEWFR-001 · Find an order by ID
Three tasks complete. The final task checks the response against PostgreSQL.
Open Requirements to follow the link.FILES / REPOSITORY EXPLORER
FilesFind the source behind the story.
The same project files your agent edits are one click away.
ATLAS / PROJECT FILES▾ .specify/▤ memory/constitution.md▾ specs/001-order-lookup/▤ plan.md · tasks.md▾ docs/▾ dist/web/▸ apps/ · tests/
productview.yamlEXAMPLE FILE
project: {name: Atlas}
components:
- id: web
kind: service
name: Web app
build: {file: dist/web/build-info.json}
- id: api
kind: service
name: API service
- id: postgres
kind: databaseThe build pipeline writes the timestamp and revision to its build file after a successful build.
ONBOARDING / PROJECT SETUP
OnboardingOpen a repo. Know what to check.
A guided checklist turns a new folder into a usable workspace.
ATLAS SETUP · 4 OF 6 REVIEWED
✓Open project folderAtlas repository found
✓Read agent guideYAML contract available
✓Review Project Map5 components linked
✓Inspect Services3 commands registered
○Run Tests4 checks ready
○Open Data SourcesPostgreSQL configured
NEXT STEP
Verify the app, not just the YAML.
Start each service, run the checks, and inspect a real data source before trusting the map.
VISION / LOCAL PRODUCT DOCUMENT
VisionGive the agent a reason to build.
The product purpose lives in a Markdown file everyone can revisit.
START WITH THE ESSENTIALSWho is it for?What hurts today?What should change?Shared product context · optional view
VISION DOCUMENT
docs/vision.mdEdit MarkdownMake every order easy to find and trust.
For support teams who answer customer questions about orders.
The problem is that finding an order means checking several systems.
First useful release lets a team find one order and see a reliable status.
ROADMAP / SHARED PROJECT YAML
RoadmapShow what comes next.
Place product outcomes in a clear status so the next task has context.
Draft1
Planned1
Share an order result.
In progress1
Find an order and trust its status.
Web · API · PostgreSQLDone1
Agree on the first outcome.
Roadmap status is a plan. Tests and runtime show what actually works.
NORTH STAR / MANUAL PRODUCT MEASURE
North StarMeasure whether people get value.
One outcome metric keeps product progress visible beside delivery.
WEEKLY TEAMS COMPLETING AN ORDER LOOKUP
12teams
Target: 100
Target: 100
Latest manually recorded value · example data
HISTORICAL PROGRESSManual measurements in this repository
Week 1Week 4
The target is a goal; the plotted values are manually entered observations.
BACKLOG / REPOSITORY ISSUES
BacklogKnow what comes next and why.
Requests, decisions, and bugs stay beside the code.
INBOXPV-032 · Saved searches
Support teams want to repeat common order lookups.
Idea · medium priorityIN PROGRESSPV-024 · Order lookup
Find an order by ID and trust the returned status.
Linked to specs/001-order-lookupNEEDS REVIEWPV-035 · Failed test detail
Make the exact failing check easy to inspect.
Bug · high priorityREQUIREMENTS / GITHUB SPEC KIT
RequirementsFollow the promise into the build.
The standard Spec Kit files connect product intent to implementation work.
specs/001-order-lookup
✓ spec.md What & why
✓ plan.md How
◌ tasks.md 3 / 4 done
✓ contracts/ API
REQUIREMENT → IMPLEMENTATION
Customers can find one order by ID.
FR-001 A valid order ID returns the matching order and its status.
T004 Verify the response against local data.
3 of 4 tasks complete · one verification task remains
DOCUMENTATION / PROJECT KNOWLEDGE
DocumentationKeep the explanation with the work.
Product and technical notes remain readable in the repository.
DOCS / MARKDOWN
▤ getting-started.md
▤ product-decisions.md
▤ architecture.md
GETTING STARTED
Run Atlas locally
1. Open the repository in OpenBuildRoom.
2. Set DATABASE_URL locally.
3. Start Web, API, and MCP services.
4. Run the registered checks and inspect the order table.
PROJECT MAP / LOCAL WORKSPACE
Project MapSee how the system fits together.
Connected components show their state and, when available, the artifact build.
3 services · 1 database · 1 storage folder · example configuration
SERVICES / LOCAL WORKSPACE
ServicesKnow which build you started.
Build time and commit are separate from the moment a process starts.
Services3 configured · manual start
Web app Stoppednode dist/web/server.js · :3000 · v1.4.2Built 04 Nov 2026, 20:41:23 · a4c9e71Not started in this demo
API service Stoppednode dist/api/server.js · :4000Built 04 Nov 2026, 20:38:12 · b8f12d0Not started in this demo
MCP server Stoppednode dist/mcp/server.js · v0.7.0Built 04 Nov 2026, 20:32:07 · c39e2a4Not started in this demo
Example build metadata · select Start for a simulated local service.
ENVIRONMENT / LOCAL ONLY
EnvironmentSpot what the system needs.
Required variable names are visible; values stay on this computer.
REQUIRED BY API SERVICE
!
DATABASE_URLPostgreSQL connection · value never shown in this demo
Missing locallyIn the desktop app, you set your own secret locally. The repository stores only its name.
CLI EXPLORER / LOCAL COMMANDS
CLI ExplorerA manual you can actually use.
Browse a project's commands and try one without guessing flags.
ATLAS CLI · COMMANDS
orders getRead one order by ID
orders listBrowse recent orders
healthCheck the local API
Last build · 04 Nov 2026, 20:36:04
Commit · d7a2f80
Version · v1.4.2
ORDERS GET · USAGE
atlas orders get <order-id>Argument order-id · required
Option --json · machine-readable output
$ atlas orders get ORD-1042 Ready to run in this simulation
MCP EXPLORER / LOCAL TOOL SERVER
MCP ExplorerSee what the MCP server exposes.
Inspect tool inputs and run a sample call deliberately.
ATLAS MCP SERVER · 3 TOOLS
Last build · 04 Nov 2026, 20:32:07
Commit · c39e2a4
Version · v0.7.0
SAMPLE MCP CALL
get_order({ id: "ORD-1042" })Ready to run in this simulation
CLI EXPLORER atlas orders get ORD-1042API EXPLORER / HTTP ENDPOINTS
API ExplorerSee the contract. Try the endpoint.
OpenAPI gives you the routes; one deliberate request shows the actual response.
ATLAS API · OPENAPI 3
GET /orders/ORD-1042Find one order by ID
GET /ordersList recent orders
GET /healthCheck API readiness
Document: specs/001-order-lookup/contracts/openapi.yaml
REQUEST COMPOSER · EXAMPLE
GET
http://localhost:4000/orders/ORD-1042Bearer token name: ATLAS_API_TOKEN · value stays local
Ready to send in this simulation
Response body appears here after Send.
DATA SOURCES / READ-ONLY PREVIEW
Data SourcesOpen the data behind the app.
Browse a local structure without leaving your workspace.
POSTGRESQL · ATLAS LOCALRead-only preview · sample data
ORDERS / FIRST 3 ROWS
IDCUSTOMERSTATUS
ORD-1042AdaPaid
ORD-1043SamPending
ORD-1044LeePaid
IDNAMEORDERS
C-001Ada2
C-002Sam1
TESTS / LOCAL VERIFICATION
TestsCheck every part of the stack.
Run the registered checks and see their results together.
LATEST SIMULATED RUN0 / 4 passed
Ready to run four checks
REGISTERED CHECKS
○Web app respondsWaiting
○API healthWaiting
○MCP order lookupWaiting
○PostgreSQL order readWaiting
› Choose Run all tests to inspect the result.
ACTIVITY / LOCAL PROJECT HISTORY
ActivitySee what happened since you last looked.
Starts, inspections, and test runs leave a trail you can review.
ORDER LOOKUP · SIMULATED EXAMPLEReady to review ✓
From FR-001 to a running API, a visible order, and four passing checks.
FR-001→API + MCP→ORD-1042→4/4 checks
Illustrative relationship · no live verification is performed here.RECENT ACTIVITY · SIMULATED
●Services startedWeb · API · MCP
●Order inspectedPostgreSQL
●Tests passed4 checks
SETTINGS / WORKSPACE PREFERENCES
SettingsMake the workspace yours.
Keep the core navigation clear; enable extra views when they help.
APPEARANCE · THIS COMPUTER
ThemeLight / Dark
SidebarExpanded
AgentLocal coding CLI
ADDITIONAL VIEWS · PROJECT YAML
VisionEnabled
RoadmapEnabled
North StarEnabled
The tour shows these optional views so you can see how product direction fits alongside runtime.
01 / OVERVIEWStart with the whole product.Play the guided walkthrough or open any view yourself.
Explore the desktop navigation through one example workspace. Tour actions are simulated; the desktop app operates your real local repository.
GET STARTED
From download to your first run.
Start with the included example. Then open a repository you already have and give its services, tests, and data a place you can see and control.
1. Download the Mac app
Get the free Apple Silicon preview. The desktop app and its source are open on GitHub.
Download free for Mac2. Install and open it
Unzip, move the app to Applications, and launch it. Try the included example first; Node.js 20+ runs its example commands.
3. Open your own project
Choose a repository. OpenBuildRoom scans for project clues and prepares a tailored agent prompt. Codex or Claude Code proposes productview.yaml; review it, then start a service or test.
Starting a new app? Copy the starter prompt
Give your next project the same setup.
For an existing repository, use the tailored prompt inside the desktop app. For a new idea, start here.
Build [my app idea] for [my audience] with Git, GitHub Spec Kit, and OpenBuildRoom Desktop: https://github.com/OpenBuildRoom/desktop Read its agent guide and YAML schema, ask me the essentials, and set up the repository so I can open it in the desktop app.
Ready to paste into your agent
Apple Silicon preview is unsigned and not notarized. View source and star on GitHub ↗
THE THREE REASONS TO OPEN IT
See the system.
Run it. Steer it.
OpenBuildRoom brings the parts that disappear across terminals, browser tabs, and agent chats into one local workspace.
01 / SEE THE SYSTEM
Your project on one map.
See the services, databases, storage, and connections your app actually needs. Click through to the local component and its status.
02 / RUN & CHECK
Start it. Prove it works.
Start and stop local services, read logs, run tests, and inspect data in one place. You can see what ran and what passed.
03 / STEER THE PRODUCT
Keep the why beside the code.
Follow vision, roadmap, backlog, documentation, and GitHub Spec Kit requirements as your agent builds the next release.
FOR PRODUCT OWNERS
Shape what gets built.
Follow what gets done.
Keep the why, the next steps, and the evidence together in the repository. Your coding agent works from the same product context that you can inspect in OpenBuildRoom.
Product direction→Spec Kit→Coding agent→Running evidence
Progress overview
Return to one dashboard for declared services, recent tests, open work, and progress read from Spec Kit tasks.
Vision
Write the product purpose in a Markdown document the team and agent can revisit. Enable this view when you have a vision to show.
Roadmap
Turn product milestones into a shared plan. Link them to components and show their declared status as the work moves forward.
North Star
Choose one product outcome, set a target, and record observations over time. The chart plots values entered by the team.
Backlog
Capture requests as Markdown issues with status and priority, then link them to specs. GitHub and Linear can be referenced; live sync is still planned.
Documentation
Read and edit product documentation in the project folder. Keep decisions and onboarding notes alongside specifications and code.
Vision, Roadmap, and North Star are optional views. Add them through workspace settings or productview.yaml when the project has real content.
RUN & VERIFY
Look inside the software.
Check what actually works.
Go from product progress to the running system. Inspect the services, tests, tools, data, and files behind each release.
Available in the desktop preview / Interface previews illustrate the workflow. Planned capabilities are marked.
Project Map
See the real services, databases, storage, and persistent processes that make up your local system.
Services & logs
Start and stop local services, read their output, and see the build timestamp, commit, optional version, and separate process start time when available.
View full demo screenshot ↗View full demo screenshot ↗Test runs
Run a suite or individual discovered tests and inspect the result and output without hunting for commands.
MCP Explorer
Connect project MCP servers, browse their tools and resources, inspect build identity when provided, and try a tool deliberately.
CLI Explorer
Discover local command-line tools, read their options like a friendly manual, and identify the artifact build before running a trial.
API Explorer
Discover project OpenAPI files, register multiple HTTP APIs, send a request on purpose, and inspect status, timing, and response. Bearer tokens stay local.
Database & storage resources
Collect every configured project source in one place. Inspect supported databases and local files with limited, read-only previews.
Environment variables
See every variable declared for the workspace and its components. Set encrypted local values without putting secrets in YAML or Product Chat.
Spec Kit & requirements
Read existing specs, plans, tasks, and project rules; follow the progress of work stored with the code.
Workspaces & files
Switch local repositories and browse their source trees, with folders collapsed until you open them.
Product Chat
Ask a local coding agent about the project, its tools, and next steps. Type or dictate in the desktop app.
Activity history
See recorded starts, test runs, agent connections, and project changes so the next session has context.
CPU, memory & disk
Historical resource trends for local services and workspaces are planned. The current app shows service state and output.
FOR GITHUB SPEC KIT PROJECTS
The missing control panel for GitHub Spec Kit projects.
Follow specs and tasks in their standard files. Start your app, inspect its data, run tests, and see what your agent has actually built.
Spec Kit gives your agent a plan.
OpenBuildRoom gives you the controls.
A DISCIPLINED BUILDING LOOP
From product direction
to software you can maintain.
Give the agent durable product context. GitHub Spec Kit structures requirements, plans, and tasks. OpenBuildRoom reads that work alongside the running system so each iteration can be reviewed.
Set the product direction
Describe the users, problem, vision, next milestone, and desired outcome. Keep product documents and backlog items in the repository so the agent can refer to them later.
Specify the work
Ask Codex or Claude Code to use GitHub Spec Kit for project rules, feature specs, technical plans, and tasks. OpenBuildRoom reads those existing files.
Map what gets built
Have the agent inspect real commands and propose productview.yaml with services, tests, data sources, and verified links to requirements. Review the configuration.
Operate, verify, and continue
Start services, inspect logs and data, and run tests. Update roadmap status and documentation when behavior changes; commit the shared setup for the next session.
THE PROBLEM
The agent built it fast.
Can you still run it next week?
How do I start this project again?
What is running, and where are its logs?
Which tests and data show it works?
What should the agent build next?
The IDE used to keep these controls close to the code. OpenBuildRoom makes them visible again, alongside product direction and Spec Kit work. Return to the project without reconstructing it from old chats and shell history.
“I’m a bit of a control freak. I built app after app with coding agents, then kept asking the same questions: What’s running? Which build am I looking at? How do I stop it, inspect the data, or run its tests? I used to have those controls close by in an IDE or terminal.
So I made little dashboards for each project. Eventually I realized I needed one reusable project file and a local viewer that makes the software visible and operable. Now the product vision and Spec Kit work can sit beside the running app, too.”
A CONCRETE EXAMPLE
A small file.
A repeatable way back in.
This is the part your team commits with the code. It points OpenBuildRoom to product documents, existing Spec Kit files, and verified local commands. It does not copy your application into another platform.
01
Keep direction visible. Vision, roadmap, and North Star sit in the repository and appear as optional product views.
02
Know what you started. The service uses the declared command. A build file written after a successful build supplies its timestamp, commit, and optional version.
03
Check the work. The suite appears on the Tests page with its actual command one click away.
04
Keep secrets local. The YAML names DATABASE_URL; each developer sets the value on their own machine.
productview.yamlSIMPLIFIED EXAMPLE
schemaVersion: 1
project:
id: atlas
name: Atlas
workspace:
additionalViews: [vision, roadmap, north-star]
apiSources:
- id: atlas-api
name: Atlas API
baseUrl: http://127.0.0.1:4000
spec: specs/001-order-lookup/contracts/openapi.yaml
product:
vision: docs/vision.md
docsRoot: docs
roadmap:
- id: launch
title: First usable release
status: in-progress
documentation: []
northStar:
name: Weekly active teams
unit: teams
cadence: weekly
target: 100
measurements: []
views:
specifications:
roots: [specs]
components:
- id: web
kind: service
name: Web app
position: { x: 15, y: 80 }
build: { file: dist/web/build-info.json }
runtime:
command: [node, dist/web/server.js]
cwd: .
port: 3000
startup: manual
- id: database
kind: database
name: PostgreSQL
position: { x: 70, y: 80 }
data:
engine: postgres
connectionEnv: DATABASE_URL
- id: tests
kind: testSuite
name: Test suite
position: { x: 15, y: 250 }
tests:
command: [npm, test]
cwd: .
connections:
- { from: web, to: database, label: uses }YOUR CODING AGENT, IN CONTEXT
Keep talking.
Keep seeing.
Product Chat connects to a locally installed Codex CLI or Claude Code setup. Talk through a new feature, ask what changed, and let the agent help update specs and project configuration in edit mode. OpenBuildRoom gives you the documents and local runtime to inspect as the work progresses.
Review the agent’s edits before treating the map as accurate. Services and tests run only after you click Start or Run; environment values stay outside the repository.
Product conversationILLUSTRATION
I want a checkout flow. Specify it with Spec Kit, then show me what needs to run.
◇
I’ll draft the spec, plan, and tasks in the repository. Then I’ll propose the related services, data source, and test commands in productview.yaml for your review.
Ask about this project…↗
PRODUCT & DEVELOPER QUESTIONS
What OpenBuildRoom
actually does.
How do I steer the product as a product owner?
Keep your vision, backlog, roadmap, North Star definition, and documentation in the repository. OpenBuildRoom shows these beside Spec Kit work and the local app. Vision, Roadmap, and North Star are optional views you enable when they have meaningful content.
Does it replace my terminal or editor?
No. It gives you a reliable entry point into the same local repository. Configured commands still run as real local processes, and the source stays in your editor.
Does it automatically know how every repo starts?
It can discover some project structure and tools. A coding agent can help draft the configuration, but you verify the commands, dependencies, and data sources before using them.
What happens to my Spec Kit files?
They stay in the repository. OpenBuildRoom reads existing .specify/ and specs/ artifacts, then lets you link verified requirements to components and test suites.
How does it work across projects?
Each repository keeps its own productview.yaml and product documents. The desktop app lets you switch local workspaces, so each project has a familiar place for its setup, tests, data, and activity.
How does it fit beside cloud deployment?
OpenBuildRoom focuses on the local development system. Your cloud platform still handles deployment and hosted operations. Direct Railway deployment is a future direction, not a feature of the current preview.
WHERE IT STANDS
A working desktop preview.
More to build.
OpenBuildRoom Desktop runs locally on macOS. The Apple Silicon preview is available for download, alongside its source and agent guide.
AVAILABLE IN THE PREVIEW
Direct and inspect a local project
- Vision, roadmap, North Star, local backlog, and Markdown documentation
- Repository configuration, onboarding, files and Spec Kit reading
- Project Map and manual service start/stop with output
- Artifact build time, commit and optional version when build metadata exists
- Test runs, data previews, CLI, MCP and API explorers
- Local Codex CLI or Claude Code chat and activity history
PLANNED, NOT SHIPPED
Make the view more complete
- Long-term process and performance history
- Stronger evidence linking requirements to behavior
- Live issue sync and automatic outcome measurements
- A reviewable path toward Railway deployment
OPENBUILDROOM
Start with an idea.
Keep building for years.
A clear framework for the work, and a local control room for the software that grows from it.
Download free for Mac