Reading Roundup: Name It Before You Fix It

Choosing the right problems, validating before you scale, and calling things what they actually are.

Hey there,

There’s a thread running through this week’s reading that I didn’t notice until I’d finished all four articles: every one of them is about being honest about what’s actually in front of you before you act on it. Whether that’s choosing which problems deserve AI, validating demand before building, reaching for the right Rails helper instead of the easy one, or just naming the pattern that Rails codebases have quietly adopted. The theme is the same. Look at what’s really there first.

Finding the Right Problems to Solve with AI
OmbuLabs on why the hardest part of AI isn’t building, it’s choosing what to build, and why automating a process that shouldn’t exist just makes bad outcomes faster.
https://www.ombulabs.ai/blog/finding-the-right-problems-to-solve-with-ai.html

From 0 Signal to 128 Cold Signups: Product Validation on a $2K Budget
Evil Martians walk through how they validated demand for an educational platform with sequenced analytics, A/B testing at 95% confidence, and a $2K Google Ads budget that produced 128 cold-traffic waitlist signups.
https://evilmartians.com/chronicles/from-0-signal-to-128-cold-signups-product-validation-on-2k-budget

Avoid html_safe with Tag Helpers, safe_join, and sanitize
Andy Croll on the three Rails tools that handle HTML escaping for you, and why calling html_safe on hand-built strings is a promise you’ll eventually break.
https://andycroll.com/ruby/alternatives-to-html-safe-in-rails/

The Rails Way in 2026
Arkency names the pattern they see across every Rails codebase they’re called in to fix: fat model, callback, service object, background job, with process state living on the Active Record row rather than beside it.
https://blog.arkency.com/the-rails-way-in-2026/

Bonus: CalendarJS
A free, MIT-licensed suite of JavaScript calendar components: date picker, scheduling calendar, timeline, availability selector, and recurrence engine. Framework-agnostic, keyboard-accessible, and themeable. Worth bookmarking if you ever need time-based UI.
https://calendarjs.com/

Quick notes and actionables

• The OmbuLabs article articulates something I keep seeing: teams reaching for AI before asking whether the work they’re automating is worth doing in the first place. The quote that stuck with me was the observation that AI is often being used to automate work that was essentially meaningless to begin with. Making a bad process faster doesn’t create value. The practical filter they suggest is simple: if this task disappeared tomorrow, would anyone outside the company notice? If not, AI won’t save it.

• The Evil Martians validation piece is a proper playbook, not just a case study: The sequencing is the interesting part. They added Plausible first for immediate traffic data, PostHog second for feature flags and A/B testing, and GA4 last specifically to close the loop with Google Ads optimisation. Each tool was added when it was needed, not installed upfront. They also set a rule: don’t touch the ad budget until roughly 15 conversions accumulate. When they doubled the spend, the conversion rate doubled too, which confirmed the foundation was working rather than just burning more money. The A/B test ran on cold traffic only, which is the part that matters. Warm audiences are too forgiving to give you honest signal.

• The html_safe article is short but it’s the kind of thing worth sending to your team: The mental model Andy lays out is clean. Need an HTML element? Use tag. Joining fragments? safe_join. Accepting rich text? sanitize. If none of those fit, you probably need a partial, not a string. The one that caught me was safe_join, which I’ve definitely underused. It’s Array#join with escaping built in, and it handles mixing safe HTML with unsafe text without you having to think about it. There are legitimate uses of html_safe (gem output that’s safe by construction, static strings), but the key question is always: could user input end up in this string?

• The Arkency article does something valuable by simply naming a pattern: Fat model, callback, service object, background job, process state on the Active Record row. That’s what they see across every Rails codebase they consult on. The observation about process state is particularly sharp: columns like last_reminder_email_sent_at and failed_payment_attempts aren’t properties of the entity. They’re checkpoints in a workflow that live on the entity table because there’s nowhere else for them to put them. Arkency isn’t arguing against this pattern in the post. They’re arguing that if you can’t describe what the Rails Way looks like today, you can’t have an honest conversation about when it serves you and when it doesn’t.

• CalendarJS looks like a solid option if you need calendar UI without the framework lock-in: It’s MIT-licensed, framework-agnostic, and covers the main calendar patterns: date picker, full scheduling grid, timeline, availability selector, and a recurrence engine. The headless mode means you can use the core logic with your own components and theme it with CSS variables. I liked that keyboard navigation and ARIA patterns are built in rather than bolted on. If you’re currently pulling in a React-specific calendar library for a Rails app with a sprinkle of JS, this might be worth a look.

From the week

Something I’ve been thinking about that isn’t a link, just an observation.

I sat through a meeting recently that ran 45 minutes over. No agenda going in, no actions coming out. Everyone left politely, and nothing changed. I’ve been in some version of that meeting for most of my career, and I think most people have. The fix isn’t complicated: agenda, decision, owner, deadline. Every meeting. Every time. If a meeting doesn’t need a decision, it probably doesn’t need to be a meeting. And if it does need a decision but nobody writes down who owns the outcome and when it’s due, that decision will evaporate by Thursday.

I’ve started being braver about saying that out loud in the room. Not in a confrontational way, just a simple “what’s the action here and who owns it?” before anyone leaves. It’s a small thing, but it’s changed the quality of my weeks more than any tool or framework.

Plenty to chew on this week. If you end up building something off the back of any of these, I want to hear about it. P.S. You can see everything I’ve been reading at dcyoung.dev/bookmarks.