Ran Craycraft

Building the next chapter of thoughtbot

2026-10-07T00:00:00Z

The situation

thoughtbot has built software for clients for more than twenty years, and it has earned a strong reputation. The market around it changed quickly. Clients were asking different questions, AI was changing what code costs to produce, and an established firm needed new ways to grow and to prove its value.

The task was to develop new opportunities while keeping sales, staffing, delivery, and financial performance connected. That meant looking at how we were organized alongside how we positioned ourselves and what we offered.

What I did

Reshaped the organization

I created the Americas and Fusion team structure, so each region could operate and price for its own market, and I oversaw three reorganizations as the business changed. I also established the Delivery discipline, to make sure clients receive what they signed up for and to strengthen accountability across engagements.

Focused the market strategy

I led a focus on regulated industries, including healthcare, fintech, and insurance, where experienced judgment matters as much as speed. I helped develop new enterprise relationships and closed some of thoughtbot's largest deals.

Developed new offerings

I designed a subscription maintenance program to support clients after the initial build and to create recurring revenue for the business. I also helped launch an AI and Product Innovation practice.

Created space to experiment

I created Space Station to organize work between client engagements, along with an experiment framework. The aim was to give available capacity a purpose and a way to test ideas, share what we learned, and produce useful work. I took part too, building a series of tools for my own team.

Wildebeest, a studio for products, platforms, and experiments

2026-10-06T00:00:00Z

The situation

After helping North Kingdom launch in the US, I wanted to build a studio of my own.

What I did

I co-founded Wildebeest and ran it as Managing Partner for nine years. We built products, platforms, and experimental experiences for clients including Google, YouTube, Disney, and GM.

Why Leave Astoria, a neighborhood network with more than 10,000 members

2026-10-06T00:00:00Z

What I did

I founded Why Leave Astoria, a neighborhood social network that grew to more than 10,000 members. We brought people together through events and charitable activities, and worked with local businesses on deals and loyalty programs.

New digital experiences for NBC, from Heroes to the project that became Hulu

2026-10-06T00:00:00Z

The situation

Television networks were just starting to figure out what the internet meant for them. Shows were still made for a living room, and the audience was moving to screens of every size.

What I did

I started at NBC as an intern and worked my way up to editor, shooter, and producer. From there I moved into new digital ventures and experiences. That included companion platforms for Heroes, fantasy football shows, virtual-world productions, and the skunkworks project that became Hulu.

Launching new ventures and growing established products at AOL

2026-10-06T00:00:00Z

The situation

AOL was reinventing itself as a media company, launching new properties while running some of the best-known entertainment brands on the web. I joined to help with both, first by starting something new and then by leading products that millions of people already used.

What I did

Starting from zero with AOL Industry

I helped launch AOL Industry and establish partnerships with trade publications across defense, energy, and government. The partnerships were built around specialized content and advertising.

Growing what already existed

I later became General Manager of AOL Entertainment, responsible for a portfolio that included Moviefone, AOL TV, Cambio, and AOL Music, with a $40M P&L and a 70-person organization.

Bringing North Kingdom to the United States

2026-10-06T00:00:00Z

The situation

North Kingdom had built its reputation in Sweden and wanted a home in the United States.

What I did

As Founding Managing Director, I helped launch North Kingdom’s US operation.

Helping stabilize the organization behind the Ruby ecosystem

2026-10-05T00:00:00Z

The situation

Ruby Central supports the infrastructure and community that Ruby developers depend on every day. When I became President of the Board in January 2026, the organization was in a period of financial distress.

What I did

As President, I helped rebuild sponsor support and reshape governance and funding, working with fellow board members and the people who sustain the organization.

Qualifier, moving a sales lead forward with one emoji

2026-10-05T00:00:00Z

New opportunities arrive in a Slack channel. Qualifying one can take three or four emails, sometimes a video call. What shouldn't take any work is the paperwork that comes after, where someone opens the CRM and types in the same details by hand. I wanted that part to take one emoji.

React with a checkmark to an inbound opportunity and Qualifier finds the deal and shows you, privately, exactly what it would change. The stage, name, project types, value and description, along with the deal's fit score. Click Yes and it saves those changes, moves the deal to Qualification and replies in the thread with every change, before and after. Then it posts a short brief on each contact, so those first emails start from what we already know.

Mention it in the thread to ask about the company or the people, and it answers with sources and saves the answer on the deal for whoever picks it up next.

Guardrails first

It started as "move the deal when someone reacts." That turned out to change deals too easily, so it grew a confirmation step.

Nothing changes until someone clicks Yes.
Only the first Yes counts, so a deal is never updated twice.
Deals past qualification are never touched.
Answering a question never edits a deal.
It never opens LinkedIn pages, since LinkedIn doesn't allow it.

