DEV Community: Michael Yousrie

Looking for a Thunder Client alternative? I built one where free stays free

Michael Yousrie — Sat, 15 Aug 2026 11:43:02 +0000

If you searched for a Thunder Client alternative, you probably hit the same wall I did: the most installed REST client for VS Code (7.4 million installs) sits at 2.39 stars, and the reviews explain why. Things that used to be free moved behind a paywall, including looking at your own request history. One review puts it plainly: "You must pay to look at a request you did in the past."

I did not want to leave VS Code for API work, and I did not want to rent access to my own data. So I built MailPal.

The promise first

MailPal exists because of one rule, and it is written into the listing like a contract:

The free tier is fully usable for a single user, forever
Unlimited requests, unlimited collections, unlimited local history
No account, no cloud, everything works offline
Paid only ever adds new value. It never gates access to your own data. If a license lapses, everything you made keeps working.

What you get

A native feeling request editor: auto-growing key/value rows like Postman, header autocomplete, color coded JSON editing with format and live validation
Collections stored as plain JSON in your workspace, so they diff, review, and share through git like any other code
Per collection variables with placeholders. Secret values go in the OS keychain through VS Code SecretStorage, never into files.
Syntax highlighted responses, an HTML raw/preview toggle (fully sandboxed), and a resizable request/response split
Import from Postman v2.1, Thunder Client, OpenAPI 3.x, and curl, so switching takes minutes
Simple per request assertions with pass/fail on every send
Unlimited local history with one click re-send

Full control over the wire

One thing I always missed in lightweight clients: knowing exactly what gets sent. MailPal surfaces every header the tool adds on its own (Content-Type from the body type, Authorization from the auth config, the HTTP engine defaults) with a note on where each comes from and how to override it.

The MCP part

MailPal ships a built in MCP server, registered with VS Code agent mode automatically. That means Copilot agent mode, Claude, Cursor, or any MCP client can list your saved requests, run them, and read the results. Ask your agent to "run the Create invoice request and tell me if the status changed" and it just works. As far as I know, no other REST client does this.

What paid adds

$4/month or $70 once. It adds AI request generation (describe a request in plain English, get it built) and MCP write tools so agents can create and edit requests. That is it. Your data is never part of the deal.

Try it

Install: https://marketplace.visualstudio.com/items?itemName=MichaelYousrie.mailpal

Issues and feature requests: https://github.com/michaelyousrie/mailpal/issues

First release shipped this week. If you try it and something annoys you, tell me and there is a good chance it gets fixed the same week.

My Pest test passed because I added a helpful failure message

Michael Yousrie — Tue, 11 Aug 2026 18:02:39 +0000

I write marketing copy about my own products and I have a bad habit of leaving claims in it that stop being true. Prices change, a feature moves tier, and the blog post from March keeps happily saying the old thing. So I wrote a test that reads the published posts and asserts the dead claims are gone.

expect($post)->not->toContain('$29/mo', 'pricing changed in June, this post is stale');

Green. Every one of them green. The string $29/mo was still sitting in the post.

What that second argument actually does

Here is the signature, straight out of vendor/pestphp/pest/src/Mixins/Expectation.php:

public function toContain(mixed ...$needles): self
{
    foreach ($needles as $needle) {
        if (is_string($this->value)) {
            Assert::assertStringContainsString((string) $needle, $this->value);
        } else {
            if (! is_iterable($this->value)) {
                InvalidExpectationValue::expected('iterable');
            }
            Assert::assertContains($needle, $this->value);
        }
    }

    return $this;
}

It is variadic. My careful explanatory message was never a message. It was needle number two.

The positive expectation is therefore a conjunction: contains A and contains B. Which means the negation is "missing at least one of them", and my sentence about June pricing was guaranteed to be missing.

How `not` gets there

Pest does not implement a separate negative assertion. OppositeExpectation::__call runs the positive one and catches the failure:

public function __call(string $name, array $arguments): Expectation
{
    try {
        $this->original->{$name}(...$arguments);
    } catch (ExpectationFailedException|AssertionFailedError) {
        return $this->original;      // positive failed, so `not` succeeds
    }

    $this->throwExpectationFailedException($name, $arguments);
}

So follow my call through. The loop checks $29/mo, finds it, passes. Then it checks pricing changed in June, this post is stale, does not find it, throws. That throw is caught, and not reports success.

The first needle was checked. The result was thrown away.

Why this one is so easy to walk into

I counted the public methods on that mixin. There are 68 expectations. 66 of them take a real message parameter.

public function toBe(mixed $expected, string $message = ''): self
public function toBeFalse(string $message = ''): self
public function toStartWith(string $expected, string $message = ''): self

Two do not: toContain and toContainEqual.

toStartWith is defined forty lines below toContain in the same file, and it takes a message. So the habit is correct 66 times out of 68 and you are not misremembering the library, you are remembering the other 97% of it. At the call site a variadic parameter and an optional trailing string are the same keystrokes. Nothing about ('needle', 'my message') looks different from ('needle', 'other needle').

The four cases, run

Pest 4.4.1 on PHP 8.4.13, value is 'hello world':

assertion	result
`not->toContain('zzz', 'qqq')`	passes, correctly
`not->toContain('hello', 'qqq')`	passes, and 'hello' is right there
`not->toContain('qqq', 'hello')`	passes
`not->toContain('hello')`	fails, correctly

Only the single-needle form does what you read it as doing. Add anything after it and the assertion turns into a coin flip you always win.

What I do now

For the check I actually wanted:

expect(str_contains($post, '$29/mo'))->toBeFalse('pricing changed in June, this post is stale');

toBeFalse has a real $message, so the sentence lands where I meant it to and the assertion is about one thing.

The wider habit I picked up from this: if an assertion is load-bearing, make it fail once on purpose before you trust it. I had written a test specifically to catch a stale claim, the stale claim was present, and the test was green. Deleting the second argument turned it red immediately. That took ten seconds and I had not done it, because the test was passing and passing tests do not feel like they need investigating.

That is the actual failure. Not the variadic signature, which is documented and reasonable. It is that a green test reads as evidence, and a test that cannot fail is green in exactly the same shade as a test that just did its job.

Reddit was removing my posts and my code could not see it

Michael Yousrie — Mon, 10 Aug 2026 18:03:23 +0000

I spent this week posting to Reddit through the API and being pleased with how it was going. Every submission returned a URL. Every URL loaded. Four of the last six were gone and I had no idea.

If you automate anything against Reddit, this is the part nobody tells you.

A removed post looks completely fine to its author

This is the whole problem in one sentence. Reddit does not show you your own removals. Load your post while logged in as the account that made it and you get the title, the body, the score, the comment count. It looks like a post. It is not visible to anybody else.

The fix is to read it back with an anonymous client. Same credentials, no user context:

import praw

# app-only: no username, no password
anon = praw.Reddit(
    client_id=CLIENT_ID,
    client_secret=CLIENT_SECRET,
    user_agent="removal-check by u/yourname",
)
anon.read_only = True

