DEV Community: John Builds

The bug report said 6 fields. The contract test said 13.

John Builds — Thu, 20 Aug 2026 17:10:34 +0000

We had one API input schema declared twice. A Zod schema validated requests on the npm package path. A hand-written JSON Schema advertised the same input on a serverless worker path. Same tool, two deployment targets, two copies of the truth, kept in sync by discipline alone.

Zod strips unknown keys by default. No error, no warning. Anything the schema does not recognize is deleted before your handler ever sees it. So when the two copies drifted, a documented field sent down the npm path was quietly removed in flight. The response looked like a success. The data was just gone. The exact same call against the worker path worked, because that copy of the schema knew the field.

A bug report came in after someone read both schemas side by side, carefully. It listed 6 drifted fields.

While fixing it I wrote the test that should have existed from the start: import both schemas, extract the key sets, assert they match. It failed with 13 fields. One of them was being silently stripped in production and nobody had reported it, because the failure mode is a success response. The other 12 existed only in the validator, so they were invisible to anyone reading the advertised schema.

The part that actually stung: the file had a comment saying both copies must be kept in sync. It had been there through all 13 drifts. Comments don't run.

What I keep from this:

When the invariant is "two lists must match", never enumerate the drift by hand. A careful human read found less than half of it. Diff the lists in a test and let the failure tell you the scope.
A validator that strips unknown keys turns schema drift into silent data loss. Treat it as an allowlist that deletes whatever it does not know.
The two drift directions fail differently. A key missing from the validator is a runtime data-loss bug. A key missing from the advertised schema is merely undiscoverable. Report them separately.
On any system with two deployment paths, "I tested it" means nothing until you say which path.

The same failed payment destroyed one customer's data and left the next one's alone

John Builds — Tue, 18 Aug 2026 14:35:26 +0000

We had a bug that only fired sometimes, and "sometimes" turned out to be a coin flip on webhook arrival order.

Here's the setup. Our billing code had two constants. One listed the statuses that still grant access. One listed the statuses that trigger destructive cleanup: reverting scheduled work to drafts, revoking API keys, turning features off.

The status a payment processor sets on a first failed invoice was in both lists. Same string, opposite meanings, four lines apart in the same file.

That alone is a bug. What kept it alive was the ordering.

The cleanup path was guarded by "was this subscription active before this webhook?" Two webhooks arrive for one failed payment, and the processor does not promise which lands first:

Subscription-updated first: prior status still reads active, guard passes, cleanup runs, the customer's scheduled times are nulled out.
Payment-failed first: that handler sets the status directly, so by the time subscription-updated lands the guard already reads false, and cleanup never runs.

Same event, same code, two outcomes decided by network timing. It never reproduced consistently enough for anyone to chase it.

Then I found the test that was protecting it. A spec looped over the "inactive" statuses asserting each one enqueued the cleanup job. Green suite. Fixing the code turned that spec red, because the spec had encoded the wrong behavior as the requirement.

Three things I took from it:

A constant used for access control and a constant used for destructive cleanup must never share a member. If they have to, the shared member needs a comment explaining why. Grep every consumer before you add a status to a list that does irreversible work. Ours had exactly one consumer, so the check cost nothing.

Any handler whose behavior depends on the record's prior state is ordering-dependent. Delivery is guaranteed. Order is not. Derive the guard from the payload, or make the handler idempotent.

Cleanup that nulls a column is not undone by re-activating. Gating access is reversible. Destroying data is not, so it belongs at a terminal state only.

A grace period is not a terminal state. We were treating "the first payment failed and we're going to retry for a few days" as "this person is gone."

Best Free Social Media Management Tools

John Builds — Sat, 15 Aug 2026 15:15:37 +0000

The best free social media management tools in 2026 are Buffer, Meta Business Suite, Zoho Social, Publer, Metricool, and XreplyAI. Each is genuinely free forever, and each caps a different thing: channels, monthly posts, or queue depth.
"Free" is doing a lot of work in this category. Some free plans run forever with real limits printed on the pricing page. Others are a 14-day trial wearing a costume, and you only find out on day 15.

The roundups that rank for this query mostly list twelve tools and bury the caps inside per-tool prose. That is the wrong shape for the actual decision. You are not choosing between logos, you are choosing which ceiling you hit first: the third channel, the tenth queued post, or the second person on your team.

