A bootcamp grad portfolio gets noticed when it shows judgment, not just finished builds, because the reviewer opening it has already seen the same weather app, to-do list and store clone that morning from other people in your cohort. Swap one of those for a project with a real user who is not you, then write down the decision you made, the option you rejected, the bug that cost you two days, and the scope you cut to ship on time. The projects are interchangeable. The reasoning around them is not, and reasoning is the only thing on the page that the previous applicant could not also hand in.
The pile
Your portfolio is probably not ugly. It is identical.
Here is the uncomfortable thing, said early and said kindly, because you were never told it during the course. On the Friday your cohort graduates, several other cohorts graduate too. All of you were taught with the same curriculum shape, so all of you shipped a weather dashboard, a to-do or task tracker, and a shop with a cart and a fake checkout. A hiring manager working through forty applications has opened that exact trio three times before their second coffee. By the time they reach you, the novelty is gone, and no amount of gradient on the hero section brings it back.
That is why the usual advice fails. You are told to add animations, buy a domain, redo the typography, put percentage bars next to your skills. None of it is wrong, exactly, but all of it treats a content problem as a design problem. The reviewer is not thinking that your site looks cheap. They are thinking, correctly, that they cannot tell you apart from the four candidates before you, and when a reviewer cannot tell people apart they fall back on the one thing that does differ, which is usually a referral or a degree. You lose that fallback every time.
The good news is narrow but real. What separates candidates at this stage is not talent and it is not the stack. It is evidence of judgment, and judgment is something you can show from work you have already done, this weekend, for free. What follows is what actually moves you out of the pile, in the order it moves you.
The separators
What actually distinguishes a bootcamp portfolio, in order
Ranked by how much a reviewer visibly changes posture when they find it. The first one is worth more than everything below it combined.
1. A real user
Someone who is not you, with an opinion
A local bakery, a running club, a nonprofit, a friend with a side hustle. One is enough. Real users ask for things at bad times, change their minds, and hate the feature you were proudest of. Surviving that is the closest experience to the job that exists outside the job, and it is instantly legible to whoever reads the page.
2. The decision log
What you chose, and what you turned down
Juniors write feature lists. Hireable juniors write forks in the road: I put the totals in cents as integers after the floats drifted, I kept state local and lifted it only when two screens needed it, I skipped auth because the deadline was real. Name the option you rejected and you have shown a reviewer more than a demo video can.
3. The bug you could not fix
Two days, one paragraph, enormous signal
The build that was green locally and broken in production. The race that only appeared on a slow connection. Write what you assumed, how the assumption was wrong, and what finally isolated it. This is the single most convincing thing a junior can publish, and it is almost never on the page, because nobody thinks the struggle is allowed.
4. The scope you cut
Shipping is a skill, so show it being used
You planned real time chat, notifications and a mobile app. You shipped none of them and launched anyway. Say so, say what the cut protected, and say what you would build first with another week. Engineers who cut on purpose are safe to hire. Engineers who gold plate until the deadline eats them are the ones seniors quietly worry about.
5. The thing still broken
One honest known limitation
No project is clean, so a page claiming none reads as a page written by someone who cannot see their own work. One line is enough: there is no rate limiting on the public endpoint, and that is the next thing I would add. Self-awareness reads as seniority long before the job title does.
Cut these
What quietly costs you credibility
Skill percentage bars, because nobody can define what 85 percent of CSS means. A wall of framework logos. The tutorial trio presented as original work. A screenshot grid with no prose. And any project you cannot walk through line by line in an interview, because you will be asked, and the asking is the interview.
The move
How to get one project with a real user in about two weeks
This is the highest leverage two weeks in your job search, and it costs nothing but the asking. Do it while you apply, not instead of applying.
Pick three targets you already have a reason to contact.
The gym you go to with a broken booking page. The society you were in at university. A relative who runs a trade and gets all their leads through a Facebook post. Warm beats cold every time. You are not selling a service, you are asking to solve one specific annoyance for free, and people say yes to that far more often than the internet suggests.
Offer a scope so small it sounds almost disappointing.
Not "I will build your website." Say: I will build the one page that shows your opening hours and takes bookings, and it will be live in two weeks. Small scope means they can say yes without a meeting, and it means you will actually finish. The finished small thing beats the abandoned ambitious thing at every level of this industry, not just yours.
Write down what they asked for before you write any code.
Ten lines in a text file. What they want, what they said no to, what they were fuzzy about. That file becomes your case study later, and it is genuine primary evidence that you gather requirements rather than guess at them. Keep the version where you were wrong about what they needed. That version is the interesting one.
Ship the small thing, then watch someone use it once.
Sit next to them, or send it and read the reply carefully. They will misread a label, miss a button, or ask for something that breaks your data model. Fix one of those and note what you changed. You have now done a build, a release and a feedback loop, which is the actual shape of the job you are applying for.
Ask for one sentence you are allowed to quote.
Something plain: the booking form saved me about an hour a week. A single line from a real person outranks any badge you can put on a portfolio, and it is the only social proof available to you before a company hires you. Publish it under the project with their permission and their first name.
The write-up
How to write the bug story so it reads as competence, not confession
Most graduates hide their hardest debugging session because it feels like an admission that they were slow. It is the opposite. Every engineer on the hiring panel has lost two days to something stupid, and they know that finding the bug is the job, while writing new features is the easy part. When you narrate a hunt properly, you are showing them your method under pressure, and method is exactly what they cannot see in a screenshot.
Keep it to five short moves. State the symptom in plain language: uploads worked on my machine and failed silently in production. State what you assumed and why the assumption was reasonable: I thought it was the file size limit, because the failures clustered on large images. State how you proved yourself wrong: I logged the request size and it was well under the cap. State the thing that cracked it: the deploy environment had a different timezone, so the signed URL was expiring before it was used. Then state what you changed so it cannot happen again. Nobody who reads that paragraph thinks you are slow. They think you are the person they want next to them on an incident.
The same shape works for your decision log. One fork, the option you rejected, the reason, and the cost you accepted. A reviewer does not need the fork to be sophisticated. They need it to be honest, and they need you to know why. That is what they will spend the first ten minutes of the interview probing, so writing it down in advance is not marketing. It is rehearsal.
The home
Where the prose actually lives, honestly compared
The problem with most bootcamp portfolios is structural: they are a grid of screenshots with a 30 word caption, and a decision log has nowhere to go. Here is what each route costs you.
| Capability | Folio | A screenshot grid template | Hand-rolled site |
|---|---|---|---|
| Room for a decision log | Each project is a case study with real prose, so the trade-offs and the bug hunt have somewhere to sit | A caption under a thumbnail. Anything past two sentences breaks the layout | Whatever you build, which usually means you defer it and never come back |
| The repo link | You paste it and it sits under the write-up. Folio does not sync GitHub or store your code | Usually one icon in a corner with no context around it | You paste it too. Same job, more plumbing |
| Time before you can apply | An afternoon. The writing is the slow part, and the writing is the point | Fast, and it looks like the other nine people who used the same template | A weekend for the scaffold, then months of restyling instead of job hunting |
| Resume in the same place | Generated from the same profile, so the site and the document cannot drift apart. PDF and DOCX export is free and unwatermarked | A separate file you upload and forget to update | A separate file, plus a link you will eventually break |
| ATS check before you send | A deterministic score out of 100 across 7 weighted criteria, shown on screen before you download | None. The template has no opinion about applicant tracking systems | None, unless you go and buy a checker |
| Your own domain | Available on Pro with the certificate handled. Free gives you a Folio address, not yourname.dev | Often paid, and often only on the higher tier | You buy it and wire up DNS yourself, which is fair and also a fine exercise |
If hand-coding the site is itself the code sample you want reviewed, hand-code it. Just do not let the site become the project you polish for six weeks while the case studies stay unwritten, because the case studies are the part that gets read.
The numbers
What the free plan actually gives a graduate, stated plainly
First-party facts about Folio, including the ones that are not flattering. You should not have to find these on the pricing page after you have already built the thing.
The honest part
What Folio does for a bootcamp grad, and what it refuses to claim
Folio is where the write-up lives. Outcomes are case studies with real prose rather than a wall of thumbnails, which means the decision log, the bug hunt and the scope you cut finally have a home, with the repository link sitting underneath as proof. That pairing is the whole job of the page: the argument on top, the evidence below it, one click apart.
Now the boundaries, because a builder that oversells here is a builder that will embarrass you later. Folio does not connect to your GitHub account, does not import repositories, does not sync commits, and does not host your code. You paste the link yourself, and the write-up around it is yours to write. Nothing on this site can produce that paragraph for you, and any tool promising to has not read your project. The same applies to the ATS score: it checks a resume Folio built, in a layout where the parsing rules cannot be broken by accident. It does not read a PDF you upload from somewhere else.
And the free plan, in full. Zero custom domains, so your address stays portfolio.wrxstack.com/yourname and a Made with Folio credit appears on the page. Ten AI drafting generations a month. The core design set rather than the whole theme gallery. Pro clears all of that at Rs 599 or 9 dollars a month. For someone three weeks out of a bootcamp with no income yet, the free tier genuinely gets the site live and the resume out, and the domain can wait until interviews start landing.
The timing
Your cohort is applying to the same jobs, in the same week, with the same link
Graduation week creates a burst. Thirty people who trained together apply to the same listings within days of each other, from the same city, with portfolios that share a shape. The recruiter reading them starts to pattern-match, and once they pattern-match they stop reading. That is not cynicism about recruiters. It is what happens to any human on the fortieth similar document.
So break the pattern where it is cheap to break. Lead with the project that has a real user, not the one with the prettiest screenshot. Put the bug story where a skim will hit it. When you send the link, add one sentence naming which project to open and why it matches their listing, because you have just done the reviewer a small favor and demonstrated the exact filtering instinct they are hiring for.
Then keep going after the burst. Add one project every month or so, rewrite the weakest case study, sharpen the opening line as the role you want comes into focus. Most of your cohort will stop updating the page by week three. The one who is still adding work in month four is not more gifted than the rest of you. They just kept a habit, and a habit is the one advantage nobody can copy off you.
Frequently asked questions
How do I make my bootcamp portfolio stand out?
Change the content, not the theme. Replace one of the standard course builds with a project that has a genuine user, then publish the reasoning: the fork you took, the option you turned down, the bug that cost you two days, and the features you cut to ship. Reviewers are drowning in identical projects. They are starved of evidence that a candidate can think.
Should I put my bootcamp capstone in my portfolio?
Yes, but not the version you submitted. Strip the assignment framing, name the deadline and the constraints you worked under, and add an honest note about what you would rip out and rebuild today. A candid post-mortem on your own graded work reads as maturity. The same project presented as flawless reads as a course certificate.
How many projects should a bootcamp portfolio have?
Two or three, each fully written up. Reviewers do not count tiles, they sample one and form a view, so a dozen thin entries just invites them to open your weakest. Three deep write-ups mean any one they choose shows you reasoning. If only one project is truly yours to defend, launch with that one and add the next while applications are out.
Do recruiters actually look at GitHub?
Engineers on the panel sometimes do. Recruiters, who see your application first and are usually not engineers, mostly cannot use it, because a profile sorts a forked config repo and your best build side by side with no explanation. Treat GitHub as your proof layer and put a page in front of it that tells a stranger which repo to open and what it demonstrates.
What if I have no real work experience after the bootcamp?
Then manufacture the closest available thing, which is a user. Build one small page for a club, a local trade or a friend running something on the side, and hand it over. You now have requirements you did not choose, feedback you did not want, and scope you had to cut. That is the raw material of every good case study, and it takes about two weeks to get.
Where can a bootcamp graduate build a portfolio for free?
Folio publishes a portfolio, a blog and a resume on its free tier, and resume export to PDF and DOCX carries no paywall or watermark at all. The honest cost is that Free includes zero custom domains, so you sit at portfolio.wrxstack.com/yourname with a Made with Folio credit shown, AI drafting caps at 10 generations each month, and your theme choice is the core set rather than all 60.