Should You Code Your Portfolio or Use a Builder? (2026)

You are a designer. You can see exactly how your portfolio should look, down to the spacing. And somewhere in the back of your head, a voice keeps saying that a real designer would just build it themselves, in code, rather than reaching for a tool.

That voice has stalled more designer portfolios than almost anything else. It turns a project that should take an afternoon into a months-long open tab, half-coded, never live.

And the reason it is so paralyzing is that it feels like a question of professional pride, when it is really just a practical decision with a clear answer.

This guide gives that answer honestly: whether you should code your portfolio or use a builder in 2026. It covers where the guilt comes from, what each path actually costs, and the clean line between the designers who genuinely should hand-code and the ones who should not.

Framekit is an AI website builder that produces the pages, galleries and structure of a creative portfolio from a description of your work, which is the route to take when you want the site to exist rather than to be a project in itself.

A website builder is a tool that lets you assemble a site visually, without writing code. Coding a portfolio, by contrast, means building it yourself in HTML, CSS, and usually JavaScript.

The right choice between them is not about which is more impressive. It comes down to one honest question: is your portfolio a showcase of your work, or is it itself a sample of the skill you are selling?

Where the "I Should Code It" Guilt Comes From

The guilt is specific to designers, and it is worth naming. Designers work beside developers, often in the same teams, and absorb a quiet hierarchy in which building something in code is "real" and assembling it in a tool is a shortcut.

Add the fact that a portfolio is a designer's most personal project, and using a builder can feel like the cobbler's children going barefoot. The guilt is understandable.

It is also, for most designers, a category error: it treats the portfolio as a test of whether you can code, when for most design roles, nobody hiring you cares, or even asks.

What Coding Your Own Portfolio Actually Costs

Hand-coding a portfolio is not free, even if you never pay a bill for it. It costs time, usually far more than planned, because a portfolio is never quite finished and every small change is now a code change.

It costs ongoing maintenance: dependencies age, things break, and the site quietly becomes a small software project you are responsible for.

And it costs opportunity, because the hours spent debugging your own CSS are hours not spent on client work, on your actual craft, or simply on having a live portfolio sooner.

For a developer, those costs are low, because the skills are already there. For a designer, they are very real.

Generating raw code with AI does not remove them either, as our guide on vibe-coding a website explains.

What the Coded Path Actually Looks Like in 2026

In one linea hand-built portfolio is a static site generator, a CSS approach, a host, and a domain, and three of those four are genuinely free, which is the strongest argument for coding and the one usually made badly.

If you are going to price this decision honestly, price what you would actually build.

The generator. Astro is the current default for a content site and the easiest to justify, because it ships almost no JavaScript by default and a portfolio is mostly images and text.

Next.js is the choice if you want React and expect the site to grow into something with logic in it. Hugo and Jekyll remain excellent and are the right answer if you would rather not have a dependency tree at all.

The styling. Tailwind if you want to move fast and do not mind the markup, plain CSS if you would rather own it. This is genuinely a taste decision and not a cost one.

The host. Netlify, Cloudflare Pages and GitHub Pages will all host a static portfolio for nothing, and so will Vercel with a significant caveat covered in the next section.

Cloudflare Pages serves static assets with unlimited requests on the free plan, capped at 500 deployments a month and 20,000 files per site, which no portfolio will approach.

The domain. Around $20 a year after the first, and this is the only guaranteed recurring cost of the coded route.

So what does it cost? About $20 a year, against $108 to $468 a year for a builder. Over five years that is roughly $100 against $540 to $2,340, and anyone telling you the coded route is not cheaper in cash is wrong. The argument against it was never the money.

The Free Hosting Catch That Applies to Exactly This Audience

In one lineVercel's free Hobby plan prohibits commercial use, and its definition of commercial is broad enough to cover a freelancer's own portfolio, which is the single most common thing people deploy to it.