So this post starts with the structure of free plans, then names tools, then covers the cost that nobody puts on the comparison chart. Every number below came off the vendor's own pricing page on 2026-08-08, because these change within weeks.

What does "free" actually mean in a social media tool?

In short: Free plans come in three shapes: free forever with hard caps, freemium where the free tier exists to funnel you to paid, and a trial dressed up as a free plan.

Free forever with caps is the honest version. Buffer, Publer, Zoho Social, and Metricool all publish a $0 tier with numbers next to it. You can sit on that tier indefinitely and the tool keeps working, just within a fence.

Trial-shaped free is the version that costs you a migration. The plan reads as free on the marketing page, and the fine print reveals a 14-day window after which publishing stops. Zoho Social is a useful hybrid here: its free tier has lifetime validity, but only after a 15-day trial of the fuller feature set expires, so your first two weeks are not representative of what you keep.

The third shape is freemium-with-a-funnel, where the free tier is deliberately sized just below the point of usefulness. One channel when you post to three. Twenty posts a month when you post daily. It works, technically, and it is engineered to stop working the week you get serious.

Here is the pattern underneath all of it. Vendors give away the thing that costs them nothing and gate the thing that costs them API calls, storage, or seats.

Capability	Typically free	Typically paywalled
Composing and drafting posts	Yes, usually unlimited	Rarely gated
Connected channels	1 to 3	Anything above 3
Scheduled posts in queue	10 to 30, or 20 per month	Unlimited queue
Content calendar view	Usually yes	Rarely gated
Analytics history	24 hours to 30 days	Full history and exports
Additional users or seats	Almost never	Always, and priced per seat
AI generation	A small credit allowance	Ongoing usage
Bulk upload and automation	Almost never	Always

Read that table as a prediction. Whatever tool you pick, the seat and the queue are where you will meet the paywall, in that order. If you want the scheduling-only view of this same question, our free social media scheduler breakdown goes deeper on queue mechanics.

The free tools worth using in 2026

In short: Six tools have free tiers that a solo founder can actually run on, and each one is the right answer for a different posting pattern.

All figures below are from each vendor's own pricing or help page, checked 2026-08-08. Treat them as perishable. For the paid side of this comparison, see our roundup of the best social media management tools.

Buffer

Free plan: 3 channels, 10 scheduled posts per channel, 1 user account, 30-day analytics history, 100 ideas. The per-channel refill is the smart part, since 10 posts per channel across 3 channels is 30 queued posts, not 10.

Best for: someone posting a few times a week across three networks who wants the cleanest interface in the category. The catch: 1 user, hard stop, and Buffer's paid pricing is per channel, so growth is metered on the axis you are most likely to grow.

Meta Business Suite

Free, no tier structure, no caps published on scheduling. Covers Facebook and Instagram only.

Best for: anyone whose audience genuinely lives on Facebook and Instagram. If that is you, stop reading and use this. It is free, it is first-party, it never rate-limits your own Pages, and no third-party tool will out-feature Meta on Meta. The catch is obvious: two platforms, and you are back to tab-switching the moment LinkedIn or X matters.

Zoho Social

Free plan: 1 brand covering 6 channels (X, Instagram, Facebook Page, LinkedIn Company Page, LinkedIn Profile, Google Business Profile), 1 team member, 5 AI credits, lifetime validity after a 15-day trial.

Best for: the widest free channel coverage on this list, and the only free tier here that includes both X and a Google Business Profile. The catch: it is one brand and one seat, and Zoho Social is a component of a much larger suite, so the interface assumes you are somewhere in the Zoho ecosystem.

Publer

Free plan: 3 social accounts, 10 pending scheduled posts per account, 25 saved drafts, 24 hours of post history. X is excluded from the free tier entirely, which Publer attributes to Twitter Enterprise API cost.

Best for: visual-platform posting where you want drafts and a real calendar without paying. The catch is the 24-hour history: you lose your own publishing record almost immediately, which makes any retrospective impossible on free.

Metricool

Free plan: 1 brand, 20 scheduled posts per month, 5 competitor profiles analyzed, 30 days of analytics. LinkedIn and X are excluded from the free brand's networks.

Best for: analytics-first users. The competitor tracking on a free tier is genuinely unusual. The catch: 20 posts a month is under one post a day, so Metricool free is a measurement tool that also schedules, not a scheduler that also measures.

