Make the workspace
feel like your team.
Edit apps/web/components/devlaunch-windows-doors/config.ts to set company name, descriptor, promise line, and default pipeline name, then rebuild. The design applies to the entire web installation. Use separate web installations to evaluate different full-interface kits, rather than stacking their installers.
Starter removal, updates, and rollback
Review unused starter additions for removal in Starter setup before removing the frontend. Server checks preserve edited or published workflows and pipelines with jobs or references. The process targets recorded kit additions rather than sweeping account records.
Preserve your local configuration and source edits. Preview frontend removal with node setup.mjs remove "/path/to/seedly" --dry-run. The automatic uninstaller uses a private restoration receipt and refuses to overwrite later edits. Keep that receipt private and out of public hosting or source exports. Removing frontend files does not remove account data or undeploy backend functions.
For an update, follow the documented removal/install process and reapply your preserved changes. A manually merged installation needs its own private change ledger and reviewed source rollback.
What the workspace records
A project is a native contact-linked opportunity with a namespaced service address label, manufacturer label, product line label, measure date, install date, crew label, manufacturer order number reference, ordered date, quoted lead days, received date, project notes, an immutable supported currency, opening rows with their type and their width and height in inches, and install day rows with their crew label, openings completed and punch items note. The recorded contract reference stays separate from native opportunity value. Other custom fields are preserved.
A recorded width or height must be a multiple of one sixteenth of an inch between 6 and 240, and the server re-checks the multiple, because a size that drifted through a rounding bug is a window built to the wrong number. Sizes read as decimals everywhere, width first, then a multiplication sign, then height. Tiles share one scale factor per project, drawn from the largest recorded dimension on that same project, so two openings on one card are comparable and two openings on different cards are not; this is stated in the interface as well. The order state is derived from two dates: received when a received date is recorded, on order when only an ordered date is, and not ordered otherwise. Elapsed days run from the ordered date to the received date when one is recorded and to the selected date otherwise, and are never negative. An order is late only while it is on order, a quoted lead days value is recorded, and the elapsed days exceed it, so a received order is never marked late and an order with nothing quoted never is either. Evidence rules are identical on the client and the server: a received date requires an ordered date it does not precede, an ordered date requires at least one recorded opening, an order number or quoted lead days requires an ordered date, a crew label requires an install date, an install date requires a measure date, and an install day cannot complete more openings than the project records. Three non-rules are deliberate: an install day date is not constrained against the scheduled install date, an install date is not required to fall after a received date, and two install days may share a date. There is no manufacturer ordering or configurator integration, no pricing or quoting engine, no energy rating data of any kind, no scheduling engine, no invoicing or payments, no customer messaging and no CAD. The tiles are proportional rectangles from two recorded numbers, not drawings, elevations, shop tickets or a takeoff, and they are not to an absolute scale. Totals are grouped by currency and never added across currencies. The pipeline stage stays the one in your CRM: recording an order never moves a card, and moving a card never records an order.
The kit’s original operational screens share the frame with full CRM modules from your own Seedly source. Existing account permissions, feature gates, and configured providers still determine access to those modules.