I think any tool that edits sales data should ask first and explain itself after.

What I'm watching

Whether what it writes is close enough to what a person would write that we stop editing it, and whether the contact briefs change who we reach out to first.

Produce pickups, movie nights, and a cleanup that’s still going

2026-10-04T00:00:00Z

The situation

When the pandemic arrived, the things that held our neighborhood together stopped. People couldn't get to the store safely, and there was no easy way to see each other. Ladera Heights also sits at the intersection of three jurisdictions, which leaves gaps in who takes care of what.

What I did

Fresh produce, picked up from my driveway

I organized a neighborhood produce pickup to help residents, including seniors, get farm-fresh food safely. They pulled up, opened the trunk, and I loaded a box of produce.

Sixteen weeks of neighborhood movie nights

I produced a weekly drive-in movie series during the pandemic, giving neighbors a way to enjoy an evening together while keeping their distance.

A monthly cleanup

I started a monthly cleanup to fill the gaps in maintenance and to bring neighbors together around a shared responsibility.

What changed

The cleanup is still going six years later. What started as a way to cover for three jurisdictions became a regular reason for neighbors to meet.

Meeting Prep, a brief waiting before every sales call

2026-10-01T00:00:00Z

Good sales calls start with ten minutes of homework. Who is this person, what does their company do, have we talked before, and is there an open deal. Most of us do that homework in a rush, or skip it.

Meeting Prep does it for you. Connect your Google Calendar once, and before every one-off meeting with someone outside thoughtbot it books a private prep block with a brief inside. The brief opens with the links you'll want first and whether this is really a first call. Then it covers the people, their company, your history in the CRM, the engagement so far and a plan for the call.

Written for the moment you read it

I read my brief when the prep block starts, thirty minutes before the call, and almost never earlier. So the brief is written once when the meeting is booked, then again just before the prep block starts. It's current when you open it and never changes while you're reading.

If you already make your own prep blocks, it writes into yours instead of adding a second one. Delete a block and it stays deleted.

Fewer no-shows

Most of my sales meetings come in through Calendly, and too many of them used to be no-shows, even with Calendly's own reminders turned on. So Meeting Prep also sends a Slack reminder the evening before and the morning of any meeting where nobody on the other side has accepted. Each one comes with a ready-to-send email to confirm or reschedule. Nothing goes to anyone until you hit send.

That small addition has greatly reduced our no-shows.

Accuracy first

A brief with one wrong fact is worse than no brief. Facts only count when both the name and the company match, so a namesake's career never ends up in front of you. A second pass checks every claim against its sources before you see it.

The question I'm asking is whether the brief is good enough that you stop doing your own research, and which part you'd still check by hand.

A 1989 jukebox for my gym

2026-09-27T00:00:00Z

When I was a kid, the best part of going to Pizza Hut was the tabletop jukebox. You flipped through the title cards, found a song, and pressed the code. For me that meant power ballads and hair metal, Warrant, Poison, Bon Jovi and Whitesnake.

I wanted that in my gym. So I built one with Lovable and set it up as a kiosk on an iPad, where anyone can walk up and pick a song.

It works like the real thing. Songs sit on cream title cards, ten to a page, each with a selection code like A1 or B7. Flip the pages, tap a title, and it joins the queue. Up next shows what's coming and how long it'll run. There's even a mechanical click when you press a selection.

The music lives on the device. I load my own files, it reads the artist, title, year and album art from the tags, and everything plays offline. Settings sit behind a PIN, so guests can pick songs but can't change the setup. From there I can set the volume, choose a short gap or a crossfade between songs, and keep the screen awake.

Always on random

It's always on random, and some days it plays from morning to night. Every time a song comes on, it takes me back to being a kid in a booth at Pizza Hut.

Can a phone tell where a sugar packet landed?

2026-09-26T00:00:00Z

Pocket Cornhole started in a bar, when I noticed my phone on its kickstand looked a lot like a cornhole board. The idea was simple. Put a phone on the table, toss a sugar packet at it, and let the phone keep score. The phone is the board, and the packet is the bag.

The game is easy to picture. The hard part is getting the phone to notice. It needs to know that a packet landed, where it came to rest, and whether it slid off the edge.

The problem

Phone screens are designed to read fingers. A paper packet full of sugar is not a finger, so the first question had nothing to do with game design. Could the phone feel the packet at all?

What worked

Wrapping the packet in foil. With foil around it, the phone reads the landing through the touchscreen, including where the packet stops and whether it slides away.

How I tested it

Before building any of the game, I built bare test screens that did nothing except report what they detected. No scoring, no sound, no design. Rough tools made it quick to try one idea after another, and they kept me focused on the one question that mattered.

I think that's the right order for most ideas. Prove the riskiest part with the roughest tool you can, then make it nice.

