DEV Community: kyb8801

24h after my 5-posts-per-day experiment on dev.to: 11 views total. The platform was right.

kyb8801 — Fri, 22 May 2026 08:24:32 +0000

24h after the 5-posts-per-day experiment: every post is at zero. The platform was right.

Yesterday I posted five articles to dev.to in a 24-hour window to test what "consistency wins" actually means. Public results, 24 hours after the first post went up:

#	Title	Views
1	Shipped: first MCP server for ISO 10012:2026	0
2	I Put 7 Products on Gumroad. 4 of Them Had No Files.	0
3	I Did Not Write New Code This Week. (README rewrite)	11
4	What an MCP server actually returns: CD-SEM 45 nm	0
5	sympy.parse_expr will run os.system if you let it	0

11 views total. One post got distributed. The other four did not exist as far as the dev.to algorithm was concerned.

I also published a meta-post the same day analyzing the multi-post-per-day dampening. That meta-post is also at zero views.

The platform has been telling me one thing for years: post once a day, consistently, and let it cook. I had assumed that meant "post often." It meant the opposite.

What "consistency wins" actually means on dev.to

Each post you publish goes into an algorithmic surfacing queue. The queue has a per-author budget. Empirically, that budget appears to be roughly one post per day. If you submit five posts in 24 hours, four of them get processed but never surfaced — they go into your feed and into the public list ordered by published_at, but they do not enter the home-page recommendation rotation.

This is the same pattern Twitter, Instagram, and YouTube run. Multi-post-per-day is treated as a low-quality signal and depressed accordingly. dev.to is more lenient than YouTube but still penalizes the pattern hard.

What I would have done if I had read the dev.to forem source code more carefully:

One post per day, no exceptions
Schedule batches via the API's published_at future date rather than publishing all at once
Tag combinations that cluster around one main tag rather than spraying across #showdev, #mcp, #anthropic, #metrology, #indiehackers, #gumroad, #sideprojects, #python, #writing, #security (this was the actual tag set I used across the 5 posts — way too scattered)

What works in my data so far

The only post that got distribution (the 11-view README rewrite story) had three things going for it:

It was the longest (~7 min read). dev.to weighs reading time as a quality proxy.
It was on a recognizable topic class — README rewriting as a build-in-public lesson. The narrative arc is familiar to indie builders, who are dev.to's main audience.
It was a Sunday evening post (~22:00 KST = ~13:00 UTC). Sunday traffic on dev.to is heavily indie/builder, which matches the content.

The four posts that got zero had one or more of these issues:

