Overview
I built Seekrly as a career CRM for managing the operational side of a job search. Instead of spreading applications across spreadsheets, recruiter conversations across email, interview dates across calendars, and resumes across folders, Seekrly puts those workflows into one connected system.
The product tracks applications, recruiter contacts, interview rounds, follow-ups, notes, and resume versions. A Chrome extension captures job postings while browsing, while APIs and an MCP server make the same career data accessible to external tools and AI applications. The public product is available at seekrly.com.
What I built
System architecture
I split Seekrly into several focused applications rather than putting every workload inside the web server. The client application contains the main product, public API, extension API, MCP server, and documentation. A separate admin application operates against the same data model, while a Go worker handles scheduled and background jobs. The browser extension, automation services, scraper, MCP tooling, and AI plugin live as separate projects.
One data model, multiple services
The client, admin panel, and worker share one MongoDB database. Mongoose models in the client act as the source of truth, while the admin application mirrors those models and the worker accesses the same collections through its MongoDB layer.
This architecture means schema changes have to be treated as system-wide changes. When a field is added, renamed, or removed, the client model is updated first, followed by the admin mirror and worker code. Existing documents are handled through idempotent migration scripts with dry-run support rather than assuming production data is already updated.
Application and relationship model
Seekrly is designed around relationships between applications, people, interviews, follow-ups, notes, and resumes. An application can be connected to a recruiter or hiring contact, interview rounds can belong to the application, and the resume version used for an application can be recorded directly.
This turns the application record into the center of the workflow rather than treating every feature as an isolated module. A user can move from an application to the related contact, see the interview timeline, review notes, identify which resume was used, and schedule the next follow-up without rebuilding the context manually.
Browser extension
The Chrome extension is designed around a deliberate capture action. When the user clicks Track Job on a supported job page, the extension reads the visible job information required for the capture and sends it to the user's Seekrly account over HTTPS.
The extension uses a per-account API key for authentication and stores that credential in extension storage rather than exposing it to the web page. Disconnecting the extension revokes the key, and the associated extension session can be reviewed from the user's account.
Authentication and security
Security is treated as part of the product architecture rather than an additional layer. Passwords are hashed with bcrypt, API keys are stored as SHA-256 hashes, and reusable secrets such as Gmail OAuth refresh tokens and SMTP credentials are encrypted at rest with AES-256-GCM.
Web sessions use signed JWTs stored in HTTP-only, Secure, SameSite cookies. One-time verification codes are hashed and expire automatically. Users can see active sessions and connected extension devices and revoke individual access.
Gmail integration
Email outreach is intentionally designed around user-controlled sending. When Gmail is connected, Seekrly requests permission to send mail but does not request mailbox-reading capabilities. The product sends only messages that the user composes and explicitly chooses to send.
The OAuth refresh token is encrypted at rest, and disconnecting Gmail removes the stored token and revokes the connection. Users can also use their own SMTP account for outreach.
Background jobs and reliability
I moved recurring operational work into the Go worker so scheduled processing does not depend on web-request execution. The worker handles reminders, email jobs, cleanup, and delayed file purging.
Seekrly's own transactional emails use an internal Email Worker HTTP API instead of direct SMTP calls from the application. Retryable jobs receive a stable job identifier so a retry does not accidentally become an additional logical email operation.
Soft deletion and lifecycle management
User-owned records use soft deletion through deletedAt rather than immediate physical removal. Application reads automatically exclude deleted records, while the worker performs the eventual hard deletion after the retention period.
The same lifecycle approach is used for sessions and other user-managed entities where revocation should be reversible at the application layer. This keeps deletion behavior consistent across clients and background processes.
File handling
Resume and other file references are modeled as records in a dedicated files collection with a refCount. The system does not need to scan unrelated collections to determine whether a file is still referenced, which keeps file lifecycle management explicit and predictable.
Dates and time zones
All application timestamps are stored and compared in UTC. The user's timezone is stored separately in preferences.timezone and used when presenting scheduled events and time-sensitive workflows.
API and MCP
One of the more interesting parts of Seekrly is exposing the career CRM through machine interfaces instead of limiting the product to the graphical interface. The public API provides programmatic access to career-management workflows, while the MCP server makes those capabilities available to AI applications.
Through the connected Seekrly MCP interface, an AI application can work with the same underlying career workflow: applications can be searched and reviewed, recruiter contacts can be resolved, interviews and follow-ups can be inspected, notes can be managed, resumes can be accessed, and outreach can be prepared or sent through the appropriate user-controlled workflow.
This creates an important architectural boundary: the AI layer does not need a separate career database. It acts through the same domain operations used by the product, which keeps the data model and business workflows consistent.
Machine-readable documentation
I maintain the public API documentation from a single source in the codebase. That source feeds the API reference page, machine-readable API documentation, an API skills document, and the site-wide llms.txt index. The goal is to make the platform understandable both to humans and to developer or AI tooling without maintaining several independent descriptions of the same interface.
Engineering challenges
The main engineering challenge was not building an individual feature but keeping several applications synchronized around the same domain model. A change to an application or contact can affect the web client, admin panel, worker jobs, APIs, extension workflows, and AI integrations.
I addressed this by keeping the domain model explicit, separating background execution from request handling, using stable identifiers for retried operations, and treating schema changes as coordinated changes across every consumer.
Validation and developer workflow
Each project has its own verification commands so changes can be checked at the boundary where they matter. The client uses TypeScript, linting, and formatting checks. The admin panel has its own type and lint validation. The Go worker uses go vet and Go tests, the Python automation uses pytest, scraper configuration is validated separately, and the MCP plugin has an explicit validation script.
What this project demonstrates
Seekrly is a practical example of designing a product as a collection of cooperating services while keeping one coherent domain model. It combines full-stack product development with backend architecture, background processing, browser extension development, authentication, API design, data lifecycle management, security, and AI integration.