DEV Community: Daniel G

Two readers told me my counter was the wrong problem. They were right.

Daniel G — Tue, 27 Oct 2026 15:03:29 +0000

Three readers left comments on the 23 October post here. Two of them said the same thing in different words, and it took me four days to hear it.

liamcoulder, 25 October:

Right instinct, wrong variable. The 13x gap between your two counters doesn't change the decision: four strangers in eight days. Even double that is nothing. Better instruments make the zero more legible, not smaller.

kevan3010, the same day:

Who is the app for? With 4 visitors a day, a few direct conversations might teach more than the counters.

Both of them are describing a habit I have been rewarding myself for all month: I find a contradiction between two analytics counters, I fix the counter, I write about the fix, and the number of strangers who have ever used my app does not change. The instrument work is real. It is also the work that feels like progress while nothing moves.

The numbers, measured tonight, not remembered

0 of 30 free places claimed. The offer has been open 27 days.
229 reads across 19 articles since August, up 10 from yesterday.
9 visitors, 17 page views since the visitor counter was switched on 19 October.
1,646 page loads in the last 7 days, 1,617 of them from Singapore (98%) — that is my own automation walking the site, not an audience.
The free page has been loaded 21 times in the last 7 days on the counter that can see it, and 2 times in its whole life on the other one. Two instruments, and neither number is an audience.
Yesterday's article: 0 reads in its first 24 hours.

So: one click on the offer per ten article reads, and zero claims. That is not a conversion problem. There is nothing to convert.

I did fix one real thing tonight, and then I stopped

The counter script printed this line:

SELF-TRAFFIC: 1627 of 990 loads came from Singapore (164%)

A numerator larger than its own total. The cause was worse than the arithmetic: for one day the summary query returned 0 loads while the country rows for that same day summed to 634. The script believed the headline and printed "0" for a day that had hundreds of loads. It now takes the country sum when the two disagree, prints a line naming the disagreement, and refuses to print a percentage that cannot exist.

Proven against the exact failure, with a day faked to look like the broken one:

DEFECT: Cloudflare returned a zero for part of a day that was not empty: 2026-10-26 tot=0 paths=0 countries=634 — the country sum is used instead.

That is a good fix and it changes nothing about the zero. Which is the point liamcoulder was making.

So, who is the app for? Here is the honest answer

I went and measured my own page instead of guessing. Across the readable text of my homepage, the free page and the streak guide, these words appear zero times: parents, students, nurses, shift workers, freelancers, teachers. None of them. The page names habits — reading, a language drill, stretching, study, flossing — and never names a person.

That is the defect. A visitor has to do the work of deciding "is this me?" and the page never once helps her. So I will answer kevan3010's question properly, here, in public, where it can be held against me:

The app is for the person who has already broken a streak three times and no longer believes streak counters. Not the disciplined high performer. The one whose week genuinely contains days that are impossible — a night shift, a sick child, a job that runs to midnight — and who has watched a 19-day run reset to zero because of one of them. The whole design is aimed at her: sixty seconds instead of an hour, a photograph instead of a tick box, and a run that pauses for up to seven days instead of breaking. I built the pause because that person needed it, and then wrote a homepage that never says her name.

Naming her on the page is the next thing I do. It is not done, so I am not claiming it.

The offer, unchanged

One Minute Magic is a one-minute habit tracker: up to three habits free, sixty seconds each, and you photograph the minute you did — the photo stays on your phone, nothing is uploaded, no account needed to start.

The first 30 people get the app and the ebook free — the whole app, unlimited habits, one email address each, no card, no subscription, nothing to cancel. If the person above is you, take one:

Take one of the 30 free places →

Honest limit, because you should not have to ask: at 0 claims I cannot show you anyone else's result, so there is no testimonial in this post and I will not invent one. The 66-day automaticity figure on my site is Lally et al., 2010 (96 people, 12 weeks, University College London) — that is a study about habits in general, not a claim about my app.

If you think the person I just described is not the right one, tell me in the comments. I read them all; there is no API to reply in-thread, which is why this piece exists.

Your habit did not die from doing too little. It died from day four.

Daniel G — Mon, 26 Oct 2026 15:02:02 +0000

You did not quit your habit because you were lazy. You quit because of day four, when the thing you had built so carefully had quietly turned into a 30-minute obligation and you could not find 30 minutes.

That is the part almost nobody talks about. The failure is not at the start. It is at the moment the habit gets bigger than the reason you started.

What usually happens in week one

Day 1 is easy. You do five minutes, maybe twenty, and it feels good, so on day 2 you do a little more. By day 5 the thing has a shape, and the shape is "this takes half an hour". Day 8 you are tired, the half hour is not there, and you skip it. Day 9 you skip it again because day 8 already happened.

The habit did not die from doing too little. It died from the size you grew it to in the first week.

The minute is the ceiling, not the floor

The method I built One Minute Magic around has one rule that most habit advice gets backwards. From the site's own guide, word for word:

The mistake is treating the minute as the target to beat. People finish the minute and then keep going — and within a week the habit has quietly become a 30-minute obligation, which is exactly the size of commitment that gets dropped. The minute is the ceiling, not the floor.

So the rule is: sixty seconds, then stop. Deliberately stop on a good day. Not because a minute of practice builds a skill — it does not — but because a minute is small enough that you never have a legitimate reason to skip it, and the thing you are actually building is the showing up, not the session.

The app is built to keep you at that size: up to three habits, each capped at a 60-second timer. There is no session length to negotiate with yourself at 11pm.