XreplyAI

Free plan: manually create, edit, schedule, and publish to up to 3 connected channels, 30 posts. All 15 platforms are available to pick from, including Bluesky, Mastodon, Threads, Discord, Telegram, Google Business, and Slack. No credit card required.

Best for: someone whose audience is spread across platforms the bigger tools treat as afterthoughts, and who wants one calendar rather than three tabs. The catch, stated plainly: AI generation is paid-gated apart from 10 lifetime AI generations, so if you came looking for a free AI writer, this is not it. Free here means free scheduling and publishing, and the writing is yours.

The limit that actually bites: per-seat pricing

In short: Every free plan on this list is a single seat, so the moment a second person touches your social accounts you are not upgrading a plan, you are starting a per-person bill.

Count the seats in the section above. Buffer: 1 user account. Zoho Social: 1 team member. Metricool and Publer: 1 brand or workspace. That is the category's pricing model showing through the free tier.

The comparison charts rarely price this out. Channel caps and post caps are annoying and linear: you hit 3 channels, you pay for more channels, and the cost tracks something you can see. Seats are a step function tied to a decision you make for non-tool reasons. You hire a contractor, you bring in a co-founder, you hand social to an intern for the summer, and the tool's price changes because your org changed.

A worked example, using real published numbers. Say you are two people posting to five channels. On Buffer's free plan you have 3 channels and 1 seat, so you are short on both axes. Paid Buffer meters channels, and the second person needs their own access, so your monthly cost is a function of channels multiplied by people. On XreplyAI's Starter tier at $11.99 a month you get 10 channels, and the workspace does not bill per person: our flat pricing, no per-seat fees model prices the workspace, not the headcount.

Here is a position you can reasonably disagree with. Most free plans in this category are sized to become painful at exactly the moment the tool starts working for you, and the seat cap is the sharpest instance of that. The honest question is never "which one is free," it is "which free plan's ceiling matches my actual volume, and what does the first upgrade cost when I cross it."

How do you choose the right free plan?

In short: Count your channels, your weekly post volume, and your people, then pick the free plan whose tightest cap sits above all three numbers.

Start with channel count, because it is the cap that eliminates tools fastest. If your list includes X, note that Publer excludes X from free and Metricool excludes X and LinkedIn from its free brand. If it includes Bluesky, Mastodon, Discord, or Telegram, most of this list drops out entirely.

Then do the post-volume arithmetic honestly. Three posts a week across three channels is 36 posts a month, which clears Buffer's per-channel refill and blows straight past Metricool's 20-per-month cap. Daily posting on two channels is roughly 60 a month, which no free plan on this list holds without refilling manually.

Third, decide whether a second person is coming in the next six months. If yes, evaluate the paid tier now instead of the free one, because migrating a scheduled queue between tools is a genuinely bad afternoon and free-tier seat caps do not negotiate.

Fourth, look at what the free tier does to your history. Publer's 24-hour post history and Metricool's 30-day analytics window mean you cannot answer "what did we post last quarter" on free. If you need that record, that constraint outranks the post cap.

Last, check the upgrade path before you commit, not after. A free plan is a trial of the paid plan you will eventually buy, so the number that matters is the second one on the pricing page. Our guide to social media scheduling tools covers that paid tier comparison in detail.

What free social media tools cannot do

In short: No free plan in this category gives you bulk upload, unlimited queue depth, multiple seats, or full analytics history, and pretending otherwise sets you up for a mid-quarter migration.

Bulk scheduling is universally paid. If your workflow is "sit down once a month and load 40 posts," every free tier here will fight you, because the queue caps are specifically sized to prevent that pattern.

Approval workflows are paid everywhere, without exception. The moment someone needs to review before publish, you are on a paid tier, and usually a mid or upper one rather than the entry plan.

Long analytics history is paid. Thirty days is the generous end of free, twenty-four hours is the tight end, and neither supports a quarterly review.

Sustained AI generation is paid across the board, including ours. Free AI allowances are sampling credits: Zoho Social gives 5, Buffer gives 5 AI reply suggestions per week, XreplyAI gives 10 lifetime generations. They exist so you can see the output quality before you decide, not so you can run a content operation on them.