This deserves its own section because the people most likely to hit it are the people most likely to read this post.

What the restriction says. Hobby is for personal, non-commercial use.

Vercel treats commercial usage as any deployment that serves the financial gain of anyone involved in building it, which explicitly extends to a paid freelancer or consultant who wrote the code, not only to the site's owner.

Accounts that cross the line get warned and can be disabled.

Why that catches portfolios. A freelance photographer's portfolio exists to get paid work. A designer's site lists services and rates. A creative selling presets has a shop on it.

Under that definition each of those is commercial use, and the fact that the site makes no money directly does not help, because the site's purpose is your financial gain. A student showing coursework is fine.

A working creative is, on a plain reading, not.

What to do instead, and it is easy. Netlify's free plan carries no commercial restriction.

The free tier gives 100 GB of bandwidth, 300 build minutes, and 10 GB of storage a month, which is far beyond what a portfolio consumes. Cloudflare Pages is likewise fine for this.

GitHub Pages is worth reading the terms on, because it also carries restrictions around running a business.

The general lesson, which outlives these specific terms. Free tiers are free because their terms define a use you are probably not making.

Read the acceptable-use section rather than the pricing page, and re-read it if your site starts selling something. This is not a reason to avoid free hosting. It is a reason to pick the one whose terms match what you are doing.

What a Coded Portfolio Costs in Year Three

In one linethe build is the cheap part and the decay is the expensive part, because a codebase you have not touched in two years often will not build, and fixing that is a worse afternoon than the one you saved.

Nobody budgets for this because it is invisible at the moment you decide.

Dependencies rot. A Next.js or Astro project pulls in a dependency tree, and those packages ship breaking changes, deprecations and occasional security advisories. Leave it eighteen months and the install alone can fail.

Hugo and Jekyll hold up far better here, which is a real and underrated argument for the boring choice.

Frameworks ship majors. A major version arrives, your version stops getting fixes, and the upgrade is a project rather than a command. You do it, or you accept running something unmaintained, and both are choices with costs.

You forget your own code. This is the one people underestimate. The clever layout solution you were pleased with is completely opaque to you two years later, and re-reading it takes longer than writing it did.

The honest counterweight. If you build with Hugo, Jekyll, or hand-written HTML and CSS, most of this does not apply. A static site with no build dependencies will still work in a decade.

The decay problem is specifically a problem of modern JavaScript frameworks, and choosing an older-fashioned tool removes it almost entirely.

The mitigation if you go this route. Pin your versions, write a short README explaining how to run and deploy the thing, and set a calendar reminder to run the build once a quarter.

Fifteen minutes four times a year prevents almost all of this, and virtually nobody does it.

What a Builder Actually Costs, and Doesn't

A builder has costs too, and pretending otherwise would be dishonest. It is a subscription, modest but ongoing. It keeps you inside its editor, so you trade away some unlimited control. And a weak builder produces generic output.

But notice what a builder does not cost: it does not cost weeks, it does not become a maintenance burden, and it does not require you to context-switch from designer to debugger.

A modern builder, especially an AI one, produces a genuinely well-designed site quickly, and for a designer the visual control is usually more than enough, because you have the eye to use it well.

Our honest look at whether AI website builders are any good covers how far the better ones have come.

Coding vs a Builder: An Honest Comparison

The row that decides it is the signal row. Hand-coding signals front-end skill, which is valuable only if front-end skill is what you are being hired for. For everyone else, it signals nothing a client weighs.

Who Should Code Their Portfolio, and Who Should Not

The honest split is clean. Code your portfolio if you are a front-end or web developer, or a designer who genuinely codes, and the site itself is a sample of the work you want to be hired for.

In that case the portfolio is the proof, and coding it is the entire point.

Use a builder if you are a graphic designer, brand designer, product or UX designer, illustrator, or any creative whose job is design rather than shipping production code. For you, the portfolio showcases the work. It is not the work.