s = anon.submission(id="abc123")
removed = s.removed_by_category is not None or s.selftext in ("[removed]", "[deleted]")

Two things to note. You need both checks: selftext goes to [removed] in some cases and stays intact in others, while removed_by_category is populated in cases where the body still reads normally. And this only works anonymously. Run the same code with username= and password= set and you will cheerfully report that everything is fine.

I also tried a plain HTTP request to reddit.com/user/<name>/about.json as a shadowban check. Don't bother from a server: it returns 403 for datacenter IPs regardless of account state, so you will diagnose a shadowban that isn't there. The app-only PRAW client is the one that tells the truth.

removed_by_category is four different stories

This field is the useful one and its values are not interchangeable:

value	who did it	what it means
`automod_filtered`	AutoModerator	a rule, usually with a bot comment explaining it
`moderator`	a human	someone looked and said no
`reddit`	Reddit itself	the sitewide spam filter
`deleted`	the author	not a removal

automod_filtered is the friendly one. AutoModerator almost always leaves a comment saying exactly what tripped, and those comments are the only place some rules are ever published. One of mine came back with "you need at least 3 karma earned in this subreddit to post here", a threshold that appears in no rules API, no sidebar, and no flair list. Read those comments; they are documentation.

moderator means a person decided. No appeal in code.

reddit is the one that should stop you. It isn't about your post, it's about your account. A subreddit rule is a local problem you can fix by writing differently. The sitewide filter deciding your submissions look like spam is a global one, and posting more into it is how it gets worse.

The numbers that made me stop

Once I could actually measure it:

last 6 submissions:  4 removed (2 of them by `reddit`)
last 8 comments:     8 live

Posting was dead. Commenting was perfectly healthy, and the comment karma was still going up. Those are two completely different signals from the same account on the same day, and I would have guessed the opposite: I assumed comments were riskier because they carry links more often.

So the rule I now follow: if the site filter is touching your submissions, stop submitting and keep commenting. Comments are what rebuild standing anyway.

The bug that made all of this invisible

I had a guard for part of this already. It never fired once.

Subreddits can require a minimum comment karma earned in that subreddit before they accept a post. Reddit exposes this:

karma = {sr.display_name.lower(): v["comment_karma"]
         for sr, v in reddit.user.karma().items()}

And my gate did roughly:

have = karma.get(sub_name)
if have is None or have >= threshold:
    return None          # allow

Read that carefully. user.karma() returns only the subreddits where you have karma. A subreddit you have never commented in is not in the dict at all. So in the exact case the gate exists for, a sub you have never participated in, have is None, and None was being treated as "cannot measure, allow it".

Absent meant zero. The code read it as unknown.

The fix distinguishes the two states properly:

karma = fetch_karma()
if not karma:
    return None                       # the CALL failed: genuinely unknown
have = karma.get(sub_name, 0)         # absent from a good response: zero
if have >= threshold:
    return None

A missing key means "not present in the result". Whether that means zero or unknown depends entirely on whether the call succeeded, and only your code knows that. Same shape as a COUNT(*) returning no row versus returning 0, or a metrics endpoint that omits idle counters. If you branch on is None you are usually collapsing those two into one, and the failure is silent because the code takes the permissive path.

Mine had never fired. It was written specifically to prevent a removal, it sat in the pipeline looking reassuring, and the removal it was written for happened anyway.

What I'd tell past me

Read your own posts back anonymously, on a schedule, rather than when you get suspicious. And treat removed_by_category == "reddit" as a stop signal, not a data point to log.

The guard thing still bothers me though. It had never failed, and I read that as it working.

A Pest test that asserts nothing: toContain takes needles, not a message

Michael Yousrie — Sat, 08 Aug 2026 22:46:35 +0000

I added a test last week that was doing absolutely nothing, and it passed every time I ran it.

The rule it was guarding is boring: no em dashes in anything my project publishes. I write marketing copy alongside the code, em dashes are the single most obvious tell that a machine wrote something, and I'd already had to go back and rewrite 126 of them out of published posts once. So I wanted a test, not a habit.

Here's what I wrote:

it('uses no em or en dashes in copy', function () {
    foreach (config('comparisons') as $key => $comparison) {
        foreach (allStrings($comparison) as $string) {
            expect($string)
                ->not->toContain("\u{2014}", "An em dash appears in {$key}: {$string}")
                ->not->toContain("\u{2013}", "An en dash appears in {$key}: {$string}");
        }
    }
});

Green. Every run. And completely inert.

toContain takes needles, not a message

Most assertion libraries have a second parameter for a custom failure message. PHPUnit does. expect($x)->toBeTrue('why this matters') does. So when I typed a helpful string as the second argument, I was pattern matching off everything around it.

Pest's toContain isn't that shape. It's variadic:

public function toContain(mixed ...$needles)

Every argument is a needle. My "message" was a second thing it went looking for.

The positive form does what you'd guess: it requires all of them.

expect('alpha beta')->toContain('alpha', 'beta');  // passes
expect('alpha beta')->toContain('alpha', 'zzz');   // fails

The negated form is where it gets you. not negates the whole conjunction, so ->not->toContain(a, b) asserts "it is not the case that both are present". One missing needle satisfies that on its own, and the other needle is never examined.

I ran the four cases against Pest 4.4.1 rather than reasoning about it:

toContain(present, absent)        => FAILED
not->toContain(present, absent)   => PASSED   <-- the one that bit me
not->toContain(absent, absent)    => PASSED
not->toContain(present)           => FAILED

Line two is the whole bug. My failure message was, by definition, never in the string being checked. That made the conjunction false, which made the negation true, forever, no matter how many dashes were sitting in the copy.

The single-needle version on line four works exactly as expected. That's what makes this so easy to ship: the code you wrote first was correct, and then you improved it by adding a message.

The fix

Route it through a plain predicate, which does take a message:

expect(str_contains($string, "\u{2014}"))
    ->toBeFalse("An em dash appears in {$key}: {$string}");

Slightly uglier. Actually asserts something. If you'd rather keep the fluent style, drop the message and let the diff speak:

expect($string)->not->toContain("\u{2014}");

Both are fine. The one to avoid is the one that reads best.

Why I believed it

The fix took a minute. The harder question is why I trusted a test I'd never seen fail.

A test that only ever passes is indistinguishable from a test that can't fail. Green tells you nothing on its own. It only means something if you know the test is capable of turning red, and for most tests you learn that by accident: you write it, it fails, you fix the code, it goes green. The red came free.

Guard tests don't work like that. You write them for a bug you've already fixed, or for a rule you're trying not to break in future. They're green from birth. Nobody ever sees them fail, so nobody finds out they can't.

So now, whenever I write one, I break it on purpose first:

# put the banned thing back
git stash
php artisan test tests/Feature/BlogClaimsTest.php   # expect FAILURES
git stash pop
php artisan test tests/Feature/BlogClaimsTest.php   # expect green

