How to track developer progress as a non-technical founder

You asked on Tuesday how checkout was going. "Almost there, just a couple of edge cases." You asked again the following Monday and got the same sentence, with the same confidence. Both times it was true. Nobody misled you, and you still cannot tell whether the thing ships this week or next month.

That is the real problem behind the question of how to track developer progress as a non-technical founder. Not authority, not access: every channel you have runs through a person describing their own work, and self-reports are hard to read even when everyone is being straight with you.

The existing advice is right about the part it covers

Rahul Varshneya's Forbes piece is the canonical version of the anti-micromanagement case, and it deserves taking seriously: "Developers don't like someone shadowing them and micro-managing during the development phase", and, more usefully, "don't expect a code push and build to check every day or each week during the development process", because "oftentimes, there isn't much to showcase as progress that you can evaluate in terms of a build on the phone" (forbes.com, 13 January 2017). Three days of real work can produce nothing you could look at. That is correct.

Vadim Kravcenko's answer to the adjacent question — what a founder should do while the product is built — covers business development, fundraising, customer development and culture. Its one line about progress runs the other way: "Show progress every week, celebrate quick wins, spot burnout before it lands" (vadimkravcenko.com). Advice about what the founder gives the team, not what they read from it.

Both leave the same gap: they tell you how to behave and never say where to look.

A status column is a second copy of the truth

The obvious place to look is the project board, and the board is not a signal.

A status field is a claim somebody typed: a second copy of a fact that lives somewhere else, only as current as the last time a busy person remembered to copy it. None of this needs anyone to be dishonest. The board is least accurate when the team is busiest, because updating it is a second job performed after the real one. It gets tidied shortly before someone senior looks at it, which is exactly when you would want it independent. And a card reaches Done because one person believes it is done, which is a different claim from the one you are trying to verify.

You are not looking for a better board ritual. You want a status nobody has to produce for your benefit.

The merged pull request is the one status you can read

One artefact in a software workflow qualifies: the merged pull request. It exists whether or not you look, because it is a step in the work rather than a report about it. It is dated, attributable, and discrete in a way "eighty percent done" is not.

GitHub treats it as the terminal event too: "When you merge a linked pull request into the default branch of a repository, its linked issue is automatically closed" (docs.github.com).

That page is also worth reading for what it withholds. The closing keywords — close, fix, resolve and their variants — "are interpreted only when the pull request targets the repository's default branch. If the pull request targets any other branch, then these keywords are ignored, no links are created, and merging the PR has no effect on the issues." The mechanism is closure, and closure has two states. Read the repository directly and you get commits, which are noise, and issues that flip from open to closed. The part of the week you most want to see — written, now waiting on a human — has none.

Tracking developer progress as a non-technical founder, without asking

The setup you want has one property: the board changes state because git did something, not because someone remembered. We build Kevta, so read what follows as illustration, not neutral survey.

Each issue hands out its own branch name. The copy button emits feature/MS-42-add-checkout-validation: a type prefix the board sets, the issue's permanent key, then the title lowercased, folded to ASCII and cut at 50 characters. The developer pastes it, and the key is in the branch — the only segment doing work.

Nothing needs linking after that. When a pull request appears, Kevta scans the branch ref, the title and the body for the board key followed by alphanumerics, so the key can sit anywhere and the -add-checkout-validation tail is ignored. No magic word and no step to forget. Rules then bind git events to states, and a new board arrives with eight, five switched on:

The three switched off are reverse transitions — back to draft, changes requested, closed unmerged — because dragging finished work backwards should be a decision, not a default. Which git events are worth binding to a state, and which are not, is its own argument.

Two limits, stated plainly

This only works if the developers use the branch names. Branch fix-thing and there is no key, no match, and the issue sits in To Do while the work happens. That is a habit, not a feature. But the only thing you ask for is small and checkable — use the branch name off the issue — instead of status, which is the request that grates.

The second limit matters more if you are shopping for a management tool. Kevta has no reporting: no burndown, no velocity, no dashboards, no Slack app posting a daily summary, no chart of anyone's output. If someone asks for a progress graph at the end of the quarter, it cannot draw one. What you get is a board that is current and readable four ways — board, list, table and calendar, with grouping and filters on top (the docs). A truthful signal, not a management console.

What the signal is actually for

Your question changes shape. You stop asking how it is going, because you can see, and start asking the one thing the board raises on its own: this has been in review since Tuesday, who is it waiting on. That is a question about a queue rather than a person's productivity, and unblocking queues is what a founder is well placed to do. The rest of what a small team needs from a tracker is in what a five-person team needs from issue tracking.

None of it covers everything. Work with no code attached — a schema argument that took two days, a supplier decision, research that ruled an approach out — leaves no merge behind and never will. You still talk to people; the point is that you spend those conversations on what git cannot tell you.

Kevta is in beta. If a board that moves off your team's own git activity is what you have been approximating with a Friday check-in, join the waitlist for an early invite, a founding-member price at launch, and a direct line to shape what we build next.