Fighting code to demonstrate a skill nobody is buying is effort spent in the wrong place.

Does a Coded Portfolio Actually Impress Anyone?

In one lineit depends entirely on the job you want, and the honest answer splits cleanly rather than landing in the middle.

The guilt this post opens with is mostly aimed at the wrong audience, so it is worth separating who is actually looking.

If you want front-end engineering work, yes, and materially. The site is a work sample, the repository is a work sample, and how you handled accessibility, semantics and responsive behaviour is legible to the person hiring you.

Here the coded portfolio is not a vanity project; it is the strongest single artefact you can present.

If you want design work, almost never. Design hiring looks at the work, the thinking behind it, and the case studies.

In many years of these conversations the question of what a designer's portfolio was built with comes up rarely, and when it does it is small talk.

A designer who spent three months coding a portfolio has three months of no case studies to show for it.

If you are a photographer, filmmaker, or illustrator, no, and it can hurt. Clients are assessing the work.

A hand-built gallery that is slightly worse at showing images than an off-the-shelf one is a net loss, and it is a common outcome, because galleries are harder to build well than they look.

If you want to learn, that is a real reason and it should be named as one. Building your own site to get better at building things is legitimate.

It is just a different project from getting a portfolio online, and conflating the two is how people end up with neither.

The Case Most Designers Land On

Most designers, once the guilt is set aside, land in the same place. The portfolio's job is to show the work and get them hired, fast, and a builder does that job better for them than a hand-coded site would.

A UX designer is hired for research, flows, and judgment, not for hand-written media queries. A brand designer is hired for identity systems. The site is the frame, not the painting.

Using a builder is not the lazy choice for these designers. It is the correct allocation of a finite amount of time, toward the work that actually wins clients.

Our roundup of the best website builders for graphic designers covers the tools that respect a designer's eye.

The Real Risk: A Portfolio That Never Ships

There is a third outcome the debate usually ignores, and it is the most common one of all: the portfolio that gets neither coded nor built, because the designer is stuck deciding.

It happens like this. You decide to hand-code it, because that feels right. You build the structure on a good weekend. Then client work lands, the energy drains, and the half-finished code sits in a folder.

Three months later a recruiter or a prospective client asks for your portfolio, and the honest answer is that you do not have a live one. The coded version was always going to be better, in theory.

In practice, theory does not get you hired.

This is the cost that does not appear in any comparison table, and it is the one that actually hurts.

A live, genuinely good portfolio built on a builder beats a perfect coded portfolio that does not exist yet, every single time, because only one of them can be sent to a client today.

So if you take one thing from this guide, make it this: ship something. If you are genuinely a developer and coding it is fast for you, code it and ship it. If you are not, use a builder and ship it.

The failure mode to fear is not picking the slightly less impressive tool. It is spending the next six months with no portfolio at all while you decide. The designers who win work are simply the ones who are live.

Frequently Asked Questions

Should I code my portfolio or use a builder?

Code your portfolio if you are a web or front-end developer and the site itself works as a code sample for the jobs you want.

Use a builder if you are any other kind of designer, because the portfolio's job is to show your work, not to prove you can code. For most designers, a builder gets a strong site live far faster with no maintenance burden.

Does coding my own portfolio impress employers?

It impresses employers only when they are hiring for front-end or web development skill, in which case the coded site is a relevant work sample.

For graphic, brand, product, and UX design roles, employers assess the work in the portfolio, not how the site was built. A hand-coded portfolio rarely earns extra credit in those interviews, and a weak one can cost you.

Is it unprofessional for a designer to use a website builder?

No. This is the guilt talking, not reality. Clients and employers judge the quality of the work shown and the clarity of the site, not the tool used to assemble it.

A polished portfolio built quickly on a builder is more professional than a half-finished hand-coded one. Using the efficient tool for a non-coding job is a sign of good judgment, not a shortcut.