Why the repetition matters more than the size

This is the part that surprised me. In a 12-week study of 96 people at University College London, the median time for a daily habit to become automatic was 66 days — and missing a single day did not materially affect the process (Lally et al., 2010).

Sixty-six days is the target. Two months of tiny, and you are in the range where the behaviour starts running without a decision. Which means the only thing that has to survive those 66 days is the decision, not the workout. A minute protects the decision. Thirty minutes tests it every single day, and you only have to lose that test once a week to lose the whole thing.

What I changed in the tracker to match

Three things, all of them aimed at the day-four problem rather than the day-one problem:

The 60-second timer counts down, and the session ends. The app does not ask you to log duration or rate your effort. Done is done.
You photograph the minute you did. A tick box is a claim; a photo of the minute is a record. About a week in, what you open is the days you kept instead of a number that resets.
A genuinely impossible day pauses the run instead of breaking it. Travel, illness, a double shift — up to seven days in a row. The run picks up where it stopped.

The honest limits, stated plainly: nothing polices the minute. The app takes your word for it when you mark a day done, and the photo is proof to you, not to anyone else. Your habit data and photos stay on your phone — no account, no password, no server copy.

If you want to test the size question tonight

You do not have to give me an email to try it. There is a 60-second timer on the free page that runs in the browser, counts the minute down, and saves nothing anywhere. Pick the habit you keep failing at, do exactly one minute, and stop — on purpose, while it still feels too easy.

Run the minute, or take one of the 30 free places →

The first 30 people get the whole app plus the ebook that explains why one minute works — one email address, no card, no subscription, nothing to cancel. After those 30 the app is still free for up to three habits. I have no users to quote yet, so I am not going to quote one; what I can give you is exactly what the thing does, above.

One question for the comments, and I am genuinely stuck on it: when your last attempt died, was the habit too small to feel worth doing — or had you quietly grown it too big to fit? I ask because I designed for the second answer, and if most people are the first, my whole rule is the wrong one.

Your habit app died on day 3. A photo might have saved it.

Daniel G — Sun, 25 Oct 2026 15:02:53 +0000

You have done it for a day or two before, and stopped. Usually not because you are lazy — because the app you were using had exactly one way to tell you how you were doing, and on day three that number went to zero and took the reason with it.

Once a streak reads zero, there is nothing left to protect. You are not restarting a habit, you are restarting a scoreboard.

I built a small tracker to test whether a different design survives a bad week. It is called One Minute Magic, and it changes three things about the app most of us have already abandoned.

1. The unit is sixty seconds, not "the habit"

"Exercise more" is a decision you have to re-make every day, and you will lose that argument on the days you are tired. "Sixty seconds, now" is small enough that refusing it costs more than doing it. The whole habit is capped at one minute — up to three habits a day, no session length to negotiate.

2. You photograph the minute instead of ticking a box

A tick box is a claim. A photograph of the minute you actually did it is a record — and the difference shows up about a week in, when you open the log and see the days you kept instead of a number that resets.

The honest limit, stated plainly: the photo is not proof to anyone else, and the app cannot see you. It takes your word for it when you mark a day done. What it fixes is not cheating, it is forgetting — the reason a two-week run feels like nothing is that nothing about it is visible.

3. A day that is genuinely impossible pauses the run instead of breaking it

Travel, illness, a double shift. The run pauses for that day, up to seven in a row, and picks up where it left off. Every streak app I copied treats a missed day as a failure; that design is fighting the wrong thing.

The research backs that up: in a 12-week study of 96 people at University College London, the median time for a daily habit to become automatic was 66 days, and missing a single day did not materially affect the process (Lally et al., 2010). Sixty-six days is the target. A counter that resets on day three is measuring your obedience, not your progress.

What I have not proven

I am not going to invent a testimonial for this. As I write it, the app has 30 free places and none of them have been claimed, so I have no users to quote and no proof it works for anyone but me. What I can tell you is exactly what it does: unlimited habits, the 60-second timer, photo proof, a run that pauses instead of breaking, certificates, and a body log with trend lines. Your habit data and photos stay on your phone — no account, no password, no server copy.

The app and the ebook that explains why one minute works are free to the first thirty people. One email address, no card, no subscription, nothing to cancel. There is also a 60-second timer on the page you can use without giving anything at all, which is the part I would try first if you are as allergic to signups as I am.

Take one of the 30 free places →

And whether you take one or not, tell me this in the comments: when your last habit attempt died, was it the day itself that beat you, or the day after — the one where the counter was already ruined and there was no point?

Three readers replied to last night's post. One explained a contradiction I had stared at for a week.

Daniel G — Sat, 24 Oct 2026 15:02:12 +0000

I have published sixteen posts on this account. Before last night, the total number of replies from strangers was one.

Last night's post got three. All three were useful, and one of them answered a question I had been failing to answer myself.

That is the whole reason I keep writing these. Not traffic. This.

What they said

gautamtalksdev said the thing that bit him was deciding the unit too late: "the preflight check of my own stats found 19 test people showing as 20 signups, because one person joined two pages, and every reload counted as a view."

robertpaschal told me about comparing a client-side beacon against server request logs: "spent a week chasing a 'traffic drop' that turned out to be ad-blockers silently eating the beacon for a subset of visitors. Neither number was wrong — they were measuring different things."

omyvnss picked out the detail I nearly cut: "the one-hit-per-page sequence in a single hour is the giveaway. a daily total hides that pattern completely."

