Try Beamline on your app in 30 minutes

Use one settings screen to decide whether Beamline fits your app. Save a real record, reload it, make a save fail, use the screen on a phone, then change its style and add a field. The free sample includes the Settings block and its controls; this trial needs no Beamline account or purchase.

Allow about 30 minutes of active work. Package downloads, your agent's availability and an unfamiliar backend can take longer. Start in a development branch of a React 19 app that already runs, with its package manager and browser automation available. Use a development record you are allowed to change.

Give your coding agent this prompt

Paste the whole prompt into Claude Code, Codex or Cursor at the root of your app. It tells the agent what to build, what to test and what evidence to leave. The same prompt covers Next.js App Router and Vite.

Give Beamline's free sample a real trial in this app. Build and verify one settings screen at /settings (or reuse
our existing settings route). Work on a development branch, preserve existing work, and do the task yourself.

1. Install the public free sample, with no account or key:

npx --yes https://mcp.beamline.io/cli.tgz install settings alert spinner --release https://mcp.beamline.io/releases/sample/0.2.0-rc.33/release.json --preset prism --fonts inter

Read the installed API before writing the screen:

npx --yes --package=https://mcp.beamline.io/cli.tgz beamline-find --app . --capabilities
npx --yes --package=https://mcp.beamline.io/cli.tgz beamline-find --app . --id settings alert spinner

Use the installed @beamline/settings block and its real props. Import the generated stylesheet once and use one
UIRoot with the installed Prism preset. In Next.js App Router keep stateful form code in a client component and
import the global stylesheet in the layout. In Vite import it in the entry file. Remove starter page-centering
styles when they conflict with a full-page layout. Do not use a demo fixture or simulator as the data source.

2. Inspect and reuse this app's data layer, record shape, validation and save operation. Load the actual settings,
map them to SettingsValues, and await the real save before reporting success. Check HTTP error responses and throw
an Error on failure so the Settings block keeps the draft and offers Retry. Keep the Settings instance mounted
while saving; a failed request must not replace its draft with the last saved values.