For the dash test I injected a real em dash into one config value and watched it fail with the message I'd written. Ten seconds. It's the same red-green loop as TDD, just applied after the fact, and it's the only thing that separates a guard from a comment.

While I was doing this I found a second one in the same file that had the identical mistake, and I'd have shipped both.

One more trap in the same family

The other guard I wrote that day banned a phrase from my published copy. It flagged something correct on the first real run, and the reason is worth mentioning because it's the opposite failure.

I'd been claiming a feature in a blog post that my product doesn't actually have. Reasonable response: ban the phrase in a test. Except the phrase also appeared in a perfectly true sentence about a competitor's plan, which does have that feature. The test was doing something, and what it was doing was wrong.

So the two failure modes sit next to each other. A guard that asserts nothing tells you your copy is clean when it isn't. A guard that's too blunt tells you your copy is broken when it's fine, and the fastest way to make that alarm stop is to delete the test. Neither one announces itself.

The version I kept scopes the check per line, so it only fires when the banned phrase shows up on a line that's talking about my own product. More code, narrower blast radius, and it survived contact with the real corpus. That last part is the test of a guard: run it against everything you've already published, not just against the case you invented it for. If it flags something true, it's not ready yet.

Summary

Pest's toContain is variadic. There is no message parameter.
->not->toContain($needle, 'message') passes whenever the message is absent, which is always. The assertion is dead.
Use expect(str_contains($h, $n))->toBeFalse('message') if you want a message, or a bare single-needle not->toContain($n) if you don't.
Break every guard test on purpose once, before you trust it. Green from birth means nothing.
Then run it against your whole existing corpus. A guard that flags a true statement gets deleted by whoever hits it next.

I found both of these while auditing my own marketing copy for claims that had drifted from what the product does, which turned out to be a much bigger problem than the tests were. That's a different post.

Python's HTTPServer will bind a port that is already in use on Windows

Michael Yousrie — Thu, 06 Aug 2026 11:41:05 +0000

I needed a throwaway HTTP server for about thirty seconds.

The job was a one-time OAuth handshake. Provider redirects the browser to a localhost URL with a ?code= on it, you swap that code for a token, done. The codes expire in roughly thirty seconds, and I'd already lost two of them to the time it takes a human to copy a string out of an address bar and paste it into a terminal. So: listen on the redirect port, grab the code the moment it lands, exchange it immediately, shut down.

Twenty lines with http.server. It printed "listening on http://localhost:8000/callback". I clicked approve. The browser landed on the callback and showed a 404.

A 404 is a strange thing to get from a server that only knows how to return 200 and 204.

The port was already taken

I run Laragon, which runs Apache, which owns :8000. Apache answered the browser. My handler never saw the request.

That part is obvious in hindsight. What wasn't obvious is that my server didn't fail to start. It bound without complaint, printed its startup line, and then waited for a connection that was being handed to another process.

I'd wrapped the bind in a try/except specifically to catch OSError: address already in use, because that was the failure I could see coming. The except never ran.

Why the bind succeeds

socketserver.TCPServer sets allow_reuse_address = False. http.server.HTTPServer overrides it:

>>> import socketserver, http.server
>>> socketserver.TCPServer.allow_reuse_address
False
>>> http.server.HTTPServer.allow_reuse_address
True

That flag becomes SO_REUSEADDR on the socket, and SO_REUSEADDR does not mean the same thing on Windows as it does on Linux.

On Linux it mostly lets you rebind a port still sitting in TIME_WAIT from a previous process, which is genuinely useful and is why HTTPServer turns it on: restart your dev server without waiting a minute.

On Windows it's broader. It lets you bind an address another socket is actively listening on. Both binds succeed, and which socket receives an incoming connection isn't something you get to decide.

Two servers on the same address, no error:

import http.server, threading, urllib.request

PORT = 8931

class A(http.server.BaseHTTPRequestHandler):
    ident = b"A"
    def do_GET(self):
        self.send_response(200)
        self.send_header("Content-Length", str(len(self.ident)))
        self.end_headers()
        self.wfile.write(self.ident)
    def log_message(self, *a): pass

class B(A):
    ident = b"B"

first = http.server.HTTPServer(("127.0.0.1", PORT), A)
threading.Thread(target=first.serve_forever, daemon=True).start()

second = http.server.HTTPServer(("127.0.0.1", PORT), B)   # no exception
threading.Thread(target=second.serve_forever, daemon=True).start()

print(urllib.request.urlopen(f"http://127.0.0.1:{PORT}/").read())

On Windows that prints b'A'. Both servers are live, and the requests all go to whichever one bound first. The second process is running fine and simply never hears anything.

The fix is one line

Turn the flag off on your own server:

class ExclusiveHTTPServer(http.server.HTTPServer):
    allow_reuse_address = False

Now the bind fails the way you wanted it to:

OSError: [WinError 10048] Only one usage of each socket address
(protocol/network address/port) is normally permitted

Which is the message I'd been trying to print by hand.

The asymmetry is what decides whether this can happen to you, and it sits with the second binder rather than the first. If you don't ask for SO_REUSEADDR, your bind gets refused whatever the other process did. If you bind first with allow_reuse_address = False, nobody can quietly join you either. Windows also has SO_EXCLUSIVEADDRUSE for a stronger version of the same guarantee.

The tradeoff you're accepting is the TIME_WAIT annoyance coming back. For a long-running dev server that restarts constantly, keep the default. For anything that must be the listener on a port, turn it off. A short-lived callback catcher is squarely in the second group, and I had it in the first.

What I changed

The catcher binds exclusively now, and it ignores requests that arrive without a code or error parameter, since a browser will also ask for /favicon.ico and that shouldn't count as the callback.

The thing I got wrong wasn't the guess about what could fail. Port already in use was exactly the right failure to plan for. I assumed the operating system would be the one to tell me, and with this class on this platform it stays quiet instead. So if you're binding a well-known port on Windows and then waiting for one specific request, check allow_reuse_address before you trust the startup message.

Things Shadow DOM does not isolate

Michael Yousrie — Wed, 05 Aug 2026 09:56:44 +0000

A while back I wrote about using the Shadow DOM to isolate an embeddable widget, and the summary was: styles do not leak in, styles do not leak out, your install shrinks to one script tag.

That is all still true. It is also the optimistic half. "Isolated" turned out to be a stronger word in my head than it is in the browser, and every gap costs you a bug on somebody else's page, where you cannot open devtools.

This is the other half. Everything below still crosses the boundary, roughly in the order it caused me trouble building the changelog widget for Patchlog.

Inheritance walks straight in

The boundary blocks selectors. It does not block inheritance.

font-family, color, line-height, letter-spacing, text-transform, visibility, cursor and direction all arrive from the host's ancestors. Drop your widget on a page with text-transform: uppercase on a wrapper div and the whole panel is shouting.

:host {
  all: initial;
  display: block; /* all: initial resets display to inline */
}

That second line matters more than it looks. all: initial sets display back to its initial value, which is inline, so your layout quietly collapses if you forget it.

rem is document scoped

