You hired a developer. Every week or two, money leaves your account, and a message arrives: “good progress, almost done with the tricky part.” You believe them — you mostly have no choice. You can’t read the code, you can’t see the work, and asking too many questions feels like distrust.
Here’s the thing nobody tells non-technical founders: the work leaves a paper trail whether anyone reads it or not. Every real software project lives in a repository — a folder with a complete, timestamped history of every change ever made, called commits. Your developer uses it every day. You own it (or should — here’s how to fix that), and you don’t need to read code to learn a lot from it.
Here are five signals worth knowing about.
1. The rhythm of the work
Open your repository on GitHub and look at the timeline of commits. You’re not reading the contents — just the dates. Healthy projects have a rhythm: changes land most working days, in reasonable clusters. What deserves attention is silence followed by a burst — nothing for two weeks, then a mountain of changes the night before your check-in. Sometimes that’s just how someone works. Sometimes the mountain was built in one panicked evening. The rhythm doesn’t convict anyone, but it tells you which questions to ask.
2. Vague messages, tiny changes
Every commit carries a short description written by the developer. “Add password reset flow” is a good sign. Nine commits in a row saying “misc fixes” or “updates” — each touching a couple of lines — is the software equivalent of a contractor’s invoice that just says “work: 40 hours.” Professionals narrate their work because they’re proud of it and because the next developer will need the story.
3. Volume is the easiest thing to fake
If your developer reports progress in “lines of code written,” be careful: lines are the least meaningful measure in software. Modern tools can generate thousands of lines of boilerplate in seconds, and copying an open-source library into the project can add tens of thousands more — none of it original work. Meanwhile, the most valuable change of the month might be forty lines that took three days of hard thinking. Some of the best weeks in a project’s life actually make the codebase smaller.
4. Tests are a tell
Automated tests are extra code that checks the real code works. You don’t need to understand them — you only need to know whether they exist and whether their number grows as features get added. A project with zero tests after six months isn’t necessarily a scam, but it is a project where “it’s done” means “it ran on my laptop once.” Ask your developer how the project is tested. The quality of the answer tells you plenty.
5. The update-versus-history gap
The strongest signal is the simplest: does the story you’re being told match the story the history tells? If the update says “huge week, payments almost done” and the history shows two small changes to a configuration file — that gap is worth a conversation. Not an accusation: git can’t see meetings, debugging dead-ends, or infrastructure work, and an honest developer can have an invisible week. But gaps that appear every week are a pattern.
The honest caveat
None of these signals proves anything on its own, and all of them can be misread — which is exactly why “just check the repo” isn’t a full answer. Cadence varies by person, some brilliant work looks tiny, and some padding looks impressive. The fair way to use the history is as a source of good questions, not verdicts.
That’s the gap DevWatch was built for: it reads your entire project history, weighs every change by how difficult it actually was, filters out the padding, and writes you a plain-English report — with honest uncertainty where the evidence is thin. Your first report is free, and it takes about two minutes to run.
Your developer sends invoices. Someone should read the code.