There's a pattern every experienced developer learns the hard way. You sit down to build something, you get about forty minutes in, and you realize the thing you're building doesn't quite match the idea that motivated it. You keep going because the sunk cost is already there. The result is fine. It is not what you meant.
The root cause is almost never the implementation. It's that the plan was never written down, or the plan was written down but half the decisions implied by it were never made.
Key takeaways
- Most software that misses its idea fails at the plan, not the code: decisions were never written down or never made.
- Decisions don't get harder later, but changing your mind gets more expensive the further into implementation you go.
- Planning gets skipped because it produces no visible output and because ideas arrive away from a desk.
- A spec answers the open questions before implementation starts, so what remains is execution.
The decision cost curve
Every decision you defer into the implementation phase gets more expensive. The schema shape you didn't pin down becomes a migration. The auth boundary you didn't mark becomes a security review. The edge case you didn't name becomes a production incident.
Studies of the cost of fixing errors show the same curve: NASA's study of error cost escalation found that the cost to fix an error rises as a project matures, and NIST's 2002 report on software testing tabulates the relative cost of repairing a defect at each stage of the life cycle.
The decisions themselves don't get harder. The cost of changing your mind gets higher. An idea has infinite malleability at 11pm on a walk home. By the time it's 400 lines of Go with tests, it has almost none.
Planning is the phase where decisions are cheap. The act of writing a plan is the act of buying decisions while they are still cheap.
Why does planning get skipped?
Even people who believe in planning often skip it. Two reasons come up over and over.
The first is that planning feels like it isn't producing anything. There's no diff, no green test, no running app. The dopamine shape of planning is flat where the dopamine shape of coding is spiky. You feel like you're moving when you're coding. You feel like you're stalling when you're planning — even when planning is what unblocks everything else.
The second is friction. Good planning requires you to sit down somewhere quiet, open a document, and write. Ideas do not arrive when you are sitting down somewhere quiet. They arrive on the subway, at the gym, in the shower, in the middle of an unrelated conversation. The moment you could plan, you have no surface. The moment you have a surface, the plan has decayed.
What Bridge is for
Bridge is the surface where the plan lives between the moment the idea arrives and the moment you sit down to build. It is a phone-first planning tool for exactly that reason: the phone is the only surface that is always with you when an idea shows up.
Capture is a typed, pasted or dictated note. You don't categorize. You don't title. You get the idea out of your head and into the system before it decays.
Related notes come together. You captured three things last week that turn out to be one idea; Bridge groups them into a constellation, and that constellation becomes the venture.
When you tap Build Plan, Bridge works through the questions the idea implies. Not "what are the features." The harder ones: what is this assuming about persistence, what fails if the user is offline, where is the auth boundary, what is the minimum data shape that could represent the core object. The questions a senior engineer would ask if they were sitting across from you. Bridge settles each one it can from what your notes say and writes the decision into the plan; a question your notes leave open stays marked in the plan for you to decide.
And then one tap produces a spec set a developer can implement against: a brief, the one end-to-end user flow, the architecture, the data model, ordered tasks, acceptance conditions and the scope, plus an AGENTS.md that points a coding agent at them. The demo walks through the full workflow, and From the Notes App to the Spec follows one idea all the way through.
The artifacts are the point
Bridge doesn't produce a summary. It produces a spec.
The difference matters. A summary is a human-readable description of what you were thinking. A spec is a structured document that a developer — or an agent — can build from without guessing. 04_data_model.md is not a paragraph about your data. It defines the entities and the function signatures. 06_acceptance.md is not a hope about quality. It lists the conditions that mean done.
When the implementation phase starts, there are no open questions about the shape of the thing that you haven't seen: each one is decided or marked. The questions that needed to be answered were answered in the planning phase, when they were cheap. What is left is execution.
Planning is execution
The implication of all this is that the line between "planning" and "doing" is not where it feels like it is. Planning looks like it happens before the work. It is actually the first and most important layer of the work.
Everything downstream — the code, the tests, the review, the deploy — is cheaper when the plan is complete and more expensive when it isn't. An hour of planning in the right place regularly saves a day of implementation. That ratio is not a claim. It's a thing every senior engineer has felt in their own career. Spec, Plan, Build, Review: A Workflow for Agent Coding shows the code, test and review steps with a coding agent: tasks that each end in a test, built one at a time, then a fresh agent's review.
Bridge is the tool I wanted when I had an idea on the train and wanted it to become a plan by the time I got home. It's what I'd hand to a developer, or to a coding agent, instead of a four-paragraph description of what I was thinking about.
The plan is the leverage point. Bridge is where the plan lives.
Frequently asked questions
Why is planning the highest-leverage part of a software project?
Because decisions are cheapest before code exists. The schema you leave open becomes a migration, the auth boundary you leave unmarked becomes a security review, and the unnamed edge case becomes an incident. Writing the plan buys those decisions while changing your mind still costs little.
What is the difference between a summary and a spec?
A summary describes what you were thinking. A spec is a structured document a developer or a coding agent can build from without guessing: the entities and function signatures themselves, and the conditions that mean done, not paragraphs about them.
Does planning slow a project down?
It feels that way, because a plan produces no diff, test or running app. In practice it unblocks everything after it: an hour of planning in the right place regularly saves a day of implementation, a ratio every senior engineer has felt.