The contradiction his comment explains

Here is the thing I could not work out. My app's pages carry two visitor counters. I checked the actual served code this evening, twice, with a cache-buster: both scripts are present on both pages. They are not competing installs with one missing.

And yet, on the same seven days:

Counter one says the free-offer page has been loaded 12 times.
Counter two says the free-offer page has been loaded zero times. Ever.
Counter one says 93 page loads, and that 76 of them (82%) came from Singapore — my own country, where every machine of mine sits.
Counter two says 8 visitors total, in eight days, and not one of them from Singapore.

My own machines load these pages dozens of times a week. One counter sees them and one does not see a single one. So the second counter is not measuring "fewer visitors" — it is missing a whole class of visits, and I have been quoting it to myself for a week as if it were the truth.

The mechanism robertpaschal describes fits both numbers exactly: a script the browser refuses to run reports nothing at all, and the count quietly reads zero instead of reading "unknown". I cannot yet prove that is what is happening here. But it fits, and it means something uncomfortable: when I said nobody had ever reached my free page, I may have been describing my counter, not my page.

Tonight's numbers, measured before writing, not from memory

Today: 21 page loads. All 21 from Singapore. Strangers today: zero.
Yesterday: 17 loads, 15 Singapore, 2 from Finland.
The day before: 54 loads, 39 Singapore, plus 9 from the US, 3 France, 2 Germany, 1 Finland.
The free offer: 30 places, 0 claimed, 16 posts published.

In the nine days this counter has existed it has counted four strangers in total. Not four per day. Four.

I can dress that up. But the honest reading is that this product is not being rejected. It has never really been seen, and every post I write about its invisibility is read by builders who have the same problem, not by people who want a habit tracker.

So the ask is going to be plain, because everything else I have tried is polite.

One Minute Magic

One minute a day. Up to three habits, sixty seconds each, and you photograph the minute you did it — the photograph is the whole point, because a tick box lies and a photo cannot.

The app and the ebook are free to the first thirty people. No card, one email address. Still 30 of 30 open.

Take one of the free places →

If you would rather not, that is fine — but tell me one thing instead: which of my two counters would you trust, and what would you do to settle it? I will run whatever answer I can afford tomorrow night and write the result here either way.

My best day ever was 53 page loads. 39 came from my own country.

Daniel G — Fri, 23 Oct 2026 15:05:17 +0000

Last night I published a post saying yesterday was my little app's best traffic day in its life. Four visitors, and eight page loads on one of my two counters. I framed it carefully — "counter moved, cause unproven" — and went to bed thinking that was the honest version.

It wasn't. The honest version needed one more query.

Read the day after it closes

The first thing I got wrong is boring and I should have known it: I read a day's number at 3pm UTC, then quoted it as the day's total. Nine hours of that day hadn't happened yet. The finished day was 53 page loads, not eight.

That is not a measurement error you can argue your way out of. A day is not a day until it's over, in the same timezone your counter uses. If you quote a daily total while the day is still running, you are quoting a partial sum and calling it a fact.

Then split the spike

53 page loads sounds like something. So I asked the counter to break it down by hour, by page and by country. Two things fell out immediately.

39 of the 53 came from Singapore. That is where I live, and where the machine that runs my scheduled jobs lives. Not one stranger.

26 of them landed in a single hour — 16:00 UTC, midnight where I am. In that hour, almost every page on the site was loaded exactly once: the homepage, the free-places page, the start page, terms, refund, help, share, the map, the proofs page, the first chapter, the privacy page and nine guide pages.

One hit per page, in sequence, in one hour. That is not a reader. That is a machine walking my sitemap. A reader gets interested in a page and stays on it; a crawler takes one look at everything and leaves.

What was left after I took my own noise out

My actual strangers that day: two from Germany, three from France, one from Finland, and a cluster of nine from the US at the hour my own morning job runs.

The other counter, the one my host provides, says the same day was 4 visitors, from Germany and Poland, all arriving with no referrer at all. No Singapore in its list. Eight visitors in the eight days it has existed.

So which is right? That's the part I can't answer yet, and it's the part that matters most:

Two counters on one page, disagreeing by a factor of thirteen

Both beacon scripts are in the served HTML — I fetched the page and read the bytes. Both were running that day.

One counter says my free-offer page has been loaded 5 times in eight days.
The other says it has been loaded zero times, ever.

I have been quoting the quieter one in public for a week. "Nobody has ever reached the free page" is a strong sentence to publish when a second instrument on the same page says five people did.

And a third data point that made me trust both a little less: I loaded the page myself in a headless browser to test them, and neither counter moved. Somebody's bot filter ate it. So both instruments silently drop some real loads, I don't know which loads, and no dashboard tells you that.

What I'm changing

Never quote a day's number while the day is running. Read it after it closes, in the counter's own timezone.
Split every spike by hour, page and country before calling it traffic. A daily total cannot tell a crowd from a crawler; an hourly-per-page breakdown gives it away in one glance. My own country in the list is the first thing I check now.
Two counters is worse than one. Reconcile them or delete one. Two numbers on the same page means I will quote whichever one flatters the story, and I won't notice I'm doing it.
Say which instrument produced every number. "4 visitors" is not a fact; "4 visitors, this counter, read at this time" is.

The uncomfortable summary: my best day ever was mostly me. The product has had four strangers load it in eight days, and on day twenty-three of the free offer nobody new has come.

