Services
Services from strategy through engineering
We offer product strategy, UX/UI design, web and mobile engineering, custom software, and AI integration. Most clients start with one of these and end up using two or three together, because the boundaries between them are softer than the service list suggests.
Which one is your starting point?
Below is what each service covers and how to tell which is your starting point. Read the short version on the right, then jump to the chapter that matches the problem in front of you. If two of them look relevant, that is normal — most projects combine a strategy pass with design and build.
A useful first question is not which service to buy, but which decision you cannot make yet. Naming that decision usually points straight at the right place to begin, and it keeps the first engagement small enough to learn from.
Product strategy and technical discovery
Start here when the problem is clear but the order of work is not, or when nobody is sure what the current system can support.
Read the chapterUX research and UI design
Start here when people use the product but get stuck, or when the interface has grown faster than the flows behind it.
Read the chapterWeb and mobile engineering
Start here when the plan is settled and you need working software in production, on the web or in the app stores.
Read the chapterCustom software and AI integration
Start here when off-the-shelf tools no longer fit, or when you want models working against your own data inside the product.
Ask about your case
Where research leads
UX research and UI design
Research comes before screens. We talk to the people who'll use the product, watch how they work now, and map the flows that matter most. What comes out of that is usually a shorter list than the one you arrived with.
UI design then turns research into interfaces and a design system, with accessibility checked as part of the work rather than patched in later. This is also where we decide what not to build, which is often the more useful output — every screen you skip is one fewer thing to maintain.
Contact us about design workWhat each service answers
Each chapter below opens with the question that service is built to answer, then what the work actually involves and how to tell whether it applies to you.
Strategy first
Product strategy and technical discovery
Strategy work answers what to build and in what order. We interview users, review what you already have, and look at your constraints: team size, budget shape, deadlines that can't move. Technical discovery adds the engineering view, so the plan accounts for what's expensive to change later.
You leave with a prioritized roadmap and enough technical grounding to trust it. That matters because a roadmap nobody can defend in an engineering review does not survive its first sprint. Most engagements run strategy and discovery together rather than treating them as separate purchases.
A short discovery phase often costs less than a quarter of a rushed build, and it surfaces the constraint that would have derailed you — an integration nobody documented, a data model that cannot hold the new case, or a decision that needs a person who is not in the room yet.
Build and ship
Web application development
Our web work centers on Ruby on Rails and Hotwire, with JavaScript stacks when the project calls for them. That covers customer-facing apps, internal tools, and modernizing systems that have become costly to change.
We've found Rails lets a small team ship a real product quickly, and Hotwire keeps many apps from needing a separate front end at all. Fewer moving parts usually means a shorter path from an idea to something people can open in a browser and use.
Mobile app development
We design and build iOS, Android, and cross-platform React Native apps. The stack question is usually about shared versus platform-specific experience, not preference.
Shared core
React Native fits products with a shared core and a need to release to both stores quickly.
Single platform
Native fits when hardware features or single-platform performance dominate. We'll make the case for one and explain the cost of the other.
When off-the-shelf stops fitting
Custom software and legacy modernization
Sometimes the right answer is software that doesn't exist off the shelf. We build it, and we also rebuild what's already there when it's holding a business back.
Legacy modernization usually means moving high-value workflows off the old system piece by piece rather than a big-bang rewrite. Keeping the business running during the transition is a requirement, not a nice-to-have. In practice that means the old system and the new one share data for a while, and the cutover happens workflow by workflow.
It also means deciding what to leave behind. Some parts of a long-lived system are load-bearing and some are habit; separating the two is most of the work before any code moves.
Signs it is time to rebuild
Small changes take weeks. The person who understands the system has left. Support tickets repeat with the same root cause. Reporting requires an export and a spreadsheet. Any one of these is survivable; three together usually means the cost is now ongoing.
How the transition runs
We pick one workflow with real value, move it, and prove it in production before touching the next. Nothing gets big-bang replaced, and the old system stays available until the new one has carried the load for a full cycle.
Models inside real products
Generative AI integration
AI work here means connecting models to your data and designing the product around them. We build on OpenAI's API and comparable providers, and on Microsoft Azure for clients already in that ecosystem.
The interesting problems are almost always in the product layer: what the user sees, and what happens when the model is wrong. A summary a person cannot check is worse than no summary. A search result with no source is a liability. So we design the fallback, the citation, and the moment a human takes over as part of the feature, not as an afterthought.
If your data is not ready to be retrieved — no structure, no permissions, no clear owner — that is the first thing we fix, because a model pointed at an unorganized pile produces confident answers that nobody can defend.
Checkout and billing
Payments and commerce flows
Stripe shows up in a lot of what we build: subscriptions, marketplaces, checkout flows. Payment UX is where conversion is quietly won or lost, and it's worth treating as a design problem before it becomes an engineering one.
Renewals, failed payments, and refund paths deserve as much attention as the initial purchase screen. Most payment support load comes from the states after checkout, not from checkout itself.
If you're weighing build versus a hosted storefront, we'll tell you which is cheaper to run. Sometimes the honest answer is the hosted one you already have, with a smaller change to how it is configured.
Payment states worth designing first
One team, working the way yours already works
We can run the work or join a team you already have. Pairing with your engineers is common, and it leaves knowledge in the company rather than in a folder. Communication happens in the tools your team already uses, whether that's Slack, Linear, Jira, or GitHub.
How projects start
A first conversation usually settles three things: what you're trying to change, who makes decisions on your side, and what a useful first deliverable looks like. From there, some clients start with discovery, others go straight to design and build. You don't need a finished spec to reach out — a rough problem statement is enough.
Start that conversationWorking alongside your team
Pairing with your engineers is common, and it leaves knowledge in the company rather than in a folder. The goal is that when the engagement ends, your team can keep going without us. That shapes decisions throughout: we write for the people who stay, and we hand over context with the code.
Tools your team already uses
Communication happens where the work already lives — Slack, Linear, Jira, or GitHub. We do not ask a team to adopt a new tool to work with us, and we do not keep project knowledge somewhere only we can reach it.
See how we workQuestions we get before the first call
Short answers to the things people ask most often when they are deciding where to start. If your question is not here, write to us and we will answer it plainly.
Contact usDo we need a full spec before starting?
No. A clear problem statement and access to the people who'll use the product matter more than a finished document. We often help write the spec as part of discovery, which is a better use of the time.
Can you work with our existing engineering team?
Yes, and it's a common setup. We pair with in-house engineers so the knowledge stays with your team after the engagement. It also tends to speed up decision-making, since the people who know the system are in the room.
What's the difference between product strategy and technical discovery?
Strategy focuses on what to build and why, from the user and business side. Technical discovery adds the engineering view: what the current system can support, what's expensive to change, and what order of work keeps risk low. Most engagements do both together.
Do you only build with Ruby on Rails?
No. Rails and Hotwire are where we have the deepest track record, but we work in JavaScript stacks, and on native iOS, Android, and React Native for mobile. The stack should follow the product and the team, not the other way around.
Tell us what you are trying to change
One conversation is usually enough to work out where to start. Bring the problem as it stands, not a finished plan. We are in Boston, reachable Monday to Friday, 9:00 AM to 6:00 PM, at [email protected] or +1 617-411-6822.