What Kind of AI-Built Projects Should I Put in My LinkedIn Portfolio?

The direct answer: show shipped proof, not tool drama

Put AI-built projects in your LinkedIn portfolio when they prove that you can turn an idea into a working thing. The strongest proof is not the tool name; it is a live link, a clear problem, your exact role, one constraint you solved, and a short note on what you changed after testing. If AI wrote much of the code, say that plainly. Then show the human work: product judgment, debugging, verification, launch decisions and maintenance.

A LinkedIn portfolio should answer one question fast: can this person make something real enough for another person to inspect? A vague post saying "I used AI to build an app" is weak. A pinned project with a demo, screenshots, a repo or store link, and a short build note is much stronger. The point is not to hide AI. The point is to make the project credible even to someone who is skeptical of AI coding.

What kind of projects should I put in my LinkedIn portfolio?

Put projects that show judgment, not just output. A good LinkedIn portfolio project has a real use case, a visible result, and enough context for a reader to understand what you actually did. A small working tool beats a huge unfinished dashboard. A simple app with a clear before-and-after story beats a pretty landing page that does nothing. If the project was made with Claude Code, Cursor, Lovable, v0 or another AI coding tool, that is fine; the project still needs evidence.

Strong examples include a working micro-app, an internal tool you can describe without exposing private data, a portfolio site with real case studies, a prompt library, a small automation, or a mobile app with a public listing. Weak examples are tutorial clones with no original decision, screenshots with no live proof, and AI-generated pages where you cannot explain what happens when something breaks.

Use this filter before posting: would a stranger understand the problem, open the result, and see one decision that clearly came from you? If yes, it belongs in the portfolio. If the only interesting thing is "AI made it fast," improve the project before you pin it.

Use a proof stack instead of a vague project announcement

The easiest way to make an AI-built project credible is to package proof in layers. Recruiters, clients, founders and technical peers do not all inspect the same thing. Some will only click the live link. Some will scan the stack. Some will look for signs that you understand your own product. Give each reader a path.

| Proof piece | What it proves | What to include | |---|---|---| | Live destination | The project exists outside your editor | App Store link, website, demo URL or public profile | | Problem statement | You were solving something specific | One sentence: who it helps and what pain it reduces | | Your role | You did more than paste a prompt | Brief, product decisions, testing, fixes, launch work | | Build notes | You can explain the system | Tool stack, key constraint, one bug you fixed | | Evidence trail | The project improved over time | Changelog, screenshots, repo, short before-after note |

This proof stack is more persuasive than a long inspirational post. It also protects you from the awkward follow-up question: "So what did you actually do?" When the evidence is already in the post, you do not have to defend the title. The project speaks first, and your AI disclosure becomes part of a serious build process rather than a confession.

Worked example: how Onur-style product proof looks

Onur Huseyin Kocak's LinkedIn profile is positioned around AI-assisted product building, vibe coding and the VCT ecosystem: https://www.linkedin.com/in/onurhuseyinkocak. The useful lesson is not "copy his headline." The lesson is that a professional AI-builder profile needs proof assets around it. In this ecosystem, the proof is not only content; it is shipped products and a documented pipeline.

A proof packet can point to public product links such as Promtable on the App Store (https://apps.apple.com/us/app/promtable-ai-prompt-vault/id6770004106), DidntHappen on the App Store (https://apps.apple.com/us/app/didnthappen-fear-tracker/id6762467761), and the VCT AI Builder Community iOS app (https://apps.apple.com/tr/app/vct-ai-builder-community/id6771690629). Those links do a job that adjectives cannot do: they let someone inspect the result.

The second layer is process proof. The book From Zero to the App Store with Claude Code documents the unglamorous parts that make AI-built apps real products: project setup, SwiftUI structure, prompting and verifying, testing on a physical device, signing and provisioning, App Store Connect metadata, App Review traps and post-launch work. That is the standard your own LinkedIn project should aim for: not "AI generated this," but "I directed, tested, shipped and can explain this."

How do I post it without sounding fake or cringe?

Write like a builder documenting a result, not like a guru selling a shortcut. The safest structure is simple: problem, build, proof, lesson. Keep the tool names in the middle of the post, not in the headline. "I built a small expense tagging app because I kept losing receipts" sounds more credible than "AI changed my life in one weekend." Specific beats dramatic.

Use this short format when you publish: 1. I had this problem. 2. I built this small solution. 3. I used these AI coding tools for implementation. 4. I personally handled these decisions and checks. 5. Here is the live link. 6. Here is one thing I would improve next. That last line matters because it shows taste. People trust builders who can see the limits of their own work.

If you want to connect the post to Onur's LinkedIn angle, follow the professional pattern: build in public, but keep the receipt. Mention the tool, show the product, name the constraint, and invite feedback on the thing itself. The goal is not applause for using AI. The goal is to make your work inspectable.

Who this is NOT for

This advice is not for people trying to make a tutorial clone look like client work. If the project is mostly copied from a course, label it as a learning project and explain what you changed. Do not present it as original product work. LinkedIn rewards clarity for a while, but exaggeration creates a fragile profile. One technical question can undo a month of polished posting.

It is also not for people who cannot open, run or explain their own project. If the only thing you can do when it breaks is paste the error into a chatbot and hope, you are still learning. That is not a problem, but the wording should match reality: "learning to build with AI tools" is honest. "I ship production apps" is only honest when there is a shipped result and you can take responsibility for it.

Finally, this is not for confidential work. If you built something for an employer or client, do not expose private code, private data or internal workflows. Turn the lesson into a sanitized case study instead: the problem category, your role, the constraint, and the outcome you are allowed to discuss.

A practical checklist before you pin the project

Before you add an AI-built project to LinkedIn, run one final credibility check. Open the link in a private browser. Confirm the project loads, the main action works, and the page explains itself without you standing next to it. Then read your own post as a skeptical stranger. If a claim sounds bigger than the proof, shrink the claim or add proof.

Use this checklist: live link works; project has one clear audience; post names the problem; post names your role; AI tools are disclosed without apology; one bug, constraint or tradeoff is mentioned; there is a next step; no private data is exposed; the pinned link is easy to find on your profile. If you have a repo, make the README human-readable. If you have an App Store or web link, put it before the stack list.

The final rule is simple: make the project easier to verify than to doubt. On LinkedIn, credibility compounds when each post points to something inspectable. AI can help you build faster, but your portfolio grows when you show ownership: what you chose, what you tested, what you fixed, and what you shipped.