Portfolio Website Source Code: Buy, Build, or Let AI Generate It

September 29, 2026 · 11 min read

By Ahmed HusseinFounder of Seera · Software Development Engineer at AmazonReviewed by Mazen Ahmed

Quick answer: There are four ways to get the code behind a portfolio site — write it, take a free template, buy one, or have a model generate the files — and developers almost always choose on aesthetics when the decision actually turns on three things: hours to live, what the licence lets you do, and what you inherit in year two. Write it yourself only if frontend work is the job you are applying for, because then the repo is a work sample. Otherwise take a template or generate the files, check the LICENSE before the README, and spend the saved weekend on the projects the portfolio is supposed to be showing. If you want the layout decided for you rather than the code, our developer portfolio template guide covers the design side; this one is about the code and the paperwork attached to it.

React component source code open in a code editor, showing JSX markup and nested div elements

Image credit: Antonio Batinić / Pexels

Key Takeaways

Every route gets you a working portfolio. They differ in what you are actually acquiring, and the differences only show up later — the first time you need to change something, or the first time someone asks whether you had the right to ship it.

Route What you actually get Realistic hours to live Where it hurts
Write it from scratch An empty repo and total control 20–60, honestly Year two: dependencies, rebuilds, drift
Free template (GitHub) Someone's design, plus a licence you must read 3–8 No licence file means no permission
Free template (studio, e.g. CC BY) A polished static site, credit required 2–6 Attribution stays unless you pay to remove it
Paid template Design plus support, per-licence terms 2–6 Still entirely yours to maintain
AI-generated files HTML/CSS you host, murky authorship 1–4 Confident-looking bugs; thin structure
Hosted AI builder A live site and no repository at all Minutes Less control; you own content, not code

Table of Contents

What Source Code Actually Buys You

"I want the source code" is usually shorthand for one of three different wants, and they have different answers. Sometimes it means I want to be able to change anything. Sometimes it means I do not want to pay a subscription. And sometimes it means I want the site itself to be evidence that I can build things. Only the third is really about code.

Worth separating out, because the first two are cheaper to satisfy than developers assume. Full control over markup matters if you are doing something unusual — a canvas experiment, a custom WebGL header, an interaction you cannot express in someone else's component. For a page with a hero, a project grid, a work history and a contact link, the control is mostly theoretical: you will use perhaps five percent of it, and you will pay for a hundred percent of it in maintenance.

The subscription argument is also softer than it looks once hosting, a domain and your own hours are on the same line. Static hosting is free or near-free on several platforms, so the honest comparison is not subscription versus zero — it is a subscription versus your weekend, plus the evening in eight months when a dependency upgrade breaks the build and the site is the thing standing between you and a recruiter.

The third want is the legitimate one, and it has a precise scope: if the job you are applying for is frontend or design engineering, the repository is a work sample. Reviewers will look at it. That is a real reason to write the code yourself, and it is the only reason on this page that outweighs every argument for speed below.

Route 1 — Write It Yourself

The most underestimated option, and the one developers estimate worst. A portfolio is a small project, so the instinct says a weekend. In practice a portfolio you are willing to put in front of a hiring manager needs responsive layout at three or four breakpoints, accessible focus states and semantic landmarks, real content, image optimisation, Open Graph tags so the link does not look broken in Slack, a sitemap and metadata, a deploy pipeline, and a domain. The build is not the hard part. The finishing is.

Budget honestly: for a developer who writes frontend regularly, twenty hours to something genuinely good. For a backend, data or infrastructure engineer who does not, closer to forty or sixty, and most of the extra time goes into design decisions rather than code — how much space to leave, which type scale, what to do with the awkward gap between the project grid and the footer. That is design labour, and being strong at systems programming does not shorten it.

What you get in return is real: a repository you understand completely, no vendor between you and the markup, and — if you are being assessed on frontend craft — an artifact that argues for you. What you also get is ownership of every future change. That is fine as long as you price it in.

Route 2 — A Template Somebody Else Wrote

The pragmatic middle, and the route most developers should take. You get a finished design, you swap the content, and you keep the ability to open any file and change it. Three flavours, with genuinely different trade-offs.

A GitHub repository. Search the portfolio and portfolio-template topics, sort by stars, and you will find hundreds. Advantages: real commit history, visible issues, and often an active maintainer. Disadvantages: quality varies wildly, many are abandoned mid-refactor, and a large share carry no licence at all — which, as the licence section below explains, is a hard stop rather than a detail. Read the last ten commits and the open issues before you fork anything.

