Build phase
Working software, early and often
Build runs with the systems design as the reference. You see working software early and often, so integration problems surface while they are cheap to fix rather than at launch.
How we work
We bolt systems together, one bay at a time.
A design and development studio in Boston. We choose the tooling, integrate it into your workflow, and stay until it runs in production.
What happens next
What happens after you get in touch
Brightwell runs engagements in phases, and each phase ends with something you can read or run. You can stop between phases. This page describes the rhythm so there are no surprises about what we ask for, who has to be involved on your side, and when a decision is due.
Phase one
Discovery and constraints
Discovery is short and its output is written. We interview the people who own the system, review what exists, and produce a constraint list: hardware limits, data handling rules, vendor commitments, and the decisions that cannot be reversed cheaply. You get a recommended toolchain and a named list of risky assumptions. If we cannot produce that list, the project is not ready to scope, and we will say so.
Prototyping
Prototyping and wireframing
Prototypes exist to answer a question, not to look finished. We build low-fidelity wireframes first to settle structure, then a prototype at the fidelity needed for the decision at hand. For a data-heavy product that means states and edge cases early, because those are what break an implementation. You review in the tool, and comments are the review record.
Design system
Component library and design-system work
Once the structure holds, we build the components that will carry the product. Tokens for color, type, and spacing; components with named states; usage rules for the cases the component should not cover. If a design system already exists, we extend it rather than starting a competing one. This is the phase where a design decision stops being a preference and becomes a rule.
Handoff
Handoff
Handoff is a deliverable, not a moment. Specs, tokens, and component behavior travel with the file using inspection workflows and naming that matches the codebase, so an engineer can read a design without a meeting. We agree the naming convention with whoever writes the code, before the build starts. Teams that skip this step usually rebuild the convention later, badly.
Three rules we hold to
Every phase ends with something you can read or run.
A deployment nobody on your team can perform is not finished work.
The rule for CI/CD and deployment
Where the work lands
Build, integration, and deployment
The last two phases run in reviewable increments with the systems design as the reference. Integration with what you already own happens here, including low-code and AI-assisted steps agreed during discovery.
Integration
The systems you already own
Existing systems come into the build here, along with any low-code or AI-assisted step agreed during discovery. The rule for AI in the workflow, including what still requires human review, is applied now rather than documented later.
CI/CD and deployment
The same way on a laptop and a server
Deployment is set up so it runs the same way on a laptop and on the server, with the pipeline configurable per environment. Self-hosted tooling is stood up here with the runbook written alongside it. We hand over admin access and a documented rollback path.
Reading the engagement
What you sign off, and what it produces
What we rule on
- Naming convention
- Agreed with whoever writes the code, before the build starts, so the file and the codebase speak the same language.
- Component states
- Every component ships with its named states and its usage rules, including the cases the component should not cover.
- AI in the workflow
- What the model may do and what still requires human review, decided during discovery and applied in the build phase.
What it produces
- A readable design
- Specs, tokens, and component behavior travel with the file, so an engineer can work from the design without booking a meeting.
- A rule, not a preference
- Once a component is built and documented, design decisions stay settled instead of being re-litigated every sprint.
- A deployment you can run
- Admin access handed over with a documented rollback path, so your team is not dependent on us to ship a change.
What we ask you to bring
Bring the tools you already use
Bring the tools you already use, the constraints you already know about, and any vendor commitments that cannot be broken. Bring the person who can approve a direction. Do not prepare a formal brief unless you want to; a description of the problem and a list of the systems involved is enough to start discovery.
- One decision-maker, available during the first month.
- One person who will own the system after we leave.
- Someone from security or compliance if the project touches either.
Missing one of those roles is the most common reason a timeline slips, and it is the one cause we cannot design around.
Timeline expectations
- Discovery
- Typically one to two weeks for a scoped engagement.
- Prototyping and design system
- Depends on the number of components and the review cycle on your side.
- Build and deployment
- Varies with integration count. We give a range before each phase starts, not a single date that assumes nothing goes wrong.
Where a hard launch date exists, say it in the first call so scope can be shaped around it.
Honest scope
When a project should not start yet
If the decision-maker is unavailable, if the constraints are still being negotiated, or if the team has not agreed what “done” means, starting a build wastes money. We would rather run discovery and stop than take a build phase we know will be reworked.
That has cost us work. It is still the right call.
Questions we get
Before you get in touch
Three answers that come up on nearly every first call.
Can we run only the discovery phase?
Yes. Discovery is priced and scoped on its own, and it ends with a written constraint list and a recommended toolchain. You can take that output to another vendor, or stop there.
Do you work on-site in Boston?
We are based in Boston and run most work remotely, with on-site sessions when a project has hardware, a workshop, or a launch that benefits from being in one room.
Who approves design decisions on our side?
One named decision-maker. We agree who that is before the first phase starts, and we do not proceed on an unanswered question.
The next step
Start with discovery and decide from there.
Tell us the problem, the systems involved, and the people who can approve a direction. We will say whether the project is ready to scope.
Brightwell Trading Group, 745 Atlantic Avenue, Suite 410, Boston, MA 02111 · Monday to Friday, 9:00 AM – 6:00 PM