Read the existing system
We review current code, infrastructure and tooling where it exists, and note the parts that will resist change before we plan around them.
How we work with product teams
An engagement with us usually starts with a conversation about a decision, not a proposal document. From there the shape depends on your situation, but the way we run the work stays fairly consistent. Here is what happens, who is involved, and what we expect from the people we work with.
The first conversation
This call is short on slides and long on questions. We ask what you are trying to change, who the product is for, and what is blocking you right now. Nobody needs a deck prepared.
-
What we listen for
Who on your side can approve a change of direction, and how quickly that decision travels. Delivery slows down far more often from unclear approval than from unclear code.
-
Honest fit check
If we do not think we are the right partner for what you described, we will say so and suggest what might fit better. There is no sales sequence either way.
-
Who joins from your side
Two or three people who know the product works better than a large stakeholder audience. Everyone else can read the notes afterwards.
-
What you leave with
A written recap of what we heard, the parts that still need answers, and a plain recommendation on whether discovery makes sense next.
Discovery is a deliverable, not a pitch. Clients who stop after it still leave with a plan they can hand to any team.
Technical discovery
Discovery is where we look at the system you have, the problem you are solving, and the constraints around both. It closes with a written plan that carries priorities and rough sequencing, not a slide tour.
Talk to the people
Interviews with users or internal stakeholders, whichever gets us closest to how the product is actually used today.
Set priorities
We agree on what has to be true first, what can wait, and what we would cut if the budget moved under our feet.
Sequence the work
A rough order of iterations, sized so the first one is small enough to start without a long approval cycle.
Who is on the team
A typical engagement is a small cross-functional team. You get named people who stay on the project rather than a rotating cast, because coordination overhead is real and does not show up on an invoice until it is too late.
Role
What they own
When they are on the engagement
-
Product designer
Interface design, user research, and the flow decisions that shape what gets built.
From discovery onward, through every iteration.
-
One or two engineers
Web, mobile, custom software, and AI integration work, plus the tests and review habits that keep it stable.
From the first build iteration to handoff.
-
Engagement lead
Accountable for the overall shape of the work, the plan, and keeping your decisions visible to the team.
Throughout, and the person you call first.
-
Strategist
Framing the problem, scoping the first phase, and turning interviews into priorities.
During discovery and planning, then steps back.
-
Your engineers
We pair with your team when you have one, so the work continues at full speed once we are gone.
Any time after the first iteration, as much or as little as you want.
Iterations, not phases
Design and development run together in short cycles, with working software at the end of each one. You will see progress in GitHub, in a shared tracker, and in running builds rather than in slide decks.
This is also how we handle AI features. Model behavior is hard to predict on paper, and a small experiment usually teaches more than a long plan. The point of the rhythm is to be able to change course while it is still cheap.
Every iteration ends with the same three things: something your team can open and use, a short written note on what changed and why, and a re-planned next cycle based on what we learned.
Short cycles keep the cost of changing direction low. When something looks wrong in week two, it is a conversation, not a renegotiation.
Communication and tools
We work inside the tools your team already uses, so there is one place to look for anything. Our rule is boring on purpose: decisions get written down, and nobody has to attend a meeting to find out what changed.
Slack for the day to day
One shared channel per engagement for quick questions, plus your internal channels when you would rather keep the thread in house.
GitHub for code and review
Pull requests, review comments and a readable commit history. If you have your own repositories, we work in them from the start.
A tracker that fits the size
Linear for a lean setup, Jira where a larger organization already lives there. Notion holds specs and research notes if you do not have a home for them yet.
Meetings we do keep
- A short check-in at the start of each iteration to agree on what ships.
- A demo at the end, with the running build rather than a status report.
- A working session whenever a decision needs more than a message thread.
Most engagements run across the United States from our base in Boston, Massachusetts. We overlap enough hours each day to make decisions together, and we are on-site when it genuinely helps rather than on a fixed schedule.
What we need from you
Projects go badly when these arrive late, and there is no good substitute for them three months in.
- One decision maker
- Someone who can approve a change of direction and can spare a few hours a week for the work, not a weekly status audience.
- Access to users
- Customers or internal users we can talk to, or the willingness to let us go find them. Research with real users beats internal guessing.
- Honest constraints
- The budget you actually have, the deadline that cannot move, and the internal politics we should know about before we plan around them.
- A yes or a no, quickly
- Approval that takes three weeks costs more than most technical debt. We would rather hear no early than yes slowly.
How we measure progress
Working software, in short. We write our measures down at the start of an engagement so both sides are looking at the same thing, and we revisit them at every review. Vanity metrics do not survive the first one.
-
Can your team change the product without us?
We look at whether your engineers can pick up the codebase and ship a change the week after we leave. If that answer is no, the handoff needs more work before the engagement ends.
-
Is the thing we built actually being used?
Adoption shows up in the product, not in the plan. We track the flows the work was meant to improve and say plainly when the numbers are flat.
-
Do the choices still look right in three months?
Architecture and interface decisions get revisited against what the product became, not only against what we assumed during discovery.
When the engagement ends
Ideally you do not need us anymore. We plan for handoff from the beginning, pair with your engineers if you have them, and document the parts that would otherwise live in one person’s head.
Some clients keep us on for a small retainer after launch; plenty do not. Either way, the deliverable includes your team’s ability to move forward.
See our work
Questions we get asked
If your situation is not here, ask us directly. Answering awkward questions early is cheaper than discovering the mismatch in week six.
Set up a first conversationHow long does a typical engagement last?
Technical discovery is usually measured in weeks. Design and build engagements often run for several months, since that is what it takes to ship something real with a small team. We would rather propose a shorter first phase and extend it than commit to a long timeline upfront.
Do you work remotely?
Yes, and we work with clients across the United States. We are based in Boston and can be on-site when it genuinely helps, but most collaboration happens in shared tools. What matters is that we overlap enough hours to make decisions together.
Can we start with a small piece of work?
That is a common way to begin. Discovery is often the first phase on its own, or a single high-value feature. It lets both sides find out how working together actually feels before committing further.
What happens if the scope changes mid-project?
It usually does. We re-plan at the start of each iteration, so changes get absorbed there rather than turning into a renegotiation. If something has to be cut, we will be explicit about what it costs and what it is worth.
Which kinds of work can an engagement cover?
Product strategy, UX and UI design, web and mobile engineering, custom software, and AI integration. Many engagements combine two or three of those in the same team, which is why the first conversation focuses on the decision you are trying to make rather than on a service list.
Start with the decision in front of you
Tell us what you are trying to change and what is in the way. We will tell you whether technical discovery is the right next step, what it would cover, and when it does not make sense to bring us in at all. You can also read how we approach specific engagements on our insights page.
Boston, Massachusetts · [email protected] · Monday to Friday, 9:00 AM to 6:00 PM