A template studio. Studios that publish static site templates are the fastest credible route to a good-looking page: the design is coherent, the markup is usually clean, and there is no build step to inherit. The catch is the licence. HTML5 UP, to take the best-known example, releases its templates under the Creative Commons Attribution 3.0 licence, which means you may use them commercially as long as you credit the author — the footer credit is the price of the template. An attribution-free option exists through its sister service for a one-off fee. Neither is a problem; not noticing which one you agreed to is.

A paid template. Marketplaces sell polish, documentation and sometimes support, typically for the price of a couple of months of a hosted builder. The thing to check before buying is the licence scope: marketplace licences are commonly granted per end product, so the template you bought for your own site may not cover the client site you build next month. Check whether stock photography in the demo is included too — frequently it is not, and the demo you fell for is partly made of images you did not buy.

All three leave you with the same responsibility as writing it yourself: it is your code now, including the parts you have not read.

Route 3 — Let a Model Generate the Files

Ask a capable model for a portfolio page and you will get plausible, well-structured HTML and CSS in under a minute, which is a genuine change from three years ago. Two distinct things get called "AI" here, and conflating them causes most of the disappointment.

A model writing source files gives you HTML, CSS and maybe a component or two that you host yourself. You keep the files, you keep control, and you skip the blank-page problem that stalls most from-scratch builds. It is best treated as a very fast first draft: models are strong at structure and conventional layout, and weaker at the things that are invisible until tested — focus order and keyboard traps, contrast ratios, whether the layout survives a 320-pixel viewport, and whether the metadata is real or decorative. Assume you are reviewing a junior pull request, because that is roughly what it is.

A hosted AI builder is a different product: you give it a resume, it produces and hosts a live site. You do not get a repository, which is precisely the trade — you give up file-level control and get a finished, hosted, maintained page in minutes instead of hours. That is the right trade for most engineers whose portfolio is not itself the work sample, and the wrong one if you want to hand-tune the markup. Our step-by-step AI build walkthrough covers that path end to end.

Two cautions specific to generated code. First, verify rather than skim: the failure mode is not code that crashes, it is code that looks right and quietly ships an empty alt attribute, a heading hierarchy that jumps from h1 to h4, or an og:image pointing at a file that does not exist. Second, the authorship question in the licence section below is worth understanding before you publish the result as a template for other people to use.

The Licence Questions Developers Skip

This is the part that gets skipped, and it is the only part with consequences you cannot refactor your way out of. Three rules cover almost every real situation.

No licence file means no permission. GitHub's documentation states it plainly: without a license, the default copyright laws apply, meaning the author retains all rights to the source code and no one may reproduce, distribute or create derivative works from it. Publishing publicly grants other users the right to view and fork the repository under GitHub's terms, and that is the extent of it. So the popular, unlicensed portfolio repo with four thousand stars is not a free template. It is someone's reserved work that you may read. Open an issue and ask the author to add a licence — most will, and the request is a normal part of open-source life rather than an imposition.

Permissive licences have terms, and they are cheap. MIT, BSD and Apache-2.0 all let you do essentially what you want commercially, provided you keep the copyright notice and licence text in the source. That is one comment block in a file nobody visits. Creative Commons Attribution is a step further: the credit must be visible, which in practice means the footer line stays. Copyleft licences such as the GPL are rarer for site templates but worth recognising, because their conditions attach to what you distribute rather than to what you merely host.

AI-generated code sits in an unsettled place, and for your own site that is fine. In Part 2 of its report on copyright and artificial intelligence, the U.S. Copyright Office concluded that outputs of generative AI can be protected only where a human author has determined sufficient expressive elements, and that prompts alone are unlikely to supply enough human contribution. It also confirmed that using AI to assist creation, or including AI-generated material inside a larger human-authored work, does not bar copyrightability. Read that as a practical rule rather than a warning: hosting your own portfolio requires you to enforce nothing against anyone, so the question never arises. It arises the day you publish that generated template for others to use, or sell it — at which point your own substantive edits on top of the output are what you would be relying on.

Without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work.

One more habit worth forming: check the images separately from the code. Template demos routinely use stock or Unsplash photography that is not part of what you downloaded, and the licence covering the markup says nothing about the hero photograph. Swap demo imagery for your own before launch, which you should be doing anyway — a generic stock desk photo is the clearest possible signal that the page is a template with the labels changed.

Year Two: The Cost Nobody Budgets For

Every comparison of these routes is written about launch day, which is the one day the differences do not matter. Here is what separates them twelve and twenty-four months later.

Dependencies rot. A static HTML and CSS portfolio will still build in three years. A framework portfolio accumulates security advisories, a major version bump, a build tool that changes its config format, and a Node version that stops being supported by your host. None of it is hard; all of it is unpaid work arriving at random times, usually when you are busy. Automating the boring half with Dependabot alerts is worth the ten minutes it takes to enable.