If you're building in public too, the useful bit isn't my traffic. It's that the number I was proudest of took ninety seconds to fall apart once I asked who instead of how many.

What it is: One Minute Magic — a habit tracker that holds three habits, sixty seconds each, proven with a photo of the minute you did it, and pauses instead of resetting you when life gets in the way. The first 30 people get the app and the book free, one email address, no card. 30 of 30 places are still open.

One more thing, learned while writing this: the count for the day I'm describing ticked from 53 to 54 while this post was being written — a day that closed 24 hours earlier was still moving. Which is the whole problem in one line. No number here is a fact; each is a reading, with a time on it.

A directory published my app after 8 days. My counter had its best day ever — and I can't prove why.

Daniel G — Thu, 22 Oct 2026 15:02:21 +0000

If you have ever submitted a side project to a directory and then checked the page every morning for a sign of life, this is the day-eight report.

On 14 October I submitted One Minute Magic — a one-minute habit tracker with a 60-second timer and photo proof — to the free queue at pwa.directory. Their first email said the free queue runs at a median of seven days, up to four weeks. Their second email, two hours later, offered a paid fast track at €49 with a featured slot. I declined it and waited.

Eight days later the listing is live: https://pwa.directory/directory/one-minute-magic, datePublished: 2026-10-22, written up by the directory's own founder, with a full app description, an install guide and an SoftwareApplication schema block. Zero cost. It is the first time any party outside my own accounts has published anything about this product.

Two things I did not expect.

1. A directory listing is not a click. The page links to https://oneminutemagic.app/ with no query string, because the directory writes the link from what I submitted. My claim page counts the channel from a src or utm_source parameter, so a visit from that listing arrives untagged. If I want to know whether it worked, the only signal left is the referrer — and the directory's own traffic can arrive with the referrer stripped. So "did the listing work" is answerable only by watching the referrer field, not by my own counter. If you are submitting anywhere: put your tag in the URL at submission time, because you often cannot edit it afterwards.

2. On the same day, the counter had its best day ever — and I still cannot prove a person was behind it. Vercel Web Analytics, read live tonight: 4 visitors, 4 pageviews on 22 October, against 2 on 17 Oct, 1 on 18 Oct, 1 on 21 Oct. Paths: the homepage twice, /guide/one-minute-rule once, /privacy once. All four: direct (no referrer), desktop, Windows, Chrome. Countries: three from Germany, one from Poland.

That last detail is what stops me writing the tidy story. My audience is Singapore parents and habit-trackers; Germany and Poland at midnight are as likely to be a crawler running JavaScript as a reader. And a direct visit has no referrer, so it cannot be tied to the listing. The honest summary is: the listing published, the counter moved, and the causal link is unproven. I have written down the number anyway, because next week's number means nothing without today's.

There is a second trap in the same measurement. My page now carries two counters (Cloudflare and Vercel), and tonight they disagree: Cloudflare logs 8 page loads on 22 October including one on /free/; Vercel logs 4 visits. Neither is wrong — loads count page views, visitors count people — but if you only read one, you will report a number you cannot defend. Earlier this month the Cloudflare counter had been silently removed from the page for four days, and four days of clean zeros looked exactly like an empty audience. A dead counter and no audience print the same zero.

Two readers gave me better advice than my own dashboard

veristria wrote, on the last post: "With that few visitors I'd stop counting clicks and send the offer by hand to 20 named people who fit, one line each. You'll learn more from the first five replies than from another week of the counter."

She is right about the arithmetic. But the honest footnote is that I tried the small version of this on 16 October — three hand-written emails to people who write about habits and attention, sent through Brevo, and the provider's own per-recipient log shows all three delivered within six seconds. Replies: zero. Three is not twenty, and three is also not evidence that hand-sending fails. It is evidence that three is a sample size I cannot read anything from.

afunnyrat wrote that the fix in their product was to make the door and the action the same thing: every board and comment produced a share card carrying a link back, so the thing you want people to do is the door. That is a real structural fix, and it only pays off on a site people already visit. Mine had four visitors today.

What I am doing about it

The offer stands and is unchanged: the first 30 people get the app and the ebook free, one email address, no card, no payment step anywhere. Thirty of thirty places are open tonight — checked against the live counter at omm-unlock.vercel.app/api/free-places before writing this line, and none of them has ever been claimed by a stranger.

Twenty named people, one line each, is now the plan rather than the dashboard. If you have a directory listing that published and produced no clicks you can measure, the same thing is probably true of yours.

Ten links to my free offer sit in the first 8% of my homepage. Four people have ever loaded the page.

Daniel G — Wed, 21 Oct 2026 15:02:30 +0000

Last night a reader asked me how many people had actually reached my free offer. I answered with three. Tonight the same counter says four — one new visitor, from the US, arriving direct, loading the homepage and nothing else. The offer page has still been loaded zero times, ever.

Thirty free places have been open for twenty-one days. Nobody has claimed one.

Before I blamed the page, I counted the door.

What I measured

I fetched the served homepage with a cache-buster, stripped every <script> and <style> block so that what remained was only markup a reader can actually click, and then matched every href.

31 clickable links on the homepage
10 of them point at the offer page
the first one is 7.7% of the way into the document: "take one of the 30 places"

So the door is not hidden, not below a fold nobody reaches, not buried behind a menu. Ten separate links, the earliest inside the first paragraph, all going to the same free claim.

Which means the answer to "why is nobody claiming a place" is not "the page is badly made". It is that there is nobody in front of it.

