Jobs & careers

What jobs and careers apps are worth building?

Look for tasks that happen on every application, not once in a career. Applying for a job means reading a posting, deciding whether it fits, rewriting the resume for it, writing a short note, and then remembering to follow up ten days later. Each step is small, and each one is a place where people drop out of the process. An app that does one step well, and hands the result back in a form someone can paste or send, is a plausible first version. An app that tries to run the whole search at once usually does none of the steps properly.

Ideas in this category fall into three groups. Matching ideas read a posting against a profile and say where the gaps are. They are the most attractive on paper and the hardest to get right, because a wrong match wastes an afternoon and quietly teaches the user to distrust the tool. Preparation ideas produce the thing that goes with an application: a tailored resume section, a cover note, or interview questions drawn from the employer’s own job description. Tracking ideas keep the state of a search: which role, which stage, which follow-up is due and which one was never sent. Start with preparation or tracking unless you have a sharp angle on matching.

Salary and offer questions are a fourth, smaller group. They are useful because the stakes are high and the user is often alone with the numbers. They are also where the data is weakest, since pay varies by region, employer size and the exact duties of a role. An idea here should say where its range comes from and how old that data is, or it should not give a range at all.

Who uses a jobs app, and how do you reach them?

The core users are people actively applying: recent graduates, people returning to work after a gap, people changing sector, and people who lost a job and are now searching under pressure. They tend to be short of time and anxious about wording, which makes a tool that produces a concrete draft attractive, and also makes them easy to mislead. Career coaches, recruiters and university careers services form a second group. They run the same process for many people, so a tool that saves each of them an hour per client has a clearer reason to exist than a tool that saves one applicant an hour once.

Reaching them is a search problem more than a distribution one. People looking for help with a specific task type specific words: “tailor resume to job description”, “salary range for a role”, “follow up after an interview”. Write the first version as a page that answers one of those questions, then test it by posting the link in the communities where the job is discussed and asking whether the output was useful before building more. Posting an idea on this board does not put a finished app in front of job seekers. It gets an idea in front of builders, and that is a different audience.

What makes a jobs and careers idea good?

1. It names one task and one person. “Help with job applications” is a category. “Turn a job posting into the three bullets a hiring manager scans first” has a user and an output.
2. The input already exists. A posting, a resume file and a target salary are documents or numbers a user already has. An idea that needs a new data source before it does anything starts behind.
3. The output is something to paste or send. A tailored list of requirements, a dated follow-up email, or a one-page comparison of two offers can all go straight into the user’s next step.
4. The mistakes are visible to the user. People check an error when it costs them an interview, so the idea should say how the user verifies the result before sending anything.
5. It is honest about what it cannot know. It does not guarantee an interview, a callback or a fair offer, and its screens should not imply that it does.

Use the list as a filter on your own idea before you post it. If you can only describe the output with the word “better”, the idea is not specific enough for a builder to pick up.

What does a first version look like? A worked example

Hypothetical, and not a product on the board: a tool that takes a job posting and a resume, and returns the requirements the resume does not yet show, each phrased as a question the user can answer honestly. The tool never writes resume lines for the user, because a line the user did not earn is a false claim sent to an employer.

Build a single-page web app. Input: two text boxes, one for a job posting and one for a resume, both pasted as plain text. Step 1: extract the eight most specific requirements from the posting (named skills, tools, years of experience, certifications). Step 2: mark each requirement as “in resume”, “in resume, weak wording” or “missing”. Step 3: for each “missing” item, write one yes-or-no question the user can answer about their own experience. Output: a table with the three groups and the questions. Never generate resume sentences. Store nothing on a server; clear both boxes when the page is closed.

The first version is ready when a real posting and a real resume produce a table the user can act on in about ten minutes. Test it with five people who are applying this month. Ask whether the questions were ones they could answer, and whether any requirement was wrongly marked as missing. Only after those checks is it worth adding a tailored draft, and then the draft should show which parts came from the user’s own text.

What goes wrong with jobs and careers apps?

• Invented experience. A tool that adds resume bullets or claims a skill the user does not have sends a false document to an employer. Ask questions about gaps instead, and show the user where each claim in an output came from.
• Scraping job boards. Many job sites restrict automated access in their terms, and listings change or disappear quickly. A first version can let users paste the posting text instead of building a crawler. Check any site’s terms before relying on its pages.
• Salary numbers without a source. A single figure labelled “the fair salary” reads as authoritative and is usually neither fair nor current. Show a range, its source and its date, or leave the number out.
• Personal data in the wrong place. A resume holds a name, an address and an employment history. Process it in the browser where possible, keep no copy, and say in plain words where it goes.
• Promised outcomes. No tool gets anyone hired. Describe what the output is, and leave out what it might lead to.

Where to start: live ideas and editorial reading

Two ideas in this category were on the board when this page was written. JobsFlow covers the whole search, from finding a role to following up, which is a broader scope than a first version should take. Salary benchmark from the actual job description is narrower: one input, one output, and the hard part is data rather than interface. Reading both side by side is useful, because the narrow one is much easier to test honestly.

Neither one is your angle? Post your own in three lines: who is applying, which step they repeat, what comes out. A builder who picks it up can use how to scope an MVP to cut it to one task, and how to validate an app idea to check it with real applicants first.