Studio notes

Notes from the studio, written as we find things

Brightwell publishes short notes on design systems, AI-assisted workflows, low-code trade-offs, and self-hosting decisions. These are working observations from client engagements and tool evaluation, not sponsored posts, and not a news feed. If a tool changes how we work, it shows up here with the reason.

Ask about your project See what we do
Fine graphite specimen drawing of a small stack of notes and a bench rule on bone paper
Bench plate — notes and rule

How we decide what to publish

We publish what we tested, and we correct what changes.

The notes

Nine notes from live engagements

Each note below is a working observation with the trade-off stated. Read them in any order — they do not stack into one plan.

  1. Design systems

    Why we recommend open-source design tools to procurement teams

    The argument for Penpot in an enterprise is not that it is free. It is that the file format is web-native and the platform can be self-hosted, which changes what happens at the end of a vendor relationship. Design files that live inside your own infrastructure do not become a migration project when a contract changes. Teams still choose proprietary tools for good reasons, usually ecosystem and plugin depth, and that is a legitimate trade.

  2. AI in documentation

    Long-context AI and the documentation problem

    Most documentation questions span a whole document, not a paragraph, which is where long-context assistants like Claude become genuinely useful rather than novel. The practical gain is in summarizing and cross-checking, not in generating final copy. We treat AI output in documentation work as a first pass that a person reviews, the same way we treat draft code.

  3. Editor tooling

    What changed when AI moved into the editor

    Cursor and similar editors put code generation, refactoring, and codebase chat inside the place where code is written, which changes review more than it changes typing speed. Developers start reviewing generated code the way they review a colleague's pull request: with suspicion and a diff. The governance question, what leaves the machine and what gets logged, has to be answered before adoption, not after.

  4. Low-code

    No-code, low-code, and the eighteen-month question

    Webflow and similar platforms are genuinely fast, and the decision to use them is usually right at the start and worth re-checking later. The question is what the site has to share with the product in eighteen months: components, data, a design system, or nothing. If the answer is nothing, no-code is a good deal. If the answer is a shared component library, plan the boundary now.

  5. Enterprise AI

    Where AI belongs in a Microsoft-heavy enterprise

    Microsoft Copilot is the assistant most enterprises will evaluate first because it sits inside Microsoft 365 and developer workflows they have already approved. That is an advantage and a limit: it is strongest where work happens inside Microsoft's apps. Teams with a mixed stack usually end up running more than one assistant, which raises the question of where the work product is stored.

  6. Delivery

    Communication tools shape delivery more than teams expect

    Slack is where a lot of decisions get made, and the difference between a team that ships and one that circles is often whether decisions get written down somewhere Slack is not. Our integration work always includes a rule about the decision record. It sounds administrative. It removes a recurring meeting from most projects.

  7. Self-hosting

    Self-hosting decisions, stated plainly

    Self-hosting is a commitment to running something, including updates, backups, and the person who gets paged. It is the right call when data residency, security review, or vendor independence requires it, and the wrong call when it is chosen for cost alone. We write the operational cost into the recommendation so nobody is surprised in month three.

  8. Physical products

    Physical products and the screen that comes after

    When a product has an enclosure or a manufactured part, the CAD work in Autodesk Fusion comes first and the interface design follows it. Teams that design the software first sometimes discover a physical constraint that invalidates a layout. It is a cheap mistake to avoid and an expensive one to discover during prototyping.

  9. Editorial rule

    How we decide what to publish here

    We publish a note when we have used a tool in a real engagement and learned something that changes a recommendation. We do not publish roundups of tools we have not deployed, and we do not take payment for coverage. If a piece of advice on this page stops being true, we would rather correct it than leave it up.

Where these notes come from

Notes are written on the bench, not at a desk in a press room.

Every note here grew out of a client engagement, a tool evaluation, or a decision the team had to make and live with. The photographs below are the studio's own working surfaces — the ones these recommendations are actually written for.

Bench

A desk under monitor glow

Over-the-shoulder view of a seated workspace under cool monitor glow

Where most of the documentation notes are drafted and revised.

Rack

An anodized wall, cabling loomed

Anodized equipment wall with cables dressed into a clean horizontal loom

The self-hosting and integration notes are tested against this rack.

Hands

A hand on a keyboard at rest

Macro view of a resting hand on a keyboard lit by a monitor edge

The editor and review notes come out of a screen the team actually works in.

Where to go next

Read the notes, then walk the rest of the studio

The notes above say how we think. These pages show what we ship and where the tooling sits in the working stack.

Platforms we use

The tooling stack behind every recommendation

Penpot, Webflow, Cursor, Claude, Copilot, Slack, and Autodesk Fusion — where each one earns its place and where it does not.

See what we use

How we work

What a Brightwell engagement actually looks like

The steps between the first conversation and the day a tool is running in your production workflow.

Read how a project runs

The rule we hold

A note is published only after the tool has run in a real engagement.

No roundups of tools we have not deployed, no coverage bought with a sponsorship, no claim we cannot point at an engagement and defend. The trade is slower publishing. What gets written down is what the studio has actually seen, which is what a reader deciding whether to hire us really needs from an insights page.

What that produces

  • Notes that change recommendations

    If we used a tool for a client and the result changed our advice, that change is what the note reports.

  • Facts a procurement team can check

    Self-hosting costs, file-format implications, and review overhead are named plainly so a reader can weigh them, not just trust a tagline.

  • Corrections when the advice ages out

    If a piece of advice here stops being true, we would rather rewrite it than leave it standing.

Talk to the studio

If a note here matches a decision on your desk, write to us.

Brightwell Trading Group works from Boston with teams selecting, integrating, and deploying design, development, and AI-assisted tooling into production. If you are weighing a platform move, a self-hosting decision, or a documentation workflow, tell us what you are comparing and we will say what we have seen.

Talk to the studio Read about the studio

Reach us

  • Studio Brightwell Trading Group
    745 Atlantic Avenue, Suite 410
    Boston, MA 02111
  • Phone +1 718 474 1511
  • Email [email protected]
  • Hours Monday to Friday, 9:00 AM – 6:00 PM