Building Solo Taught Me What PM Process Is Actually For

The real job was getting people to agree

For most of my career as a project manager and product owner, deciding what to build was rarely the hard part. The hard part was getting everyone with a stake in it to actually agree, before a single line of code got written. Specs, sign-off meetings, review rounds: most of that existed to converge other people's opinions, not to describe the feature.

Then I built WEREVEN on my own: an app for splitting shared expenses in a group, taken from a rough Flutter version in February to a published app on Google Play by August. There was nobody to get on the same page with. I decided what it should do, and then I built that.

No proposal, no review round, no "let's align on this before we commit." The decision and the agreement were the same moment, because there was only one person in the room.

What a spec was actually buying

A spec was never really a description of a feature. It was the thing you pointed to when two people needed to agree on what was about to happen before either of them committed real time to it. Every round of feedback on a ticket was less about the wording and more about closing the gap between what I meant and what someone else was picturing.

Build alone, and there's no gap to close, because there's no second opinion to reconcile with. I still make every one of those calls: what counts as done, what an edge case should do, what gets cut. I just make the call and move, instead of writing it down so someone else can agree to it later.

What didn't disappear

Some of the discipline stuck around anyway, and that's the part worth noticing. WEREVEN went from a single-event app to a multi-event one across six phases, lettered A through F: a new data model, then a database layer, then the state management rewired to use it, then the UI wired on top, each one shipped and working before the next one started. Nobody made me break it down that way.

I did it because skipping straight to the end result is how you end up debugging five new things at once instead of one. I also still run a pre-merge checklist on every feature, even though I'm the only one who'll ever read it: tests passing, static analysis clean, docs updated, the plan file cleared once the feature actually lands. A pre-commit hook blocks the commit outright if the tests or the analyzer aren't clean.

None of that exists to convince anyone else the work is good. It exists because the checklist is how I catch my own mistakes, not someone else's doubts. That part of the job was never about communication in the first place.

Ceremony versus load-bearing

That's the line I'd draw now between what's ceremony and what's load-bearing. A status update mostly exists to prove progress to someone who isn't in the room to see it directly. A heavily detailed ticket often exists to protect against a disagreement later about what was actually agreed to.

Neither one makes the software better on its own. They exist to manage trust and expectations between people who aren't looking at the same thing at the same time. Breaking a rewrite into six verifiable phases, or refusing to skip the checklist because nobody's watching, isn't about managing anyone else.

It's how you'd work even with zero audience, because the alternative is shipping confidently wrong. That's the test I use now.

Taking it back to a team

I'm not arguing every team should stop aligning with each other. Most teams genuinely need to; that's a real part of why distributed work functions at all. But building WEREVEN alone made the difference between agreement-seeking and actual thinking impossible to miss.

When I'm back in a room with a team, I can tell which meeting is building shared understanding and which one is just insurance against a disagreement nobody's willing to have directly. I treat them very differently now.