A shadow root does not get its own root element for font sizing, so rem resolves against the host page's html element rather than against anything of yours.

A page still using the old html { font-size: 62.5% } trick renders your widget at 62.5% of every size you designed. I replaced every rem with px and em. Not elegant, but predictable, and predictability is worth more when you do not control the page.

event.target is rewritten, which cuts both ways

My earlier post framed retargeting as a feature, because it stops you leaking internal structure. It is also a trap in the other direction.

By the time a listener on document sees a composed event, target has been rewritten to your host element. So the host page's own click tracking records one identical element for every click anywhere inside your widget.

document.addEventListener('click', (e) => {
  const real = e.composedPath()[0]; // not e.target
});

document.activeElement has the same shape of problem and returns the host. Use host.shadowRoot.activeElement for what is genuinely focused.

ID references do not cross, so ARIA breaks silently

aria-labelledby, aria-describedby and for are all ID references, and IDs are scoped per root. An ID reference pointing across a shadow boundary does not resolve.

It is not deprecated, it is not discouraged, it simply does nothing, and nothing warns you. Keep the label and the control in the same root, or use aria-label with a literal string. There is spec work on cross root ARIA. I would not build on it yet.

Nothing outside can select in, including things you wanted

document.querySelector cannot reach your nodes. That is the point, right up until it is not: the host's analytics selectors, their end to end tests and their browser extensions cannot reach them either.

Worth knowing before someone files a bug: Playwright pierces open shadow roots by default, Cypress needs includeShadowDom, and anybody poking at your widget with jQuery in the console will conclude it does not exist.

Layout is not isolated at all

This is the one that cost me an evening.

Shadow DOM scopes styles. It says nothing about the containing block. If any ancestor has overflow: hidden, your popover is clipped. If any ancestor has a transform or a filter, that ancestor creates a containing block, and your position: fixed element is suddenly positioned relative to it instead of the viewport.

Both are properties of where you mounted, not of your CSS. I now append the host element as a direct child of document.body and position from there, rather than rendering wherever the script tag happens to sit.

Use adoptedStyleSheets, not a stylesheet link

Put your CSS in the shadow root as an inline <style>, or use adoptedStyleSheets. A <link rel="stylesheet"> inside a shadow root gives a visible unstyled flash on every single load.

Closed mode buys you almost nothing

Anything can patch Element.prototype.attachShadow before your script runs and keep a reference to every root you create. Closed mode mostly makes your own debugging worse. I said use open last time and I still think so, just for a less flattering reason.

The tradeoff nobody mentions up front

You also give up letting the host restyle you. That is exactly what you asked for, and it means "can you make the heading smaller" stops being a two line CSS override on their end and becomes a feature request on yours.

Custom properties inherit through the boundary and ::part() exposes named hooks, so decide up front how much surface you are willing to expose, then hold that line. I went with a small fixed set: light, dark and auto, plus one accent color.

If the main selling point of your widget is that it blends into the host's design, Shadow DOM may be the wrong tool, and a carefully namespaced class prefix or an iframe will serve you better. I picked "never break a stranger's site" over "fully themeable". For something people install on trust, I still think that is the right way round, but it is a choice with a cost rather than a free win.

If you have a cleaner answer than "px and em everywhere" for the rem problem, I would genuinely like to hear it.

I measured 402 posts across 4 founder subreddits before posting to any of them

Michael Yousrie — Mon, 03 Aug 2026 12:04:12 +0000

Every "where should I post my SaaS" thread produces the same list of subreddits. I wanted to know whether that list is worth anything, so before posting again I recorded 402 posts across four of them and looked at the numbers.

Some of what I found changed where I post. More of it changed how I measure.

What I collected

For r/SaaS, r/microsaas, r/indiehackers and r/SideProject I pulled roughly 100 recent posts each and stored the score, the comment count, the author, and whether the post was a link or a text post. Nothing clever, just the public listing.

Then I re-checked the same post IDs six hours later, which turns out to be the only way to learn anything about removals. More on that below.

Finding 1: comments per upvote is a better signal than either number alone

Upvoting is one click. Commenting is work. In a normal community you would expect far more upvotes than comments.

Here is the ratio of total comments to total upvotes across each sample:

subreddit	upvotes	comments	comments per upvote
r/indiehackers	1,463	6,101	4.17
r/microsaas	217	462	2.13
r/SaaS	554	453	0.82
r/SideProject	257	229	0.89

Two of those are inverted, and one is inverted by a factor of four.

A ratio above 1 means people are commenting on things they are not willing to spend a click endorsing. That is what reciprocal posting looks like: I comment on yours, you comment on mine, neither of us reads the other.

The top five comment-getters in the r/indiehackers sample were titled, in order: "Share what you're building", "Share what you're building", "i made a free list of 100 places where you can promote your app", "Share what you're building", "100 users is hard." Those five threads pulled 292, 212, 210, 193 and 189 comments.

Finding 2: count the authors, not the posts

The same sample of 100 r/indiehackers posts came from 56 unique authors. One account wrote 10 of them.

The other three subs were nothing like that: 93, 94 and 101 unique authors per 100 posts.

Author count is worth checking anywhere you plan to spend time, because subscriber count cannot tell you the difference between a community and a queue.

Finding 3: you cannot measure removals by looking

This is the one that generalises beyond Reddit.

A removed post still looks fine to the person who posted it. Logged in as the author you see your post, your title, your body. Logged out, the body is [removed]. The API returns HTTP 200 either way.

Worse, listings only ever show survivors. I checked 100 recent posts in one sub and exactly zero carried a removal marker, which does not mean nothing gets removed. It means removed posts are not in the listing I was reading.

So the only way to get a removal rate is to record a cohort of post IDs now and re-check those same IDs later, through a logged-out client. That is the difference between "my post is up" and "my post is visible", and I had a post sitting invisible for three weeks before I understood the distinction.

Finding 4: the median post gets nothing

Across all 402 posts, 50% scored 1 or 0 and 25% had no comments at all. Median score was 2.

That is not a criticism of those subreddits. It is what a firehose looks like from inside. But it does mean a single post is a lottery ticket, and the honest way to treat it is as one sample, not as a verdict on the channel.

What I actually changed

The uncomfortable part of doing this was realising I had no way to check the conclusion, because not one link I had ever posted carried a campaign tag. Every claim I could make about which channel worked was an argument, not a measurement.

Platform metrics do not fix that. Upvotes tell you how a post did on the platform, which is a different question from whether anyone came to your site and stayed. Those two answers disagree more often than you would like.

So now every link gets a source tag at the moment it is posted, rather than being stored pre-tagged. Three things that are worth knowing if you set this up:

Answer 302, not 301, on anything you want to count. A 301 is a permanent redirect and the browser caches it, so the second click from the same person never reaches your server. The count does not break, it quietly flattens.

Do not bake the source into the stored link. Store the bare URL and add utm_source when you post. Otherwise every channel reports as whichever one you set up first, and you cannot separate them afterwards.

A short link resolves to one destination. If you route a deep link through it, someone clicks a link about a specific page and lands on your homepage. Tag deep links in place on their own domain instead.