None of that makes free plans a trap. It makes them a scoped tool. A free plan is the right call when your volume is genuinely low, when you are testing whether a posting habit sticks before paying for it, or when your platforms happen to line up with a first-party tool like Meta Business Suite. It is the wrong call when you already know your volume and you are choosing the free tier to avoid a $12 decision.

Pick the free plan whose tightest cap sits above your real numbers, not the one with the longest feature list. If your audience is on Facebook and Instagram, Meta Business Suite is free and first-party and you should just use it. If you need six channels on one seat, Zoho Social has the broadest free coverage here.

If your presence is scattered across platforms the big tools treat as afterthoughts, that is the gap XreplyAI was built for: 15 platforms from one calendar, 3 channels and 30 posts free with no credit card, and flat pricing with no per-seat fees when you outgrow it. Start free at XreplyAI and see whether the calendar holds your actual posting rhythm before you pay anyone.

Buffer pricing (checked 2026-08-08)
Publer plans and pricing, Publer Help Center (checked 2026-08-08)
Metricool pricing (checked 2026-08-08)
Zoho Social pricing (checked 2026-08-08)
Meta Business Suite (checked 2026-08-08)

Frequently Asked Questions

What is the best free social media management tool?

It depends on your platforms. Meta Business Suite wins if you only post to Facebook and Instagram. Zoho Social gives the widest free channel coverage at 6 channels. Buffer has the cleanest interface at 3 channels and 10 posts per channel.

Are free social media management tools actually free forever?

Some are. Buffer, Publer, Metricool, and XreplyAI publish permanent $0 tiers with hard caps. Zoho Social's free tier has lifetime validity but only after a 15-day trial of fuller features ends. Always check whether the plan is free forever or a trial.

How many social accounts can you connect for free?

Typically 1 to 3. Buffer, Publer, and XreplyAI allow 3. Zoho Social allows 1 brand covering 6 channels. Metricool allows 1 brand. Meta Business Suite covers your own Facebook and Instagram accounts with no third-party cap.

Can you schedule posts to X for free?

Rarely. Publer excludes X from its free plan and Metricool excludes X and LinkedIn from its free brand, both citing X API costs. Zoho Social and XreplyAI include X in their free tiers. Verify this before committing, since API pricing shifts often.

Why do free social media plans only allow one user?

Because seats are how the category prices. A second user is not a bigger plan, it is a second bill. If you expect a teammate within six months, compare paid tiers now: some price per seat, others price the workspace at a flat rate.

Is a free plan enough for a solo founder?

Often yes, at low volume. Three channels and roughly 30 queued posts covers posting a few times a week. It breaks down at daily posting across four or more platforms, or when you need analytics history beyond 30 days.

Do free plans include AI content generation?

Only as sample credits. Zoho Social includes 5 AI credits, Buffer offers 5 AI reply suggestions per week, and XreplyAI includes 10 lifetime AI generations. Ongoing AI writing is paid on every tool in this roundup.

What does XreplyAI's free plan include?

Manually create, edit, schedule, and publish to up to 3 connected channels, 30 posts, with no credit card required. All 15 platforms are selectable. AI generation is paid-gated apart from 10 lifetime AI generations.

Originally published at xreplyai.com.

Picking the model that's already the right shape

John Builds — Fri, 14 Aug 2026 15:06:03 +0000

A user reported that their weekly content plan could only post to one of their three Instagram accounts. I assumed a misconfiguration. It wasn't one. The planner selected a platform and then one account inside it, so "Instagram" resolved to exactly one Instagram account. The other two were unreachable and no setting could change it.

Fixing it meant making the account the unit of targeting instead of the platform. Straightforward enough.

The interesting decision was the second feature that came with it: letting several same-platform accounts share one generation, so one post body publishes to all of them.

There were two places to model that. The obvious one was the per-account assignment table, which is where a plan records "this account gets a post at this time." But that table has a required single-account foreign key, a uniqueness constraint on account plus plan plus time, and 19 consumers. Widening it to many-accounts meant touching all of them and relaxing a constraint that was doing real work.

The other option was a nullable group column on the channel row: channels in the same group generate together. The scheduled-post record downstream was already multi-account, because publishing the same post to several accounts has been supported for a long time. The capability existed, it just wasn't reachable from the planner.

Modeling it on the channel meant one migration, one nullable column, and no change to the assignment table at all.

