Settle's work spans deadlines, client records, legal matters, correspondence, time entries, billing, and specialist registries. Those workflows needed one operating system without flattening their domain differences.
Case study
Pulse CRM for Settle Law Firm
A legal-operations CRM that connects matters, tasks, time, correspondence, documents, billing, registries, and reporting inside one daily workspace.
The responsive dashboard gives staff a starting point for matters, tasks, events, correspondence, and daily activity.
Built a Flask and JavaScript CRM with shared navigation, search, task and activity flows, matter-linked records, specialist legal modules, and role-aware operational views.
Moved recurring legal operations into one connected CRM surface designed around the records and actions staff use throughout the working day.
Context
A law firm’s workflow does not fit neatly into a generic contact database. A single engagement can involve a client, a legal matter, deadlines, tasks, correspondence, documents, billable activity, and a specialist registry such as trademarks or powers of attorney. When those records live in separate tools, the cost appears in repeated searching, duplicate entry, and weak visibility over what needs attention.
The project scope covered the product structure, Flask backend, JavaScript interface workflows, and the visual system used across the CRM. The goal was to make the software feel like one operational workspace even though it covers several distinct legal processes.
Workflow Design
The matter is the organizing record. Clients provide relationship context; tasks, activities, correspondence, documents, and specialist legal records connect the work performed around that matter. Billing and reporting then use the operational data rather than asking staff to reconstruct it at the end of a period.
The product supports repeated daily actions through shared patterns: a global search, persistent module navigation, one creation menu for common record types, status and assignee filters, and dashboards that surface due work. This reduces the mental switch between modules while preserving the differences between a task, a legal filing, a time entry, and a billing record.
Decisions and Tradeoffs
The main product decision was to prioritize operational density over a sparse marketing-style interface. Staff need to scan lists, compare states, and move between linked records quickly. The navigation therefore remains visible and predictable, while filters and creation actions sit close to the data they affect.
The second decision was to extend a common CRM core with domain-specific registries instead of forcing legal work into generic notes. Trademarks, watch notices, powers of attorney, leads, and correspondence have their own entry points but remain part of the same product model.
Responsive behavior was treated as useful access, not a separate reduced product. The mobile surface preserves dashboard and task visibility, while the fuller desktop layout remains the main environment for record-heavy work.
Screenshots and Access
Pulse is live, but the authenticated system contains confidential client and legal correspondence. The portfolio therefore shows the product shell, an empty assigned-task workflow, and the cross-module creation menu. Screens containing client names, matter details, documents, invoices, or correspondence are intentionally excluded. A deeper walkthrough can be given in a controlled setting without publishing client data.
Result
Pulse connects clients, matters, work, records, and finance inside one operational product. The published screenshots stay limited to privacy-safe interface states, while deeper workflows remain available only in a controlled walkthrough.
Contact
Let's talk.
For professional opportunities, collaborations, or selected freelance work.
Open to conversations Frankfurt, Germany Europe/Berlin
GitHub penguindevteam@gmail.com