The Step I Used to Skip: Deciding What the App Should Automate Before I Design the Database

Switchpath takes a resume and a target job posting, finds the actual skill gap, and generates scoped project briefs, a prioritization exercise, a mock PRD, that a career switcher completes and hosts on a shareable portfolio page. It solves a specific, real problem: a certificate proves you sat through a course, not that you can do the job, and that's exactly where career switchers get filtered out at screening.

Before writing any code, I spent the session mapping where the app should act automatically versus where a person needs to make the call. Should parsing the resume and job posting kick off analysis automatically the moment both are uploaded? Should the generated project brief appear without a click, or should it wait for the user to confirm the skill gap analysis looks right first? Neither question has an obviously correct answer in the abstract. They only resolve once you actually sit with what the product is for: a career switcher who's already anxious about whether they're qualified doesn't need one more automated thing happening to them without warning.

Here's the pattern I named plainly to myself while doing this: every time I've skipped this step and jumped straight to building, I've ended up retrofitting automation onto a system that wasn't designed for it. Mapping the agentic layer first means webhooks and cron jobs have somewhere to plug in from the start, instead of getting bolted on after the database is already shaped around a different assumption.

The target for Switchpath: hiring managers across five transition types validating the briefs, plus a 50-person cohort tracking whether it actually moves the needle on interview conversion.

This is the same underlying principle as mapping Firstflow's agentic layer, applied to a different product with its own real numbers and its own specifics. If you're about to design a database for something with any automatic behavior in it, map the automation decision first. The schema you'd design without that mapping and the schema you'd design with it are usually not the same schema.