So before widening a model to fit a new feature, check whether some other model in the system is already the right shape. Multi-account publishing was already solved one layer down. The planner just needed a way to say "these go together."

One detail that fell out of the design: a group needs a single posting schedule, so the lowest account id in the group leads and the others follow its slots. Deterministic, no new column, and if that account disconnects the next one takes over.

https://xreplyai.com/dashboard/content-planner?utm_source=devto&utm_medium=social&utm_campaign=feature-2026-08-14

iOS Universal Links follow redirects, and that quietly breaks OAuth

John Builds — Thu, 13 Aug 2026 17:49:24 +0000

I lost a day to an OAuth bug that produced no errors, no logs, and no failed requests. On an iPhone with the provider's app installed, tapping "Connect" opened that app to its feed. No authorization dialog, no callback, nothing on the server. The flow just evaporated.

My first theory was that the authorize URL was registered as a Universal Link, so iOS was routing the whole thing to the app. I shipped a parameter to force the web dialog. It changed nothing, because the parameter does not exist. I had picked it up from a URL I saw in the wild and assumed it did what its name suggested.

The actual mechanism:

The provider's apple-app-site-association file explicitly excludes /oauth/authorize from Universal Links. They want the dialog in a browser. But if you have no web session with them, and almost nobody who lives in the app does, the authorize URL responds with a 302 to /accounts/login. That path is not excluded. It matches the catch-all.

And iOS evaluates Universal Links across the server redirects of a tap-initiated navigation, not just the URL you started with. So the excluded path handed off to a registered one, and the app swallowed the flow.

The fix is not a provider parameter. Universal Links fire on tap-initiated navigations and not on programmatic ones. Open a blank popup synchronously inside the click handler, so the popup blocker stays happy, then navigate it with location.assign. The whole redirect chain stays in the browser.

Two things I would do differently. Check the provider's AASA file before theorizing about deep links; it is a public URL and it disproved my first theory for free. And follow the entire logged-out redirect chain with curl, not just the entry URL. An excluded path that redirects to a registered one still deep-links.

I was certain the auth URL was broken. It was the login page it redirected to.

Dogfooding as QA: four months of publishing through our own scheduler

John Builds — Tue, 11 Aug 2026 14:59:50 +0000

In April I made a rule for myself: our product's own social accounts have to run on the product. No composers, no manual posting, no exceptions.

I build a social media scheduler, so this should have been an easy call. It still took four months of shipping before I trusted it with our own presence. Since mid-April, our LinkedIn, X, Bluesky, and Threads accounts have published every weekday through the same pipeline we sell, and I have not opened a composer since.

Two findings I did not expect:

Dogfooding is the best QA we have. When a platform changes its API, our own morning post breaks first, before any customer's does. We have caught real publish bugs hours before a support ticket could have existed.
Consistency compounds quietly. Nothing went viral. But every profile looks alive, and "looks alive" is the first thing a stranger checks before trusting you with anything.

The uncomfortable version of the lesson: if your product claims to save people time and you do not run your own operations on it, you are asking customers to believe something you never tested.

The scheduler is XreplyAI: one calendar, 15 platforms. https://xreplyai.com/?utm_source=devto&utm_medium=social&utm_campaign=edusales-2026-08-11

Adding usage-based pricing turned a UX decision into a billing bug

John Builds — Mon, 10 Aug 2026 20:50:46 +0000

We shipped a model picker last week. Users choose which AI writes their posts, see the cost per model up front, and pay the provider's exact measured rate with no markup on top.

Then we found a bug that could not have existed the week before.

Our Generate button had always returned three drafts per press. It was a UX call made back when generation was free and unmetered: more options, one click, nothing to think about. Nobody revisited it.

The moment a premium model sat behind that button, one press billed three times.

The obvious fix is wrong

The intuitive fix is to read which model the user selected and bill off that. It does not work, and the reason is the part worth stealing.

What the user picked is not what actually runs. If their plan lapsed, or their prepaid balance hit zero, generation degrades to the included model and the run costs nothing. Bill off the stored preference and you charge people for generations that were never premium in the first place.

So the check had to move. Ask the generation service what model it actually resolved to at runtime, then decide both how many drafts to produce and what to debit:

count = if AiModelRegistry.premium?(service.ai_model_key)
  1
