The Brightwell Trading Group studio seen from the doorway, desks leading back to a lit bay wall under morning light.

Brightwell Trading Group · Boston, MA

We bolt systems together, one bay at a time.

A computer systems and software design studio, organized around a small number of long engagements rather than a large number of short ones.

Systems design & software design engagement

Discovery, integration, and handoff on one named team.

The studio

A Boston studio built around one spine

Brightwell Trading Group is a computer systems and software design studio in Boston. We are organized around a small number of long engagements rather than a large number of short ones, which is why our process pages are specific about what we do not take on. What follows covers who we work with, how the studio is arranged, and the standards behind what we publish.

  • Constraint Systems design & architecture Most engagements start with a constraint problem rather than a design problem — a budget, a legacy dependency, or a deadline the current toolchain cannot absorb.
  • Surface Software design & design systems Interfaces, design systems, and the handoff work between them — built so the team that inherits the file can keep shipping without us in the room.
  • Deployment CI/CD and self-hosted tooling Pipelines, self-hosted runners, and the operational plumbing that keeps deployments predictable once a project leaves the studio.
  • Integration Platform selection & connector work Choosing the platforms that will actually be maintained and wiring them into the rest of the stack — the decisions that outlive the engagement.
  • AI assistance AI-assisted tooling in production Where AI-assisted tooling is genuinely useful in a production workflow, and where it belongs behind a review gate rather than in front of a customer.
  • Handoff Documentation & operational readiness The written record that lets a team run what we built after we leave — including the trade-offs we chose and the ones we deliberately skipped.

Our editorial standard

We only write about platforms we have deployed.

No sponsored roundups. No vendor referral fees. No recommendations for tools we have not run in a real workflow. When we get something wrong, we correct the page rather than quietly removing it — the record matters more than the polish.

Who we work with · How we are arranged

A small bench, and a named lead on every engagement.

Who we work with

Our clients range from startups building a first product to operations and marketing groups inside larger companies that need a system a non-developer can maintain. Some are engineering-led, some are not. The common thread is a decision that has to be defensible: a toolchain, an architecture, or a design system that other people will have to live with long after the engagement closes.

We are a good fit when the person who owns the decision will be in the room. We are a poor fit when a system needs to be delivered to a stakeholder nobody has met — that work usually belongs with a larger firm that can absorb the coordination cost.

How the studio is organized

Work runs in small teams with one named lead who stays on the engagement from discovery through handoff. We do not rotate staff mid-project to balance utilization, because the cost of that lands on the client. Specialists join for hardware, security review, or infrastructure work when those constraints appear, and they are named when they do — you will always know who is on the engagement and when that changes.

Boston, and why it shows up in the work

Our studio is in Boston, and a good share of our clients are in the region: hardware teams, research-adjacent companies, and established firms with systems old enough to have real integration problems. We run most work remotely and travel when a project benefits from it.

Being in one place with a client for a workshop does more than a month of calls in some engagements — usually at the point where the architecture is being decided, or where a team needs to agree on what to stop doing.

Boundaries

What we do not do — and why this page says so

We are not a staffing agency, we do not sell seats on a bench, and we do not resell platform licenses. We do not take engagements where the decision-maker is unavailable for the first month. We turn down work, and this page exists partly so that is not a surprise.

  • Not staffing

    If you need bodies at desks for a fixed term, a staffing partner will serve you better than a studio. We take the work when we own the outcome.

  • Not resellers

    We do not take vendor referral fees and we do not resell platform licenses. If we recommend a platform, it is because we deployed it, not because someone paid for the mention.

  • Not fully detached

    We pass on engagements where the decision-maker is unavailable for the first month. The first four weeks decide the architecture, and a decision made without the owner is a decision we will not quietly accept.

What we rule on

Platforms the studio has deployed, not platforms it has read about.

  • Selection: which toolchain will still be maintainable in two years, given the team that has to run it.
  • Integration: how platforms connect to what is already in the stack, including the parts nobody wants to touch.
  • Deployment: pipelines, self-hosted runners, and the operational detail that keeps releases boring.

What that produces

A system the team can keep running.

Every handoff carries a written record: the decisions we made, the trade-offs we accepted, the parts of the stack we deliberately did not touch, and the questions we would want answered if the same call came up again.

See what we do Compare the platforms we deploy

Getting to a first conversation

The first call is a scoping conversation, not a pitch.

Bring the problem, the systems involved, and any constraint you already know about. If it is a fit, we will describe a discovery phase. If it is not, we will say so — and in some cases point you toward a different kind of studio.

Ways to continue