Check the target's rules first. r/SaaS auto-removes shortened links and says so in its rules, along with a ban threat for disguised links. Posting a tracked link there would have gotten the post deleted, and the zero clicks would have read as "this sub does not convert" rather than "nobody ever saw it". A confident wrong answer is worse than no answer.

The part I got wrong

My first read of the r/indiehackers ratio was "bots". It is not. The accounts are real people with real post histories.

It is more awkward than bots. Those subs are full of founders, and founders are there to be seen. Everyone in the room is selling and almost nobody is buying. That makes them a reasonable place to talk to peers and a poor place to expect customers, which is a different conclusion from "Reddit does not work" and leads to different behaviour.

The thing that still seems worth it: those threads get indexed, and a post answering a real question keeps getting found by people searching that question months later. That is a slower payoff than upvotes and it is the one the platform's own metrics are worst at showing you, which is the whole argument for tagging your own links.

I build Swyfty, which is the shortener I used for the tagging described above, so treat that section as biased and check the redirect behaviour of whatever you use. The 301 caching problem in particular applies to every shortener, including the one you host yourself.

Shipping a read-only API for a small SaaS: the decisions that are not about REST

Michael Yousrie — Sat, 01 Aug 2026 07:35:01 +0000

Adding an API to a small SaaS is mostly not a REST question. The routes are the easy part. The decisions that bite are about what the API is allowed to see, who it answers to, and how it fails.

I shipped a read API last week for a product that already had a public widget endpoint and a billing plan with an api_access flag that had been granting precisely nothing since launch. Here is what actually needed deciding.

Read only, on purpose

The first version exposes GET and nothing else. Not because writes are hard, but because every verb you expose is a promise you maintain forever, and the dangerous verbs are the ones with side effects your users see.

For a changelog tool the risky verb is publish. A write API means somebody's broken script can push a half written entry to their customers at 3am, and no amount of "well, they called it" makes that a good day. Read gives integrators most of what they actually ask for (pull entries into a docs site, mirror them into Slack, back them up) with none of that.

Ship the surface you can support. Adding POST later is a feature announcement. Removing it is a breaking change.

The API and the UI must agree on what "published" means

This is the one I would put at the top if I could only keep one.

The product supports scheduled entries: an entry can be marked published with a date in the future, and the widget deliberately hides it until that date arrives. That behaviour lives in a query the widget endpoint uses.

The API has to use the exact same query. If it filters on status = published alone, it happily hands out entries the customer scheduled for next Tuesday. Nobody would call that a security hole in a bug report, but it is an embargo leak: the product promised "this goes live Tuesday" and then served it on Friday to anyone with a token.

So the rule is: any new read surface reuses the existing visibility scope rather than reimplementing the filter.

$query = match ($status) {
    // Published means published AND past dated, exactly as the widget sees it.
    'published' => $project->publishedEntries(),
    'draft'     => $project->entries()->where('status', 'draft'),
    default     => $project->entries(),
};

The general form: whenever two code paths answer "what is visible", one of them will drift. Make them the same function. If you cannot, write the test that asserts they agree.

401, 403 and 404 are three different sentences

Most APIs blur these and it makes them miserable to integrate with. The distinctions I settled on:

401 means the token is missing or unknown. Nothing else.

403 means the token is real but the thing you are asking for is not available to it. That covers two cases: the plan does not include API access, and the project exists but belongs to a different account.

404 means the resource genuinely does not exist for anybody.

The second 403 case deserves an argument, because the security reflex is to return 404 for another user's resource so the API does not confirm the ID exists. That reflex is right for an unauthenticated or public endpoint. Here the caller has already proven they hold a valid token for a real account, so the enumeration win is small, and the cost is a developer staring at a 404 for an ID they can see in their dashboard. I took the clearer error.

The error bodies say which it is, too. "The API is a Pro feature. Upgrade to use it." is a support ticket that never gets opened.

Gate on plan data, not on code

The plan check is one line reading a column:

if (! $token->user?->activePlan()?->api_access) {
    abort(403, 'The API is a Pro feature. Upgrade to use it.');
}

api_access is a boolean on the plan row, alongside the other entitlement flags. No plan names in controllers, no if ($user->plan === 'pro') scattered across the codebase. When a plan changes, or a grandfathered account needs an exception, it is a database update and not a deploy.

Two smaller things that fall out of this: the check happens server side on every request (never trust a flag the frontend read), and a downgrade takes effect on the next call rather than whenever a cache decides.

Cap the page size, not just the default

Pagination defaults are easy. The cap is the part people skip:

private const MAX_PER_PAGE = 100;

$perPage = min((int) $request->query('per_page', 25), self::MAX_PER_PAGE);

Without the min, ?per_page=100000 is a request that reads an entire account into memory and serializes it, and the first person to try it will be a well meaning integrator writing a sync job, not an attacker. Validate the input, clamp the value, and put a rate limit on the route as well. They defend different things: validation bounds one request, the throttle bounds a loop.

Tokens: show once, revoke instantly

The token screen creates, lists and revokes. The plain value is displayed exactly once at creation and is not readable afterwards, because only a hash is stored.

The test worth writing is not "a valid token works". It is "a revoked token stops working on the very next request". That is the assertion that catches the day someone adds a cache in front of token lookup, and it is the entire security promise of a revoke button.

One limitation I will state plainly rather than let somebody discover: tokens are scoped to the account, not to a single project, so a leaked token reaches everything that account owns. That is acceptable for a first iteration with a small user base, and the fix is a nullable project column applied at lookup. Knowing where your own edges are is more useful than pretending you have none.

Tell integrators where data came from

Each entry in the response carries a source field, manual or github, plus the commit range it was drafted from when it came from a push. It costs two columns and it answers a question an integration will otherwise have to guess at.

Cheap metadata that preserves provenance tends to be worth more than it looks a year later.

None of this is exotic. It is just the set of things that are annoying to change once other people's scripts depend on them, which is why they are worth an hour before launch rather than a migration after.

I build Patchlog, a changelog widget for small SaaS, and this is the API it now ships on the Pro plan: read only over your own projects and entries, four endpoints, bearer authenticated. If you want the same shape, take the decisions rather than the product.

Sending your git diffs to an HTTP endpoint from GitHub Actions, and the four things that broke it

Michael Yousrie — Sat, 01 Aug 2026 07:34:35 +0000

Sending your own diffs somewhere is a surprisingly common need. Post them to an internal service, run them through a review bot, feed them to a summarizer, archive them for compliance. The GitHub Actions job that does it looks like five lines until you run it on a real repo, at which point four separate things break.

Here is a workflow that works, followed by why each awkward bit is there. Everything is plain git, jq and curl, all present on ubuntu-latest.

name: Send diffs

on:
  push:
    branches: [main]