else
  params[:variants].to_i.clamp(MIN_VARIANTS, MAX_VARIANTS)
end

One press, one billed generation, and only when the thing that ran was genuinely the paid model.

The transferable part

If you are adding usage-based pricing to an existing product, you are not adding a payment step. You are re-auditing every default the flow already had.

Batch sizes. Retries. Auto-refresh. Preview renders. Anything that quietly multiplies work was free before and none of it is now. Each one was a UX decision when it was written, and every one of them silently became a billing decision the day money showed up.

The second lesson is narrower but bit us harder: when a system can degrade or fall back, "what the user configured" and "what executed" are different values. Bill the second one. Log the second one. If your metering reads a stored preference anywhere, that is a bug waiting for someone's plan to lapse.

We build XreplyAI, a scheduler for 15 platforms, if it matters: https://xreplyai.com?utm_source=devto&utm_medium=social&utm_campaign=feature-2026-08-10

The most specific sentence in your draft is usually not the first line

John Builds — Thu, 06 Aug 2026 17:19:32 +0000

I spent a year writing posts that were technically true and completely unreadable.

"Learned a lot about pricing this month." "Shipping has been going well." "Big lessons from the latest release." Every one is a summary of a post I never actually wrote.

The habit that fixed it takes about ten seconds. Before publishing, find the most specific sentence in the draft. Then check whether it is the first line. It almost never is. It's usually sitting in paragraph three, hedged, after two paragraphs of setup.

"Learned a lot about pricing" becomes "I raised my price 40% and two customers thanked me." Same month, same lesson, same person. One of them gets read.

The test: could anyone else in your position have written this sentence? If yes, it's a category, not a detail. Go find the number, the quote, or the specific moment.

Specificity also gives readers something to disagree with, which is where most replies come from.

The buried line is usually the post.

Lessons from migrating a production Rails API from Render to Railway

John Builds — Wed, 05 Aug 2026 18:16:34 +0000

Moved a production Rails API from Render to Railway recently. Web service, Solid Queue worker, Postgres 18. Here are the lessons worth stealing, whichever direction you're migrating.

Suspend the old services. Do not delete them.

Suspending costs nothing and it is the entire rollback plan. On cutover night we suspended the old worker, then the old web service, and left both sitting there. If the restore had gone badly we could have brought them back in seconds.

The part people get wrong is when that plan expires. The rollback is valid right up until the new database takes its first write. After that it is void, and restarting the old host actively makes things worse, because now writes are split across two databases and you have to reconcile them by hand. From the first write onward you roll forward and you fix problems where the traffic already is.

Knowing exactly where that line sits is what lets you move fast before it and stop hesitating after it.

Migrate your OAuth config weeks before your infrastructure

A cutover that touches auth config is a cutover that breaks. We normalized every redirect URI to our own domain well ahead of time, so cutover night touched zero OAuth config.

Our plan doc's list of which platforms needed this was wrong in both directions. We assumed X, Instagram and TikTok were already on the canonical domain. Only TikTok was, and X is our highest-traffic connect path. Meanwhile Threads, Pinterest and YouTube were not on the list at all. Grep the live environment export, not the plan doc.

Verify OAuth by connecting, not by reading config

A redirect URI that looks right in a dashboard proves nothing. We ran a real connect on all 11 platforms and watched the nonce rows get created and consumed.

That is how we found a caching bug in our own registration service: it cached a client per instance domain and short-circuited whenever a cached ID and secret existed, without comparing the cached redirect URI to the requested one. It built the authorize URL from the new env var while sending the old client ID. We also found a Facebook scope error that had been quietly broken for three weeks.

Only one worker can exist at a time if you use rotating refresh tokens

X and Bluesky issue a new refresh token on every use and kill the old one. Two workers polling the same account means one silently invalidates the other's credentials, and the account starts failing to publish with no obvious cause.

This is what shapes a parallel-run migration. A second web service alongside the old one is harmless, because reads do not rotate anything. A second worker is not. We deployed the new worker once, confirmed it booted with a supervisor, dispatcher, three workers and a scheduler enumerating all 27 recurring tasks, then removed the deployment and disconnected the repo so nothing could auto-deploy it back on the next merge.

Prove env parity by hashing, not by eyeballing

123 environment variables. Eyeballing that is not verification, and the failure mode is nasty: one wrong byte in a secret produces an auth error days later that looks like something else entirely.