Try it

Pocket Cornhole runs in the browser, so anyone can open it on a phone. Play it or read the code.

Pipeline Health, a grade for the sales pipeline that matches how it feels

2026-09-22T00:00:00Z

Every sales leader has looked at a pipeline and had a feeling about it. I wanted a number that agreed with the feeling when the feeling was right, and argued with it when it wasn't.

Pipeline Health puts a bar under the toolbar on any deals view in our CRM. It gives a letter grade, then shows how deal count, fit, value, stage spread, freshness and client signals compare with the team's own history. Click it and you get the reasons, the odds of reaching budget, and an Improve tab that lists specific deals to work on and how much each step would help.

Critical but helpful

I wanted it to be honest about what it takes to at least hit budget, based on how we've actually performed, without scaring anyone. The point is to show where to focus, so every grade comes with the specific deals that would move it.

It isn't generous about everything, though. A pipeline full of stale deals is never healthy, however big it looks.

The first grade was wrong

The first version averaged five separate grades, and it graded my own team's pipeline far lower than it felt. So I checked it against what had actually happened. The pipeline was on track for a fairly typical month. The grade was counting the same shortfall twice and leaning on measures that had never been validated.

I rebuilt it around a forecast. The grade now asks how much revenue this pipeline has historically turned into, compared with the budget for the month it lands in. On budget is an A. An A also needs a healthy pipeline underneath, so weak areas and stale deals pull the grade down even when the forecast looks fine. Today our teams sit at an A- and an A, which matches how the pipeline feels.

Honest about its limits

The forecast is fitted on a short history, and for one team the fit is weak. The panel says so instead of hiding it. The real test is simple. Check the forecast against the month when it arrives, and tell me how far off it was.

It uses no AI and sends nothing anywhere. Everything is scored in the browser, and the tone of client emails comes from plain lists of phrases anyone can read.

Is it AI? Looking for evidence instead of guessing

2026-09-17T00:00:00Z

People ask me all the time whether a site or a product was built with AI. Most detectors answer with a guess about writing style. I wanted something that looks for evidence you can point at.

Is it AI? checks the page you're on and answers in one word, AI, Human or Mixed. Behind that word is everything it found. Agent instruction files served by the site, builder badges, generator metadata, content credentials on images, configuration left in source maps, and commit trailers in a linked repository.

Showing the work

Every finding says what it is and how much it's worth. Direct evidence is kept apart from a signature that merely suggests. The stack counts too. A site on the newest framework releases with stock photos looks like what AI builders produce by default. A site with years of accumulated marketing tools looks like neither.

Age counts as well. A page published before ChatGPT made AI writing common is evidence on its own.

Verdicts can be wrong, so they can be argued with. You can correct one on the spot, and the correction stays in your browser.

Written by people, flagged as AI

The humbling moment came early. Several of thoughtbot's own blog posts, written by people years ago, read as AI because they used words detectors associate with models. That's the problem with judging style. People wrote that way first.

I capped how much vocabulary could count, and now the things you can point at always outweigh writing habits.

Tools aren't authors

The honest limit is that evidence of a tool isn't evidence of authorship. An agent file shows an AI coding tool was used on the project. It doesn't show that the tool wrote the page you're reading, and the wording says so throughout. Whether that distinction survives contact with real readers is the thing I most want to find out.

Like Grandma Made, a cookbook of my grandmother’s recipes

2026-09-15T00:00:00Z

My grandmother, Ruth Lavon Craycraft, was happiest with plates to set and people to welcome. Her table was always beautiful. The placemats were straight, the napkins were folded just so, and the chairs sat exactly two inches from the table. When I was small I told her she was the best cook this side of the Mississippi. She would giggle and brush it off.

She never wrote a cookbook. She kept recipe cards taped to the inside of her kitchen cabinets, cards she didn’t need to read but kept anyway. Those cards, and what my family remembered about how she used them, became Like Grandma Made.

A list of ingredients wasn’t the point. I wanted a book that felt like sitting at her table, so that anyone in the family could open it and cook something the way she did.

A recipe is really a person

Look at the table of contents and you meet half of her world. Aunt Doris’s Cornbread. Ma Thompson’s Chicken & Noodles. Pap’s Ricotta Blueberry Pancakes. Uncle Teddy’s Spaghetti. Mrs. Milam’s Deviled Eggs. Fred’s Red Dressing. She swapped recipes with her sisters, clipped them from newspapers, and collected them from church kitchens and the women at the golf course. What made them hers was how she made them and who she made them for.

So I kept the names. A recipe titled with a person tells you where it came from before you read a word of it.

The table of contents reads like a guest list.

The notes hold the stories

Every recipe ends with a short note, set in a dotted box like something tucked into a recipe card. That’s where her habits live, the things no recipe card ever said.

