Building a portfolio site for a client — a designer, a photographer, a freelance writer who isn’t technical — puts you in an odd position. You could hand them a WordPress install and a theme, which means you’re now on the hook for their hosting, their updates, and every “can you just change this text” request forever. Or you build something custom, which is overkill for a five-page portfolio and takes longer than the client’s budget usually accounts for.
This is about the middle path: something that looks custom, that you can build fast, and that the client can actually maintain themselves once you’re done.
Why the usual options are both wrong here
A full CMS handoff means you’re implicitly signing up for ongoing support. Every client who isn’t technical will eventually email asking why the site looks broken, and the honest answer is usually “a plugin updated and something conflicted” — a problem you now own indefinitely for a project that was scoped as a one-time build.
Custom-coding a static site solves the maintenance problem but creates a new one: the client can’t update anything themselves. Every text change, every new project added to their portfolio, comes back to you as a request — which is fine if you want an ongoing retainer, and a bad outcome if you were expecting this to be a single billed project.
What the client actually needs to be able to do
- Swap images for new work, without touching code.
- Edit text — a bio, project descriptions, contact details — directly.
- Not break the site while doing either of those things. This is the part CMS handoffs usually fail at.
Where a simple page builder actually fits
This is the specific gap a tool like Carrd fills for this kind of handoff: you build the initial layout and design once, using real typography and layout choices rather than a generic template, and the client edits content afterward through a simple visual interface with no way to break the underlying structure. You’re not learning their CMS because there isn’t one to learn — and you’re not stuck maintaining it because there’s nothing fragile enough to require you to.
Building it so it doesn’t look templated
Pick real typography before you start
The single biggest lever for making a one-page site look intentional rather than default is choosing a typeface pairing that isn’t the tool’s out-of-the-box font. Ten minutes spent here changes the entire feel of the finished page.
Design around their actual work, not generic placeholder content
Build the layout using the client’s real photos or writing samples from the start, not lorem ipsum. A layout that works with placeholder content often needs rework once real content goes in — better to discover that during the build than after handoff.
Document the handoff in five minutes, not a manual
A short screen recording showing “here’s how you swap this image, here’s how you edit this text” is more useful to a non-technical client than a written guide, and takes less time to make than it would to write out the same instructions clearly.
Setting expectations about scope
Be explicit with the client about what they can and can’t change themselves — content and images, yes; fundamental layout changes, generally no, unless you’re being retained for that. This avoids the awkward conversation later where they expected you’d still be available for every request, when the whole point of this approach was that they wouldn’t need to be.
Pricing the work honestly
It’s worth pricing this kind of project as what it actually is — a focused, scoped build, not a discounted version of a full custom site. Clients sometimes assume a simpler-looking tool means less value delivered, but the value here is speed, a maintainable result, and not needing you on retainer forever — all things worth stating plainly when you’re explaining the approach and the price, rather than letting the client assume “simple tool” means “should cost less.”
What to skip
Skip building in functionality the client didn’t ask for — a blog, a booking system, an e-commerce section “just in case.” Scope the build to what’s actually needed for launch; anything speculative is easier to add later, once there’s a real reason for it, than to maintain unused from day one.
Quick checklist
- Confirm what the client actually needs to edit themselves before you start building.
- Choose real typography — this alone avoids the generic-template look.
- Build with the client’s actual content, not placeholder text.
- Record a short handoff walkthrough instead of writing a manual.
- Set clear expectations about what’s in scope for self-editing versus a future request.
The best outcome for this kind of project is one where the client never needs to email you again — not because you disappeared, but because they genuinely don’t need to.
Tested firsthand
