Can you put a vibe-coded app on your resume?

Can you put a vibe-coded app on your resume?

Yes, you can put a vibe-coded app on your resume — provided you claim the product decisions and the outcome rather than authorship of every line. On 13 October 2026, Google Play began letting people in the US install private, AI-built Android apps straight onto their own device through a Personal Library: no $25 developer account, no public listing, nothing surfacing in Play search. Google's VP and GM for Play, Sam Bright, described the shift as moving from "there's an app for that" to "there's an app for me." Translation for job seekers: the gap between prompting a thing and shipping a thing just narrowed to almost nothing, and recruiters are about to see a lot more project bullets.

That flood is both your opportunity and your risk. A working app you can hand someone is still the strongest evidence a junior candidate can produce, and recruiters genuinely do click project links — a live build beats a screenshot and beats a bare repo. One large recruiter experiment covering well over a thousand screeners in the US, UK and Germany found that resumes signalling AI skills lifted interview-invitation odds by roughly eight to fifteen percentage points across several job families. The same body of work found something less comfortable: trust in a candidate dropped sharply when they openly described leaning on machine assistance in a motivation letter. So the upside is real and the framing decides which way it cuts.

Here's my flat opinion: don't write the words "vibe-coded" anywhere on your resume. In engineering circles the phrase is used half-ironically, and putting it in a bullet reads as if you're proud of the shortcut instead of the result. Write "Built" or "Shipped," describe what the thing does, and name your AI tooling in the stack line where it belongs — honest, searchable, unglamorous. The underlying work is legitimate. Prompt-driven development is how a lot of real teams now move, and plenty of job ads in retail, finance and healthcare already list it as preferred. You just don't need the meme in your headline.

What should you actually claim about an AI-built app?

Claim four things: the problem, the people using it, the architecture decisions you personally made and can defend, and the measurable outcome. Those four are yours regardless of who typed the code. The model didn't choose to store sessions in Postgres instead of a JSON file, didn't decide that offline-first mattered more than real-time sync, and didn't notice that your date handling broke across time zones. You did. A bullet built from those choices survives scrutiny; a bullet built from "used AI to generate a full-stack app" collapses the moment anyone asks a second question. Ownership on a resume is a story about judgment, not about keystrokes.

Get concrete. Say you built a shift-swap app for the 40-person gym where you work weekends. What's genuinely claimable: you interviewed six staff before writing anything, you chose SQLite plus a tiny sync layer because the floor has dead Wi-Fi spots, you rejected push notifications after the first week because nobody enabled them, you wrote the test that caught double-booked slots, and you pushed it to eleven real users who now swap shifts in the app instead of a group chat. Every one of those is a decision with a reason attached. Strung together, they read exactly like the work a junior engineer does in their first year on a team.

What you never claim: sole authorship of generated code, "built from scratch," line counts, or user numbers you can't name. Don't quietly hide the tooling either — list Claude Code, Cursor, Copilot, Google AI Studio, v0 or whatever you actually used under tools, the same way you'd list Docker. Disclosed in a stack line, it looks fluent; discovered in an interview, it looks like concealment. If you're assembling the whole document through an assistant, the same rule applies to the resume itself — this walkthrough of building a CV by chatting with an AI covers which invented details to strip before you export.

Where does the project go — junior or senior resume?

If your paid experience is thin, the project goes high: a dedicated Projects section placed directly after your skills block and above Education, with two or three builds. If you're senior, it drops to a single line near the bottom — or comes off entirely. The reason is simple arithmetic about attention. A screener spends seconds deciding whether to keep reading, and they spend those seconds on whatever sits highest. For a self-taught developer or a bootcamp grad, a shipped app is the strongest thing on the page. For a staff engineer with eight years of production work, a weekend app competes with better evidence and loses.

Juniors, cap it at three projects and make each one show something different — one with a real data model, one with a deployed front end, one built with other people. Two or three bullets apiece is plenty, and a fourth project adds nothing but noise. Give each a name, a date range and a link that actually resolves; a dead link is worse than no link. Keep the project bullets in the same voice as your experience bullets so the page reads as one document rather than a resume with a hobby appendix stapled to the back. If you're rebuilding from scratch, the HRLens CV builder will hold that structure for you across six ATS-friendly templates.

Career changers sit in between and should treat projects as pivot evidence. A finance analyst moving into engineering gets more mileage from one app that solves a finance problem than from three generic to-do clones, because it proves the domain knowledge transfers. Seniors, the honest use case is narrow: a project belongs on your resume when it demonstrates a stack you're not paid to use yet. And if the build never launched or got cancelled, that's not disqualifying — there's a clean way to write up a product that got scrapped that keeps the decisions and drops the apology.

How do you write bullets that prove impact and ownership?

Use one shape for every project bullet: the problem, the decision you made, the outcome with a number, then the stack. That order matters because the first half of a bullet is what a skimming recruiter reads and what an answer engine quotes. Pre-launch numbers count as numbers — eleven active users, six interviews, a 2.3-second load time you cut to 400 milliseconds, 40 staff who stopped double-booking. You don't need thousands of downloads. You need figures you can source and defend out loud. Vague scale claims hurt you twice: they read as padding, and they hand the interviewer an easy place to push.

Compare two versions of the same work. Weak: "Vibe-coded a mobile scheduling app using AI tools, demonstrating full-stack skills." That's a sentence about a tool with no problem, no user and no result. Strong: "Built a shift-swap app for 40 gym staff after six user interviews; chose offline-first SQLite over live sync for patchy floor Wi-Fi; cut swap requests in the staff group chat to near zero across 11 weekly users. Kotlin, SQLite, Google AI Studio, Claude Code." Same project, same tooling, same honesty — but the second one gives a hiring manager three things to ask you about, and you'll have an answer for each.

Then check how it actually scores before you send it. Automated screening reads your stack line for keywords and your bullets for evidence of ownership, and the two fail independently — a beautifully worded project with no parsable tech names won't surface in a search, while a keyword-stuffed one with no outcomes won't convince a human. A free CV analysis from HRLens returns an overall score out of 100 plus separate category scores for experience, tech stack, impact and ownership, clarity and structure, and ATS compatibility, so you can see which half of that problem you've got.

How do you survive "walk me through this code"?

Know every file well enough to change it live, or take the project off your resume. "Walk me through your code" has become the standard ownership check for exactly this situation, and experienced interviewers report spotting the failure in about thirty seconds. The sharper version is the live modification: they'll ask for a small, unexpected change — add a field, handle an empty state, make this function idempotent — and watch whether you know where to make it and why the current implementation works the way it does. You can't bluff that. Someone who assembled the thing from model output and never read it back stalls immediately.

So do the prep properly. A week before you start applying, open each project and read it end to end. Flag every section you couldn't reconstruct from memory, then pick one of two options for each: understand it well enough to defend line by line, or delete it. Rehearse three architecture decisions you made and the alternatives you rejected. Know one bug you found and fixed, with the symptom and the root cause. Know one thing you'd rebuild differently now and why. Those four answers cover roughly every follow-up a screener will throw at a personal project, and they're also just true, which makes them easy to deliver.

If a section is generated and you understand it anyway, say so plainly: "That retry logic came out of Claude Code — here's what it does, here's why I kept it, and here's the case it doesn't handle." Interviewers are fine with AI-assisted. What ends an interview is AI-authored and never examined. That distinction is now baked into hiring scorecards: the generated code earns you nothing on its own, and the points come from your decisions, corrections and explanations around it. For the full first-screen checklist, including how to lay out a stack section parsers can read, start with a software engineer CV built for the first screen.

Frequently asked questions