jobs:
  send:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Send changes
        env:
          TOKEN: ${{ secrets.MY_TOKEN }}
        run: |
          BEFORE="${{ github.event.before }}"
          AFTER="${{ github.sha }}"

          # First push to a new branch has no usable "before" ref.
          if ! git cat-file -e "$BEFORE^{commit}" 2>/dev/null; then
            BEFORE="$(git rev-parse "$AFTER~1" 2>/dev/null || echo "$AFTER")"
          fi

          git diff "$BEFORE" "$AFTER" -- . ':(exclude).env*' ':(exclude)*.lock' > /tmp/full.diff
          head -c 200000 /tmp/full.diff > /tmp/send.diff
          TRUNCATED=false
          [ "$(wc -c < /tmp/full.diff)" -gt 200000 ] && TRUNCATED=true

          git log --format='%H%x09%s%x09%an%x09%aI' "$BEFORE".."$AFTER" \
            | jq -Rn '[inputs | split("\t") | {sha:.[0], message:.[1], author:.[2], date:.[3]}]' \
            > /tmp/commits.json

          jq -n \
            --arg repository "${{ github.repository }}" \
            --arg before "$BEFORE" \
            --arg after "$AFTER" \
            --rawfile diff /tmp/send.diff \
            --slurpfile commits /tmp/commits.json \
            --argjson truncated "$TRUNCATED" \
            '{repository:$repository, before:$before, after:$after,
              commits:$commits[0], diff:$diff, truncated:$truncated}' \
            > /tmp/payload.json

          curl -sS -X POST "https://example.com/api/push" \
            -H "Authorization: Bearer $TOKEN" \
            -H "Content-Type: application/json" \
            -H "Accept: application/json" \
            --retry 8 --retry-delay 15 --retry-max-time 300 --retry-all-errors \
            --fail-with-body \
            --data-binary @/tmp/payload.json

Now the parts that are not obvious.

`fetch-depth: 0`, because the default checkout cannot diff

actions/checkout does a shallow clone by default. Shallow means git diff BEFORE..AFTER fails on anything but the most recent commit, because the older side of the range is not in the local history at all.

This is the failure that looks like a bug in your endpoint. The workflow goes green on the push where you tested it and starts failing on real ones.

`github.event.before` is not always a commit

On the first push to a new branch, github.event.before is forty zeros. On a force push it can point at a commit that no longer exists in the remote history.

git cat-file -e "$BEFORE^{commit}" asks a simple question: does that object exist here and is it a commit? When it does not, the fallback diffs against the parent of the current commit, and if even that fails (an initial commit with no parent), it diffs the commit against itself and sends an empty diff. An empty payload is fine. A crashed workflow on somebody's first push is not.

Write to files, do not put diffs in shell variables

This is the one that cost me the most time, and it fails in a way that reads as nonsense:

jq: error: Argument list too long

A week of changes can be hundreds of kilobytes. ARG_MAX on Linux is a couple of megabytes for the whole argument list and environment, but you hit trouble well before that, and the error blames jq when the kernel refused the exec.

The fix is to stop passing large content as arguments. jq --rawfile name path reads a file in as a JSON string, correctly escaped, and --slurpfile reads a file of JSON in as a value. The diff never becomes an argument, so it never counts against ARG_MAX.

The same trick applies to the request body: --data-binary @file streams from disk instead of expanding on the command line.

While you are there, use jq -n to build the whole payload rather than string concatenation. A diff contains quotes, backslashes and newlines, which is exactly the set of characters that turns hand-rolled JSON into an unparseable mess at 2am.

Cap the size, and say that you capped it

head -c 200000 bounds what you send. The interesting half is the truncated flag next to it.

A consumer that receives a silently truncated diff has no way to know the input was incomplete, so it will report confidently on half a change. Sending the flag lets the other side adapt (in my case, lean on commit messages where the diff runs out). A boolean is cheap. Silent truncation is a correctness bug wearing a performance costume.

One caveat: head -c cuts on a byte boundary, so it can split a multibyte character in half. Depending on what reads the file next, that stray tail byte turns into a replacement character or an encoding error further down the pipe. If your repo has non-ASCII content, piping through iconv -c -f utf-8 -t utf-8 after the head drops the broken tail and costs nothing.

Exclude paths in CI, not on the server

git diff -- . ':(exclude).env*' uses pathspec magic to drop files before the diff is built. It is worth understanding why that placement matters.

Filtering on the receiving end means the sensitive file was transmitted, arrived, and was then deleted by code that has to be correct. Filtering in CI means it never left the machine. Those are very different promises to make to whoever owns the repo, and only one of them survives a bug on the server.

`Accept: application/json` and `--fail-with-body`

Without an Accept header, a lot of server frameworks answer a validation failure with an HTML error page or a 302 back to a login screen. Your workflow then either goes green on a redirect it never followed, or logs a wall of HTML.

--fail-with-body is the flag people miss. Plain -f fails the step on a 4xx or 5xx but throws the response body away, which is where the reason lives. --fail-with-body fails the step and prints the body, so the Actions log tells you what was wrong.

Retry, because your endpoint will be deploying

--retry 8 --retry-delay 15 --retry-max-time 300 --retry-all-errors covers about five minutes of downtime.

--retry-all-errors is the important one. By default curl retries only on a small set of transient conditions and does not retry on connection refused, which is exactly what you get while the receiving app restarts. Deploys are the single most likely reason a push arrives at an endpoint that is not there, and a push is not repeatable: nobody is going to git push --force just to trigger your workflow again.

Make the receiving endpoint idempotent on the commit sha as well. A unique index on the after sha turns a duplicate delivery into a no-op, which is what you want when a retry succeeds after the first attempt actually landed.

The general shape

Four rules, none of them specific to diffs:

Assume the range you were handed might not exist, and degrade instead of crashing.
Keep large content out of argument lists. Files and --rawfile are not a style preference.
Truncate loudly and let the consumer know.
Make failures readable in the Actions log, and retry the network like the other side might be restarting, because it might be.

I build Patchlog, and this workflow is the one it hands you for turning pushes into draft changelog entries, which is why it has been beaten on by real repos. The traps above are yours to use with any endpoint at all.

I turned git pushes into changelog drafts with an LLM. The prompt was the easy part.

Michael Yousrie — Sat, 01 Aug 2026 07:34:28 +0000

If you are adding an LLM feature to an existing product, you will spend a week on the prompt and then discover the prompt was never the risky part. The risky parts are what you feed it, how often you call it, what you do with a bad response, and what you keep afterwards.

I just shipped a feature that turns pushes to a Git repo into draft changelog entries. Here are the five decisions that actually determined whether it worked, none of which are prompt engineering.

1. Do not generate on every event

The obvious design is: push arrives, generate an entry, done. It is wrong for two reasons.

The first is volume. A normal working day produces pushes like "fix typo", "wip", "actually fix it". One entry per push gives you twenty drafts a day and a review queue nobody opens.

The second is worse. A single feature usually lands across several pushes. Generating per push means the model never sees the whole change, so it writes three half descriptions of one thing instead of one description of the thing.

