Documentation / Guides

Updated July 25, 2026 · About 9 min read

One Screen Per Project: The Live Project Dashboard

Most of a solo developer's day isn't spent writing code. It's spent figuring out where things stand - is the build green, did the tests pass, is the branch ahead of origin, is the dev server still up. One live screen per project answers all of that at a glance, so you can stop being a human status checker.

Why one live screen beats hopping between terminal and tabs

Picture the usual way you check a project. You switch to the terminal, run tests, wait. You open another terminal to check git status. You flip to a browser tab to see whether the dev server is still responding. You find a third tab for the deploy logs. By the time you've assembled the picture, you've opened five windows and lost the thread of what you were actually doing.

None of those steps is hard on its own. The cost is that they're scattered, and gathering them is a chore you repeat dozens of times a day. Each check is a small interruption, and the sum of the interruptions is most of your attention.

One live screen flips the order. Instead of you going out to investigate the project, the project reports back to one place. The build result, test status, git state, and running services all sit on a single surface you can read without typing a command:

• No hunting - the answers you check most are already on the screen, not one command away.
• No juggling terminals - one place to look instead of a fan of windows to keep track of.
• No half-remembered commands - you stop memorizing the incantation to learn something you check ten times a day.

What belongs on the dashboard

A dashboard is only useful if it shows the things you actually check by hand, rather than just adding noise. In most projects, four categories earn their place:

1. Build status. Whether the last build succeeded, and how long ago. A red build is the first thing you want to know, because everything downstream depends on it.
2. Test results. The suite's pass or fail state, ideally with a count and a timestamp. A suite that went green an hour ago and one that went green thirty seconds ago say very different things.
3. Git state. The current branch, whether you're ahead of or behind origin, and whether there are uncommitted changes. This is the question you answer with a command more than almost any other.
4. Running services. Whether the dev server is up, whether the database container is alive, whether something crashed. A service that died quietly is exactly the kind of problem you want the screen to surface, not discover an hour later.

The test for whether something belongs is simple: if you type a command to learn it several times a day, it belongs on the dashboard. If you check it once a month, it doesn't. Resist the urge to cram every metric onto the screen - a dashboard that shows everything ends up showing nothing, because the signal you care about drowns in the clutter.

Live state vs. stale snapshots

The most important property of a project dashboard is that it's live. A snapshot - the output of a command you ran at some point - is accurate for exactly one moment, and then it starts to rot. The test run you kicked off ten minutes ago says green, but you've committed twice since. The git status you glanced at was from before the agent pushed a fix. The service was up when you last checked.

Stale state isn't just useless - it's actively dangerous, because it looks like information. A green check reflecting a build from an hour ago gives you false confidence. You make a decision on it, deploy on it, move to the next thing on it, and only afterward discover the check lied by omission.

A live screen closes that gap. It updates itself as reality changes: the test badge flips when a run finishes, the git line updates when a commit lands, the service indicator turns red the moment a container crashes. You never have to ask "is this still true?" because the screen has already answered.

• Trust by default. When the screen is always current, you can act on it without re-verifying, which is the whole point of having it.
• Failures surface themselves. A crashed service or a suite gone red shows up on its own instead of waiting for you to go looking.
• No stale-check trap. Live red state is honest; stale green is the bug that bites you later.

Cutting the context-switching cost

The hidden expense of the terminal-and-tabs approach isn't the seconds spent typing commands. It's the mental reload. Every time you leave the work to check something, you drop the fragile picture you were holding in your head, and when you come back you have to rebuild it. Do it enough times and you spend more energy reassembling context than making progress.

This gets dramatically worse the more projects you have. A solo developer with five side projects can't hold five mental models at once. Switching from one to another means reconstructing each one's state - which branch, what failed, what's left half-done - from scratch, usually by running the same handful of commands over and over.

A dashboard that already holds the state eliminates the reconstruction step. When the picture lives on the screen instead of in your head, switching between projects costs a glance instead of an investigation:

• The screen remembers so you don't have to. Coming back to a project after a week, you read its status instead of re-deriving it.
• Switching is cheap. Moving between projects is a click and a glance, not a fresh round of diagnostic commands.
• Attention stays on the work. The attention you save on status checks is attention you spend on the change itself.

Designed for a glance, not a read

A dashboard succeeds or fails on whether you can grasp it in a single glance rather than a careful read. The goal is to look for half a second, absorb the state, and look away - not to parse a wall of text to extract the one fact you needed.

That puts a premium on how the state is presented. Color and shape carry meaning faster than words: a green badge, a red badge, a spinner for something in progress. The eye finds the single red thing on a screen of green instantly, and that's exactly the thing it matters most that you notice. Numbers and timestamps back up the badges for when you want the detail, but the top-level read should land before you start reading consciously.

• State as color, not prose. Green, red, and yellow-running are read pre-consciously; a sentence has to be parsed.
• One glance, one answer. Each tile should answer one question, so scanning the screen is scanning a list of answers.
• Detail on demand. Keep the surface calm and let numbers, logs, and history live one click deeper, for when you actually need them.

Making the dashboard your home base

The payoff comes when the dashboard becomes the first thing you look at and the place you return to between tasks. Not a screen you open when something feels off, but the ambient backdrop of your work - the way you'd watch a cockpit's instrument panel instead of checking each gauge in turn.

• Start there. Open the project screen before you begin working, so you start from a known state instead of a guess.
• Return there. Between tasks, a glance at the dashboard tells you whether anything changed while your attention was elsewhere.
• Let it interrupt you, not the other way around. When the screen surfaces a red build or a dead service on its own, you respond to real problems instead of hunting for them by hand.
• Trust it enough to stop checking by hand. The habit worth building is not running the status command out of reflex, because the screen already told you.

Done right, the dashboard melts into the background of how you work. You stop feeling the constant low-grade uncertainty of "wait, what state is this in?" because the answer is always there, always current, one glance away.

Go deeper: Readable test failure reports - when the dashboard shows a red suite, here's how to turn the failure into something you can act on in seconds instead of decoding line by line.

Frequently asked questions

What should be on a single-project dashboard?

The few things you'd check manually anyway: the last build result, the test suite status, the current git state (branch, ahead of or behind origin, uncommitted changes), and whether the project's services are running. If you type a command to learn something several times a day, that answer belongs on the dashboard where you can read it at a glance.

Why does live state matter more than a snapshot?

A snapshot tells you what was true the last time you ran a command, which is exactly the moment it starts going stale. Live state updates itself as tests finish, commits land, and services come up or crash, so the screen always reflects reality. A stale green check is worse than no check at all, because it convinces you everything is fine when it isn't.

How does one screen per project reduce context-switching?

Every terminal window and browser tab you open to check a project is a small tax on your attention, and coming back means rebuilding the mental picture you lost. One screen that already holds build status, tests, git, and services collapses all of that into a single glance, so you spend your attention on the work instead of reassembling the state.