When she cooked eggs for kids, she stirred in a few chunks of Velveeta. On New Year’s Day she hid a clean dime in the cabbage for one lucky person to find. Fred’s, one of her favorite local spots, eventually sold its salad dressing at Kroger, and she still made her own. The white bean soup came from her close friend Ruth Davis, who worked at the Hamburger Inn, where my grandparents liked to have lunch. Cheese soup was what she made when I wasn’t feeling well. And the chili was the dish she liked me to make for her.

Granny’s Lucky Cabbage, and the dime.

The recipes themselves are written so they work. She cooked in Appalachia in a time when fresh produce wasn’t always easy to find, so the cooking is simple and honest about it. Each recipe gives how many it serves and how long it takes, steps grouped the way you’d actually cook them, and the details that matter. Soak the potatoes. Brown the chops first. Trust the texture of the cornbread batter.

Every recipe gets a spread, the recipe on the left and the dish on the right.

Designed like her table

The cover is red gingham, the tablecloth every one of these dishes belongs on, with the title on a cream panel framed like a recipe card. Inside, the type is a warm, bookish serif with red for titles and headings, the same two colors all the way through.

The book is organized like a day of her cooking. Morning & Baking, Everyday Suppers, Soups & Slow Pots, From the Garden & the Pantry, Potluck & Gatherings, Sweet Things. Each section opens with a line drawing in red ink and a short line that sets the mood. Everyday Suppers is “for kind people and a full table.” Potluck & Gatherings is “for tables that filled themselves.” Sweet Things just says “there’s always room.”

The six section openers.

Every dish is illustrated the same way, in warm kitchen light on a checked cloth with a wooden spoon nearby, so the whole book feels like one kitchen. They look like the food she actually served, not food styled for a magazine.

Ma Thompson’s Banana Bread, Mashed Potatoes, and Aunt Mary’s Fudge.

How it ends

The book opens with two short essays, one about her table and one about how she cooked. It closes with “How It Was Done,” a page about her life beside a portrait of her at her kitchen table. She was born in 1927 near South Portsmouth, Kentucky. She waited tables at her Uncle Teddy’s restaurant, loved her Cincinnati Reds, and once made two holes-in-one on her favorite golf course. She never thought she was a very good cook.

How It Was Done.

After that come a few blank pages headed “It’s your turn.” Grandma found recipes she loved, made them her own, and shared them with the people she cared about. The book asks the next person to do the same.

She didn’t let many people help in her kitchen, and we were the exceptions. She taught us to peel, dice, fry and bake, then to plate, serve, clear the table and make people feel welcome. As she got older, she let us cook for her. This book is how we keep cooking for each other.

Most of the book came from my own memories. I did a lot of cooking with her, and my sister helped with one of them.

Delivery Copilot, an AI assistant that stays beside the work

2026-09-12T00:00:00Z

Our internal operations app, Hub, already had an AI copilot for delivery work. It lived on its own page, which meant leaving the project you were looking at to ask about it.

Delivery Copilot is a second home for the same copilot. It docks in Chrome's side panel and follows you around Hub, so it stays beside the record instead of taking over the page.

Three rules

It adds a home screen for each project with five suggested actions, and at most one proactive card about the record in front of you. The cards follow three rules.

Silence is the default. If nothing crosses a threshold, there's no card.
Every card shows its evidence. The numbers behind it and where they came from.
Nothing happens without a person. Choosing a task opens Hub's own ticket form, filled in and waiting for someone to click save.

I think every AI assistant at work should follow some version of these.

Measuring before guessing

Early on, answers felt slow. Before optimizing anything I measured, and found that Hub writes the whole answer and sends it once at the end. No client can be faster than that. So instead of a single spinner, the panel now says which of four stages it's in, which made the wait feel far shorter.

Built to be deleted

This was always scaffolding. I built it outside Hub because that was the fastest way to work out what the panel should be. The finish line is moving the good parts into Hub and deleting the extension, and that work is underway now.

I wrote porting notes for the team that are blunt about the cost. One rule duplicates something Hub already does. Four things that look like moving code across are really new builds. That's how a week becomes a month, and I'd rather say so before anyone commits to the week.

thoughtbot analytics, one useful suggestion for every page

2026-09-04T00:00:00Z

We use TWIPLA for analytics on thoughtbot.com because it respects our visitors' privacy. I'm glad we do. Its interface is also tough to navigate, and our search data lives somewhere else entirely, in Google Search Console. Answering a simple question about one page meant two tools and a lot of clicking.

I wanted the numbers on the page itself. Open any page on thoughtbot.com and a side panel answers two questions. What is happening here, and what is the single most valuable thing to improve? It combines Search Console, TWIPLA and a look at the page itself into one verdict and at most three suggestions.