Our first pass used a dashboard .env export and it lied to us. Three secrets appeared to carry literal double quotes, and we nearly reproduced those quotes byte-for-byte in production. Pulling the same variables from the platform API showed no quotes. They were an export formatting artifact.

We generated a sha256 prefix, length and whitespace flags for every value and diffed that manifest against the destination's own JSON output. Two values genuinely were byte-sensitive: a multiline PEM key and a secret with a meaningful trailing newline. Exactly the ones a careless copy-paste destroys, and exactly the ones a hash comparison catches.

Restore into an empty schema

pg_restore --clean against a pre-provisioned schema died on dependency-ordered drops, complaining about multiple primary keys on one table. What worked: DROP SCHEMA public CASCADE, recreate it, then a plain pg_restore with no --clean. Verify against row counts captured before the suspend.

The db:prepare trap in Rails multi-database setups

When two logical databases live on one physical Postgres instance, db:prepare creates the first and then treats the second as already existing, so its schema never loads. The deploy goes green, then seeding crashes the first time it enqueues a job because no solid_queue tables exist.

Three traps sit inside the fix. Chaining db:prepare db:schema:load:queue silently no-ops, because rake invokes a task once per run and the prerequisite already ran. A production schema:load refuses to run without an explicit environment-check override. And if your host's redeploy replays a frozen config snapshot, a pre-deploy-based fix never executes at all.

What worked was SSHing into the running container and running the schema load directly, verifying with an actual SolidQueue::Job.count query returning 0 rather than an exception. We reverted the pre-deploy command back to plain db:prepare afterward, because a schema load is destructive and must never run against restored production data.

Threads do not survive SolidQueue's fork

We ship logs with a background flusher thread started once in an initializer. That initializer runs in the SolidQueue supervisor process. SolidQueue then forks its worker and dispatcher children, and threads do not survive fork. Each child inherited a handle pointing at a dead thread, the ||= never respawned it, and nothing ever flushed.

Logs still teed to stdout, so the host's log view looked completely normal. The only flush that ever fired was the inherited at_exit on process exit, dumping hundreds of buffered lines at once with ingestion-time timestamps. Signature: bursts of identical-timestamp events at restart moments, silence in between. Ours had been dead for days.

A migration is not done when traffic moves

Point-in-time recovery sat above our plan tier, so we built a nightly pg_dump to a private object-storage bucket. Then we actually restored from it into a scratch database on the same instance and compared row counts against live before trusting it.

One packaging trap: Debian's stock postgresql-client is pg_dump 15, and 15 hard-refuses to dump a Postgres 18 server. You need postgresql-client-18 from PGDG, and you must derive the Debian codename dynamically. Our Ruby base image moved to trixie underneath us, so a hardcoded codename would have broken the build.

We did not delete the old host until a clean week of monitoring said the new one was holding.

Full writeup with the cutover sequence and the rest of the detail: https://xreplyai.com/blog/render-to-railway-migration-guide

Our test stubbed the bug, so the bug passed

John Builds — Tue, 04 Aug 2026 18:14:59 +0000

A vendor API we integrate with sends a field called publicaly_available_post_id.

That is not a typo I introduced writing this post. That is the field name. It ships in their docs and it ships on the wire, missing the "l", and it has presumably been that way since whoever wrote the endpoint typed it.

Our code read publicly_available_post_id. Correct English. A field the vendor has never once sent.

That should have been caught immediately, and here is why it wasn't: the test stubbed the correctly-spelled field too.

I had written something like this:

stub_response(
  status: "PUBLISH_COMPLETE",
  publicly_available_post_id: "7391..."
)

and then asserted that our reader picked up the ID. It did. Green. The test passed for months.

What that test proved is that our reader agrees with our stub. Both were written by the same person on the same afternoon out of the same wrong assumption, so of course they agreed. The vendor was never in the room.

The failure surfaced somewhere else entirely. There was a fallback: if the post ID is missing, store the temporary upload handle instead. So the first post that ever completed publishing stored an upload handle where a permanent post ID belongs. Nothing errored. The record looked fine. The breakage appeared weeks later in a different subsystem, where the metrics fetcher asked for stats on an ID the vendor had no idea about and got back an error message about integers.

Three things I took from it.