If there is no backend, create a tiny local development API: GET /api/settings and PATCH /api/settings backed by a
JSON file on disk (a Next.js route handler, or a small Node server behind Vite's /api proxy). Validate input on the
server and write it before returning success. Label this local API clearly in the report; it is real local storage,
not a production service. Do not substitute localStorage, a timer, an always-successful promise or in-memory data.

Use the record's name, email and time zone. Show loading while fetching, a useful empty state when no record exists
with a way to create it, and a load-error state with Retry. Keep test/failure controls out of the customer screen.

3. Run and record this checklist in EVALUATION.md, with actual commands, observations and screenshot paths:
- Change Name, save, read the stored record through the API, then refresh the page. The new value must remain.
- Make one real backend save fail before it writes (use a local/dev failure control or stop the local API). The
  stored record must stay unchanged, the edited value must remain visible, an error must show, and Retry must save
  that same draft once the API recovers. Do not mock the browser's response to stand in for this check.
- Exercise a delayed initial load, no-record response, and failed initial load followed by Retry. Verify each state
  in the browser, not only in source. Restore the development record afterwards.
- At 390 px wide, edit and save without clipped fields, an unreachable save bar, or horizontal page scrolling.
- With the keyboard alone, reach and edit a field, reach Save, and activate it. Check visible focus and that focus
  remains usable after saving. Use semantic labels; do not rely only on a screenshot or a passing build.

4. Restyle the working screen through the Beamline style CLI. Create trial.style.json from Prism, with a custom
id trial/calm, radiusScale 1.5, motionScale 0.8, brand #168f85 and Archivo for body and display type. Use these commands
from the app, replacing ROOT_FILE with the actual file containing your UIRoot:

npx --yes https://mcp.beamline.io/cli.tgz install settings --release https://mcp.beamline.io/releases/sample/0.2.0-rc.33/release.json --preset prism --fonts inter,archivo
npx --yes https://mcp.beamline.io/cli.tgz style create trial.style.json --base prism --name "Trial calm" --id trial/calm
npx --yes https://mcp.beamline.io/cli.tgz style parameter trial.style.json radiusScale 1.5
npx --yes https://mcp.beamline.io/cli.tgz style parameter trial.style.json motionScale 0.8
npx --yes https://mcp.beamline.io/cli.tgz style parameter trial.style.json brand '#168f85'
npx --yes https://mcp.beamline.io/cli.tgz style set trial.style.json --token --pui-font-body --value '"Archivo Variable", "Archivo", ui-sans-serif, system-ui, sans-serif'
npx --yes https://mcp.beamline.io/cli.tgz style set trial.style.json --token --pui-font-display --value '"Archivo Variable", "Archivo", ui-sans-serif, system-ui, sans-serif'
npx --yes https://mcp.beamline.io/cli.tgz style validate trial.style.json --release https://mcp.beamline.io/releases/sample/0.2.0-rc.33/release.json
npx --yes https://mcp.beamline.io/cli.tgz style add trial.style.json --app . --root-file ROOT_FILE

Verify the custom preset and computed radius, motion scale, brand and font in the browser. Keep reduced-motion
support. Do not restyle by editing component internals, and do not reset the stored record.

5. Add an optional Job title field using Settings profileFields with id jobTitle, stored as profile.jobTitle.
Wire it through the UI, request mapping, server validation (string, at most 80 characters), storage and read-back.
Preserve every existing field. Save a value, refresh, and verify both the visible value and the API record. Verify
that invalid input sent directly to the API is rejected without changing storage.

Repeat the save, failure/retry, phone and keyboard checks after both changes. Run the app's production build.
Capture the final screen at 1512x982 and 390x844 in evaluation/desktop.png and evaluation/phone.png. Leave a concise
EVALUATION.md with PASS/FAIL/BLOCKED for every check, framework and package versions, the API/storage actually used,
before/after style observations, the added field's read-back, elapsed time and exact rerun steps. Report anything
not exercised; do not call a build or a toast proof of persistence. Fix problems you can resolve and rerun the
affected checks. Stop and name a missing permission or incompatible prerequisite rather than claiming a pass.

The command pins the free release used for this evaluation. If that archived version is no longer available, use the current no-account install line on the Settings code page, and record the new version. Keep the CLI and release compatible; do not replace a failed free install with a paid package or sign-in flow.

What a pass looks like

Install

Pass: The app uses the free Settings package, its stylesheet and an installed preset. No Beamline account was needed.

If it fails: Read the installer error. Check React 19, the release URL and the printed setup; follow Install.

Save and refresh

Pass: The API's stored value and the refreshed field agree.

If it fails: Check the request, response status and stored record. Await persistence before reporting success.

Failed save and retry

Pass: Storage is unchanged, the draft remains, an error is visible, and Retry saves that draft.

If it fails: Throw on a failed response; keep the mounted form and draft. Follow Connect your data.

Loading, empty and error

Pass: Each state is visible and has the right next action; Retry loads real data.

If it fails: Separate “not loaded”, “no record” and “request failed”. Do not replace them with invented profile data.

Phone and keyboard

Pass: At 390 px every field and Save is reachable. A keyboard-only edit and save succeeds with visible focus.

If it fails: Inspect the page and its containing layout. Remove fixed widths and repair focus or labels.

Restyle

Pass: The saved custom style changes radius, motion, brand and font; existing data remains.

If it fails: Validate the style, install its font and target the actual root file. See Customise.

Add a field

Pass: Job title reaches server validation and storage, survives refresh, and invalid API input cannot corrupt the record.

If it fails: Follow the field through every mapping. An extra input without backend support is not a pass.

What you have proven

You have checked a real integration with your framework and data contract: persistence, recovery, a phone layout, keyboard use, a custom style and one complete field change. A local file API proves those paths locally; it does not qualify your production authentication, hosting or database.

The full system includes 200+ components and 50+ ready-made screens, including data grids, charts, trading, AI and voice interfaces, plus all nine looks, for the $49 launch price with lifetime updates. Those counts come from the catalog and are rounded down to tens. Your app continues to own its data and services. Use the library to decide which additional screens you need after the trial passes.