Our Work
Product challenges we take on
Our work spans web applications, mobile products, custom software, and AI features, usually for companies that have outgrown their first version of something. This page describes the kinds of problems we take on and how we approach them. If a scenario here sounds like yours, that is the useful signal.
What this page is for
We work across product strategy, design systems, and engineering for web, mobile, custom software, and AI projects. The chapters below are the shapes of work we end up in most often. Read them the way you would read a mechanic describing symptoms: the closer the description matches your situation, the more relevant our experience is to you.
Where we can name a client in public, we do. Where we cannot, we describe the work instead. Either way, a conversation goes further than a slide about ourselves.
Web applications
SaaS products, internal platforms, and customer-facing tools built and maintained in Rails and Hotwire.
Mobile products
React Native and native iOS and Android work where the interface is part of what customers pay for.
Custom software
Internal tools that replace tangled spreadsheets and the manual steps between them.
AI features and UX/UI
AI integration with a real review step, and design work that engineers can build from without translation.
From spreadsheet to internal tool
A recurring pattern: a process that started in one spreadsheet now runs across five, with three people copy-pasting between them. The work is part discovery, part software.
We map what actually happens, find where the errors come from, then build a tool around the real workflow instead of an idealized one. Change management matters as much as the code here, because people have to keep doing their jobs while it happens.
How we sequence it
- Firstwalk the floor with the people who use the sheets daily and write down where they slow down.
- Thentrace the errors to their source — usually one hand-off point nobody owns.
- Aftership the tool alongside the old process and switch over department by department.
The interesting part is almost never the code
It is what happens when a migration goes sideways, when a payment fails, or when an AI answer is wrong. Those moments decide whether a product earns a second year of investment. So we design for them from the start rather than bolting them on after launch.
Taking a web app from MVP to something you can grow
First versions are built to learn, and second versions are built to last. We often inherit a Rails app that shipped fast and now needs structure: better data models, background jobs that do not fall over, and a test suite that catches regressions. Hotwire usually gets us there without introducing a separate front-end codebase.
The measure of success is how confidently your team can change the product six months after we leave.
What we typically change
- Data model
- Split overloaded tables, name things after the domain, and add the constraints the database should have enforced from day one.
- Background work
- Move slow jobs out of the request cycle so reports, imports, and notifications stop timing out under load.
- Test coverage
- Cover the paths you change most so refactors stop being a negotiation about risk.
- Front end
- Keep the markup, CSS, and interaction close to Rails instead of maintaining a second application for the interface.
Mobile apps where the interface is the product
Some mobile work is about reaching a store. Some is about the experience itself, and that is where design and engineering have to sit together.
We have built React Native apps where one team ships to iOS and Android on the same schedule, and native apps where platform behavior was the differentiator. The decision gets made with real product examples, not by default.
Cross-platform
Shared code, one release calendar, and a shared design language across both stores.
Platform-native
Native navigation, gestures, and performance where the platform is the reason customers chose the app.
Design handoff
A component library both teams use, so a new screen does not need a design debate each time.
Release path
Beta channels, staged rollouts, and a plan for what happens when a build lands badly.
Payments and subscription flows
Stripe-based flows come up constantly in SaaS and commerce work. A subscription screen looks simple until you account for failed payments, upgrades mid-cycle, and what a customer sees when a charge declines. We treat those paths as core product, because they are where revenue quietly leaks.
Declines and retries
The screen a customer sees when a card fails decides whether they fix it or leave. We design that state on purpose, with clear language and one obvious next action.
Upgrades mid-cycle
Proration, plan changes, seats added in the middle of a billing period — each one is a product decision, not a billing edge case to patch later.
One review, not three
Design, backend, and billing logic get reviewed together rather than sequentially, so the flow holds up end to end before it reaches customers.
AI features that survive contact with users
The interesting part of an AI project is rarely the model call. It is what happens when the output is wrong, how a user corrects it, and whether anyone trusts the result twice.
We build features on OpenAI's API and comparable providers, with a human review step wherever the stakes justify it.
Summarization
Long threads, transcripts, and documents condensed into something a person can actually read and act on in a few minutes.
Document search
Answers grounded in your own material, with a link back to the source so people can check the claim instead of taking it on faith.
Workflow automation
Steps that used to need a person copy-pasting between tools, handled end to end with a review queue for anything unusual.
Correction paths
A fast, obvious way to fix a wrong answer, and a record of the fix so the same mistake gets less likely over time.
Enterprise systems that need to move
Microsoft Azure shows up in modernization work with corporate clients, usually because the organization is already invested in Microsoft tooling. The project is less about novelty and more about fitting the new system into an existing landscape of identity, data, and compliance.
We have found ecosystem fit predicts success better than technical elegance. That is not glamorous, but it is how these projects actually get approved and shipped.
What we check before proposing anything
- Where identity lives today, and who can change access without breaking an audit.
- Which data is authoritative, which is duplicated, and which nobody trusts.
- What the review process can absorb in a quarter without stalling the roadmap.
- Which teams have to be consulted before a decision is final.
Design systems that engineers use
A design system is only worth building if it removes decisions rather than adding meetings. We build systems tied to real components, documented where your team already works, and reviewed as the product changes.
Notion is often where that documentation lives; GitHub holds the code side. The test is whether a new screen can be built next quarter without a design debate.
Built as real code in the product repository, not as a separate artboard library that drifts out of date.
Written where the team already reads and works, with a short example for each pattern and its limits.
The system gets revised as the product changes, so it stays useful instead of turning into a museum.
When we tell clients not to build
Some of the most useful work we do is negative. A custom platform may be the wrong answer when a configured product would do. An AI feature may be premature when the underlying data is not in order. A rewrite may be avoidable when the real problem is one bad integration.
Saying so early saves more than any code we would write in the same period, and it means the recommendations we do make carry weight.
A note on methods and tools
We work in GitHub, with pull requests and CI/CD automation through Actions, and in whatever tracker fits the team, whether that is Linear for a lean setup or Jira for something larger.
AI coding assistance speeds up the routine parts of engineering without replacing review. A method is worth keeping only if it makes the product better or the team faster.
Questions we get before a first call
Can you show case studies with client names?
We only reference clients publicly where we have permission, so some work stays general here. We are happy to walk through relevant examples in a call, including the parts that went sideways.
Do you take on projects that need a full rewrite?
Occasionally, but it is a last resort. Most legacy problems are better solved by moving high-value workflows off the old system step by step. We will make the case for a rewrite only when the alternative costs more.
What size projects do you usually work on?
Small enough that a cross-functional team makes sense, large enough that the decision matters. A first mobile release, a platform migration, a payments rebuild. We are a poor fit for staff-augmentation at scale.
If a scenario here sounds like yours
Tell us what you are working on and we will say honestly whether it fits what we do well. You can reach us at thoughtbot in Boston, Monday to Friday, 9:00 AM to 6:00 PM, or start with the pages that explain our process and services.