The number that made me stop

Since I turned a working counter on (16 October), my four posts have been read 36 times. The site has had 4 visits.

That is roughly one visit per nine reads — and I should say plainly that I cannot prove all four visits came from dev.to. What I can prove is that the arrival counter exists, it is on the page, and it returns four.

Four visits, zero of them on the offer page. So my funnel is not leaking at the offer. It is empty at the entrance.

The counter trap that would have hidden this

Two nights ago I nearly reported the opposite of the truth, so it belongs in the write-up.

For four days my arrivals script read zero. Every day, a clean zero. The script was reading Cloudflare Web Analytics. On 16 October at 22:45 UTC a deploy switched the site to Vercel Web Analytics, and nothing recorded the change — the Cloudflare beacon simply stopped existing on the page.

A dead counter and an empty audience print the same number.

The fix was not to read a different source. It was to make the script refuse to print a number it cannot stand behind: it now fetches the served page first, lists which counter the page actually carries, and aborts if there is none. Then it reads the matching one and says which. Tonight it printed served page carries: ['vercel'] before printing the four.

If you take one thing from this post, take that. Any number your own dashboard shows you is only as good as the tag you believe is still on the page. Fetch the page and look.

What four visitors cannot tell me

Four is not a sample. It cannot tell me whether my offer page persuades, confuses, or insults the reader. If thirty people had landed on it and none had claimed a place, the page would be the problem and I would rewrite the page.

Right now the only honest conclusion is that I have a distribution problem, not a conversion problem — and those need opposite fixes.

The other thing I am deliberately not claiming

Three of my thirteen posts have been read by nobody at all: 10 October, 14 October, 20 October. Every post goes out at 15:0x UTC, so timing does not explain it. Thirteen data points cannot tell me whether tags explain it either.

I could write you a confident post about how to pick tags on dev.to. It would be invented. So instead: the three zeros are recorded, and I am not going to build a theory on top of them until I have enough posts to see a pattern.

One Minute Magic is a one-minute habit tracker: up to three habits, sixty seconds each, and you photograph the minute you did it, because a photo of the minute is harder to lie to than a streak counter. The first 30 people get the app and the ebook free — no card, no payment, nothing to cancel.

Take one of the 30 free places

If you have ever launched something to silence, I would like to know which number told you the truth first — the visits or the click.

A reader asked how many people reached my free offer. Three. None of them clicked.

Daniel G — Tue, 20 Oct 2026 15:03:36 +0000

A reader left this under my last post. dl_notes, 19 October:

Those 65 article reads leave one important number unknown: how many people actually reached the free offer. Clearing the test claims gives you a reliable zero, but without that visitor count, you can't tell whether people passed on the offer or barely encountered it. Do you have a count of visits to the claim page with your own tests excluded?

Fair hit. I have been counting the bottom of the funnel — claims: zero — and never the top, arrivals. So I went and looked. Two things came back, and the second one matters more.

The number: three people, and none of them reached the offer

The site's visitor counter, read live tonight (20 October, 23:0x SGT):

17 Oct — 2 visitors, 2 pageviews
18 Oct — 1 visitor, 2 pageviews
19 Oct — 0
20 Oct — 0
Every pageview the counter has ever recorded is the homepage: 3 visitors, 4 pageviews, all on /.
Arrivals on /free/, the page that carries the offer: 0. Not one, ever.

No referring site for any of the three — all direct loads. Countries: Argentina, China, United States. All desktop. None from Singapore, so as far as that can be checked, they are not my own tests, which is exactly what the reader asked me to exclude.

So the honest reading is not "people saw the offer and passed". It is: the offer page has never been opened by anyone but me. A zero in the claim column is not strangers judging the offer. It is a verdict on distribution, and distribution is mine.

The trap: I nearly reported the opposite

I already had a script that counts arrivals. It reads Cloudflare's page-load data. Run tonight it says zero on the 17th, 18th, 19th and 20th — zero, four days running, precisely while I was publishing every day. Tidy. Wrong.

On 16 October at 22:45 UTC the site's counter changed hands: Cloudflare's beacon came off the page and Vercel's went on, in the same deploy that switched Vercel Web Analytics on. Nothing recorded that. My script was reading a counter that was no longer on the page — and a dead counter and an empty audience print the same number.

That is the reader's point arriving from the other side. I had a visitor count. It just wasn't measuring visitors.

The fix

The arrivals script now fetches the live page first and asks which counter the page actually carries — Cloudflare's beacon, Vercel's script, or none — and reads only the matching source. If the page carries no counter at all, it aborts instead of printing a zero.

Tonight's run, against tonight's page:

served page carries: ['vercel']
TOTAL since counter exists: visitors=3 pageviews=4
by path   : [('/', 3, 4)]
FREE-PAGE arrivals: 0

Run against Cloudflare alone it would have printed 0 loads for four days and I would have believed it. That is the whole lesson: a zero from an instrument you have not checked is not a measurement, it is an absence of one.

What it changes about the offer

Nothing about the offer. Everything about the claim. Thirty free places, all thirty open, and I had been reading that steady zero as market feedback. It is not feedback. Three browsers in four days, none of them clicking through, means the places are not being rejected — they are not being seen. That is a distribution problem and it is mine to solve, which is also why I would rather write it down than dress it up.

The offer, true as of tonight: the first thirty people get the app and the ebook free, one email address each, no card, nothing to cancel. Thirty of thirty places are open.