Posted within 4 hours of each other (sequence dampening)
Highly specific niche tags (#metrology, #anthropic) that filter audience
Short read time (1-3 min) which the algorithm undervalues
A Show-Off style post about an MCP server, which is interesting to a sub-1% of dev.to readers

What I will do today, day 2

One post. This one. Posted ~24 hours after the first of yesterday's batch, well outside the multi-post-per-day window. Then nothing tomorrow. Then one post on Friday.

I will publish the next stats post in 7 days. If this post gets 10x the average view count of yesterday's batch (target: ≥100 views in 7 days), the one-per-day rule is confirmed working for this account. If it gets <50 views, the issue is either the topic class or my account standing — different fix.

For other indie devs running into the same wall

Public summary of the lesson, no caveats:

Multi-post-per-day on dev.to does not work. Verified, 5 posts → 11 views.
The first post you publish each day is the only one the algorithm sees.
Cross-post strategy (Medium ↔ dev.to ↔ Hashnode) needs canonical_url set on dev.to so SEO consolidates on the source-of-truth, not on the cross-post.
The series field on dev.to does internal link-building for free. Use it for any post group you would otherwise publish as a series of articles. I did not, and the four lost posts had no upstream funnel.

If you are about to ship something and you think "I'll post 5 times to maximize reach," you will get exactly the opposite of what you hoped for.

If you want to see the actual product the dev.to posts were about: github.com/kyb8801/measurement-uncertainty-mcp · MCP server for ISO 10012:2026 calibration uncertainty. Live at measurement-uncertainty.mcpize.run. Excel companion on Gumroad: kyb8801.gumroad.com/l/gum-toolkit.

I'll publish next stats in 7 days.

I published 5 dev.to posts in 24 hours about my MCP server. Here's exactly what each one got.

kyb8801 — Tue, 19 May 2026 02:59:47 +0000

I published 5 dev.to posts in 24 hours about my MCP server. Here's exactly what each one got.

A test of the "consistency wins on dev.to" advice. Five posts in 24 hours about the same MCP server. Same author. Different angles. Public stats below.

The raw numbers (May 19, 2026, ~24h after the first post)

#	Published	Title (truncated)	Read	Views
1	2026-05-18	Shipped: first MCP server for ISO 10012:2026	1 min	0
2	2026-05-18	I Put 7 Products on Gumroad. 4 of Them Had No Files.	3 min	0
3	2026-05-18	I Did Not Write New Code This Week. (README rewrite)	7 min	11
4	2026-05-19	What an MCP server actually returns: CD-SEM 45 nm	3 min	0
5	2026-05-19	sympy.parse_expr will run os.system if you let it	4 min	0

Total: 11 views, 0 reactions, 0 comments. One post (the longest one, posted first) got 11 views. The other four got zero each.

What the data says (and what it doesn't)

Multi-post-per-day dampening is real. Posts #1, #2, #3 went up on the same day with the same author. Only the first (or in this case the longest — posts went up in close succession) got any algorithmic distribution. Posts #2 and #3 received essentially zero algorithmic surface area.

Same pattern on day 2. Posts #4 and #5 on May 19 are both still at zero a few hours after publish. Insufficient time to be sure, but the day-1 pattern strongly suggests dev.to caps the daily algorithm budget per author somewhere around "one post."

The 7-minute post outperformed. Longer reading time correlates with surfacing in this sample. n is too small to be a real signal but the post that got distribution was 7 minutes; the others were 1–4 minutes. Worth testing.

No tag was magic. I tried #showdev, #mcp, #anthropic, #metrology, #indiehackers, #gumroad, #sideprojects, #python, #writing, #security. Combinations of 4 each. None of them produced organic discovery in 24 hours.

What I will change next time

One post per day, not three. The data above is the experiment, and the experiment says don't do this.
Promote on Mondays / Tuesdays. Saturday/Sunday posts are a known weak window on dev.to. Posts #1–#3 went up on a Sunday (KST).
Use the canonical_url field. All five posts were original-on-dev.to. Cross-posting from Medium with canonical_url set still gets you onto dev.to algorithm surface area while consolidating SEO juice on the canonical. I did not do this and probably should have.
Start a series. The Forem series field groups related posts. Series posts appear linked at the top of each member, which is essentially free internal-link distribution. I will tag the next batch as a single series.

The honest part

Five posts. Eleven views. Zero reactions. Zero comments. This is what build-in-public looks like for an indie MCP server in a regulated niche on day one, with no audience pre-built. If you are about to ship and you expected a soft landing because "dev.to is fair," recalibrate. The platform rewards consistency over time. Not five-on-one-day.

If you are doing the same thing and want to compare notes, the underlying product is a measurement-uncertainty MCP for ISO/IEC 17025 calibration labs. Repo and live MCP below. I'll publish another stats post in 7 days.

Repo: github.com/kyb8801/measurement-uncertainty-mcp. Live MCP: measurement-uncertainty.mcpize.run. Weekly build log: YB's AI Hustle Weekly.

sympy.parse_expr will run os.system if you let it. Here's the AST gate that stopped me from shipping the RCE.

kyb8801 — Tue, 19 May 2026 02:56:02 +0000

sympy.parse_expr will run os.system if you let it. Here's the AST gate that stopped me from shipping the RCE.

I was building an MCP server that accepts a measurement formula as a string from an LLM, parses it with sympy, and evaluates it via Monte Carlo. Five minutes of integration. Thirteen tests. Twelve passed.

The thirteenth was a safety test. The formula it passed was:

"__import__('os').system('echo PWNED')"

The test expected a ValueError. Instead I got a test failure message and the string PWNED printed to my terminal.

Let me spell that out. sympy.parse_expr, with the default arguments I was using, actually invoked os.system on my machine. My own parser, running in my own test process, shelled out and echoed text into my terminal. If I had shipped this to production, any LLM user with a sufficiently creative prompt could have had that same shell-out happen on a Cloud Run instance under my billing account.

Why this happens

sympy.parse_expr is implemented on top of Python's eval(). When you don't explicitly lock down the global dictionary it evaluates in, eval inherits the current module's __builtins__, which includes __import__, open, compile, exec, getattr, and friends. A string that looks like a math expression but references __import__ resolves like a Python expression — and runs.

This is documented sympy behavior with warnings in the docs. Warnings do not save you when you are moving fast on launch day.

The vulnerability surface is broader than __import__. Any of these can give an attacker code execution depending on what is in scope:

__import__('os').system(...) — direct shell out
__builtins__.__dict__['eval'](...) — re-enter eval
(0).__class__.__bases__[0].__subclasses__() — escape to arbitrary class instances
getattr(__builtins__, 'open')('/etc/passwd').read() — file read
''.join.__globals__['__builtins__']['exec']('...') — exec via string method walk

The fix that actually works: validate at the AST level before sympy sees the string

import ast

_DANGEROUS_NAMES = frozenset({
    "__import__", "__builtins__", "__class__", "__subclasses__",
    "eval", "exec", "compile", "open", "globals", "locals",
    "getattr", "setattr", "delattr", "exit", "quit",
})

_FORBIDDEN_AST_NODES = (
    ast.Attribute,    # blocks "os.system" and "obj.__class__"
    ast.Subscript,    # blocks "x[0]" indexing into dunders
    ast.Lambda,
    ast.GeneratorExp,
    ast.ListComp,
    ast.DictComp,
    ast.Starred,
    ast.JoinedStr,
    ast.FormattedValue,
    ast.NamedExpr,
)

def _validate_formula_ast(formula: str) -> None:
    tree = ast.parse(formula, mode="eval")
    for node in ast.walk(tree):
        if isinstance(node, _FORBIDDEN_AST_NODES):
            raise ValueError(
                f"Disallowed formula construct: {type(node).__name__}"
            )
        if isinstance(node, ast.Name):
            if node.id in _DANGEROUS_NAMES:
                raise ValueError(f"Disallowed identifier: {node.id!r}")
            if node.id.startswith("__") and node.id.endswith("__"):
                raise ValueError(f"Dunder identifiers are not allowed")

The gate runs before sympy ever sees the string. The whitelist permits exactly what a measurement model needs — arithmetic operators, unary minus, named inputs, and calls into sympy's own math namespace for exp, log, sin, sqrt. Anything else raises a clean ValueError that names the offending construct.

ast.parse(..., mode="eval") is the standard library's free safety net here. It refuses to parse a statement (you cannot pass import os), and it gives you a typed tree you can walk and filter without ever evaluating anything.

Why blocking `ast.Attribute` matters specifically

The most common attack path through sympy.parse_expr is attribute access: os.system, ().__class__.__bases__[0].__subclasses__(), and the string-method-walk family. If you block every ast.Attribute node and every ast.Subscript node at the parser stage, you cut off basically all known sandbox escapes through the eval-based path.

The cost is that your accepted formula grammar becomes "arithmetic on bare names + calls to a whitelisted set of math functions." For a measurement uncertainty calculator, that is exactly the grammar you want. For more general DSLs, the whitelist gets longer but the pattern is the same.

Verifying the gate

def test_mc_blocks_import_trick():
    bad = "__import__('os').system('echo PWNED')"
    with pytest.raises(ValueError, match=r"(?i)disallowed|dunder|attribute"):
        propagate(formula=bad, estimates={}, components=[])

def test_mc_blocks_attribute_walk():
    bad = "(0).__class__.__bases__[0].__subclasses__()"
    with pytest.raises(ValueError, match=r"(?i)disallowed|dunder|attribute"):
        propagate(formula=bad, estimates={}, components=[])

def test_mc_allows_real_formula():
    good = "(V * R) / (V + I)"
    # Should not raise. The downstream sympy call will lambdify it.
    propagate(formula=good, estimates={"V": 10.0, "R": 100.0, "I": 0.1}, components=[])

The test asserts not only that the call raises, but that the error message contains "disallowed", "dunder", or "attribute" — because a downstream sympy error would indicate the gate failed. The safe version passed. The shell never ran. Test suite ended that evening at twenty-six green.

The pattern, generalized

Any time you accept a string-as-code from a source you do not trust — LLM output, web input, webhook payload, any of it — the pattern is:

Parse with ast.parse(s, mode="eval") — refuses statements outright
Walk the tree with ast.walk(tree) and filter against a whitelist of allowed node types and names
Reject explicitly with a typed error
Then hand the sanitized input to whatever permissive parser you actually wanted to use

Defense in depth, with the permissive parser as the inner layer. This is what kept me from shipping the RCE to a hosted MCP endpoint that any LLM could call.

If you are building an MCP server that takes a formula, a query, a filter expression, a JSONata path, or any other string-as-code from your LLM, please go check whether your parser is eval-based and what its global dictionary contains by default. The bug is shipping today in more code than its authors realize.

Repo: github.com/kyb8801/measurement-uncertainty-mcp. The gate above lives in math_kernel.py. Live MCP: measurement-uncertainty.mcpize.run.

What an MCP server for measurement uncertainty actually returns: a CD-SEM 45 nm worked example

kyb8801 — Tue, 19 May 2026 02:49:32 +0000

What an MCP server for measurement uncertainty actually returns: a CD-SEM 45 nm worked example

A common reaction when I tell people about measurement-uncertainty-mcp is: "OK but show me what it actually does."

Fair. Here is one query, paste-ready for Claude Desktop, with the actual output.

The query

I measured a 45 nm linewidth on a CD-SEM twenty times: 45.12, 45.08, 45.15, 45.11, 45.09, 45.13, 45.10, 45.14, 45.07, 45.12, 45.11, 45.09, 45.13, 45.10, 45.14, 45.08, 45.16, 45.10, 45.12, 45.11 nm. Combine with magnification calibration of ±0.5 nm at k=2 (50 dof) and line-edge roughness ±0.4 nm at k=2 (50 dof). Report u_c, effective ν via Welch-Satterthwaite, and expanded U at 95%.

The tools the MCP calls

type_a_uncertainty(samples=[...]) — sample mean, Bessel std, u_A, ν_A
type_b_normal(U=0.5, k=2, nu=50) — u_B1 magnification
type_b_normal(U=0.4, k=2, nu=50) — u_B2 line-edge roughness
combine_uncertainty(components=[u_A, u_B1, u_B2]) — u_c via root-sum-of-squares
welch_satterthwaite(components=[...]) — ν_eff
expanded_uncertainty(u_c, nu_eff, level=0.95) — k from Student-t, then U = k × u_c

The actual numbers

Quantity	Value
Mean	45.1125 nm
Sample std (Bessel)	0.0245 nm
u_A (Type A)	0.0055 nm (ν = 19)
u_B1 magnification	0.2500 nm (ν = 50)
u_B2 line-edge roughness	0.2000 nm (ν = 50)
u_c combined	0.3202 nm
ν_eff (Welch-Satterthwaite)	95.5
k @ 95%	1.985
U @ 95%	0.636 nm

Reported result: 45.11 ± 0.64 nm at 95% confidence (k = 1.99, ν_eff = 95).

Why each step matters (and where Excel gets it wrong)

u_A: the sample std must use the Bessel correction (n−1, not n). About one in ten Excel uncertainty templates I have audited use the population std formula by mistake. The MCP uses numpy.std(ddof=1) — no choice.

u_B from k-expanded inputs: a vendor datasheet that says "±0.5 nm at k = 2" means the standard uncertainty is 0.5/2 = 0.25 nm. The tool exposes this conversion explicitly so it cannot be skipped.

Welch-Satterthwaite: when you combine components with different degrees of freedom, the effective ν is not just the sum. The MCP uses the formula from JCGM 100:2008 §G.4.1 directly. Skipping this step and using k = 2 by default gives the wrong U whenever the dominant component has a small ν.

Coverage factor k: at νeff = 95.5 and confidence = 95%, k = scipy.stats.t.ppf(0.975, 95.5) = 1.985. Note this is _not 2 — using k = 2 by reflex (the common shortcut) gives U = 0.640 nm instead of 0.636 nm. Small difference here, large difference when ν_eff is small.

What this would take in Excel

About 20 minutes per budget, and roughly 10% of attempted budgets have at least one numerical error in my experience auditing calibration certificates. The errors are always one of:

Bessel skip (population std vs sample std)
Forgetting to divide a k-expanded input by k
Using k = 2 by default instead of Welch-Satterthwaite + Student-t
Misapplying the sensitivity coefficient when the model is non-linear

The MCP makes each of these into a tool call. You cannot skip Bessel because there is no type_a_population_std tool. You cannot skip the k-divide because type_b_normal requires both U and k. The whole point is that the wrong answer is not reachable without explicitly bypassing the typed interface.

Why this is relevant right now

ISO 10012:2026 was published in February — the first revision since 2003. It adds practical requirements around Test Uncertainty Ratio, decision rules, and guard-banding. Every calibration lab is currently updating their templates. The 10 MCP tools cover exactly the primitives the new standard requires.

Try it yourself

claude mcp add --transport http "Measurement Uncertainty" https://measurement-uncertainty.mcpize.run

Free tier: 50 calls/month, no credit card.

Paste the query above into Claude Desktop. The output you get should match the table above to four decimals.

Repo: github.com/kyb8801/measurement-uncertainty-mcp. Live MCP: measurement-uncertainty.mcpize.run. Weekly solo-builder build log: YB's AI Hustle Weekly.

I Did Not Write New Code This Week. I Rewrote Two Paragraphs and Ten Example Queries.

kyb8801 — Mon, 18 May 2026 11:29:04 +0000

I Did Not Write New Code This Week. I Rewrote Two Paragraphs and Ten Example Queries.

On Tuesday at 3:19 PM local time I committed the smallest, dumbest, highest-impact change I have made to my Model Context Protocol server since the day I made the repo public.

I rewrote two paragraphs in README.md. I added five concrete example queries. I removed one phrase. The diff was twenty-nine lines added, two lines removed. I did not touch a single Python file, no test was rerun, no version was bumped, no MCPize redeploy was triggered. The endpoint kept serving the same ten tools at the same Cloud Run instance. The deploy badge stayed green.

Then I closed the laptop and went to bed because everything I had been doing wrong for six days was about to embarrass me, and I needed to think about it from a distance.

This is the post about what changed and why I should have done it on day one.

Context: A Live MCP Server With a Funnel That Did Not Funnel

The product is measurement-uncertainty-mcp. I shipped it the previous week — a Model Context Protocol server that implements the Guide to the Expression of Uncertainty in Measurement (GUM, JCGM 100:2008) plus the Monte Carlo supplement JCGM 101:2008. Ten tools, GitHub Actions tests, AST-whitelisted formula parser, MCPize Cloud Run live at https://measurement-uncertainty.mcpize.run. I am proud of the technical work. I am embarrassed by the marketing.

Here is what happened in the seven days after public launch.

GitHub stars: 0. NPM downloads: 0. MCPize tool invocations: a handful, mostly mine. Aggregator submissions sat in three pending queues. A Show HN draft sat in a markdown file uncommitted because I kept second-guessing the title. The daily healthcheck task kept reporting "10 tools active, status Active." The infrastructure was healthy. The funnel was a corpse.

I spent two days assuming the problem was reach. So I drafted a 5-channel coordinated launch script — Hacker News Show HN, r/LocalLLaMA, r/MachineLearning, r/Calibration, MCP Discord, LinkedIn — pre-wrote every post body, scheduled it for the following Saturday at 23:00 KST. I was about to drop my one shot at a coordinated public launch into a funnel that, if it had been working, would already have shown some signal from organic discovery.

Sunday morning I sat down with the repo and read the README cold, pretending I was a stranger. That is when I noticed the sentence that was killing me.

The Sentence That Was Killing Me

The original second paragraph of the README, written six days earlier:

Built for AI engineers, metrologists, and semiconductor equipment teams who need to compute Type A/B uncertainties, combined standard uncertainty, effective degrees of freedom, and expanded uncertainty directly from their LLM assistant — without leaving chat or switching to a spreadsheet.

Read that sentence as if you are a calibration lab QA manager whose ISO 10012:2026 audit is in six months. You will bounce. You bounce on the first three words.

"Built for AI engineers" — you are not one of those.

You skim the rest. You see "metrologists" and "semiconductor equipment teams" and conclude this tool is for people who do science at companies that buy ASML steppers, not for the eight-person calibration lab in Bucheon that calibrates pressure gauges for petrochemical plants. You close the tab. You go back to the Excel template you were updating because somebody at ILAC published new guidance on guard-banding and your decision rule needs a paragraph.

That is the actual buyer of an uncertainty calculation tool. There are roughly ten thousand ISO/IEC 17025 accredited calibration labs globally. Each one has a QA manager, a senior metrologist, and a stack of Excel files. None of them describe themselves as "AI engineers." Most of them have heard of MCP only because their own kid mentioned it.

I had written the sentence six days earlier without thinking, because the first audience I had imagined for the launch was the indie-hacker-developer crowd that lives on Hacker News and r/LocalLLaMA. That crowd will star a clever MCP. That crowd will not pay for an uncertainty calculation tool because they do not have an audit in six months.

The sentence that needed to be there was a sentence that named the regulation, named the accreditation body, and used the buyer's own vocabulary.

The Rewrite

The first paragraph used to end with "GUM-compliant measurement uncertainty analysis." It now ends with: "GUM-compliant measurement uncertainty analysis. Built for ISO/IEC 17025 calibration labs, ISO 10012:2026 measurement management systems, and KOLAS / A2LA / UKAS accredited testing."

That is one phrase. It does five things at once. It names the standard the audit will be measured against (ISO/IEC 17025). It names the new standard published in February that triggered every lab to update their templates this year (ISO 10012:2026). It names the three accreditation bodies a calibration lab in Korea, the United States, and the United Kingdom respectively reports to (KOLAS, A2LA, UKAS). It signals that I know the standards numbers. And it does all of this before the reader scrolls.

The Five Example Queries

The biggest change in conversion was probably the example query block.

The repo previously had no concrete query examples. I replaced it with a section called "Five example queries (paste these into Claude Desktop)" and wrote five queries. Real queries:

CMM length calibration at 10 mm nominal — uses the prebuilt template, computes u_c and U at 95%.
CD-SEM 45 nm linewidth uncertainty budget — Type A from twenty replicate measurements, combined with magnification calibration and line-edge roughness, reports ν_eff via Welch-Satterthwaite.
DMM 10 V calibration with TUR check — references a standard at ±20 µV, asks for u_c, expanded U, and the Test Uncertainty Ratio against a tolerance.
Type-K thermocouple at 100 °C with a parameter override on the prebuilt template.
Non-linear ratio model — Y = (V × R) / (V + I) — Monte Carlo with 200,000 trials, shortest 95% coverage interval per JCGM 101 §7.7.

Three things make these examples convert that the previous "Use cases" paragraph did not.

First, every query names a real measurement scenario from a real lab. CMM at 10 mm. CD-SEM at 45 nm. DMM at 10 V. Thermocouple at 100 °C. A reader who works in any of those scenarios sees their own day in the example.

Second, every query produces an answer that the buyer needs to produce anyway. The example is not a demo. It is a job they have to do.

Third, the queries use the buyer's vocabulary back at them. ν_eff via Welch-Satterthwaite. Coverage factor k. JCGM 101 §7.7. A QA manager who has been writing uncertainty budgets for ten years recognizes that vocabulary instantly.

Three Lessons I Did Not Want to Learn

One. The "Built for X, Y, Z" sentence kills your funnel before it starts. If the X is wrong, the rest of the page does not get read. The sentence was a one-line buyer-persona declaration and I had declared the wrong persona. The fix — naming ISO/IEC 17025, ISO 10012:2026, KOLAS, A2LA, UKAS — took me twelve minutes once I knew what to write. The six days of zero conversion were the cost of not having known.

Two. Example queries are not documentation. They are job listings for your tool. Every example query you put in your README is a sentence that answers the question "what would I hire this tool to do for me today?" If you write generic examples — "compute uncertainty," "process this data" — you are listing a job nobody applies for. If you write "CD-SEM 45 nm linewidth uncertainty budget combining magnification calibration and line-edge roughness, report ν_eff via Welch-Satterthwaite" then somebody whose Tuesday looks like that recognizes their Tuesday in your README. They install. The cost of writing five concrete queries is one hour. The benefit is the entire conversion funnel.

Three. In a regulated niche, standards-referenceable language is the buyer's trust currency, and you are spending counterfeit currency if you skip it. A calibration lab QA manager has been burned at least once by a vendor whose product claimed compliance with a standard that the vendor had not actually read. Every time you cite a standard in your README — JCGM 100:2008, JCGM 101:2008, ISO 10012:2026, ISO 14253-1, ILAC G8 — you are putting a number on the page that the buyer can look up. In an unregulated developer niche this lesson does not apply, because developers do not look anything up. In a regulated niche it is the difference between getting installed and not.

What I Will Not Do Again

I will not write a "Built for X" sentence on a regulated-niche README without first writing down the three standards numbers that the buyer types into Google when they have a problem. If I cannot write down the three standards numbers, I do not understand the buyer well enough to be writing the README at all, and the right next action is to read the standards, not to write more code.

I will not ship a README with no example queries. The example queries are the part the buyer reads. The rest is the part they skim while deciding whether to read the queries.

I will not assume that an MCP server's discovery problem is a reach problem before I have read my own README cold, pretending I am the buyer. The reach problem is real. The wrong-buyer problem is more common.

If you are running a solo MCP, a solo SaaS, or any indie product where the funnel feels broken and the build is fine, please go read your README cold. Pretend you are the buyer. Pretend you have an audit in six months. See how long it takes you to bounce.

If it is fewer than three sentences, the build is not the problem.

Repo: github.com/kyb8801/measurement-uncertainty-mcp. Live MCP: measurement-uncertainty.mcpize.run. Weekly solo-builder build log at YB's AI Hustle Weekly — same operational logs, every Sunday morning KST.

I Put 7 Products on Gumroad. 4 of Them Had No Files.

kyb8801 — Mon, 18 May 2026 11:27:18 +0000

I Put 7 Products on Gumroad. 4 of Them Had No Files.

Gumroad Recovery Tour — Episode 1 of 4. 24 days of data, no filter.

I published my first Gumroad store on March 24, 2026.

Seven products. Prices from $9 to $14. Pitched to an audience I had spent six weeks building — YouTube Shorts, X threads, a newsletter with a handful of loyal subscribers.

Twenty-four days later, the dashboard looks like this:

Metric	Number
Products listed	7
Products with files uploaded	3
Products with files missing	4
Page views (all products combined)	~180
Add-to-cart events	0
Completed sales	0
Affiliate clicks from my Medium articles	1
Net revenue	$0.00

And here's the part nobody tells you about empty storefronts: four of my products had no product files attached. If somebody had actually bought one of them, Gumroad would have sent them a receipt and then... nothing. No download link. No file. A refund request, best case. A chargeback at worst.

I only noticed this on day 23 — while auditing my own pipeline for this article.

What the missing files were

Specifically:

AI Power Prompt Pack ($9) — 100 prompts. Had the landing page copy written. Never rendered the PDF.
Python Data Analysis Scripts ($14) — 8 scripts. Had an outline. Never zipped the folder.
Invest Tracker Pro ($12) — a Notion + Excel template. Had neither.
AI Side Hustle Dashboard ($9) — another Notion bundle. Same story.

Four products, four empty shells. A storefront that existed only as screenshots and promises.

Why this happened (the honest answer)

I'd been shipping YouTube Shorts for weeks. Built the pipeline, wrote the automation, set up cross-posting to X and TikTok. Had a newsletter in Beehiiv. A content machine with real outputs and real costs.

And then, when it came time to actually package something somebody could buy, I skipped the packaging step.

I published the store before the products existed.

Why? Because publishing the store felt like "shipping." It had a URL. It looked done. The page said "Add to cart" and the cart worked. The storefront was a demo of a storefront, and the demo was so convincing that I moved on.

This is the content creator trap in 2026, and I walked directly into it: you get so used to making the wrapper — the Short, the tweet, the article, the thumbnail — that you forget the thing inside the wrapper.

The Shorts get views. The tweets get likes. The newsletter gets subscribers. All of those feel like forward motion. None of them are money. The thing that would have been money — a finished PDF, a working Excel file, a zipped folder of Python scripts — required the one kind of work my pipeline couldn't do for me.

It required me to actually build the product.

The cost breakdown

In the name of full transparency, here's what I spent to get to $0:

Category	Cost over 24 days
Anthropic API (Claude scripts, newsletter generation)	~$11
Google API (Gemini Flash-Lite, Veo B-roll)	~$4
Pexels API	$0 (free tier)
Beehiiv	$0 (free tier)
Gumroad	$0 (fee-only model)
Medium MPP	$0 (free writer program)
Domain (optional)	~$1 prorated
Total	~$16

I spent sixteen dollars and roughly 60 hours of my own time to produce: a storefront, an automated Shorts pipeline running two videos a day, a Beehiiv newsletter, a cross-posting setup to X and TikTok, and a domain I've barely used.

Sixteen dollars and zero sales is a cheap lesson in absolute terms. It's an expensive lesson in opportunity cost.

What I'm doing about it (today)

As of this publication:

All four missing files now exist. I spent yesterday generating them. Real PDF. Real zipped scripts. Real Excel with 1,055 working formulas (I checked). Real Notion-importable dashboard. Each one is in the store. Each one would actually download if somebody bought it.
I'm reducing to one Shorts per day, not two. The two-per-day experiment ran for 35 days and produced the same subscriber growth as one-per-day. Content volume was never the bottleneck. Product readiness was.
I'm writing this series. Four episodes. You're reading the first one.

Honest question: if you've hit the same wall — you've built the wrapper and skipped the product inside — what was the thing that made you finally finish it?

Reply or DM. I'll be writing the next episode as soon as the data from this one comes in.

Building in public:

Store: https://kyb8801.gumroad.com
MCP server (my next bet): https://github.com/kyb8801/measurement-uncertainty-mcp
Weekly build log: https://yb-ai-hustle.beehiiv.com
Full reflection on Medium: https://medium.com/@kyb8801

This article was edited by me. The outline and tables were drafted by Claude. The numbers and the embarrassment are both mine.

Shipped: first MCP server for ISO 10012:2026 measurement uncertainty

kyb8801 — Mon, 18 May 2026 11:22:15 +0000

Spent 48 hours building a Model Context Protocol server for ISO 10012:2026 measurement uncertainty.

10 tools. JCGM 100:2008 plus 101:2008 compliant. Live on MCPize.

Built for ISO/IEC 17025 calibration labs that spend hours in Excel on the same uncertainty math every month. The buyer is a QA manager whose audit is in six months, not an AI engineer.

What it does

Type A statistical uncertainty (Bessel-corrected, ν=n-1)
Type B rectangular / triangular / k-expanded distributions
Combined standard uncertainty u_c via root-sum-of-squares
Welch-Satterthwaite effective degrees of freedom
Expanded uncertainty U at target confidence level
Monte Carlo propagation per JCGM 101:2008
6 pre-built uncertainty-budget templates (CMM 10mm, CD-SEM 45nm, DMM 10V, OCD 50nm, thermocouple, balance)

Try it

Repo: https://github.com/kyb8801/measurement-uncertainty-mcp
Live MCP: https://measurement-uncertainty.mcpize.run
Free tier: 50 calls/month, no credit card
Full build log (Medium): https://medium.com/@kyb8801/i-did-not-write-new-code-this-week-i-rewrote-two-paragraphs-and-ten-example-queries-d5e7aa18ecfe

Building in public. Weekly progress log: yb-ai-hustle.beehiiv.com (free).

Building DevSignal: AI signal-based outreach for solo devtool founders. 30-day public sprint.

kyb8801 — Thu, 30 Apr 2026 07:09:34 +0000

Hey dev.to 👋

I'm a solo SaaS founder. In the past 6 months I shipped 4 packages on NPM — and like everyone here, the hardest part wasn't building. It was getting anyone to care.

So I'm starting a 30-day public build of DevSignal — a tool that turns GitHub stars, HN comments, Reddit threads, and Twitter mentions into warm leads + AI-drafted outreach. Built for solo founders, by a solo founder.

Wait list: https://devsignal.dev

Why I'm building it

Three things I keep hitting:

Cold email blasts feel sleazy AND don't work anymore. Open rates collapsed. Reply rates near zero.
Apollo, Clay, Common Room are built for sales teams. Clay starts at $185/mo. Common Room at $1,000+. I'm one person.
The people who'd actually pay for my tool already exist. They starred my competitor's repo. They complained on Reddit about the exact problem I solve. They hang out on HN. I just can't see them.

DevSignal is the tool I wish I had when I shipped.

What it does (planned MVP)

Connect — your repo, competitor repos, HN/Reddit/Twitter handles. 5 min.
We surface warm signal — devs who starred you, devs complaining about a pain you solve, devs commenting on competitor threads. With context.
You send 1-tap outreach — AI drafts a context-aware first message. You approve. We track replies.

No data brokers. No cold lists. No spam blasts. Signal-first.

The 30-day plan

Week 1 — Landing + 30 interview prospects + first conversations
Week 2 — 10–15 founder interviews. Refine value prop based on their words.
Week 3 — MVP scope. Start building. Lock in 5 beta users.
Week 4 — Ship MVP. Convert 3 paid pilots ($49 each).

Day 30 gate: 50 wait list / 10 interviews / 5 betas / 3 paid → continue. Below that → pivot.

Stack (cheap & boring)

Tally for forms
Carrd for landing
Supabase + Clerk for auth/DB
Vercel + Next.js for backend
Claude API for messaging
Resend for email send
Stripe for payments

Total infra: ~$50–200/mo at start. Scales.

What I'd love from this community 🙏

1. If you've been a solo devtool founder and struggled with finding your first users — would love a 30-min interview. I'll trade early access + lifetime 50% off for your time. Reply or DM.

2. Honest critique. What kills this idea? What did Common Room/Clay actually solve well that I'm missing? Tell me the unflattering truth.

3. Wait list: https://devsignal.dev — if you'd want this when it ships, drop your email. You'll get 14-day free trial + 50% off first 3 months.

Why I think this works (or doesn't)

✅ I've felt the pain personally. Currently dogfooding Phase 0.
✅ Sub-niche is sharp: solo, devtool, signal-based (not list-based), $49–199/mo.
✅ Competition (Common Room, Clay, Apollo) is real but sized for teams. Solo gap looks underserved.

❌ "Yet another outreach tool." You should be skeptical.
❌ NuReply, Coldreach.ai, PlusVibe exist at solo prices. Differentiation has to be sharp.
❌ Solo founders are notoriously hard to acquire as customers.

If this fails, I'll write a post-mortem here too. Either way, you'll see the journey.

Let's go 🛠️

Wait list → devsignal.dev

DEV Community: kyb8801

24h after my 5-posts-per-day experiment on dev.to: 11 views total. The platform was right.

24h after the 5-posts-per-day experiment: every post is at zero. The platform was right.

What "consistency wins" actually means on dev.to

What works in my data so far

What I will do today, day 2

For other indie devs running into the same wall

I published 5 dev.to posts in 24 hours about my MCP server. Here's exactly what each one got.

I published 5 dev.to posts in 24 hours about my MCP server. Here's exactly what each one got.

The raw numbers (May 19, 2026, ~24h after the first post)

What the data says (and what it doesn't)

What I will change next time

The honest part

sympy.parse_expr will run os.system if you let it. Here's the AST gate that stopped me from shipping the RCE.

sympy.parse_expr will run os.system if you let it. Here's the AST gate that stopped me from shipping the RCE.

Why this happens

The fix that actually works: validate at the AST level before sympy sees the string

Why blocking ast.Attribute matters specifically

Verifying the gate

The pattern, generalized

What an MCP server for measurement uncertainty actually returns: a CD-SEM 45 nm worked example

What an MCP server for measurement uncertainty actually returns: a CD-SEM 45 nm worked example

The query

The tools the MCP calls

The actual numbers

Why each step matters (and where Excel gets it wrong)

What this would take in Excel

Why this is relevant right now

Try it yourself

I Did Not Write New Code This Week. I Rewrote Two Paragraphs and Ten Example Queries.

I Did Not Write New Code This Week. I Rewrote Two Paragraphs and Ten Example Queries.

Context: A Live MCP Server With a Funnel That Did Not Funnel

The Sentence That Was Killing Me

The Rewrite

The Five Example Queries

Three Lessons I Did Not Want to Learn

What I Will Not Do Again

I Put 7 Products on Gumroad. 4 of Them Had No Files.

I Put 7 Products on Gumroad. 4 of Them Had No Files.

What the missing files were

Why this happened (the honest answer)

The cost breakdown

What I'm doing about it (today)

Shipped: first MCP server for ISO 10012:2026 measurement uncertainty

Building DevSignal: AI signal-based outreach for solo devtool founders. 30-day public sprint.

Why I'm building it

What it does (planned MVP)

The 30-day plan

Stack (cheap & boring)

What I'd love from this community 🙏

Why I think this works (or doesn't)

Why blocking `ast.Attribute` matters specifically