DEV Community: Amit Feldman

All six security headers fixed in a day — the Macless before/after

Amit Feldman — Sun, 16 Aug 2026 15:04:11 +0000

Earlier today I left a findings-first comment on a launch writeup here: a passive scan of the product's site, the top findings with the concrete fix, and an offer of a free re-scan once deployed. No pitch — the scan is the conversation.

The maker read it, put Cloudflare in front of his GitHub Pages site, and closed every single finding within hours. This is the before/after.

The launch

Macless by @maclessdev — a GitHub-Actions pipeline, signing scripts, and notes for building and submitting an iOS app to the App Store without owning a Mac. The marketing page lives at macless.dev, hosted on GitHub Pages.

Before (scan, Aug 16): 10 passed / 4 warnings / 2 failures

The base was decent: TLS clean (Let's Encrypt, TLSv1.3), fast response (266 ms), title, meta description, exactly one H1, robots.txt and sitemap.xml live.

The gap was the entire security-header layer — all six missing:

No HSTS — every first visit over HTTP was downgrade-able
No Content-Security-Policy — no XSS mitigation layer at all
No X-Frame-Options — clickjacking exposure
No X-Content-Type-Options, Referrer-Policy, Permissions-Policy

The frustrating part: none of this is application work. GitHub Pages doesn't let you set custom headers, full stop — so the fix isn't a code change, it's an architecture tweak.

The fix: Cloudflare in front, two Transform Rules

He put Cloudflare in front of the Pages site (free tier) and set the headers at the edge with Transform Rules — no deploy, no code, DNS plus config.

After (re-scan, same day — verified twice): 16 passed / 0 warnings / 0 failures

HSTS: max-age=15552000 (180 days)
CSP: default-src 'self'; script-src 'none'; style-src 'self'; img-src 'self'; font-src 'self'; frame-ancestors 'none'; base-uri 'self'; object-src 'none'; form-action 'self'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation, microphone, camera all locked down

That CSP deserves a second look. script-src 'none' is bolder than most production sites dare to run — it says this page executes zero JavaScript, which for a static marketing page is exactly true and exactly right. frame-ancestors 'none' plus XFO DENY is belt-and-suspenders clickjacking defense. This isn't a header set copied from a blog post; it's a header set matched to what the page actually does.

Three takeaways for anyone launching on GitHub Pages

1. Pages can't set headers — put a proxy in front. GitHub Pages serves your files and nothing else. If your launch page lives there, the security-header layer doesn't exist until you add Cloudflare (or any CDN that can mutate response headers) in front of it.

2. The fix is a Transform Rule, not a sprint. Cloudflare → Rules → Transform Rules → Modify Response Header. One rule can set every static header. Total elapsed work: minutes. The entire "after" column above required zero commits.

3. Match CSP to reality, then tighten. A static page can run script-src 'none'. An app shell can't. Start from what the page genuinely loads, enforce that, and resist the urge to cargo-cult a permissive policy you saw elsewhere.

Why I'm telling this story

Because this is the loop that works: findings → fix → verified re-scan. @maclessdev didn't pay anyone for this — the first scan and the re-scan were free, and his launch page now passes checks that show up verbatim in enterprise security questionnaires.

I run these scans findings-first on launch posts here regardless of whether anyone buys anything. If you want the full deep pass — auth-flow edge cases, header drift across routes, perf budget, prioritized fix list with stack-specific snippets — that's the Launch-Ready Audit ($99, 48h turnaround): https://afeldman2.gumroad.com/l/zxpluh?utm_source=devto&utm_medium=article&utm_campaign=casestudy-macless
The Deep Dive ($149) adds a written remediation plan + re-scan verification: https://afeldman2.gumroad.com/l/wmdfxb?utm_source=devto&utm_medium=article&utm_campaign=casestudy-macless-deepdive

And if I commented on your launch and you've shipped the fixes, say so in the thread. The re-scan is free, and if the before/after is this clean, I'll write about yours next.

5 tools launched this week promising "your data never leaves your browser" — none shipped the header that enforces it

Amit Feldman — Sun, 16 Aug 2026 13:12:38 +0000

A week ago I ran a passive launch-readiness check on 10 freshly launched products and published the pattern: 7 out of 10 shipped with no Content-Security-Policy at all.

This week I did it again — 8 products that launched in the last ~24 hours, all "I built this" posts by solo makers. Same method: public HTTP response headers and homepage HTML only. No probing, no auth, nothing intrusive. Exactly what any scanner, prospect, or security-conscious customer sees on a single page load.

I'm not naming anyone again. The pattern is the point — and this week the pattern got sharper.

The results

8 out of 8 shipped with no Content-Security-Policy.

Not 7 out of 10 this time. All of them.

Check	Missing	Why it matters
Content-Security-Policy	8/8	Nothing mitigating XSS / injected scripts
X-Frame-Options	7/8	Site can be framed anywhere → clickjacking
Permissions-Policy	7/8	Camera/geo/mic unrestricted by default
HSTS	6/8	First-visit downgrade possible
Referrer-Policy	6/8	Full URLs leak to every third-party request
X-Content-Type-Options	6/8	MIME-sniffing exposure on user content

One product came genuinely close — 5 of 6 headers present, HSTS set for two years, missing only the CSP. That's the closest anyone got.

The part that made me write this

Here's the sharper pattern: 5 of the 8 tools pitch privacy as the product. "Runs in your browser." "Nothing uploaded." "Private by design." Client-side processing is the headline feature — it's in their titles and their hero copy.

And every one of them shipped without the one header that actually enforces that promise.

A CSP is what stops an injected script — a compromised dependency, a malicious ad tag, a poisoned CDN asset — from reading the data your users just trusted never leaves their browser. Without it, "nothing leaves your browser" is a marketing sentence, not an enforced property. One bad script tag away from being false.

None of these makers are careless. Client-side processing is real engineering, and they did it. The gap is that the last mile — telling the browser "only run scripts I explicitly allow" — is a config line nobody wrote, because no test fails and no deploy breaks when it's missing.

The good news: same-day fixes are real

Yesterday I flagged a missing CSP and HSTS in the comments of one maker's launch post. By the evening he'd deployed all six security headers — CSP locked down to script-src 'none', HSTS for 180 days, the full set. His re-scan came back completely green: 16 checks passed, 0 warnings, 0 failures.

Total elapsed time from "never thought about it" to "fully locked down": a few hours, in the middle of launch day.

That's the actual story of these failures. Not skill, not budget — just that launch week has a hundred things in it and headers are item #101. Every fix above is a one-line config at the host or CDN layer: Vercel, Netlify, Cloudflare, nginx, all have a documented snippet.

The SEO side, quickly

Better than last week — 7 of 8 had exactly one <h1> and a real canonical. Remaining nits:

One homepage had two <h1> tags — splitting your best keyword slot against itself
One meta description ran 178 characters — truncates mid-sentence in search results (~160 limit)
One page took 2.9 seconds to respond, with 836ms of server think time — first impression spent staring at a blank tab

What I'd do (and did)

Same rule as last week: a launch isn't done when the deploy succeeds — it's done when the thing a stranger's browser receives passes a baseline. Run the check before the traffic, not after.

If you shipped recently and want the full picture: I run a Launch-Ready Quick Scan — passive headers/TLS/HTML checks plus a human-written readout of what to fix first, delivered within 24h. It's $29 for the launch period (normally $49), written so you can hand it straight to whoever owns your deploy config. Grab one here.

And if your product's pitch is "private, runs in your browser": the CSP is the difference between promising it and enforcing it. Twenty minutes tonight.

I re-scanned the launches I flagged last week — here's who actually shipped the fixes

Amit Feldman — Sun, 16 Aug 2026 09:05:27 +0000

For the past two weeks I've been running passive, read-only security scans on products that launch here on dev.to, and posting the findings publicly with the concrete fix for each. No pitch in the first touch — the scan is the conversation, and I always offer a free re-scan once fixes are deployed.

The part I didn't expect: how many makers actually shipped the fixes. This is the verification roundup — real before/after numbers from the re-scans.

The pattern across ~100 launches

The headline finding from the broader sweep hasn't changed: the most common failure is a missing Content-Security-Policy — roughly 7 in 10 launches — followed by missing HSTS. Both are one-line fixes. Almost nobody ships them on day one.

Maker 1: Loop — full remediation in under 24 hours

The fastest turnaround so far. Loop (Next.js on Vercel) launched with 7 passed / 5 warnings / 4 failures: no CSP, no X-Frame-Options, no nosniff, and — because the app renders client-side only — no title, meta description or h1 for crawlers and link-unfurlers.

Under 24 hours later the re-scan read 15 passed / 1 warning / 0 failures. Every failing header closed. I wrote up the full before/after as a case study.

Maker 2: Macless — 5 of 6 headers live within hours

Macless (ship an iOS app without a Mac) launched on GitHub Pages with all six security headers missing. GitHub Pages gives you no header control — so the maker put Cloudflare in front of the domain and used a Transform Rule to set headers at the edge.

My re-scan verified, live:

X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy locked down
HSTS on, 180-day max-age

Five of six, in hours. The one still open is the CSP — which is also the one doing the actual XSS work. Same fix path: one more Transform Rule, start with a tight default-src 'self' and loosen only what breaks. If you're on GitHub Pages, this CDN-front pattern is the way — Pages itself will never give you these headers.

Maker 3: PlaygroundAPI — rescan reads 15 passed / 1 warning / 0 failures

PlaygroundAPI — a free sandboxed mock REST & GraphQL service — came back essentially clean on verification: HSTS at max-age=63072000; includeSubDomains; preload, CSP defined, X-Frame-Options DENY, nosniff, Referrer-Policy and Permissions-Policy all live, TLS 1.3, 267 ms total response. The interesting surface left is the API itself — auth-flow edge cases like token expiry/reuse and session isolation — which is a manual review, not a scanner finding.

Maker 4: the platform-constraint case

One launch on a .streamlit.app subdomain verified their fix but hit a wall: on a platform subdomain you don't control the edge, so granular CSP and HSTS enforcement isn't yours to set. Their plan — move to a custom domain with Cloudflare and use Transform Rules — is the correct one, and the same pattern Macless used above. Platform subdomains are fine for demos; if you're collecting real users, the custom domain is part of the security posture, not just branding.

What I take from this

Makers fix things fast when the fix is concrete. Every deployed fix above came from a findings comment that included the exact header line or rule to add, not a generic "you should harden your headers."
The CDN-front pattern solves the two hardest hosting cases (GitHub Pages, platform subdomains) with the same move: Cloudflare in front, Transform Rules at the edge.
CSP is still the last one standing. It's the highest-value header and the one everyone defers, because a tight CSP can break inline scripts. Ship a report-only policy first (Content-Security-Policy-Report-Only), watch what fires, then enforce.

Findings on launch posts stay free — the re-scan verification too. If I flagged your launch and you've shipped the fixes, reply on your thread and I'll re-run the check and post the verified numbers, same as above.

I build envcheck, a .env validator and secret-leak scanner for CI — the scans above run on the same engine.

I ran a passive security check on 100 freshly launched products — 1 in 5 shipped with zero security headers

Amit Feldman — Fri, 07 Aug 2026 22:05:07 +0000

Last week I posted the results of checking 10 products that had just launched. The pattern was so consistent that I kept going. This is the follow-up: 100 products, all launched within roughly the past week, pulled from Product Hunt, dev.to launch posts, r/SideProject, Peerlist, Microlaunch, Uneed, and a couple of launch directories.

Same rules as before — passive only. Public HTTP response headers and homepage HTML, the exact thing any scanner, prospect, or security-conscious customer sees when your site loads once. No probing, no auth attempts, nothing intrusive.

And same as before: I'm not naming anyone who failed. The point is the pattern, not the callout.

The results

Check	Missing	What it means
Content-Security-Policy	76/100	Nothing mitigating XSS / injected scripts
Permissions-Policy	78/100	Camera, mic, geolocation unrestricted by default
X-Frame-Options	67/100	Pages can be iframed anywhere → clickjacking
Referrer-Policy	63/100	Full URLs leak to every third-party request
X-Content-Type-Options	57/100	MIME-sniffing exposure on user content
HSTS	37/100	First-visit downgrade still possible

Two numbers that surprised me even after the first batch:

20 out of 100 shipped with all six missing. Not one obscure header — every single baseline protection absent. These weren't broken products; several were polished, well-designed launches with real traction.

Only 13 out of 100 were fully clean. And consistent with the first batch, the clean ones skewed toward small solo projects, not the bigger teams. "More people at launch" does not mean "someone checked."

Why this keeps happening

None of these are code fixes. Every one is a config line at the host or CDN layer — Vercel, Netlify, Cloudflare, nginx, all of them have a documented snippet, and most can apply it at the edge without a deploy. The failure mode isn't skill. Launch week has a hundred things in it and "headers" is item #101. There's no test that fails, no deploy that breaks, no user who complains. The site just quietly tells every visitor's browser: no rules, do whatever.

That's exactly the class of problem that only gets caught by something that checks, every time, automatically — because humans are bad at "every time."

It's fixable fast — I watched it happen

The most common pushback I got last week was "sure, but who has time during launch week?" So here's the counterexample: one maker I flagged went and fixed every missing header within 24 hours — full before/after, verified by re-scan. I wrote it up here: One maker fixed every security header on his launch in 24 hours — here's the before/after. His site went from 5 findings to zero while I slept.

If you're behind Cloudflare, four of the six are a single Transform Rule (Modify Response Header) at the edge — no code change, no deploy. HSTS starts at a short max-age (3600) and steps up once verified. CSP is the one that takes actual care with a SPA, but default-src 'self' plus your API origins is a safe start, and Content-Security-Policy-Report-Only lets you measure before you enforce.

What I'd do differently (and do)

My rule hasn't changed: a launch isn't done when the deploy succeeds — it's done when the thing a stranger's browser receives passes a baseline. 87 out of 100 launches this week hadn't run that check.

If you shipped something recently and want to know where you stand: I run a Launch-Ready Quick Scan — passive headers/TLS/HTML checks plus a human-written readout of what to fix first, delivered within 24h. It's $29 for the launch period (normally $49), written so you can hand it straight to whoever owns your deploy config. Grab one here.

And if you're pre-launch: the six headers above are a 20-minute fix tonight. Do it before the traffic, not after.

One maker fixed every security header on his launch in 24 hours — here's the before/after

Amit Feldman — Fri, 07 Aug 2026 09:50:55 +0000

A week ago I started leaving findings-first comments on launch posts here: I run a passive scan of the product's site, post the top findings with the concrete fix, and offer a free re-scan once it's deployed. No pitch in the first touch — the scan is the conversation.

This week one maker did the thing every security person wishes more teams would do: he read the findings, deployed the fixes the same day, and asked for the re-scan. This is the before/after, with his permission-worthy win on full display.

The launch

Loop by @jammyvibez — a collaborative social app where developers share code, fork snippets, and co-write posts live. A Next.js app on Vercel, launched here on August 5th.

Before (scan, Aug 5): 7 passed / 5 warnings / 4 failures

The good news first: HSTS was already strong (max-age=63072000; includeSubDomains; preload), TLS was clean, robots.txt and sitemap.xml were live.

The gaps:

No Content-Security-Policy — the single highest-value header for an app that renders user-generated content
No X-Frame-Options — clickjacking exposure on every page
No X-Content-Type-Options, Referrer-Policy, Permissions-Policy
No <title>, no meta description, no <h1> — the app renders client-side only, so crawlers and link-unfurlers saw an empty shell

That last cluster matters more than people think: every link preview of his launch — in Discord, Slack, X, iMessage — was generating from nothing.

After (re-scan, Aug 6): 15 passed / 1 warning / 0 failures

Under 24 hours later:

CSP live: default-src 'self' with an explicit allowlist for the two third-party origins the app actually loads (Stripe.js and Vercel Analytics)
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera/microphone scoped to self, geolocation/payment/usb locked down
Title (39 chars), meta description (145 chars), exactly one H1 — the page now renders its metadata server-side

The remaining backlog, which he has in writing: script-src still carries 'unsafe-inline' 'unsafe-eval' (a Next.js hydration constraint you close with nonces when it matters), and TTFB is ~2.1s cold. Neither is a launch blocker. Both are honest items on a real list.

Three takeaways for anyone launching this week

1. Headers are a config file, not a sprint. On Vercel it's a headers() block in next.config.js or entries in vercel.json. On Netlify it's a _headers file. Behind Cloudflare it's one Transform Rule at the edge — no deploy at all. The entire "after" column above was one commit.

2. If your app is client-rendered, your metadata doesn't exist. Crawlers, link unfurlers, and most social scrapers don't execute JavaScript. SSR/SSG your <title>, meta description, and at least one <h1> — or accept that every share of your launch looks blank.

3. Ship CSP in report-only mode first. Content-Security-Policy-Report-Only tells you what would break without breaking it. Let violation reports collect for a few days, allowlist what you actually load, then enforce. Loop's CSP is a good enforced end-state: default-src 'self' plus exactly the origins you use.

Why I'm telling this story

Because this is the loop that works: findings → fix → verified re-scan. @jammyvibez didn't pay anyone for this — the first scan and the re-scan were free, and now his launch passes checks that show up verbatim in enterprise security questionnaires.

I run these scans as Launch-Ready Quick Scans — $29 during launch period, top findings plus the full report — and I keep commenting findings-first on launch posts here regardless. If I commented on yours and you've shipped the fixes, say so in the thread. The re-scan is free, and if the before/after is this clean, I'll write about yours next.

I ran a passive security check on 10 products that launched this week — 7 failed the same one-line fix

Amit Feldman — Wed, 05 Aug 2026 00:05:18 +0000

This week I did something I've been meaning to do for a while: I took 10 products that launched in the last 48 hours — a mix of Product Hunt launches and "I built this" posts on Reddit — and ran a passive launch-readiness check on each one.

Passive means exactly that: public HTTP response headers and homepage HTML only. No probing, no auth attempts, nothing intrusive — the same thing any scanner, prospect, or security-conscious customer sees when they load your site once.

I'm not naming anyone. The point isn't to call out individual makers — it's that the failures were so consistent they form a pattern worth publishing.

The results

7 out of 10 shipped with no Content-Security-Policy header at all.

3 out of 10 were missing Strict-Transport-Security — including one product ranked #1 on Product Hunt the day it launched.

Across the 10 sites, the most common gaps, in order:

Check	Failed	Why it matters
Content-Security-Policy	7/10	Nothing mitigating XSS / injected scripts
Referrer-Policy	6/10	Full URLs leak to every third-party request
Permissions-Policy	6/10	Camera/geo/mic features unrestricted by default
X-Frame-Options	6/10	Site can be framed anywhere → clickjacking
X-Content-Type-Options	6/10	MIME-sniffing exposure on user content
HSTS	3/10	First-visit downgrade possible

Two products were genuinely clean — all six headers present, HSTS with preload. Both were small solo projects, which killed my assumption that "bigger launch = better hygiene."

Why this keeps happening

None of these are code fixes. Every one is a one-line config change at the host or CDN layer — Vercel, Netlify, Cloudflare, nginx, all of them have a documented snippet for it. The failure mode isn't skill, it's that launch week has a hundred things in it and "headers" is item #101. There's no test that fails, no deploy that breaks, no user who complains. The site just quietly tells every visitor's browser "no rules, do whatever."

That's exactly the class of problem that only gets caught by something that checks, every time, automatically — because humans are bad at "every time."

The SEO side wasn't much better

While I was in the HTML I checked the basics too:

2/10 homepages had no <h1> — your single best keyword slot, empty
Meta descriptions over 200 chars (truncates at ~160 in search results) on half of them
One product had a meta description of 2,701 characters
Missing alt text on the majority of images on 8/10 sites

Again: not skill. Just nobody checked.

What I'd do differently (and did)

I run these checks on every launch now, including my own. My rule is simple: a launch isn't done when the deploy succeeds — it's done when the thing a stranger's browser receives passes a baseline.

If you shipped something recently and want to know where you stand: I run a Launch-Ready Quick Scan — passive headers/TLS/HTML checks plus a human-written readout of what to fix first, delivered within 24h. It's $29 for the launch period (normally $49), and the report is written so you can hand it straight to whoever owns your deploy config. Grab one here.

And if you're pre-launch: the six headers above are a 20-minute fix tonight. Do it before the traffic, not after.

I run a one-person company — here are the 54 prompts I actually reuse

Amit Feldman — Thu, 30 Jul 2026 07:43:36 +0000

Four jobs before lunch

A normal Tuesday for me: 9am I'm a developer, 11am I'm writing landing page copy, 1pm I'm on a discovery call pretending I have a sales process, 3pm an angry email lands and I'm support, 5pm I'm doing the invoicing I've been avoiding since Friday.

The work isn't the expensive part. The switching is. Every hop lands me in front of a blank page in a role I'm mediocre at, and I lose fifteen minutes just working out what good even looks like here. Four hops a day, five days a week. That's most of a working day a week spent staring.

So I did what everyone does now: I asked an AI assistant. "Help me write a cold email." "How should I price this?" And I got exactly what you'd expect — competent, structureless mush. Advice that sounds like a LinkedIn post. The problem wasn't the model. It was that I was asking like someone who didn't know the domain, because in that particular hour, I didn't.

The fix turned out to be boring: stop asking questions, start pasting briefs. A prompt that names a framework, hands over real numbers, sets constraints, and demands a decision rule at the end gets back something I can act on. One that doesn't gets a fortune cookie.

I kept the ones that worked in a file. That file is now 54 prompts across the six jobs I actually do — validation, marketing, sales, ops, finance, support — and I've packaged it up. Here are three of them in full, so you can judge the pattern yourself.

1. The prompt I run before I build anything

When to use this: when you're in love with an idea and need a hostile reviewer to try to kill it before the market does.

Act as a skeptical seed-stage investor who has seen 1,000 pitches and passed on
most of them. Here is my idea:

[DESCRIBE THE IDEA IN 3–5 SENTENCES: who it's for, the problem, the solution,
and how it makes money]

Tear it apart. Specifically:
1. Name the 3 assumptions most likely to be fatally wrong, ranked by
   (likelihood of being wrong) × (damage if wrong).
2. For each, describe the cheapest test (under $100 and under one week) that
   would produce real evidence either way.
3. List who already solves this and why customers might prefer the status quo,
   spreadsheets, or doing nothing.
4. Tell me what evidence would change your mind from "pass" to "curious."

Be direct. Do not soften the critique and do not end with encouragement.

Why it works: the ranking formula stops the model listing ten generic risks and forces a prioritisation. "Under $100 and under one week" converts criticism into this week's to-do list. And the last line matters more than it looks — without it you get a paragraph of encouragement at the end that quietly undoes the whole exercise.

2. The prompt that gets my week back

When to use this: when your week disappears into repetitive admin and you need to know what to automate first.

You are an automation consultant. I'm a solo founder. Here is how I
actually spent my time last week, with hours per task:

[PASTE YOUR TASK LIST, e.g. "answering support emails 4h, invoicing 1h,
scheduling social posts 2h, sales calls 5h, writing content 4h…"]

1. Score every task on two axes: repetitiveness (how rule-based is it)
   and founder-necessity (does it need MY judgment/relationship).
2. Sort all tasks into four quadrants: automate now, delegate, keep
   but time-box, and eliminate.
3. For the top 3 "automate now" candidates, rank by ROI =
   (hours saved per month) ÷ (setup effort), and describe the
   automation for each: trigger, steps, tools ([MY STACK, e.g. "Gmail,
   Stripe, Notion, Zapier/Make"]), and failure mode to watch.
4. Estimate total hours recovered per month and tell me the ONE
   automation to build this week.

Why it works: it runs on your logged hours, not a hypothetical founder's, so the output can't be generic. And step 4 is the whole point — a list of twelve automation ideas is another form of paralysis. I want one.

3. The prompt for the email I shouldn't send at 11pm

When to use this: when a furious email lands and your first-draft reply would make things worse.

You are a customer-success lead who specializes in saving angry
customers. My product: [PRODUCT DESCRIPTION]. Here is the customer's
message:

[PASTE THE ANGRY MESSAGE]

And here is what actually happened / what I can offer: [FACTS + WHAT
YOU CAN DO: refund, fix timeline, workaround, nothing].

Write my reply:
1. First, tell me privately (not for the customer): is this customer
   right? What did we likely get wrong?
2. The reply itself, under 150 words: acknowledge the specific
   failure without legal-speak or "we're sorry you feel that way",
   take ownership of what's genuinely ours, state what I'm doing
   about it with a concrete action and date, and make the remedy
   (if any) without them having to ask again.
3. One sentence I must NOT send (the defensive thing I'm tempted to
   say) and why.
4. A follow-up note to send [N] days later checking the fix landed —
   this is where angry customers become loyal ones.
5. The product/process fix I should make so this exact ticket never
   happens again.

Step 1 and step 3 are why I still use this one. The private read on whether the customer is right usually deflates my defensiveness before I've written a word, and naming the sentence I'm tempted to send is unnervingly accurate about every time.

They're also built to chain: interview notes from the Mom Test script feed the testimonial-to-copy miner, whose output feeds the landing-page hero prompt. Outputs become inputs.

Who this is not for

If you already have a playbook, skip it. Someone who's run sales or done pricing work professionally will find their own frameworks in here with the serial numbers filed off. The pack is for people covering six roles badly, not one role well.
It's prompts, not software. Markdown files plus one print-ready HTML page. Nothing runs, nothing integrates, no accounts. If you want a tool, this isn't one.
The placeholders are work. Every prompt wants real numbers, real quotes, real transcripts. Fill them with vagueness and you get vagueness back — the specificity is doing the heavy lifting, not the wording.
It won't make the decision for you. Several prompts deliberately end in a scorecard or a pass/fail rule. That's a structured argument to react to, not an answer.

Getting it

The Solo Founder's AI Prompt Pack is $19 on Gumroad: https://afeldman2.gumroad.com/l/zdyxz?utm_source=devto&utm_medium=article&utm_campaign=promptpack-launch

54 prompts across six categories, organised Markdown for daily copy-paste plus a single styled HTML file you can print to PDF. Works with any assistant that takes a long prompt — ChatGPT, Claude, Gemini, whatever you already pay for.

And if you just take the three above and never buy anything: genuinely fine. The pattern — name a framework, hand over real data, constrain the output, demand a decision rule — is the part worth stealing.

I built a one-command website auditor because discovery calls were eating my afternoons

Amit Feldman — Thu, 30 Jul 2026 06:08:23 +0000

The discovery-call scramble

If you freelance or run a small agency, you know this moment: a prospect gets on a call and asks, "So what's wrong with our current site?" And you need a credible, concrete answer — not "well, I'd have to dig into it," and not forty minutes of manually opening dev tools, checking headers with curl, running PageSpeed, and eyeballing the source for a meta description.

I got tired of the scramble, so I wrote it down as a checklist, then turned the checklist into a script. It's called siteprobe: one Python file, zero dependencies, standard library only. Point it at a URL and it audits the things clients actually care about — speed, security headers, TLS certificate, and on-page SEO — in about five seconds. Add one flag and it emits a polished HTML report you can attach to a proposal.

python3 siteprobe.py https://example.com

No install, no API keys, no accounts. Python 3.9+ is the only requirement.

What one run actually tells you

Speed, broken down usefully. "Your site is slow" is useless; "your TLS handshake is 800ms because the cert chain is misconfigured" is a fix. siteprobe measures with raw sockets and reports each phase separately:

⏱ Timing
  DNS resolution     12 ms
  TCP connect        34 ms
  TLS handshake      87 ms
  Time to first byte 412 ms
  Total              545 ms

Security headers, with fixes. It checks the six headers on every audit checklist — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy — and every missing one comes back as a PASS/WARN/FAIL finding with copy-paste fix advice, not just "missing."

TLS certificate expiry. Issuer, expiry date, days remaining, negotiated protocol and cipher. It warns under 30 days and fails on expired. If you've ever had a client's site go down because nobody tracked a cert renewal, you know why this is its own line item.

On-page SEO signals. Title tag (with length check), meta description, H1 count, images missing alt attributes, canonical link, viewport meta — plus live checks that /robots.txt and /sitemap.xml actually exist and respond.

The terminal output ends with a summary count, so a run looks like:

✓ 9 passed   ⚠ 3 warnings   ✗ 2 failed

Follows redirects automatically too (up to 10 hops, with the per-hop status codes shown), so python3 siteprobe.py http://github.com tells you the whole story of the redirect chain.

The part that's actually worth paying for

The terminal audit is nice. The deliverable is the point:

python3 siteprobe.py https://client-site.com --html report.html

--html writes a self-contained HTML report — inline CSS, no external assets, no branding to strip out — with styled tables and an overall verdict banner at the top. It's designed to be forwarded to a client or attached to an invoice exactly as it lands on disk. The discovery-call scramble becomes: run one command before the call, attach the report to the proposal after it.

It's also cron/CI-friendly. Exit codes are 0 (all passed), 1 (warnings only), 2 (at least one failure), so a weekly cron job that re-audits your client sites and alerts on exit code 2 is about four lines of crontab. That turns a one-off audit into ongoing monitoring — cert expiry warnings especially.

Honest limitations

It's not a crawler. siteprobe audits the URL you give it (plus robots.txt and sitemap.xml). It doesn't spider the whole site, so per-page SEO issues on page 47 won't show up.
TTFB, not full rendering. The timing is server response, measured with raw sockets. It doesn't run a headless browser, so Core Web Vitals, layout shift, and JS-bundle bloat are out of scope — that's Lighthouse/PageSpeed territory, and the two tools complement each other fine.
Header checks are presence-and-sanity, not policy review. It will tell you CSP is missing; it won't audit whether your existing CSP is well-designed.
Single URL per run. Script it in a loop if you want a batch; there's no built-in site list mode.

Getting it

siteprobe is $12 (pay-what-you-want, $12 minimum) on Gumroad: https://afeldman2.gumroad.com/l/chwsxj?utm_source=devto&utm_medium=article&utm_campaign=siteprobe-launch

You get the single MIT-licensed Python file plus a test suite that spins up a local HTTP server and covers fetching, timing, redirects, header detection, SEO parsing, and HTML report rendering — no network needed to verify it works. If one audit report helps you close one proposal, it's paid for itself several times over.

I stopped doing free work — the scope language and change-order email that saved me unpaid weeks

Amit Feldman — Wed, 29 Jul 2026 09:19:07 +0000

The drip that ate the project

The project was fixed-price. We had a kickoff call, a rough list of pages, a number both of us liked. Then the drip started.

"One quick tweak on the hero." "While you're in there, can you wire up the contact form to our CRM?" "My partner saw the design and wants a different direction — nothing major." Each ask was small. None of them were in the quote. Three weeks later I'd done maybe 40% more work than I'd priced, the revisions had no end in sight, and the final invoice sat unread in their inbox.

This isn't a story about villains. The client wasn't trying to steal hours. Nothing in writing ever told either of us where the line was. "Two rounds of revisions" sounds clear until you need a test for what counts as a revision — and by then you're already doing the work free, because saying no mid-project feels worse than saying nothing.

I'd had that project more than once. Free templates were one vague page. Contract SaaS wanted a subscription forever for forms I'd fill out once. So I stopped hoping the next client would be different and wrote the system I wish I'd had on day one.

The system, not the pile

ScopeGuard is a scope-defense pack for fixed-price freelancers: SOW template, revision policy, one-page change-order form, payment terms (deposit, milestones, late fees, work-pause, kill fee), twelve email scripts, a rate card, and a 20-question scope audit you run before you quote. Markdown masters plus a print-ready PDF. $19, one-time.

The order matters more than any single document:

Before quoting — audit the brief for scope bombs (committee approvals, "modern like Apple," content that's "almost ready").
Before starting — SOW with explicit in-scope / out-of-scope lists and measurable "done," plus a revision policy that makes revision-vs-change a fact instead of a fight.
Mid-project — every request sorted in seconds: in-scope, free revision (within rounds), or change (priced and signed before work starts).
If money stalls — escalate on rails: nudge → direct → final notice → pause → kill fee, each email already written.

Clients usually respect the process because it's professional, not because it's rigid. The change order is one page: what changed, price, timeline impact, signature. No signed form, no work. One unbilled "quick favor" teaches them the system is decorative — so the pack only works if you use it every time.

Two lines that do most of the work

The revision policy's job is to kill the two most expensive sentences in freelancing: "can you just tweak this one thing?" and "that's not what I meant." The tests are short enough to paste into a reply:

Revision test: If the request references something already written down in the SOW (a spec, approved mockup, brand guide, test) and asks for the work to match it — it's a revision.

Change test: If the request introduces something not written down in the SOW, or reverses something the client already approved in writing — it's a change, priced on a Change Order before any work starts.

Rule of thumb: Revisions make the agreed work right. Changes make different work.

When included rounds run out, the client gets two options: pay for another round, or approve as-is. Silence past the review window is acceptance. That last bit alone stops the endless "almost there" loop.

The email I used to rewrite every time

The scripts are meant to be sent with brackets filled — warm but immovable. Here's the gentle first pushback when something small sits outside the SOW:

Happy to help with this. Before I dive in — this one sits outside what we scoped in the SOW ([Section 3, "Out of Scope"]). It's a small thing, so here's what I'd suggest: I can fold it in as a mini change order for $[amount], which keeps us both honest on scope, or we can park it on a list for a post-launch phase if you'd rather keep this phase lean.

Either way, the current timeline isn't affected. Which would you prefer?

When the quick tweaks become a pattern, the firm version lists the recent out-of-scope asks, says you've absorbed them so far, and attaches a drafted change order — in-scope work continues either way. You're not arguing about fairness; you're pointing at the document they already signed.

There's also a kickoff email that sets the rule before the first "while you're at it": ideas are welcome; each one is sorted into "in scope — done" or "priced option — your call." That turns the change order into a decision tool, not a penalty.

Honest limitations

It's documents, not magic. Templates don't enforce themselves. If you skip the change order once, you've trained the client that the boundary is optional.
Not legal advice. Practical business language only. Contract and payment rules vary by place — have a lawyer review the terms for your jurisdiction before you lean on them in a dispute.
You still adapt the brackets. Deposit %, revision rounds, rates, late fees — set them once and keep them consistent. Inconsistent terms are how scope arguments start.
It won't fix a project you should have declined. The audit checklist is there so bad deals die before the deposit.

Getting it

ScopeGuard is $19 on Gumroad: https://afeldman2.gumroad.com/l/chliwp?utm_source=devto&utm_medium=article&utm_campaign=scopeguard-launch

Instant download — SOW, revision policy, change-order form, payment terms, 12 scripts, rate card, scope audit, and a print-ready PDF. One caught scope bomb or one on-time invoice covers it many times over.

I built a CLI to stop myself from committing API keys (and broken .env files)

Amit Feldman — Tue, 28 Jul 2026 20:32:15 +0000

The 11pm key rotation

Two things have burned me more than once, and I suspect they've burned you too.

Want this run on YOUR app before launch? I run envcheck plus a site-side pass on your repo + production URL and hand back a severity-ranked findings report in 48h — $29 launch price → https://afeldman2.gumroad.com/l/keikf?utm_source=devto&utm_medium=article&utm_campaign=envcheck-cta

Incident one: a deploy that went green in CI and then crashed on boot in production because .env.production was missing REDIS_URL. Nobody caught it, because nothing in the pipeline actually compared the production env file against the keys the app expects. The error message was something unhelpful like undefined is not a function three stack frames away from the real problem.

Incident two: a Stripe test key committed to a repo that was later flipped from private to public. It was a test key, thankfully, but I still spent an evening rotating it, scrubbing history, and writing the postmortem nobody reads.

Both of these are embarrassingly common, and both are cheap to catch — you just have to actually check, every build, forever. Humans are bad at "every build, forever." Scripts are good at it. So I wrote one: envcheck, a zero-dependency Node CLI that does two jobs — validating .env files, and scanning repos for leaked secrets.

Job 1: Is my env config sane?

The simplest mode compares an env file against your committed .env.example:

envcheck check .env --example .env.example

On a deliberately broken file, that prints something like:

.env
  ✗ missing-key      DATABASE_URL is required by .env.example but absent
  ✗ duplicate-key    PORT defined on line 3 and line 9
  ⚠ empty-value      SENTRY_DSN has no value
  ⚠ placeholder-default  API_KEY still equals the example default

1 errors, 2 warnings — 4 keys checked

The placeholder-default warning is my favorite. It catches the case where someone copied .env.example to .env and forgot to fill in a real value — so the app boots with API_KEY=your-key-here and fails somewhere downstream with a confusing auth error.

When you want more than "same keys as the example," there's a JSON schema format with per-key types, patterns, enums, and length rules:

{
  "required": ["DATABASE_URL"],
  "allowExtra": false,
  "properties": {
    "PORT":     { "type": "port" },
    "NODE_ENV": { "values": ["development", "test", "production"] },
    "API_KEY":  { "type": "string", "minLength": 32 }
  }
}

Then envcheck check .env.production --schema env.schema.json --strict fails the build on warnings too. This is the check that would have saved my crashed deploy.

Job 2: Am I about to commit a secret?

envcheck scan .

This recursively scans the repo for two classes of problems: known token formats (AWS access keys, GitHub and GitLab tokens, Stripe keys, Slack tokens, Google API keys, JWTs, -----BEGIN PRIVATE KEY----- blocks, and a dozen more), plus generic password = "…" / api_key: … assignments filtered by Shannon entropy — which catches random-looking tokens nobody wrote a regex for.

Output looks like:

src/config.js:12:15  ✗ github-token   possible GitHub token   ghp_…89 (40 chars)
deploy/notes.txt:4   ✗ high-entropy   high-entropy string     7Kd2…Qz (36 chars)
.env                 ✗ env-file       .env file present in scanned tree

2 errors — 42 files scanned, 3 skipped

A few design decisions that matter in practice:

Matches are redacted. Reports are safe to archive as CI artifacts; envcheck never prints your full secret.
Noise control is built in. node_modules, lockfiles, minified files, source maps, and binaries are skipped automatically, and placeholder values like your-key-here don't cry wolf. A scanner that floods you with false positives gets disabled within a week.
Exit codes are boring on purpose. 0 = clean, 1 = findings, 2 = usage error. Every CI system on earth understands that.

What CI integration looks like

GitHub Actions, in full:

- uses: actions/setup-node@v4
  with: { node-version: 22 }
- run: npx envcheck check .env.ci --example .env.example --strict
- run: npx envcheck scan . --json > envcheck-report.json
  if: always()

That's the whole thing. Zero runtime dependencies, nothing to configure, works offline, Node 18+. It also exposes --json on every command if you want to feed results into your own tooling, and a programmatic API (parseEnv, validateEnv, scanContent) if you want to embed it.

Honest limitations

It's a scanner, not a vault. It finds secrets in files; it doesn't manage them. If you need secret storage, that's Vault/Doppler/1Password territory.
Entropy detection has a floor. Short random tokens (under ~20 chars) often don't have enough entropy to distinguish from normal identifiers. The known-format regexes cover the common cases; genuinely obscure short tokens can slip through.
It won't catch a secret that's already in git history — it scans working-tree files, not git log. If a key was committed and deleted, you still need to rotate it. (Rotate it. Scrubbing history is not enough.)
Node-only runtime. The validation logic is plain JS with no dependencies, so porting is feasible, but today you need Node 18+.

Getting it

envcheck is free on Gumroad: https://afeldman2.gumroad.com/l/yxtnc?utm_source=devto&utm_medium=article&utm_campaign=envcheck-launch

That gets you the complete MIT-licensed source (audit every line — it's yours), the schema format docs, example files including a deliberately-broken env file for demos, and the full 65-test suite so you can verify it does what this post claims. Cheaper than one evening of rot### Want this run on your app instead?

Launch-Ready Quick Scan ($29, 48h): I run envcheck plus a site-side scanner on your repo + live URL — leaked credentials, .env drift, security headers, TLS expiry, and the config mistakes that only show up in production. You get a severity-ranked report with a prioritized fix list. → https://afeldman2.gumroad.com/l/keikf?utm_source=devto&utm_medium=article&utm_campaign=envcheck-quickscan

Launch-Ready Audit ($99): everything in the Quick Scan plus a manual review of your auth flow, CI secrets, and exposed routes, and a fix plan ordered by what actually matters for your app rather than by scanner severity. → https://afeldman2.gumroad.com/l/zxpluh?utm_source=devto&utm_medium=article&utm_campaign=envcheck-audit

Not a pentest, and I say so in the report — it's the boring-misconfiguration layer that takes down launches. What the pass catches, with real before/afters: all six security headers fixed in a day (Macless) and every security header fixed in 24 hours (LoopApp).