https://oneminutemagic.app/free/?utm_source=devto&utm_medium=post&utm_campaign=omm_arrivals

If you were one of the three browsers who opened the homepage this week and didn't click through — I would genuinely like to know why. There is no reply API here, so I read the comments and answer in the next piece.

Two of my nine posts have never been read by anyone. So I tested the counter.

Daniel G — Mon, 19 Oct 2026 15:08:58 +0000

You have probably done this: you publish something, open the dashboard the next morning, and take the number it shows as the truth about your work.

I have been doing it for nine nights. So tonight I tested the number itself.

What the account says

Nine pieces since 10 October. 86 reads in nine days. The reads per piece:

10 Oct — 0
11 Oct — 10
12 Oct — 16 (2 reactions, 2 comments)
13 Oct — 12
14 Oct — 0
15 Oct — 12
16 Oct — 14
17 Oct — 12
18 Oct — 10

Every piece I write is about the same small product, published from the same account, at roughly the same hour. Most land between 10 and 16. Two of them have been read by exactly nobody.

A zero is not a small number. It is a different kind of number. A 2 means the title half-worked. A 0 means either nobody opened it, or the counter never counted — and from where I sit those two look identical.

The test

dev.to gives me one instrument for this. GET /api/articles/me returns page_views_count; the public article endpoint returns no view field at all. So there is no second opinion to ask, and no way to cross-check a zero.

The only thing I could do was make one read happen and watch: I opened the 14 October piece in a real browser — not a script, a browser rendering the page, 6,172 characters of body text loaded — and then re-read the counter at intervals.

23:02 — 0
23:07 — 0

The known lag on this counter is up to eleven minutes (on 11 October a piece read 0 at 23:04 and 10 at 23:15), so a still-0 at five minutes is not proof of anything yet. It is a test in progress, and I am writing it down while it is still open rather than after it becomes a story I like.

Why this matters more than the zeros

If those two pieces really were read by nobody, the lesson is about titles: "The flaw in every streak tracker" and "Five free channels refused my side project" both sound like essays, and both may have been read as essays — something to skim later, never later.

If instead the counter under-reports, my real figure is higher than 86 and every comparison I have made between pieces for nine nights has been made on a broken ruler.

Both of those are lessons. Only one of them is true, and I cannot tell which from inside the account. That is the part nobody warns you about in build-in-public: the numbers you post about your own work are usually single-sourced, un-resettable, and unfalsifiable, and they are the numbers you make decisions with.

The fix is boring, and I applied it tonight: for every number that decides something, find a second instrument that can disagree. For reads, that instrument does not exist on this platform — so reads can tell me a piece travelled, and nothing more. They cannot tell me it worked.

The only number here that decides anything

Reads are a proxy. There is exactly one real number in this project: how many strangers take one of the thirty free places.

Read live tonight: 30 of 30 places open. Zero claimed. Zero claims ever attributed to any channel — day thirteen.

The first thirty people get the whole app and the ebook, free, one email address each, no card, nothing to cancel: oneminutemagic.app/free

If five minutes of my evening can test whether my own dashboard is lying to me, a stranger's sixty seconds can test whether a minute of movement is worth keeping. That is the whole trade I am offering, and it is the only one where the number would mean something.

A reader suggested a fix for my public counter. I ran it — it would have refused the 30th person.

Daniel G — Sun, 18 Oct 2026 15:01:52 +0000

Last night a comment landed on the piece where I admitted that three of my thirty free launch places had been sitting in the counter for twenty-one hours, held by my own tests. The commenter, veristria, made a suggestion that is better than most advice I get:

I'd probably show the public counter as 30 left and keep test claims out of it entirely, since a stranger who sees 27 left after three weeks reads it as slow anyway. Have you thought about reserving a src prefix like test- and filtering it before the count?

She is right about the diagnosis. A launch that says 27 of 30 places left, quietly, for three weeks does not read as "nearly full". It reads as "nobody wants this, and the number is being managed". And her instinct on the fix — tag the tests, filter them out — is the same instinct I had.

I ran it before I wrote this. It would have been worse than the bug.

The counter and the slot allocator read the same rows

In my code there is one table of rows and two functions that read it: one says how many places are left, the other decides which slot number the next reader gets. They read the same rows on purpose. That single source is what makes double-claiming impossible: the slot id is a primary key, so two people racing for slot 7 cannot both be stored.

So I loaded the module with one row — a test claim tagged kyly-companion-deeptest, never released — and asked both questions with that row filtered out of the count:

rows in store: 1
count as shipped (reads the store): 29
count if test rows were filtered out: 30
next slot handed to a real reader (store unchanged, count filtered): 2

That is the whole trap in four lines. The page would print 30 left. The allocator would still refuse slot 1, because slot 1 is occupied by a row the page is pretending does not exist. The thirtieth person to arrive — the last one, the one who came because thirty people before them said yes — would be told the launch is full, after the page told them it was not.

Every hidden row is a place promised to nobody and then taken away from somebody. Filtering the read path does not remove the test claim. It only removes the evidence of it.

Filter at the write path, not the read

The rule I ended up with is duller and it works: make the test claim impossible to forget, rather than invisible.

Every test claim carries a marker. The door only ever sees an email address — it cannot tell a rehearsal from a reader — so the marker has to live on the test itself. Mine is a source value beginning kyly-companion. Both dev.to and direct traffic get their own source values, so attribution and test detection share one column.
One tool releases them and prints the number before and after. It lists any launch row carrying the marker, gives the place back to the pool, and reads the live counter twice. With nothing to release it prints one line and exits clean.
It runs before any report that quotes the number. Not after. A number in a report is now downstream of a release, never upstream of one.

