For a CRM hackathon, I built a persistent application around a demanding starting point: a legacy dataset that needed to become usable through a web interface, APIs, and an AI assistant. The project combines migration engineering with everyday sales and support workflows.
Turning legacy files into application data
The importer processes a nine-file Windows-1252 archive in a background worker and loads it into PostgreSQL. Validation covered record counts and derived business results rather than stopping at a successful import response.
The project’s recorded verification includes 539,423 migrated CRM records, with zero discrepancies in the specified independent revenue and list-membership audits. Those figures describe the supplied hackathon dataset and verification runs.
One application behind the interface and assistant
The CRM includes company and contact records, sales and renewal boards, tickets, dynamic lists, and import and export tools. Browser actions, API operations, and assistant writes use shared transactional services so business rules are enforced in the same place.
The assistant can answer questions about CRM data and carry out supported operations. Ambiguous requests and conflicting records are handled as application concerns, alongside ordinary validation and error handling.
Checking the whole system
The release documentation records automated server checks, browser verification, migration audits, and deployed behavior checks. That made the project a useful exercise in proving that the interface, persistence layer, and assistant agree about the same underlying data.
Stack: React, Vite, TypeScript, Express, PostgreSQL, an LLM integration through OpenRouter, Railway.
Context: Hackathon project. Dataset measurements are benchmark evidence, not customer or revenue claims.