SimplyCareer: job application cockpit

I documented the existing workflow, its gaps, and a target process before turning them into requirements. This separated problems that needed a new screen from problems that needed a better data model or a rule the system could enforce.

For example, a tracker that mixes application stage, outcome, and whether a posting is still open makes later analysis ambiguous. The proposed model separates those fields and links applications, contacts, and messages by ID. That gives reviews a clearer record to work from.

I left job discovery out of the first version. Existing aggregators already supplied postings; SimplyCareer would supplement them. I also kept submission and sending under the candidate's control. The product is meant to prepare and organize the work, with the person reviewing and taking the final action.

I kept onboarding because a new user needs a clear next step. Its intended outcome is to start the first application. The requirements allow document import or manual setup, show what remains to be completed, and keep imported facts unverified until the candidate confirms them.

The requirements rank features and define a cut order if the release becomes too large. Batch generation can run sequentially before adding parallel execution, for example. This makes the fallback explicit while preserving the core application journey.

My documentation runs from business analysis into technical design. The charter and process analysis establish the problem. Business and product requirements define what should change. User stories and acceptance criteria describe the expected behavior. Architecture decisions, the data model, API specification, and test strategy work through how to deliver it.

I connected these through a requirements traceability matrix. A requirement can be followed into the stories, design, planned tests, and implementation tickets that address it. A checked-off document is not proof that the feature works; the trace gives the build and review a specific path to follow.

The target architecture uses a React and TypeScript interface, Clerk for identity, and Convex for backend functions, data, storage, and scheduled work. AI requests stay on the server. These are the documented design choices for the MVP; the full workflow is still to be implemented.

The design gives AI responsibility for writing and checking meaning. Application code owns validation, calculations, permissions, limits, and saving. A coverage score or application stage should follow a defined rule rather than change with a model's phrasing.

The same boundary applies to context. Imported documents help draft a profile and suggest claims. They do not become permission to use every statement in a resume. The candidate must verify the claims that generation is allowed to draw from.

One worked example runs through the whole document set: a generated line must be supported by the candidate's verified information. The requirement leads to claim tiers and source references in the data model, server-side checks, a review state, an export restriction, and planned test cases.

I documented a two-stage check. Code checks known violations, such as prohibited claims or invalid source references. An AI judge then examines whether a cited source supports the wording of each line. Rules alone can miss a fabrication that has been rephrased; a judge alone does not provide deterministic checks.

Flagged content remains available for review, but acceptance and export are intended to stay blocked until it is edited or removed. The tradeoff is another model call and the possibility of false flags slowing the user down. Those need evaluation rather than an assumption that a second model guarantees correctness.

I compared a fully split profile schema with a hybrid model. The accepted design keeps small, fixed profile fields together and puts growing collections, such as roles, projects, claims, and bullets, in separate tables. This reduces the number of reads and moving parts needed for the screens without putting an ever-growing history inside one record.

Generated resume content references roles and projects by ID. Names, dates, and other locked facts come from the stored profile when the document is rendered. The intention is to keep those identity fields outside the model's editable output.

A generation request may finish after the user has retried or changed something. The design assigns each run an identifier and checks it again before saving, so a stale result can be dropped. Batch jobs have individual states, allowing one failed job to be retried without restarting the whole batch.

The implementation plan turns the design into vertical slices: backend behavior, checks, and a connected screen delivered together. Candidate evidence comes before analysis and generation; tracking and reviews depend on a reliable application record.

The prototype makes the proposed workflow inspectable, from setup and captured jobs to application review and weekly feedback. It is also a way to examine whether each screen gives the user a useful next action.

The documentation and authentication are complete. Database setup is partly complete. Upcoming work includes finishing the schema and database setup, implementing the features, and validating the complete application journey. The intended MVP works end to end; the current product does not yet do so.

The test strategy separates predictable software behavior from model quality. Unit and backend tests use fixed examples to check rules, calculations, permissions, error paths, and state changes. Real-model evaluations ask whether the generated material remains supported by evidence and whether its cost and response time are acceptable.

Browser journeys then connect those pieces: analyze a job, generate materials, resolve a flag, export, and find the application in the tracker. Manual acceptance checks cover usability and the actual workflow. These are planned checks, not results I am claiming to have passed.

The planning work brought several decisions into focus. Choosing a boundary determines which dependencies the first release needs. Treating a resume claim as stored evidence changes the schema, generation context, review behavior, and tests. Separating stage, outcome, and posting state determines what a later review can meaningfully calculate.

That is the connection I want this project to demonstrate: taking a business problem through requirements and technical decisions into work that can be built and checked. The documentation is a foundation for that work. The next step is to implement those decisions and test them in use.

There are still important questions to validate. Can a new user finish setup and start an application without help? Do the claim checks catch unsupported wording without making review frustrating? Does keeping the application history connected produce useful weekly decisions? The prototype lets me examine the journey, while the finished system and its evaluations will need to answer those questions.