The Messenger thread from month one reads like a post mortem.
"Are you on the contracts view?" "Wait, did you just push to main?" "I'll wait." "Actually I pushed already, sorry." Three threads like that in a single afternoon. By evening, one of us had overwritten the other's branch. The work wasn't lost, but an hour went to untangling it. That was a Tuesday. By Friday it had happened twice more.
Zsombor was in Finland. I was in Budapest. We were building VitalRegistry, a rental CRM for BEMER device distributors, and we had exactly zero system for coordinating. We had a shared repo, a group chat, and the optimistic assumption that two brothers who knew each other well would naturally stay in sync. We did not.
The problem that doesn't look like a problem
The failures weren't dramatic. Nobody rage quit. The app kept moving forward. But the cost was invisible and cumulative. Features went quiet for two weeks because neither of us had clearly handed off the thread. A database schema change sat in a branch for ten days while the other person built on the assumption it was already merged. Standups, when we had them, were 40 minutes of catching up and 10 minutes of actual planning.
The hardest problem on a small team: two people in the same repo trying not to step on each other's branches. We solved it eventually with GSD and an adversarial review and fix pipeline. We did not solve it during the build of this product.
We solved it after.
Three things that failed first
Long standups. We tried daily voice calls when the build was active. They held for about two weeks. Then one stretched to an hour arguing about Streamlit billing math and two days later neither of us felt like scheduling the next one. The format required both of us alert, available, and at a keyboard simultaneously. That condition held maybe three days out of seven.
"Just message me when you start something." This is the informal system most small remote teams default to. It fails because the message never comes. You start a task when you're in flow, not when you're thinking about coordination. By the time the other person sees it, you're already three files in.
Shared Notion pages nobody looked at. We had a board. It existed. Cards moved on it approximately never. The problem with any shared tracking tool is that updating it is a second job that only pays off if the other person checks it, and both conditions fail simultaneously.
The 3-rule system we use now
Around month four, Zsombor and I had a direct conversation about the coordination tax. Not a retrospective. A specific accounting: here are the three things that burned hours this month that shouldn't have. Three rules came out of it. None of them are clever. All of them have held.
Rule 1: Async standups in a shared doc, not a call.
Each of us writes three lines at the start of a work session: what got done, what is getting done today, anything blocking or needing a decision. The doc is a shared Google Doc, always the same one, newest entry at the top.
It's not a meeting. It's a log. Zsombor writes his at 9am in Finland. I write mine whenever I open the laptop in Budapest. No scheduling, no overlap required.
Rule 2: One weekly 20-minute call, fixed day, non negotiable.
Twenty minutes is not enough to solve architectural problems. That's the point. The constraint forces triage. Usually one or two things actually need a live discussion. The rest gets handled in the doc.
The call happens on Thursday. If someone is unavailable, we move it by 24 hours, maximum. It hasn't been skipped since we formalized it.
Rule 3: Nothing moves on the board without a linked commit.
A card in "done" with no commit link means someone moved a card. A card with a commit link means the work shipped. These are different states and they are easy to confuse when you're tired and want to feel like the week was productive.
The linked commit rule also means the board doubles as a lightweight code review trigger. Card moves with a commit link tell the other person exactly what to look at. No separate "hey can you review this" message needed.
The accountability decision
Options considered: More calls, more structure, a dedicated project management tool, or the async first system we landed on.
Chosen: Async doc standups, weekly 20-minute call, linked commits.
Rationale: The coordination failures were happening because we were optimizing for synchronous moments neither of us could reliably hold. Two people in two countries, building part-time around other commitments, can't guarantee overlap. The async doc puts coordination in a pull model. Each person writes when ready and reads when they open the doc. The weekly call is the only sync moment; its brevity forces triage. The linked commit rule closes the loop between the board and the codebase so the board reflects reality instead of intention.
Tradeoff: Async first is slower for fast iterative decisions. If we're debugging together on a tricky bug, we need a call, not a doc. The system doesn't replace judgment. It replaces the ambient coordination tax we were paying on every ordinary workday.
What accountability actually is for a two person remote team
Not more meetings. Shared visibility that doesn't require you to be present simultaneously.
The Messenger threads stopped when we had somewhere else to put the information. "Are you on the contracts view?" became a standup entry. "Did you just push?" became a linked commit card that answered the question before it was asked.
Two months after we locked in the three rules, the repo collisions stopped. Not reduced. Stopped. The features that were going dark for two weeks started landing in three to five days with a clear handoff. The 40-minute catch up calls became 18-minute calls where we mostly just confirmed what the doc had already said.
VitalRegistry shipped on that system. The ten distributors running ten to thirty devices each on the platform today didn't see any of the coordination work. They saw a CRM that arrived in a reasonable state. The accountability system is why.
For your own setup: if one of you disappeared for a week with no notice, would the other person know what was in progress, what was blocked, and what needed a decision? If the answer is no, the system isn't the async doc or the weekly call. The system is whatever makes that answer yes.