Weighted by who's searching

Before any suggestion is made, the searches get filtered. Searches for our own name go, since that person already found us, along with noise and anything with very little traffic. What's left is weighted by who is searching rather than how many. A search from someone likely to hire us outranks a much bigger generic one.

Suggestions come from plain rules instead of a model. Each one either has evidence or stays quiet, and each carries a confidence, so a weak idea doesn't get shown.

No sample numbers, ever

Both data sources are live. When one isn't connected, the panel says so instead of showing placeholder figures. A tool that shows plausible fake numbers is worse than one that shows nothing.

The honest limit today is the company facts behind the advice. They need marketing sign-off before anyone copies them into a page. The plumbing is real and the data is real. The facts underneath are still being checked.

Handbook Helper, a better way to read our company handbook

2026-09-02T00:00:00Z

thoughtbot's handbook is one of the best things about working here. It explains how we make decisions, what we expect of each other and why. It was also hard to read inside our internal app, with long lines across the whole screen and no way to tell a policy from a guide.

Handbook Helper adds a reading layer. A path through the introduction for someone new, search that only looks at the handbook, categories, and a comfortable reading column. Its icon is an open book with a smiley face, in the spirit of Hamburger Helper, in thoughtbot red. Turn it off and the handbook is exactly as it was.

Policies and guides

Every page now says which one it is. Policies get a red badge and guides get a gray one, because the point of red is that it's the exception. The answer comes from the handbook itself wherever it says so.

That came from a mistake. An earlier version used its own rule to decide what counted as a policy, and it filed real policies under guides. Second-guessing someone else's document was the bug.

Reuse over rebuild

The index is the handbook's own table of contents, read from the page, so it can't drift from the real thing. Search uses the existing endpoint and answers instantly from page titles while full text catches up.

I also took something out. A hand-picked "key pages" section felt helpful, but it was my judgment rather than data, and it buried everything it didn't pick.

A reader, not an author

A tool for reading should author nothing. New pages still go to the handbook, where everyone can see and change them.

Hub Helper, small fixes for the reports we read every week

2026-08-31T00:00:00Z

Every week our delivery leads read the same two reports, utilization and project delivery, to get ready for our weekly Client Success Check-in. Both reports had the data. Neither made it easy to see what needed attention.

Hub Helper is a set of quality-of-life fixes on top of those pages. Sortable columns, quick date ranges, filters, a difference column with a color band down each row, and totals folded into the headers.

On the delivery report, a Weekly Review button turns a handful of checked projects into something ready for the check-in, with each project's open tickets listed by name. Notes and tickets can be written right from the review, so the meeting prep and the follow-up happen in the same place.

Small details that matter

Rounded numbers decide the color. Two people both showing -5% always land in the same band, even if the raw numbers differ slightly.
Context matters. Internal investment projects used to be marked down for having no client. thoughtbot is the client there, so now they aren't.
The thresholds are guesses, and I say so. The amber and red lines sit at the top of one file. If they don't match how people actually read the numbers, that's the most useful feedback I can get.

A good constraint

I can't change the app underneath, so every fix has to live in the layer on top. I like that constraint. It forces the question of what really needs to change in the product versus what just needed a better view.

The other lesson kept proving itself. Get the real page before fixing anything. Guessing at markup cost me several rounds every time.

Pocket Cornhole, a bar game played on your phone

2026-08-27T00:00:00Z

I was sitting in a bar on a Friday night, getting ready to build a real set of cornhole boards the next morning, when I noticed my phone sitting on its kickstand. It looked a lot like a cornhole board. My girlfriend threw a sugar packet onto it, and the rest was history.

Pocket Cornhole turns your phone into the board. Lay it flat on a table, toss a sugar packet at it, and the screen works out where the packet landed. In the hole is three points, on the board is one, off the edge is nothing. Play on your own or head to head across a table.

The trick is foil

The phone reads the landing through its touchscreen, and a bare paper packet is often too light to register. Wrap it in foil and it works. That one line of instructions took more testing than anything else in the game.

Telling a throw from everything else

Most of the code has nothing to do with scoring. It's about ignoring things that aren't throws. A hand reaching in, the phone's own buzz, a knock on the table, someone picking a packet back up. There's a setting for how steady your table is, which is really a setting for how suspicious the game should be.

The only question that matters

It's a bar game that fits in your pocket, so the only thing worth measuring is whether anyone plays a second round. Starting a game and finishing one are counted separately, which keeps the answer honest.

Experiments, a home for what thoughtbot people build

2026-08-24T00:00:00Z

The first thing I built wasn't a tool. It was a place to put tools.

People at thoughtbot were building useful things on their own, and almost none of it traveled. A great prompt stayed in one person's notes. An extension that saved someone an hour a week never reached the person sitting next to them in Slack.

