thoughtbot · Boston, Massachusetts
A Boston product team you can actually meet
thoughtbot is a product design and software development consultancy. Senior people who stay on a project from start to finish, who can sit with your users in the morning and review code in the afternoon.
The shape of the firm
What kind of consultancy we are
We sit between a general software agency and a pure design studio. Product strategy, UX/UI design, and engineering are one process here. That matters most when the problem itself isn’t fully defined yet, and when the people doing the work are also the people asking the questions.
Clients often arrive after a build that went technically fine and commercially nowhere. Nobody wrote bad code. The product simply solved something the market didn’t need at the price it cost to run. Understanding why is usually the first piece of work.
So we start by reading the situation, not by proposing a stack. Sometimes the honest answer is a rebuild. Sometimes it’s a configuration change, a sharper scope, or a decision that was never made upstream. We say which one before the invoice, not after.
Our background
Years of web applications, with deep roots in Ruby on Rails and Hotwire. Alongside that: iOS, Android, and cross-platform React Native apps. That history shapes what we recommend — proven tools, small teams, and working software early enough to argue with.
Rails and Hotwire are still remarkable for how much honest product you get from a small team in a short window. They’re also not always the answer, and we’ll say so when a mobile-first product, a heavier data pipeline, or a hosted service fits the problem better.
Web applications
Rails, Hotwire, and modern front-end builds for products with real traffic and real edge cases.
Mobile products
Native iOS and Android, plus React Native when one codebase genuinely serves the roadmap.
Custom software
Internal tools and platform work where off-the-shelf software stops at the edge of your operation.
Design and engineering under one roof
Designers here work against real constraints, and engineers take part in user research. The combination is hard to fake and easy to notice in the output: interfaces that account for edge cases, and features that ship without three rounds of rework. It’s also why we can advise on tradeoffs honestly rather than defending a specialty.
How the pairing shows
Research notes land in the same tracker the engineers read. Design reviews happen with a running build in front of them, and code reviews happen with the product decisions in view. Fewer handoffs, fewer surprises at the demo.
What design brings
Flows and interfaces grounded in what users actually do, including the unhappy paths that usually get deferred. We wireframe in the browser when it’s faster to test a decision than to debate it.
What engineering brings
Features shipped in small, reviewable steps, with tests around the parts that carry the product. If a design would cost six weeks for a decision that isn’t made yet, you’ll hear it while it’s still cheap.
Where AI fits into our work
A model is a component, not a strategy. We build AI features on OpenAI’s API and comparable providers, and we work on Microsoft Azure for clients already inside that ecosystem. Our interest is in the product layer — what the user sees, how errors are handled, and where a person stays in the loop.
What we actually build
Features where AI removes a real step for a real user: summarizing a long thread, drafting a first version of a document, routing an inbound request to the right person, or flagging the unusual case among the ordinary ones.
How we handle errors
Every AI feature we ship has a visible fallback. When a model returns something uncertain, the product says so, offers a retry, and gives the user a path that doesn’t depend on the model at all.
Where humans stay
Any action with a real consequence — sending, charging, publishing, deleting — has a person in the loop unless you’ve decided otherwise on the record. That’s a product decision, not a technical one.
How we think about clients
We work best with teams that want a partner. That means one decision-maker on your side, honest constraints shared early, and a tolerance for being told something is a bad idea.
-
One decision-maker, one conversation
We need someone on your side who can say yes or no without a committee. When that person exists, decisions take days instead of quarters.
-
Constraints shared early
Budget, compliance load, integration reality — if we hear them in week one, we plan around them. If we hear them in month three, you pay for the rework.
-
Disagreement is part of the job
You’ll hear our view before the invoice arrives, not after. We’d rather argue about scope in a two-hour meeting than rebuild a feature six weeks from now.
-
Code you can take with you
You own the repository from day one. If we part ways, your team inherits a codebase with tests, documentation, and no mystery rooms.
Tools we live in
None of this is a pitch. It’s the environment most of our clients already share, and it’s what your team inherits when the engagement ends.
- Code & review
- GitHub for code, review, and CI/CD through Actions.
- Communication
- Slack for day-to-day, with enough shared hours for real-time decisions.
- Planning
- A tracker that fits the team, whether that’s Linear or Jira.
- Specs & research
- Notion tends to hold specs and research notes.
- Commerce
- Stripe is a frequent part of commerce and subscription work.
Where we work
We’re based in Boston and work with clients across the United States. Some collaboration happens on-site when it genuinely helps, particularly early discovery and workshops. Most of it happens in shared tools, with enough overlap for real-time decisions.
Geography matters less than whether we can get the right people in one conversation. If your team is spread across time zones, we’ll agree on the hours that matter and protect them.
What we don’t do
We don’t do staff augmentation at scale. We don’t take on projects where nobody on the client side can make a decision. We don’t promise outcomes that depend on factors we don’t control. And we don’t recommend custom software when a configured product would do the job.
Saying no early is cheaper for everyone. If your project is a fit, we’ll tell you and get moving. If it isn’t, we’ll say that too — and usually point you somewhere more useful than us.
A small team, close enough to know your product
If you’re weighing a new build, a rebuild, or an AI feature you’re not sure how to scope, the first step is a conversation. Bring the messy version of the problem — that’s the one that’s useful.