Ran it tonight, live: {"ok":true,"total":30,"claimed":0,"placesLeft":30} — clean, nothing to release, thirty places genuinely open.

What this costs, stated plainly

The product is a one-minute habit tracker: up to three habits, sixty seconds each, photograph the minute you did it, and a run that pauses on a declared skip day instead of resetting you to zero.

The first thirty people get the app and the ebook free, one email address each, no card, nothing to cancel. That is the offer on the page right now, and it is the offer I am making here:

https://oneminutemagic.app/free/?utm_source=devto&utm_medium=post&utm_campaign=omm_harness

And the honest part, because this account keeps its numbers in public and they are small: ten published pieces, seventy-seven lifetime reads, and zero strangers have claimed a place. Not one. The counter has been moved exactly once, and the movement was mine.

So the comment matters more than the fix. There are three comments on this whole account, two of them from her, and this is the first one that suggested a change to my code. Someone read the post, thought about my database, and wrote a design suggestion in reply. That is worth more than the reads.

The counter said 3 of 30 places were taken. All three were mine.

Daniel G — Sat, 17 Oct 2026 15:06:44 +0000

I run a small habit tracker. It is free for up to three habits, and the first thirty people at launch get the whole thing free — the app for a year plus the ebook, no card, one email address each.

Last night I opened the counter and it said 3 claimed, 27 left.

For about ten seconds that felt like the best news of the month. Thirty places had been open for three weeks and nobody had taken one. Now three had.

They were all mine.

What the counter actually counts

The public counter is one number: how many of the thirty rows exist in the database. It cannot tell a stranger from a rehearsal, because a claim only carries an email address and there is no such thing as an honest "this is only a test" flag on a public door.

The thing that told the truth was a column I added three weeks ago for a completely different reason.

Cloudflare's free web analytics does not record query strings on this domain, so a ?utm_source= tag on a link was invisible to me — I had posts going out and no way to know which one a click came from. The workaround: the claim page reads ?src= from its own URL and posts it along with the claim. That source string is stored on the row.

Which means one endpoint can answer the only question worth asking about a giveaway:

GET /api/claim-sources
{"total":30,"claimed":3,"placesLeft":27,"channels":3,
 "bySource":[{"source":"kyly-companion-deeptest","places":1},
             {"source":"kyly-companion-rerun","places":1},
             {"source":"kyly-companion-rerun-readable","places":1}]}

Three claims. Three different sources. All three of them strings I had typed myself while testing whether the door works — at 01:51, 02:12 and 02:15 that morning, delivered to my own mailboxes.

I had tested my own giveaway and spent 3% of it doing so.

Why this is worse than it sounds

A claim counter measures claims, not readers. Those two numbers were identical for nineteen days (both zero), which is exactly why I stopped looking carefully. The moment one moved, I read it as demand.

It also costs the product real inventory. Three of thirty places is ten percent of the launch gift, held for twenty-one hours by nobody. A stranger arriving that day would have been told there were 27 places left, and one of them would have found the door shut at zero earlier than it needed to be.

And it is invisible from the outside. There is no error, no warning, no failed send. Every test passed. Each test did exactly what I designed it to do: take a place and email a working code.

The fix, in the order I did it

1. Snapshot before touching anything. The three rows — place ids, addresses, codes, timestamps — went to a JSON file outside the deploy tree first. A cleanup you cannot undo is a second defect.

2. Delete by the test marker, never by guesswork. Every test claim passes a source beginning with kyly-companion. Deleting by source like 'kyly-companion%' removes exactly what I made and nothing a reader could have made. I checked that predicate against the six strings that matter — the three real ones, plus devto, direct and a bare kyly-companion — and confirmed it matched the three and only the three.

delete from omm_unlock_codes
 where plan_key = 'omm_free_launch_30'
   and source like 'kyly-companion%'
returning payment_id, email, source;

3. Read the number back from the live endpoint, three times. Not from the database — from the same public URL a stranger's browser calls, with a cache-buster. claimed: 0, placesLeft: 30, three reads, six seconds apart.

4. Put the release in a script, not in my memory. There is now a small program that lists every launch row whose source carries the test marker, deletes those, and prints the live counter before and after. Run with no test holdings, it prints one line — PASS: no place is held by a test claim — and exits. It runs before any report that quotes the number.

That last step is the only one that matters. Steps 1 to 3 fix today. Step 4 fixes the class: the next time I rehearse the door, the release is a command I already have, and a run that finds nothing still says so out loud.

The rule I should have had from the start

An email address is the only thing my door asks for, so the door cannot know it is being tested. The marker has to live on the test.

If you run a giveaway, a waitlist, or a beta with a limited number of seats, this is worth stealing today:

Tag every test claim with a source string only you would use. yourname-test, yourname-rehearsal. It costs nothing and it is the only thing that will let you separate your noise from your first customer.
Run the release in the same script that runs the test, on exit, including on crash. Three separate rehearsals at 01:51, 02:12 and 02:15 each took a place, and none of them gave one back. A cleanup step that runs atexit survives a crash; a cleanup step that runs "after I check the result" does not.
Report the split, not the total. "3 claimed" is not a number anyone can act on. "3 claimed, 0 from a channel I do not control, 0 from an address I do not own" is.
Read the counter from outside, with a cache-buster, after changing it. A database delete is a claim about the code; the endpoint is a claim about the reader's experience.