I'd already created Space Station to organize work between client engagements, along with an experiment framework to help people turn ideas into tangible work and shared learning. That work needed a home. So I built Experiments, an internal catalog where every experiment gets a card, a page, an install button and a few honest numbers.

Today it holds 29 experiments, and dozens of people at thoughtbot are using them.

How it works

It's a plain static site with no framework and no build step. Each experiment is a folder with a short description, a picture and a download. Adding one means adding a folder, and a GitHub Action does the rest. It lists the folders, publishes the downloads, and announces new versions in our #experiments channel.

The only thing that needs a database is what a static file can't know. Visits, hearts, which version each person is running, and which features get used inside each tool.

Later I added a lighter way in. Most people will never build a Chrome extension, and the catalog shouldn't need them to. Now anyone can share a prompt, a skill or a Loom through a short form, and it opens the pull request for them.

What I learned

Ask questions people will answer. Each card used to ask "Should this become real software?" Almost nobody answered. Replacing it with a simple like got real signal.
Count people, not builds. The first version counted every version anyone had ever run, so one person testing fourteen builds looked like fourteen users. Now it counts the version each person last reported.
Close doors you don't need open. I removed comments. A public form posting to a public endpoint invites spam, and feedback works better as a button into Slack anyway.

The catalog is an experiment too. If the numbers on it are the wrong numbers, I'd rather hear that than work around it.

Client Onboarding, learning how a client works before kickoff

2026-08-17T00:00:00Z

Most of what makes a consulting engagement go well or badly is style rather than skill. How involved the client wants to be in day-to-day decisions. How they feel about AI on their project. Where they land when speed and quality pull against each other. None of that shows up in a statement of work, so we usually learn it in week three.

Client Onboarding asks up front. It's a seven-step wizard written in plain language, covering what made past collaborations work, what didn't, the working style that fits, and what a consultant needs to meet to be a good match.

So far it has delighted clients, mostly because it helps us get the right people on the job the first time.

Small design choices that mattered

No middle option. The sliders have four stops instead of five, because nearly everyone picked the middle when there was one.
A bias review on the wording. Options run from neutral to permissive, delivery choices are symmetric, and the list of priorities shuffles for each person so the first option doesn't win by default.
One submission at the end. Saving every step would have meant messy partial rows and more cost for very little benefit.

Answers land in a spreadsheet rather than a database, so the people doing the matching can read, sort and argue with them without logging into anything new. Each response gets a short AI-written summary of what a consultant should do to succeed with that client.

A kindness to both sides

Asking about working style turns out to be good for everyone. Clients get to say what they need without it feeling like a complaint, and our team walks in already knowing.

Schedule Helper, seeing who's free at a glance

2026-08-13T00:00:00Z

Staffing a consultancy comes down to one question asked many times a week. Who is free, and when? Our schedule page had the answer, spread across a layout that made it hard to see.

Schedule Helper redraws it as a compact timeline with one row per person. Bars are colored by type of booking rather than by project, so client work, internal projects and investment time never look alike. A red line marks today, and zoom goes from one week to three months. The filters we use most, like department, team, region and skills, sit in a toolbar. Clicking any stretch of free time opens the booking form with the person and dates already filled in.

Our director of development finds it incredibly useful now.

Being honest about a guess

The underlying data marks a day as booked without saying which project booked it. When several projects shared a week, each one claimed the whole week, so a two-day assignment looked full time. Now the week is divided between them, and because which days is a guess, those bars get a faint hatch and show the real allocation on hover. When the two disagree, the allocation is the number to trust.

Knowing when to retreat

I spent four versions trying to make the whole page scroll with the dates pinned to the top. Each attempt introduced a new bug, and the last one painted a white sheet over everything. I rolled all four back and rebuilt from the last good version. Knowing when to stop digging is part of the job.

Blog Helper, an editor that knows our style guide

2026-08-10T00:00:00Z

thoughtbot has published on its blog for a long time, and we have editorial guidelines to match. The trouble with guidelines is that they live in a document, and the draft lives somewhere else.

Blog Helper puts them side by side. Open a draft in our internal editor and a panel appears next to it. It scores the piece, works through the guidelines as a checklist, suggests links to older posts with the anchor text already picked, and can write a first draft from rough notes. Titles, teasers and tags each get their own pass.

I use it most for two things. It finds the right older posts to link to, and it helps me take a few snippets of an idea and turn them into a fully thought-out post much faster than I could on my own.

Rules people can argue with

The guidelines are plain markdown files inside the extension, rather than a prompt buried in code. That's deliberate. Rules should be readable and arguable by the people they apply to, and changing one should mean editing a sentence.

