Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.folksbase.joselito.dev/llms.txt

Use this file to discover all available pages before exploring further.

Being honest, time flies when you’re building a project like this from scratch, and while I’m very proud of what’s here, no project is ever truly “finished”. I had to be very intentional about where to put my energy to make sure the core engine was rock solid. As a developer and technical lead, I’ve learned that knowing when to ship is just as important as knowing how to code. Think of this document as the post-race debrief: we had a 1-2 race, but there’s still more performance to squeeze out of the car before the next Grand Prix. Below is the “internal backlog” of technical debt and opportunities I’d tackle if we were moving this from a challenge to a production roadmap.

​
Infrastructure & Performance

  • Neon WebSockets vs. HTTP Driver: While the current implementation uses the standard HTTP driver, I initially explored moving to Neon WebSockets for a more reactive, real-time feel. I ran into some early configuration hurdles that didn’t fit the current sprint, but it remains a top priority to reduce latency and improve database reactivity.
  • Web Worker Feasibility: The indexCsv function is a prime candidate for Web Worker offloading. It’s a pure, self-contained function with no DOM dependencies. Moving the index building and line-offset calculations to a worker would keep the main thread entirely free for UI interactions, ensuring a 60fps experience even during massive file processing.
  • Deeper Inngest Orchestration: This was my first time using Inngest, and while it was a fantastic learning experience, I’ve only scratched the surface. I see a massive opportunity to use their more advanced orchestration features—like step retries, throttling, and fan-out patterns—to make the import pipeline even more resilient.

​
UX, A11y & Design

  • The “Async Delete” Puzzle: Right now, bulk deletion is synchronous. I chose this because of a specific UX concern: if I handled it asynchronously like the imports, a user might try to edit or save a contact that is already “dead” in the background. This “ghost contact” scenario leads to terrible data integrity. A future fix would involve a robust optimistic UI that locks or hides records immediately while the background job catches up.
  • Inclusive Design (A11y & i18n): As a human who loves to create websites, it pains me that the accessibility is currently at a “bare minimum” level. I had intended to implement a full i18n system with browser detection and profile-based preferences (EN/PT-BR), but I had to prioritize the core “T-shaped” engineer requirements first.
  • Mobile-First Refinement: The application follows basic responsiveness, but there is a clear bias toward the desktop experience. With more time, I’d move beyond simple breakpoints and refine the mobile UI to be just as polished and “pixel-perfect” as the desktop dashboard.
  • Interactive Platform DX: I wanted to replicate the Resend experience by adding “Copy Code” snippets for every action in the dashboard, allowing users to see how to perform that same task via the API. Since the API is already OpenAPI compatible, this is a low-hanging fruit for the next iteration.

​
Product & Features

  • Workspaces & Collaboration: The foundation is there—the database schema and API are entirely structured around Workspaces. Contacts are associated with the workspace, not the user. While the time didn’t allow for invite flows or multi-user sharing, the architecture is ready to support full-scale team collaboration whenever we pull that lever.
  • The “Snake Game” Easter Egg: I’m a fan of adding personality to software. I actually implemented a Snake Game to keep users entertained during long imports, but I commented it out because it didn’t quite hit the UX polish I wanted for the final submission. It’s still there in the code, waiting for a v2 refactor.
  • Weekly Digest & Resend Keys: I initially planned a “Weekly Digest” template to showcase more react-email work, but I swapped it for real-time import/export notifications which felt more logical for a short-term test. I also explored allowing each workspace to use their own Resend API Key, a feature that is partially implemented but not yet fully wired to the UI.
  • MCP Server: I briefly considered building an MCP (Model Context Protocol) server for contact management. While it would have been a very “2026” move, I decided to discard it to maintain focus on the core requirements of the challenge—focus is just as important as being “cool”.