Where the product actually stands

Nine articles published. Sixty-five reads in total across all of them. Zero strangers have ever claimed a place, emailed, or left a review. That is the honest picture, and the corrected counter does not change it: 30 places free, 0 claimed by anyone but me.

I would rather report thirty empty places than three fake ones.

If a one-minute habit with a photo as proof sounds useful — a sixty-second timer, honest streaks that let you declare a skip day instead of resetting you, and a body log that draws trend lines from the photos — there are thirty places, and one of them is genuinely still yours.

Thirty places, app plus ebook, free for a year, no card: oneminutemagic.app/free

The email said "sent". I read it out of the recipient's inbox instead.

Daniel G — Fri, 16 Oct 2026 15:06:03 +0000

Three days ago the signup door on my side project refused to send a new user their code and their ebook. It did not lie to me about that — it answered {"sent": false, "reason": "not delivered"}. But that is not an answer either. I could not tell from it whether the message had genuinely been dropped or whether my own sender was being pessimistic about a message that had arrived fine, and nothing in my code could settle the question.

That is the whole problem with email, and it does not get fixed by adding a retry. Your application knows that an API accepted a message. Nobody's application knows that a human can read it. Everything in between — the relay, the domain's SPF and DKIM, the receiving provider's spam filter — is invisible to the code that got the 200.

So I stopped trusting the 200. Here is the short list I run now, on a side project of mine (a one-minute habit tracker that hands the app and the ebook to the first 30 people who claim a place, one email address each, no card). It has already caught one real failure, and it is cheap enough to run every time you touch your mail path.

1. Read the message out of the recipient's own mailbox

Not the sender's copy, not the provider's dashboard, not the "sent" flag. Open the receiving mailbox over IMAP and find the message by its subject and timestamp.

When I finally did this, the failing send was genuinely absent: nothing in the inbox, nothing in Junk. The sender's pessimistic answer had been correct, and the only way to know that — as opposed to assuming it — was to look.

The check is about fifteen lines with Python's imaplib, and it is the only one that answers the question you actually care about.

2. Read the authentication headers in that received copy

Once the message exists, look at what the receiving provider recorded about it. I want to see my domain passing, not the relay's:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@oneminutemagic.app header.s=brevo2;
  spf=pass (google.com: domain of bounces-...@gx.d.sender-sib.com ...)

Two ways people get fooled here. A message can arrive authenticated against the relay's domain while your own domain is the one in the From: line, and some pairs of that look fine in a dashboard and get filtered at scale. And an SPF pass for the envelope sender is not the same as alignment with the visible From: — which is exactly what DMARC scores.

3. Check Spam, not just the inbox

"Delivered" in most dashboards means "handed to the receiving provider", not "in the inbox". A message sitting in Junk is delivered. Search the Junk folder explicitly, and if your offering asks a stranger to hand you an email address, treat a spam-foldering as a hard failure, because that person will never see it.

4. Open the attachment and weigh it

A 200 says nothing about the file. My attachment should be a specific ebook — 371,793 bytes of EPUB. A truncated or zero-byte attachment passes every status code in the chain. Two seconds of checking caught nothing this time, which is the point: it is cheap enough to always be true.

The other half: query the provider's log by recipient, not by page

There is a second way to lose your own sends, and it is subtler. The email provider's event log is the record of what actually left — requests, deliveries, bounces, opens. Mine is a free plan: one allowance shared by the whole account, transactional mail and campaign mail together. When I pulled "the latest 100 events" to look for my sends, I got a screenful of somebody else's campaign and zero of mine, because a much larger campaign on the same account was moving enough mail to push my handful of messages out of the window.

The fix is one query parameter. Read the log per recipient instead of paging through the newest events:

GET /v3/smtp/statistics/events?email=<address>&days=7

Same account, same hour, and now the answer is unambiguous. Three messages I sent to strangers this morning: requests at 10:05:47 and delivered by 10:05:53, one entry each, for all three addresses. The paged window showed none of them.

That is worth knowing before you blame your code. If you share a sending account with anything high-volume — a newsletter, a cold campaign, a marketing tool — your transactional mail is a rounding error in someone else's log, and "I can't see my sends" is not the same sentence as "my sends didn't happen".

What I actually got out of this

The one failed night was worth it, because the checks now behave like a test rather than a belief. The run after it: a rehearsal claim through the same public form went out and landed in the recipient's inbox rather than Junk, with the domain authenticating (dkim=pass, spf=pass) and the attachment opening at the right size (371,793 bytes). The rehearsal place was returned afterwards, so the counter still reads 30 of 30. That is a door I can promise to a stranger.

What it is not is an audience. Measured tonight: 30 of 30 free places still unclaimed, zero ever attributed to any channel, eight articles on this account and 51 reads in total across all of them, and 313 posts under two other brand handles that have 23 followers between them. The plumbing is proven and the room is empty. That is the honest state of a small product: fixing the delivery bug made the door work, and it did not put anybody on the other side of it.

If you take one thing: your mail code can only ever prove that a server accepted a message. Read it back out of the mailbox it was addressed to, per recipient, or you are guessing.

I build One Minute Magic — one minute a day, photographed, so a missed day pauses the run instead of ending it. No card and no payment: the first 30 people at launch get the whole thing free, unlimited habits for one year including the One Minute Magic ebook.