Sep 15, 2026
By Victor Teran
The Founder Reporting Stack That Runs Without You
Most founder reporting is a weekly hour of copying numbers between tabs, and it is the first thing to go the week something urgent happens. Ours runs on a weekday schedule nobody triggers, and the design decision that made it stick was not technical.
Automation
Systems
Reporting
There is a specific category of work that is important, repeatable, and quietly optional. Reporting is the purest example. Nobody notices the week you skip it. You notice about six weeks later, when a decision arrives and the numbers to make it with do not exist.
The instinct is to fix that with discipline. Discipline is the wrong tool, because the task is competing against genuinely urgent work and will lose every time it is close.
The fix is to make the reporting happen without a decision. Below is how ours works, including the part that has nothing to do with tooling.
Key takeaways
A weekly report is the shape of task that quietly stops happening. A daily one that takes two minutes does not.
Our outbound pipeline has run on a weekday schedule since 29 July 2026: 427 companies contacted across 25 run days, with no human ever starting a run.
Automate the volume, keep the judgment. Of those 427, 332 went to an automated sequence and 95 stayed manual on purpose.
Reporting that nobody reads is worse than none, because it produces the feeling of oversight without the fact of it.
Why does weekly reporting stop happening?
Because a weekly pile is easy to defer once, and deferring it once is how it ends.
Miss a Monday and the following Monday has two weeks of work in it, which makes deferring more attractive, not less. The failure compounds, and it always resolves the same way: the report quietly becomes a thing you used to do.
We hit this exactly. Our outbound pipeline originally ran weekly, and at the end of July 2026 we moved it to every weekday for one reason that had nothing to do with engineering. A weekly batch of drafts to review is the shape of task that quietly stops happening. A handful each morning does not.
That is the design principle underneath everything here. Match the cadence to the behaviour you can actually sustain, then build the system around that, rather than building the ideal system and relying on yourself to keep up with it.
What does "runs without you" mean in practice?
No human triggers it, and nothing waits for a human to notice.
The pipeline runs on GitHub Actions on a weekday schedule. Between 29 July and 2 September 2026 it contacted 427 companies across 25 run days. Nobody started a single one of those runs.
The numbers underneath matter more than the total:
Measure | Value |
|---|---|
Companies contacted | 427 |
Run days | 25, weekdays only |
Pushed to an automated sequence | 332 |
Kept as drafts for manual review | 95 |
Runs triggered by a human | 0 |
That 332 / 95 split is the whole philosophy. The automated path handles reach, where a failure costs a wasted send. The manual path handles the leads where a wrong sentence costs a relationship, and it is the highest-converting step in the system.
The value of automation was never removing the founder from the loop. It was removing the founder from the 332 so there was attention left for the 95.
FREE GUIDE
The 4 product leaks costing you growth
A short audit guide for founders. Find the four places your product leaks revenue, and what to fix first.
What should a founder actually get every morning?
A short, boring, consistent set of numbers you would notice the absence of.
The test for whether a metric belongs in a daily brief is not whether it is interesting. It is whether a change in it would alter what you do that week. Most dashboards fail this and become wallpaper.
A workable minimum for a founder-led product business:
1. Pipeline in. New qualified leads or bookings since yesterday, and the source. 2. Activation. New signups reaching your defined value moment, on a fixed window. If you have not defined that event, this line is not available to you yet. 3. Retention shape. Weekly cohort return rate, not a single blended number. 4. Cash. Money in, money out, runway in months. Boring, and the one that changes decisions fastest. 5. One thing that broke. Failed payments, failed jobs, errors above a threshold.
Five lines. If it takes longer than two minutes to read, it will stop being read, and an unread report is worse than no report because it produces the feeling of oversight without the fact of it.
Where do these systems go wrong?
They keep running while producing wrong numbers, and a wrong number looks exactly like a right one.
This is the failure mode worth planning for, and it is not hypothetical. Our own pipeline shipped four separate bugs that produced plausible output and raised no error. Substring matching classified a sales role as a design role. An ordering dependency silently disabled the highest-priority feature. A deduplication key collided on company name. And one data source turned out to carry a usable contact on only about half its records.
None of those crashed. Every run reported healthy. We found all four by reading the output, not by being alerted, and we have written up why that class of failure survives so long.
This is not a small-operation problem. Google's SRE practice is built around alerting on symptoms precisely because causes are too noisy to page on (Google SRE), and a wrong-but-plausible result produces no symptom at all. Meta documented the same phenomenon in hardware, where data errors go undetected by the wider system (Engineering at Meta). Google reported CPU cores that quietly compute wrong answers while appearing entirely healthy (Hochschild et al., HotOS 2021).
The practical defence is three habits, none of which need new tooling:
Read the actual output weekly, not the summary. Open the artefacts and read a handful end to end.
Assert on shape, not exit code. Make the job check the things you would check by eye, and be loud when they fail.
Write down what correct looks like before you build. A system with no written definition of a correct result cannot be wrong, which is comfortable and is precisely the problem.
What should you automate first?
The task you have already skipped twice.
Not the most complex one, and not the most time-consuming. The one that keeps not happening, because that is the one where the system is genuinely doing something you cannot.
Then apply the same split we use: automate anything whose failure mode is a wasted send, and keep a human on anything whose failure mode is a burned relationship. That line is worth drawing explicitly, in writing, before you build, because it will otherwise get redrawn every time the automation looks tempting.
The compounding argument is simple. Five minutes a weekday is twenty hours a year. Getting that back matters far less than the fact that the numbers now exist when a decision arrives, and that the decision no longer waits on you finding an hour.
WHAT NEXT
Want this fixed in your product, not just explained?
Sep 15, 2026
By Victor Teran
The Founder Reporting Stack That Runs Without You
Most founder reporting is a weekly hour of copying numbers between tabs, and it is the first thing to go the week something urgent happens. Ours runs on a weekday schedule nobody triggers, and the design decision that made it stick was not technical.
Automation
Systems
Reporting
There is a specific category of work that is important, repeatable, and quietly optional. Reporting is the purest example. Nobody notices the week you skip it. You notice about six weeks later, when a decision arrives and the numbers to make it with do not exist.
The instinct is to fix that with discipline. Discipline is the wrong tool, because the task is competing against genuinely urgent work and will lose every time it is close.
The fix is to make the reporting happen without a decision. Below is how ours works, including the part that has nothing to do with tooling.
Key takeaways
A weekly report is the shape of task that quietly stops happening. A daily one that takes two minutes does not.
Our outbound pipeline has run on a weekday schedule since 29 July 2026: 427 companies contacted across 25 run days, with no human ever starting a run.
Automate the volume, keep the judgment. Of those 427, 332 went to an automated sequence and 95 stayed manual on purpose.
Reporting that nobody reads is worse than none, because it produces the feeling of oversight without the fact of it.
Why does weekly reporting stop happening?
Because a weekly pile is easy to defer once, and deferring it once is how it ends.
Miss a Monday and the following Monday has two weeks of work in it, which makes deferring more attractive, not less. The failure compounds, and it always resolves the same way: the report quietly becomes a thing you used to do.
We hit this exactly. Our outbound pipeline originally ran weekly, and at the end of July 2026 we moved it to every weekday for one reason that had nothing to do with engineering. A weekly batch of drafts to review is the shape of task that quietly stops happening. A handful each morning does not.
That is the design principle underneath everything here. Match the cadence to the behaviour you can actually sustain, then build the system around that, rather than building the ideal system and relying on yourself to keep up with it.
What does "runs without you" mean in practice?
No human triggers it, and nothing waits for a human to notice.
The pipeline runs on GitHub Actions on a weekday schedule. Between 29 July and 2 September 2026 it contacted 427 companies across 25 run days. Nobody started a single one of those runs.
The numbers underneath matter more than the total:
Measure | Value |
|---|---|
Companies contacted | 427 |
Run days | 25, weekdays only |
Pushed to an automated sequence | 332 |
Kept as drafts for manual review | 95 |
Runs triggered by a human | 0 |
That 332 / 95 split is the whole philosophy. The automated path handles reach, where a failure costs a wasted send. The manual path handles the leads where a wrong sentence costs a relationship, and it is the highest-converting step in the system.
The value of automation was never removing the founder from the loop. It was removing the founder from the 332 so there was attention left for the 95.
FREE GUIDE
The 4 product leaks costing you growth
A short audit guide for founders. Find the four places your product leaks revenue, and what to fix first.
What should a founder actually get every morning?
A short, boring, consistent set of numbers you would notice the absence of.
The test for whether a metric belongs in a daily brief is not whether it is interesting. It is whether a change in it would alter what you do that week. Most dashboards fail this and become wallpaper.
A workable minimum for a founder-led product business:
1. Pipeline in. New qualified leads or bookings since yesterday, and the source. 2. Activation. New signups reaching your defined value moment, on a fixed window. If you have not defined that event, this line is not available to you yet. 3. Retention shape. Weekly cohort return rate, not a single blended number. 4. Cash. Money in, money out, runway in months. Boring, and the one that changes decisions fastest. 5. One thing that broke. Failed payments, failed jobs, errors above a threshold.
Five lines. If it takes longer than two minutes to read, it will stop being read, and an unread report is worse than no report because it produces the feeling of oversight without the fact of it.
Where do these systems go wrong?
They keep running while producing wrong numbers, and a wrong number looks exactly like a right one.
This is the failure mode worth planning for, and it is not hypothetical. Our own pipeline shipped four separate bugs that produced plausible output and raised no error. Substring matching classified a sales role as a design role. An ordering dependency silently disabled the highest-priority feature. A deduplication key collided on company name. And one data source turned out to carry a usable contact on only about half its records.
None of those crashed. Every run reported healthy. We found all four by reading the output, not by being alerted, and we have written up why that class of failure survives so long.
This is not a small-operation problem. Google's SRE practice is built around alerting on symptoms precisely because causes are too noisy to page on (Google SRE), and a wrong-but-plausible result produces no symptom at all. Meta documented the same phenomenon in hardware, where data errors go undetected by the wider system (Engineering at Meta). Google reported CPU cores that quietly compute wrong answers while appearing entirely healthy (Hochschild et al., HotOS 2021).
The practical defence is three habits, none of which need new tooling:
Read the actual output weekly, not the summary. Open the artefacts and read a handful end to end.
Assert on shape, not exit code. Make the job check the things you would check by eye, and be loud when they fail.
Write down what correct looks like before you build. A system with no written definition of a correct result cannot be wrong, which is comfortable and is precisely the problem.
What should you automate first?
The task you have already skipped twice.
Not the most complex one, and not the most time-consuming. The one that keeps not happening, because that is the one where the system is genuinely doing something you cannot.
Then apply the same split we use: automate anything whose failure mode is a wasted send, and keep a human on anything whose failure mode is a burned relationship. That line is worth drawing explicitly, in writing, before you build, because it will otherwise get redrawn every time the automation looks tempting.
The compounding argument is simple. Five minutes a weekday is twenty hours a year. Getting that back matters far less than the fact that the numbers now exist when a decision arrives, and that the decision no longer waits on you finding an hour.
WHAT NEXT
Want this fixed in your product, not just explained?
Sep 15, 2026
By Victor Teran
The Founder Reporting Stack That Runs Without You
Most founder reporting is a weekly hour of copying numbers between tabs, and it is the first thing to go the week something urgent happens. Ours runs on a weekday schedule nobody triggers, and the design decision that made it stick was not technical.
Automation
Systems
Reporting
There is a specific category of work that is important, repeatable, and quietly optional. Reporting is the purest example. Nobody notices the week you skip it. You notice about six weeks later, when a decision arrives and the numbers to make it with do not exist.
The instinct is to fix that with discipline. Discipline is the wrong tool, because the task is competing against genuinely urgent work and will lose every time it is close.
The fix is to make the reporting happen without a decision. Below is how ours works, including the part that has nothing to do with tooling.
Key takeaways
A weekly report is the shape of task that quietly stops happening. A daily one that takes two minutes does not.
Our outbound pipeline has run on a weekday schedule since 29 July 2026: 427 companies contacted across 25 run days, with no human ever starting a run.
Automate the volume, keep the judgment. Of those 427, 332 went to an automated sequence and 95 stayed manual on purpose.
Reporting that nobody reads is worse than none, because it produces the feeling of oversight without the fact of it.
Why does weekly reporting stop happening?
Because a weekly pile is easy to defer once, and deferring it once is how it ends.
Miss a Monday and the following Monday has two weeks of work in it, which makes deferring more attractive, not less. The failure compounds, and it always resolves the same way: the report quietly becomes a thing you used to do.
We hit this exactly. Our outbound pipeline originally ran weekly, and at the end of July 2026 we moved it to every weekday for one reason that had nothing to do with engineering. A weekly batch of drafts to review is the shape of task that quietly stops happening. A handful each morning does not.
That is the design principle underneath everything here. Match the cadence to the behaviour you can actually sustain, then build the system around that, rather than building the ideal system and relying on yourself to keep up with it.
What does "runs without you" mean in practice?
No human triggers it, and nothing waits for a human to notice.
The pipeline runs on GitHub Actions on a weekday schedule. Between 29 July and 2 September 2026 it contacted 427 companies across 25 run days. Nobody started a single one of those runs.
The numbers underneath matter more than the total:
Measure | Value |
|---|---|
Companies contacted | 427 |
Run days | 25, weekdays only |
Pushed to an automated sequence | 332 |
Kept as drafts for manual review | 95 |
Runs triggered by a human | 0 |
That 332 / 95 split is the whole philosophy. The automated path handles reach, where a failure costs a wasted send. The manual path handles the leads where a wrong sentence costs a relationship, and it is the highest-converting step in the system.
The value of automation was never removing the founder from the loop. It was removing the founder from the 332 so there was attention left for the 95.
FREE GUIDE
The 4 product leaks costing you growth
A short audit guide for founders. Find the four places your product leaks revenue, and what to fix first.
What should a founder actually get every morning?
A short, boring, consistent set of numbers you would notice the absence of.
The test for whether a metric belongs in a daily brief is not whether it is interesting. It is whether a change in it would alter what you do that week. Most dashboards fail this and become wallpaper.
A workable minimum for a founder-led product business:
1. Pipeline in. New qualified leads or bookings since yesterday, and the source. 2. Activation. New signups reaching your defined value moment, on a fixed window. If you have not defined that event, this line is not available to you yet. 3. Retention shape. Weekly cohort return rate, not a single blended number. 4. Cash. Money in, money out, runway in months. Boring, and the one that changes decisions fastest. 5. One thing that broke. Failed payments, failed jobs, errors above a threshold.
Five lines. If it takes longer than two minutes to read, it will stop being read, and an unread report is worse than no report because it produces the feeling of oversight without the fact of it.
Where do these systems go wrong?
They keep running while producing wrong numbers, and a wrong number looks exactly like a right one.
This is the failure mode worth planning for, and it is not hypothetical. Our own pipeline shipped four separate bugs that produced plausible output and raised no error. Substring matching classified a sales role as a design role. An ordering dependency silently disabled the highest-priority feature. A deduplication key collided on company name. And one data source turned out to carry a usable contact on only about half its records.
None of those crashed. Every run reported healthy. We found all four by reading the output, not by being alerted, and we have written up why that class of failure survives so long.
This is not a small-operation problem. Google's SRE practice is built around alerting on symptoms precisely because causes are too noisy to page on (Google SRE), and a wrong-but-plausible result produces no symptom at all. Meta documented the same phenomenon in hardware, where data errors go undetected by the wider system (Engineering at Meta). Google reported CPU cores that quietly compute wrong answers while appearing entirely healthy (Hochschild et al., HotOS 2021).
The practical defence is three habits, none of which need new tooling:
Read the actual output weekly, not the summary. Open the artefacts and read a handful end to end.
Assert on shape, not exit code. Make the job check the things you would check by eye, and be loud when they fail.
Write down what correct looks like before you build. A system with no written definition of a correct result cannot be wrong, which is comfortable and is precisely the problem.
What should you automate first?
The task you have already skipped twice.
Not the most complex one, and not the most time-consuming. The one that keeps not happening, because that is the one where the system is genuinely doing something you cannot.
Then apply the same split we use: automate anything whose failure mode is a wasted send, and keep a human on anything whose failure mode is a burned relationship. That line is worth drawing explicitly, in writing, before you build, because it will otherwise get redrawn every time the automation looks tempting.
The compounding argument is simple. Five minutes a weekday is twenty hours a year. Getting that back matters far less than the fact that the numbers now exist when a decision arrives, and that the decision no longer waits on you finding an hour.
WHAT NEXT