Copy field names, never retype them. Every character of a vendor's wire format should arrive in your codebase via paste, from their reference response. The moment you type it from memory you have a second source of truth, and your test will loyally defend it.

A stub you wrote is not evidence about the vendor. It is evidence about you. If a test's fixture and the code under test share an author and an assumption, the test can only catch typos in the implementation, not errors in the belief. Somewhere in the suite there should be one real captured response from the actual API, warts and misspellings preserved.

Watch fallbacks that make an absent value look present. The || upload_handle fallback turned "we have no ID" into "here is an ID", which is how a parsing bug got laundered into a data integrity bug and shipped off for another team's code to discover.

The fix was three lines. Read the misspelled field first, keep the correct spelling as a fallback in case they ever fix it, and re-stub the test from a raw response captured off the wire.

My A/B test wasn't broken. My counter was.

John Builds — Mon, 03 Aug 2026 18:05:21 +0000

I ran a 50/50 homepage split for a couple of weeks. The arm counts came back 178 to 57.

That is not 50/50. So I did what you'd do: I went and stared at the randomizer. Read the middleware. Read the cookie logic. Wrote a script to call the assignment function ten thousand times and count the buckets. It came back 4,981 / 5,019, which is exactly what Math.random() < 0.5 is supposed to do, and left me with a working randomizer and a number that said otherwise.

The randomizer was fine. The counter was lying.

Here's what happened. I had one function doing two jobs:

function setVariant(arm) {
  gtag("set", { ab_variant: arm });          // must run on every page load
  gtag("event", "ab_variant_assigned", {...}); // should run ONCE per visitor
}

Those two calls look like they belong together. They do not. The set call attaches the arm as a sticky dimension to every event that follows it, so it has to repeat on every single page load or your later events lose the label. The event call records an exposure: one human entering the experiment. It should fire once.

I called that function from the root layout. Every page load, sitewide, fired both. So my "exposure" count was really a pageview count.

And then the part that actually fooled me: the two arms rendered through different layout trees, so they accumulated pageviews at different rates. If both arms had over-counted evenly I'd have seen 178 vs 174, shrugged, and moved on with a wrong-but-harmless denominator. Instead the uneven inflation produced a lopsided ratio, which is exactly the shape a broken randomizer makes. The bug disguised itself as a different bug.

The fix was to split the two operations and guard only the exposure one, keyed by arm value so a re-bucketed visitor counts once per arm instead of vanishing. If the guard's storage throws (Safari private mode does this), it returns "yes, count it". Over-counting one arm is recoverable, silently dropping it is not.

Three things I took from it:

set and event have opposite idempotency requirements. One must repeat, one must not. If they share a function, one of them is wrong. Mine had been wrong for weeks.

Mounting anything in a root layout makes it a per-pageview thing. That's the whole job of a root layout. Any one-shot event you put there (experiment assignment, activation, funnel entry) quietly becomes a tally of page loads instead.

A ratio that contradicts your randomizer is not evidence about your randomizer. It's evidence that one of the two is wrong, and the counter is the one nobody tests. I spent a day proving the coin was fair. Nobody had checked whether I was writing the results down correctly.

The conversion counts were fine, incidentally. Only the denominators were inflated, which means every conversion rate I'd computed was garbage while every number feeding it was correct. That is a fun way to lose two weeks of a test.

The 2.5-hour week: a posting system for developers who hate posting

John Builds — Wed, 29 Jul 2026 15:25:38 +0000

Most developers building a side project know they should be visible somewhere (X, LinkedIn, wherever their users are), and most quietly skip it, because context-switching out of code into "content" is miserable.

I fought this for months while building my SaaS. What stuck was making posting look like a build pipeline instead of a creative act:

Batch on Sunday (90 min). Write the whole week's posts in one sitting. Ideas come from the week's commits, bugs, and user conversations, so the material is already there.
Publish on a queue. Fixed slots, Tue/Thu/Sat. No decisions during the week.
Reply 10 minutes a day. Small comments in your niche compound faster than posts do.
Recycle monthly. Your best post from last month is new to most of this month's audience.

The mental shift: treat consistency as infrastructure. Cron beats willpower.

I ended up building this into my own product, XreplyAI, which plans and publishes across 15 platforms from one calendar: https://xreplyai.com?utm_source=devto&utm_medium=social&utm_campaign=edusales-2026-07-29