The same goes for the small decisions. Internal links follow a simple rule of about one for every 300 words, at least two and never more than six, because a paragraph full of links reads like a directory. A post gets four tags, because three kept being treated as "done" in three different places.

What I learned

The most expensive bugs in this build were edits that silently did nothing. A change lands in the wrong file, everything still works, and the feature is just quietly missing. Now I check for the result after every edit instead of trusting that it applied.

The question I'm watching is which passes people run twice. A review that gets run once and never again is a review nobody trusted.

Meeting Helper, logging client meetings without thinking about it

2026-08-06T00:00:00Z

Before this, our client meetings were never logged in the CRM. Everyone agreed it mattered, and nobody did it. I wanted to see what would happen if nobody had to.

Meeting Helper checks Google Calendar every ten minutes for meetings that have ended, matches the outside attendees to CRM contacts by email address, and logs the meeting on each one with the real title, time and description. If a contact has an open deal, the meeting goes on the deal's timeline too.

It skips what should be skipped. All-day events, canceled meetings, internal meetings and recurring ones, since a standing weekly is rarely a one-off sales call.

Right after the call

Automatic logging was the reason I built it. The part that matters most to me now is what happens the moment a call ends, when my thoughts on what to do next are at their freshest.

Inside a Google Meet call, the extension works out which opportunity the call belongs to. When I leave, a single card appears on Meet's own "You left the meeting" screen with the note already focused. I write the follow-up right there and save it to our CRM, to our internal platform Hub, or both. The AI meeting notes follow once they're ready, so the notes and the next steps end up in the same place.

That card went through many versions. Chips, logos, a separate card and colored borders were all tried and dropped as too busy. One composer and two checkboxes won.

What I learned

Trust, but read back. The CRM often replies "success" while quietly ignoring fields. Now every change is read back to confirm it actually took.
Unmatched attendees are a finding. When the extension can't match someone, that's a gap in the CRM, which is arguably more useful to know than the meeting itself.
Count what it does on its own. A tool that works in the background gets no clicks, so clicks can't tell you whether it's working. This one keeps its own count.

Freshsales for thoughtbot, our CRM inside the inbox

2026-08-03T00:00:00Z

Business development happens in email. Our CRM lives in another tab. Every time I wanted to know whether someone was already a contact, or what was happening on their deal, I had to leave the conversation to find out.

This extension adds a CRM sidebar to Gmail. On a thread it shows who's already in Freshsales, the related deal, a recommended next step and recent activity, with a box to add a note. If there's no deal yet, creating one takes a couple of clicks.

Five people a week

The part that has paid off most is the smallest. The inbox view has a Suggestions tab with five people worth reconnecting with each week. It never refills. Five is a list you can finish, and a feed that tops itself up is one you learn to ignore.

It's been reigniting conversations with past clients, people who spent money with us before and simply hadn't heard from us in a while. That's some of the best business there is, and it was sitting in our CRM the whole time.

The part most likely to be wrong

When a thread includes several companies, an AI pass works out which one is actually the client rather than assuming it's the sender's domain. That's the guess most likely to miss, so it's the one I ask people to report.

What I learned

Bump the version every time. It sat on the same version number for weeks, and nobody could tell which build they had installed.
Look at the real page before guessing. The CSV exporter that lives inside this extension got better every time I worked from the actual page structure instead of my assumptions about it.
Never let a tool move what's already closed. Closed deals no longer show stage buttons at all.

Hub Search, Cmd+K for our internal app

2026-07-28T00:00:00Z

Search is the front door to any internal tool. Ours, inside our operations app Hub, was hard to use. The interface made filters awkward, and the AI search was buried where most people never found it.

I didn't want to rebuild search. I wanted to know whether a better front end alone could fix it, without touching anything underneath.

Hub Search adds a Cmd+K palette anywhere in Hub. Results appear as you type across pages, projects, opportunities, teammates, clients, the handbook and the blog, re-ranked in the browser rather than shown in the order the server returns them.

Ranking with context

Where you are counts. If you're on a project, other projects rank a little higher, since that's usually what you're after. The boost is small enough that it only breaks ties and never lifts a weaker match over a better one. The page you're already on drops out of its own results.

An Explain ranking setting shows the score behind each result. It's the fastest way for someone to tell me the ranking is wrong.

Nothing new to trust

There's no backend and no new database. It uses the session you're already signed into, and nothing you search leaves your browser. Hub holds client and people data, so I think that's the right default for anything built on top of it.

What I learned

Show something before you finish thinking. The palette felt slow because it waited for saved settings to load. Drawing first and reading settings second made it feel instant.
Read the source before guessing. Three rounds of guessing at the question-answering endpoint failed. Reading the app's own code settled it in one.

The open question is whether a better front end is enough, or whether the search underneath needs to change too. Usage will tell.