Performance regresses quietly. Hand-coding does not confer speed; measuring does. The Core Web Vitals thresholds are public and worth holding your build to: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less. INP replaced First Input Delay and became a stable metric in 2024, so an older checklist may have you optimising a retired number. A custom build with a component library, four font weights and an autoplaying header video will lose to a plain hosted page on all three.

Rendering choices decide whether you get indexed. A hand-built client-side-rendered single-page app is the classic way a developer portfolio ends up invisible: the markup arrives empty and the content appears only after JavaScript executes. It can work, but it is a thing you now own and must verify. Static output or server rendering avoids the whole category, and Google's JavaScript SEO basics is the reference for checking your own. Nobody is searching for you by name and finding a blank div on purpose.

The content goes stale faster than the code. This is the real failure mode across every route. Portfolios die of neglect, not of technical debt — the last project is from two jobs ago and the bio still says "currently seeking". Whichever route you pick, the one that wins is the one you will actually edit on a Tuesday evening. For a lot of engineers that argues against the beautiful custom build they are proud of and reluctant to touch.

Skip the build — turn your resume into a live portfolio free →

Which Route, for Which Developer

Condensed to the recommendation I would actually give a colleague, in order of how common the situation is.

Whatever you choose, get a domain of your own on it and put the link on your LinkedIn profile. A portfolio nobody can find is the same as no portfolio, no matter who wrote the CSS.

Frequently Asked Questions

Where can I get free portfolio website source code?

Three places cover almost all of it. GitHub, by browsing the portfolio and portfolio-template topics and sorting by stars, which gives you real projects with real commit histories. Template studios such as HTML5 UP, which publish polished static sites under a Creative Commons Attribution licence. And framework starter templates — the official Next.js, Astro and Hugo example repositories, which are maintained by the projects themselves and are the safest technical bet of the three. Whichever you pick, open the LICENSE file before the README, because free to download and free to use are different claims, and a repository with no licence file at all grants you no permission to reuse the code.

Can I use a free portfolio template from GitHub on my own site?

Only if it carries a licence that says you can. GitHub's own documentation is blunt about the default: without a license, the default copyright laws apply, meaning the author retains all rights and no one may reproduce, distribute or create derivative works from the work. Publishing the repository publicly gives other GitHub users the right to view and fork it, and nothing more. So a starred, unlicensed portfolio repo is not a free template — it is someone's reserved work that you are allowed to look at. Where a licence does exist, MIT and similar permissive terms only ask that you keep the copyright notice, which costs you one comment in a file.

Who owns the code an AI writes for my portfolio?

Less settled than most developers assume, and it matters less than they fear. In Part 2 of its report on copyright and artificial intelligence, the U.S. Copyright Office concluded that generative AI outputs are protectable only where a human author has determined sufficient expressive elements, and that prompts alone are unlikely to supply enough human contribution. Using AI to assist creation does not bar copyrightability, and neither does including AI-generated material inside a larger human-authored work. For running your own portfolio none of this bites: you are not enforcing a copyright against anyone. It becomes real the moment you try to sell or licence that code as a template, which is exactly when you want a human-authored diff on top of whatever the model produced.

Is a hand-coded portfolio faster than one from a builder?

Not automatically, and assuming it is has cost a lot of developers a weekend. A hand-rolled site can be extremely fast, because you control every byte and can ship one HTML file with inlined CSS. A hand-rolled site can also pull in a component library, three font weights, an animation package and a hero video, and lose to a hosted builder on every Core Web Vital. The thresholds to beat are public: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Measure your build against those on a mid-range phone before claiming the performance win, because the number, not the method, is what a recruiter's browser experiences.

Do employers care whether I coded my portfolio myself?

They care about the repository, not the rendered page. Nobody on a hiring panel opens view-source on a candidate's site to audit whether the CSS was hand-written; they open the projects it links to. The exception is narrow and real — if you are applying for frontend or design-engineering work, the site is a work sample and the code behind it is fair game, so ship something you would be happy to walk through in an interview. Everyone else is better served by the shortest route to a credible page, because the hours you save go into the thing that is actually being evaluated: the projects, the write-ups and the commit history behind them.

Useful sources and further reading

About the author

Ahmed Hussein — Founder of Seera · Software Development Engineer at Amazon

Ahmed is the founder of Seera and a Software Development Engineer at Amazon. He builds the AI that turns resumes into portfolio sites and writes about the engineering and product side of getting hired.

Reviewed by Mazen Ahmed, Co-founder & Growth Product Manager at Seera.

Editorial standards →