How long does it take to code a portfolio from scratch?

For most designers, coding a portfolio from scratch takes weeks of part-time work, and often longer, because a portfolio invites endless tweaks and every tweak is a code change. Developers who do this routinely are faster.

A builder, by contrast, gets a designer to a live, polished portfolio in hours. The time difference is the core of the decision.

Do UX designers need to code their portfolio?

No. UX designers are hired for research, information architecture, interaction design, and judgment, not for writing production front-end code. A UX portfolio needs to present case studies clearly and tell the story of your process.

A builder does that well. Time spent hand-coding the site is time not spent making the case studies themselves stronger.

What are the downsides of using a builder for a portfolio?

A builder is an ongoing subscription, it keeps you working within its editor rather than giving unlimited control, and a weak builder can produce generic-looking output.

The first two are minor for most designers, and the third is solved by choosing a strong, design-led builder. None of these outweighs the weeks of time and maintenance a hand-coded site costs a non-developer.

Can I start with a builder and code it later?

Yes, and it is a sensible plan. Use a builder to get a strong portfolio live now, so you are not losing opportunities while a coded version sits unfinished.

If you later decide a hand-coded site genuinely serves your goals, for example because you move toward front-end work, you can rebuild then. A live builder-based portfolio today beats a perfect coded one someday.

Is free hosting really free for a freelance portfolio?

It depends on which host, and the difference matters.

Vercel's Hobby plan prohibits commercial use, and it defines that as any deployment serving the financial gain of anyone involved in building it, which on a plain reading covers a freelancer's own portfolio because the site exists to win paid work.

Netlify's free plan carries no such restriction and says so in its own words: on the Free plan you can deploy commercial projects, personal sites, or other creative explorations, as set out in Netlify's announcement of the plan.

It allows 100 GB of bandwidth and 300 build minutes a month. Cloudflare Pages is also fine. Read the acceptable-use terms rather than the pricing page.

What does it cost to code your own portfolio?

About $20 a year, which is the domain, because Netlify, Cloudflare Pages and GitHub Pages will host a static site for nothing.

Against a builder at $108 to $468 a year, the coded route is roughly $100 over five years versus $540 to $2,340, and anyone claiming otherwise is wrong about the cash.

The cost that actually decides this is your time: a first build realistically runs weeks rather than days, and the maintenance arrives in year two when a framework you have not touched no longer builds.

Does coding your own portfolio impress employers?

For front-end engineering roles, yes and substantially, because the site and its repository are both work samples and your handling of semantics, accessibility and responsive behaviour is legible to whoever is hiring.

For design roles it is close to irrelevant; hiring looks at the work and the thinking, and a designer who spent three months coding has three months of missing case studies.

For photographers and illustrators it can actively hurt, because a hand-built gallery is usually worse at showing images than an off-the-shelf one.

Which static site generator should I use for a portfolio?

Astro if you want something modern and content-first, because it ships almost no JavaScript by default and a portfolio is mostly images and text. Next.js if you want React and expect the site to grow logic.

Hugo or Jekyll if you want the thing to still build in five years without attention, which is the most underrated consideration in this whole decision, since dependency rot is what kills coded portfolios rather than any design failing.

The Bottom Line

Should you code your portfolio or use a builder? Strip away the guilt and the answer is simple. If shipping code is the skill you sell, code it, because then the site is the sample.

If your job is design, use a builder, because the portfolio's only job is to show your work and get you hired, and a builder does that in hours instead of weeks, with nothing to maintain.

The designers who ship a live portfolio are the ones who get the work. The ones still hand-coding theirs are often still not live. Choose the path that gets your work in front of clients soonest.

For the gentlest starting point, see our roundup of the easiest portfolio website builder to use.

_Re-verified July 2026: the free-tier hosting terms were read on the acceptable-use pages rather than the pricing pages, because that is where the commercial-use restrictions live._