Rainbow Tabs, sorting browser tabs by color

2026-07-25T00:00:00Z

I've been known to have nearly 70 tabs open in a single window. At that point the tab bar stops helping you find anything. So I decided to at least make them look good.

Rainbow Tabs sorts them. Click the toolbar icon and the tabs in your window reorder red through violet by the main color of each site's icon. Tab groups move as a block, placed by their group color, with the tabs inside sorted too. Pinned tabs stay put. Click again to undo.

Deciding what color an icon is

That turned out to be the whole project. Average the pixels in a colorful icon and you get gray, because opposite colors cancel out. So colors are sorted into hue buckets, weighted by how saturated they are, and the heaviest bucket wins.

Notification badges get ignored, since a red unread dot is usually louder than the logo it sits on. Pale icons have to clear a higher bar before they count as colored. Whites go first and darks go last, like bookends.

Some cases are still unresolved. Google's multicolor logo measures as a vivid blue, and I'd rather it sat with the whites. I haven't won that argument with the math yet.

A toy, and that's fine

Not every experiment needs to save anyone time. This one is a toy, so the only question is whether anyone clicks it twice. I do. My 70 tabs are a rainbow now, and it's so pretty.

Email Zenmaster, AI help in Gmail that still sounds like me

2026-07-23T00:00:00Z

I write a lot of email, and some days I'd like to be more blunt than I should be. Email Zenmaster helps me say the right thing anyway. It lets me write quickly without coming across as terse.

It adds four things to Gmail, and each one only runs when I click it.

A sparkle beside the subject field suggests subject lines.
Selecting text brings up Zenify, which rewrites the selection in place with an Undo.
A right-click review reads the whole thread and flags up to three real issues, starting with anything I'm repeating and any question I haven't answered.
A right-click draft writes a reply based on the thread above.

Writing like a person

I have opinions about how email should read. Clear, kind, direct, and free of the habits that make writing sound generated. So the interesting part is what it won't do.

Everything it writes is checked against a list of AI tells borrowed from my Is it AI? experiment. Stock openers, "not just X" contrasts, words like delve, and punctuation habits I've banned from my own writing. If the model slips, it gets one corrected pass with the problem named.

It also leaves good writing alone. Early versions rewrote everything they touched. Now, if a passage is already fine, Zenify says there's nothing to change and keeps its hands off. That turned out to matter as much as the rewrites.

Measured by Undo

The number I watch is how often a rewrite gets undone. A tool that changes your words is only useful if the change survives the next ten seconds.

Building tools for my own team

2026-07-21T00:00:00Z

Every tool in this series started the same way. I saw a problem, imagined a solution, and looked for the smallest version of it I could build quickly. That's how I've always worked. What's changed is how small and how quick that version can be.

For the past year a lot of people at thoughtbot have been experimenting with AI on their own. Someone builds a prompt that saves them an hour. Someone else builds a script that fixes an annoying report. Most of it lives in a DM or a personal folder, and the next person starts over.

I wanted to change that, so I started building in the open. Every week I pick something that slows my team down, build a small tool for it, and put it in front of the people it's meant for. Sales, delivery, writing, scheduling, and a couple of toys.

It's about ambition

That's the title of a memo I wrote to the company. None of this is about replacing people or making thoughtbot smaller. AI should raise our ambition. I want us to be 90% better, and by 2027 I want us to be able to tell clients the best new way to build software, because we helped figure it out.

The only way I know to find out what better looks like is to build things, watch whether people use them, and be honest when they don't.

How I run these

Every experiment has the same few rules.

It solves a problem someone on the team actually has.
It asks one honest question, like "does anyone click this twice?" or "is the brief good enough that you stop doing your own research?"
It counts anonymously whether people use it, so the answer comes from behavior rather than politeness.
It changes nothing until a person says yes.

How I build them

Most of these start as a conversation with ChatGPT, where I work out what the problem really is and what the smallest useful version would look like. Then I build it with Claude Code.

Over a couple of months, the experiments got more ambitious. The first, Email Zenmaster, helps rewrite a few sentences in Gmail. The most recent, Qualifier, is a Slack app that turns a checkmark on an inbound opportunity into an enriched, qualified deal in our CRM, with a brief on the people involved. Each one taught me something that made the next one possible.

Where it stands

Our internal catalog now holds 29 experiments, and dozens of people at thoughtbot are using them. Some are in daily use. Some are probably the wrong shape and will be thrown away. Both outcomes are useful.

The posts in this series are in the order I built them, so you can watch them grow. Each one covers a single experiment, what it does, why I built it, and what it taught me.

The bigger goal is convergence. A year of everyone diverging was the right start. Now the work is turning individual experiments into something the whole company can build on, so that when one person raises the bar, everyone else starts from there.