So pushes go into a buffer, and generation runs on a cadence. Each run gets a window of work and can see the shape of it. The cadence is the user's choice (hourly for a repo that ships all day, weekly for a side project), and the scheduler ticks more often than the shortest cadence so that "hourly" is not secretly "up to an hour late".

Buffering also splits the two halves at exactly the right seam. Ingestion has to be fast, because a CI step is waiting on the HTTP response. Generation takes minutes. Put them in the same request and you have a CI job that hangs on a language model.

2. Decide the output granularity before you write the prompt

"Summarize this week's work" gives you one blob of text. That reads like a status report, and status reports are not what anyone subscribes to.

The right unit was already sitting in the database schema. Each changelog entry has one type (feature, fix, improvement, security) and renders as one item with one badge. So the contract is N entries, one per user-facing change, and the model is told to cluster related commits into a single entry.

The general lesson: your existing schema usually already encodes the granularity your users think in. Match it. If the model's output shape and your storage shape disagree, you will either mangle the output on the way in or build a second review screen you did not need.

3. An empty response is a success

This one is easy to get wrong and expensive to leave wrong.

A week of dependency bumps, refactors, CI fixes and test changes contains nothing a user can see. The correct output for that week is nothing at all.

If you do not say that explicitly, the model will invent something. It has been handed a pile of work and asked for changelog entries, and returning nothing feels like failure, so you get "Improved performance and stability" on a week where you renamed a variable. That is how changelogs become noise, and it is the model doing exactly what it was asked.

So the contract has an explicit success case for nothing:

{"entries": []}

and the prompt says, in as many words, that this is a correct and expected answer, not a failure, and that inventing an entry to avoid an empty result is worse than the empty result.

Worth generalizing: for any extraction or summarization feature, define the empty answer as a first class output and say so in the prompt. Otherwise "no signal here" becomes "here is some noise".

4. House rules belong in a validator, not only in the prompt

I have a hard rule that nothing I publish contains an em dash or an en dash. It is the single most recognizable tell of generated text, and these drafts become public changelog copy on somebody else's website.

Putting that rule in the prompt is necessary and not sufficient. Prompts are a request. Models comply most of the time, which is precisely the failure mode you cannot ship on, because "most of the time" means it appears in production copy on a day you are not looking.

So the rule is also a validator. Every title and body is checked, and a response containing a banned character is rejected in full, then retried once with the rejection reason fed back so the retry knows what to fix. If it fails again, the job fails and creates nothing.

Three properties of that design are worth stealing:

Reject the whole response, not the bad entry. Persisting three of four drafts leaves a human to work out which one is missing and why. Rejecting everything costs one retry and keeps the state simple.

Feed the reason back. "Your previous reply was rejected: a title contained an em dash. Fix that and reply again." is a much better retry than the same prompt sent twice.

Losing a run beats shipping a violation. Whatever your equivalent rule is (no pricing claims, no customer names, no promises about unreleased features), decide up front which side you fail on. Write the rule as code, because a rule that lives only in the prompt is a preference.

And do not fix it with find and replace. Swapping an em dash for a comma leaves the same rhythm behind, which is the actual tell. Ask for a rewrite or drop the response.

5. Delete the input as soon as you are done with it

To write a decent entry from commit messages like "fix stuff", the model needs the diff. Which means the feature asks people to send their source code to a third party, and how that is handled is a real question, not a paragraph in a privacy policy.

The design I settled on:

Exclusions are applied in CI, before anything leaves the repo, so excluded paths are never transmitted rather than transmitted and then dropped.
The diff is stored only until a run consumes it, then nulled in the same transaction that writes the drafts.
A sweep nulls diffs on anything a run never reached, so source does not linger because generation kept failing.
Commit messages and stats stay, because they are the audit trail for where a draft came from and they carry no source.

There is a real cost to this, and it is worth naming rather than hiding: once the diffs are gone, a draft cannot be regenerated. You get the drafts from that run or you write it yourself. I took that trade because "we delete your code" is only worth saying if it is literally true.

The pattern underneath

Every one of these is the same shape. The model is a component with a contract: defined input, defined output, defined failure. The prompt describes the contract, the code enforces it, and the retention policy decides what the component is allowed to remember.

Teams that treat the prompt as the feature end up with a system whose behaviour is a matter of opinion. Teams that treat the prompt as one part of a contract can actually ship the thing.

I build Patchlog, a changelog widget for small SaaS, which is where this feature lives (it is on the Pro plan, and it is GitHub only for now, one repo per project, push triggers only). Everything above is how it is built, so you can take the design without taking the product.

UTM conventions that stop your analytics turning to mush

Michael Yousrie — Fri, 31 Jul 2026 10:42:05 +0000

Most broken analytics I have seen were not broken by a bug. They were broken by three people tagging links slightly differently for six months.

UTM parameters have no schema. Nothing validates them. Your analytics tool takes whatever string you put in utm_source and treats it as gospel, which means the discipline has to live in you, not the tool. Here is a convention that takes ten minutes to adopt and saves you from a report you cannot trust.

The five parameters, and what each is actually for

utm_source: where the click came from. A single named place: newsletter, instagram, partner-acme.
utm_medium: what kind of channel it is: email, social, cpc, qr, referral.
utm_campaign: which initiative it belongs to: spring-launch, black-friday-2026.
utm_content: which specific link, when one page has several: header-cta, footer-link.
utm_term: paid keyword. Mostly vestigial unless you are running search ads.

The distinction people get wrong is source versus medium. Source is the place, medium is the type. Instagram is a source; social is a medium. Your newsletter is a source; email is a medium. If you find yourself putting instagram in medium, the whole report will fragment later.

Rule 1: lowercase everything, always

This is the single highest-value rule, so it goes first.

utm_source=Instagram
utm_source=instagram
utm_source=INSTAGRAM

Most analytics tools treat those as three different sources. You will not notice for a month. Then you will open a report, see Instagram split across three rows, and have no clean way to merge history.

Lowercase everything. No exceptions, no judgment calls.

Rule 2: hyphens, never spaces or underscores

A space becomes %20 and looks broken in reports. Underscores are fine technically but mixing them with hyphens gives you the same fragmentation problem as casing.

❌ utm_campaign=Spring Launch
❌ utm_campaign=spring_launch
✅ utm_campaign=spring-launch

Pick hyphens. Write it down. Done.

Rule 3: date your campaigns

utm_campaign=black-friday seems fine until it is your third Black Friday and every year is stacked into one row.

✅ utm_campaign=black-friday-2026
✅ utm_campaign=2026-03-product-launch

Year-first works well if you want campaigns to sort chronologically.

Rule 4: never tag internal links

This is the one that silently corrupts data.

If you tag a link from your own homepage to your own pricing page, most analytics tools start a new session at that click and overwrite the original referrer. The visitor came from a newsletter, clicked one internal link, and is now attributed to your own site.

UTMs are for traffic arriving from outside. Internal navigation is what your normal page-path reporting is for.

Rule 5: keep a canonical list

Not a spreadsheet nobody opens. A short list in whatever doc your team actually reads:

