Build a complete, interactive customer relationship management application for the browser in the spirit of Salesforce — a working CRM that a salesperson could sit down in front of and actually run a pipeline from, not a dashboard mockup or a screenshot-shaped landing page. It should open on a seeded, believable org full of accounts, contacts, leads, opportunities, cases, activities, and people, and every surface a real CRM user touches should be there and should work: a global navigation bar with an app launcher and object tabs, list views, record detail pages with related lists, a sales pipeline, activity and note logging, search, reports and dashboards, and the small settings and personalization surfaces that make a workspace feel like the user's own.
Give it the full object model and the relationships between records, because the relationships are what make a CRM feel real rather than a set of disconnected tables. Leads that can be qualified and converted into an account, a contact, and an opportunity in one flow. Accounts that roll up their contacts, open opportunities, cases, and activity history. Contacts that carry roles, titles, reporting lines, and their own related records. Opportunities that move through named stages with amounts, close dates, probability, products or line items, competitors, and forecast categories. Cases with priorities, statuses, owners, and comment threads. Tasks, events, calls, and emails that appear on the records they relate to and in a per-user activity timeline. Users and teams with ownership, so records can be reassigned and filtered by owner. Navigating from any record to its related records should always be possible, and deleting, editing, or creating a record should update every place that record appears.
Match the interaction texture of an enterprise CRM at full fidelity. List views should be switchable and savable, with column sorting, resizing, and reordering, inline editing directly in the grid with a save bar for pending changes, multi-row selection with mass actions, filter panels with real field-level operators, search-within-list, pagination or virtualized scrolling over enough records to feel substantial, and both table and Kanban presentations where they fit. The opportunity pipeline should offer a drag-and-drop Kanban across stages with live per-column totals, plus a guided path component on the record page that shows the current stage, lets the user advance it, and surfaces the key fields and guidance for that stage. Record pages should support inline field editing with validation, required-field enforcement, dependent and formula-like fields that recompute, highlights panels, tabbed detail and related sections, a collaboration feed with posts and comments, and a right-hand activity composer for logging a call, sending an email, or scheduling a follow-up. Add global search with typeahead across objects and recent items, a create-record quick action available from anywhere, a notifications tray, a favorites or recent-records list, and a utility bar or docked panel for quick tools.
Then make it genuinely easy to use — the part enterprise software usually gets wrong. The interface should be fast, legible, and forgiving: instant response to every click, optimistic updates, undo where a mistake is plausible, non-blocking toasts that confirm what happened, empty states that tell the user what to do next, skeletons and loading shimmer only where waiting is real, and error and validation messages written in plain language attached to the field that caused them. Keyboard users should get real support — shortcuts for search, creating a record, saving, navigating rows, and closing overlays, with a discoverable shortcut reference. Onboarding should be self-evident: a new visitor should understand the pipeline, find a record, and edit a field without instruction. Filters, sorts, view choices, panel states, and theme preference should persist across reloads so returning feels continuous.
Carry the craft all the way through the visual and motion layer. Establish a coherent design system — a clear type scale, consistent spacing rhythm, a semantic color system for record types and statuses, object-colored icons, avatars, badges, and data-dense but breathable tables — and apply it consistently on every screen. Motion should be purposeful and quick: modal and panel transitions, Kanban card lift and drop, row hover and selection states, focus rings, stage-path advancement, chart draw-in, and toast entry and exit. Include the secondary and edge states that prove the application is real rather than a happy-path demo: empty lists, single-record lists, very long field values and truncation with tooltips, records with no related items, overdue tasks, closed-lost opportunities, permission-limited or read-only fields, sorting on nulls, deleting the last item in a view, and unsaved-change warnings when the user navigates away. Make the whole thing responsive, so it holds together on a wide desktop, condenses sensibly on a tablet, and remains usable on a phone rather than collapsing into a broken grid. Give it a light and dark theme and keep contrast and focus visibility strong in both.
Include reporting and analytics that actually compute from the seeded data rather than displaying static images: a dashboard home with pipeline by stage, forecast versus quota, win rate, activity volume, leaderboards, and aging or trend views, with charts that respond to filters and to date-range and owner selection, and a report builder or at least drill-down from any chart into the underlying filtered record list. Numbers on the dashboard must reconcile with the records in the lists — if a user changes an opportunity's stage or amount, the dashboard should reflect it.
Do not take shortcuts, substitute a cookie-cutter admin template, or stop once the application is recognizable as a CRM. This work has no token budget limit, so pursue the full depth of the product: complete the secondary flows, the states between the main screens, the small feedback details, the responsive behavior, and the interactions that only reveal themselves when someone actually uses the thing for ten minutes. Keep refining it until the application feels authored, coherent, and complete — something that stands up to a real user opening it, poking at every tab, and trying to break it.