sources:  newsletter, instagram, tiktok, linkedin, youtube, partner-<name>
mediums:  email, social, cpc, qr, referral, print
campaign: <yyyy>-<mm>-<short-name>
content:  header-cta, inline-link, footer-link, bio-link

The rule is: if it is not on the list, it does not get used until it is added to the list. That single sentence is what prevents drift, because the failure mode is never one bad decision, it is fifty small ones.

Rule 6: think about what the user sees

A URL like this in an Instagram bio is ugly, and it leaks your internal campaign naming to anyone who looks:

https://example.com/pricing?utm_source=instagram&utm_medium=social&utm_campaign=2026-03-launch&utm_content=bio-link

This is where a short link earns its place. The tagged URL becomes the destination, and the thing you publish stays clean. You keep the attribution and the reader gets a link that fits.

It also means the tagging lives in one editable place. Get a UTM wrong on a printed QR code and you are reprinting; get it wrong behind a short link and you fix the destination.

Rule 7: QR codes need `utm_medium=qr`

Scans from print are not "direct" traffic, but that is where they land if you do not tag them. Tag the URL behind the code, and if the same campaign runs on a poster and a flyer, separate them with utm_content:

utm_source=poster&utm_medium=qr&utm_campaign=2026-03-launch&utm_content=cafe-window

Now "did the flyers do anything" is a question with an answer.

A worked example

Spring launch, promoted through the newsletter, Instagram bio, and a printed flyer:

# newsletter, main button
?utm_source=newsletter&utm_medium=email&utm_campaign=2026-03-spring-launch&utm_content=header-cta

# instagram bio link
?utm_source=instagram&utm_medium=social&utm_campaign=2026-03-spring-launch&utm_content=bio-link

# flyer QR code
?utm_source=flyer&utm_medium=qr&utm_campaign=2026-03-spring-launch&utm_content=cafe-window

Same campaign across all three, so they roll up. Different sources and mediums, so they break down. That is the whole point.

The check that catches drift

Once a month, list your distinct utm_source values. If you see instagram and Instagram, or ig and insta, drift has started. Fix the convention now, because merging historical rows is unpleasant and sometimes impossible.

I build Swyfty, a short-link and analytics tool, which is why I have opinions about this. But none of the above needs my product or any product. It needs a list of allowed values and the discipline to stick to it.

The tooling is never what makes attribution work. Consistency is. A boring convention applied every time beats a sophisticated analytics stack fed inconsistent strings, every single time.

Bitly alternatives: the limit that bites is data retention, not links

Michael Yousrie — Fri, 31 Jul 2026 10:42:03 +0000

If you are comparing link shorteners, you have probably lined them up by price per month and by how many links each tier allows. That is the comparison every pricing page invites you to make, and it hides the limit that actually bites.

For click analytics, the limit that matters is how long your data survives.

What Bitly actually meters

Bitly's published pricing, as of July 2026:

Plan	Price	Links/month	Click data history
Free	$0	5	(not offered)
Core	$10/mo, annual only ($120/yr)	100	30 days
Growth	$29/mo annual, or $35/mo	500	4 months
Premium	$199/mo annual, or $300/mo	3,000	1 year
Enterprise	custom	custom	2 years

Clicks themselves are unlimited on every tier. That sounds generous, and it is the number everyone quotes. But look at the right-hand column.

On Core, your click history is 30 days. Run a campaign in March, come back in May to see how it did, and there is nothing to see. The clicks happened. The record of them expired.

The second thing worth noticing: city-level and device tracking sit on Premium. That is $199/month billed annually, or $300 month to month. If "I just want to know where my clicks come from and what they are opening it on" is your entire requirement, Bitly's answer is its top self-serve tier.

None of this makes Bitly a bad product. It is a mature platform with a real enterprise business, and the pricing is shaped for that buyer. But if you are one person with some links and a question about them, you are shopping in the wrong aisle.

The question to ask every shortener

Before you compare prices, ask this:

"In six months, can I still see what happened to a link I made today?"

It reframes the whole evaluation. A $10/month plan that forgets everything after 30 days is not cheaper than a $7/month plan that does not. It is a different product that happens to have a similar-looking price.

Then two follow-ups:

"Is the granularity I need on the tier I can afford?" Country-level is common on cheap plans. City and device often are not. Decide which you actually need before you pay for a tier that gives you neither.

"What happens to my links if I stop paying?" This is the one people find out about late. A short link is a promise printed on things you no longer control: business cards, packaging, an old tweet, someone else's blog post. If those links go dead or start showing a parked page when you downgrade, you have handed your reputation to a billing relationship. Ask before you print.

A checklist for comparing link tools

Data retention window. The single most under-compared spec. Get the number in months.
Granularity per tier. Country, city, device, browser, referrer, unique versus repeat. Which of those are on the plan you would actually buy?
Unique versus total clicks. If a tool only reports total clicks, one enthusiastic person and a preview bot can look like a successful campaign. You want both numbers.
What happens on downgrade or cancellation. Do existing links keep resolving?
Link creation limits. Monthly caps are common. If you generate links programmatically, a 100/month cap disappears fast.
Custom domain cost. Often the real jump between tiers.
Is there an API on the plan you can afford? If links need to come out of your own tooling rather than a dashboard, check this early. It is frequently gated.
Export. Can you get a CSV out? If the answer is no, the data was never really yours.

That list is the useful part of this post. Run it against any tool, including mine.

Where Swyfty fits, and where it does not

Full disclosure: I build Swyfty, so treat this section as the biased part and check it yourself.

It exists because of the gap above. Short links, click analytics, QR codes and a link-in-bio page behind one login, with a REST API. Analytics include country and city, device, browser, referrer, and unique versus repeat visitors, and they are on the $7/month plan rather than a $199 one. There is CSV export, so the data leaves with you. Free covers 3 links, 500 visits each, and one bio page, with a short interstitial before each redirect; Pro is $7/month or $60/year and removes the interstitial, adds custom slugs, QR codes and hourly checks that your destination URLs are still alive.

Now the honest part, because a comparison post that only lists strengths is an ad. Swyfty does not have:

Team accounts or multiple seats
White-label custom domains
Retargeting pixels
A/B testing of links
Scheduled link expiry

If you need branded custom domains at scale, or several people working in the same account with permissions, Bitly or Rebrandly is genuinely the better buy and I would rather you went there than churned out of mine in a month. If all you want is a bio page and nothing else, Linktree has a much larger template ecosystem.

It is also early. There is no traction to point at, no testimonials, and I am not going to invent any. What I can tell you is what the product does and what it costs.

The decision rule

Are you buying link infrastructure for a team, or answers about your own links?

If it is a team, buy the platform. Seats, permissions, branded domains and long retention are what those prices are for, and they are worth it at that size.

If it is answers, then retention and granularity are the only specs that matter, and you should not have to reach an enterprise tier to keep six months of your own click history.

Either way: compare the retention column first. It is the one nobody puts in the comparison table, and it is the one you notice in six months when you go looking for a number that is no longer there.