ShellScholars is a portfolio builder. Instead of a static resume or a LinkedIn profile you don't fully control, you get one link - your shell - that shows the right person the right proof. A recruiter, a friend, and a stranger can each open the same URL and see a version tailored to them. One link · many versions of you.
Every tool people use to represent themselves fails at the same job: none of them let you control what a specific audience sees. A recruiter, a client, and a curious stranger arrive with different questions - and today you answer all of them with the same page.
Ongoing - building in public
Each existing option breaks somewhere different - and the break is always the same shape: you cannot decide what a given reader sees.
A portfolio isn't a page - it's an answer to a question, and different readers arrive with different questions. So visibility belongs on the smallest unit of content (the block), not on the page. That single decision is what makes one link able to be many versions of you.
Signup to shared link, with no blank canvas anywhere in the path.
Claim your shell
Google or a passwordless magic link. No password to set.
0 frictionOnboard in 2 steps
Name, location, and a public URL checked live for availability.
Suggested slugSeed the content
Upload a resume and let AI build it, pick a discipline template, or start blank.
Never a blank pageEdit in place
Add, reorder, and edit blocks on your live page. Set per-block visibility.
Publish on saveShare one link
The same URL for everyone. Approved connections unlock reserved blocks.
One surfaceLearn from it
Insights show how the shell is viewed; requests ask for deeper access.
Feedback loop
// Import is an accelerator, not an authority - the parser drafts, the user confirms.
Keeping this vocabulary tight is what keeps the UI teachable.
| Term | What it means |
|---|---|
| Shell | Your portfolio and its single public link. You can have more than one. |
| Block | A modular content card - banner, project, timeline, metric, testimonial, bio, contact. |
| Visibility | A per-block setting: Public, Connections-only, or Hidden. |
| Connection | Someone you approved to see your restricted blocks. |
| Insights | Analytics on how your shell is being viewed. |
Visibility is a property of every block, so the page composes itself around the reader.
// Same link, two readers, two pages.
// You always edit the live page; Save publishes and writes a change log entry.
Anyone who needs to prove what they've done and control who sees it.
ONE SURFACE
A single durable URL replaces the resume, the profile, and the scattered project links.
PER-BLOCK VISIBILITY
Public, connections-only, or hidden - the same link renders a different version of you.
STARTER BLOCKS
Discipline templates seed a curated starter shell, so the blank page is never the first screen.
SOLE OWNER
Product, design, frontend, and database - built end to end on Nuxt and Supabase.
Four calls that shaped everything downstream.
A preview mode would have been simpler to build and safer to ship.
Splitting "edit" from "see" is exactly what makes portfolio tools feel heavy. You edit the live page and publish on Save.
Less creative freedom for the author.
Constrained blocks keep every shell legible and let me upgrade the design system underneath without touching anyone's content.
An extra confirmation step between upload and a finished shell.
Treating extraction as truth makes the first impression wrong in a way people don't come back from.
More state to design and explain per block.
Audience control on the page level just means maintaining two portfolios again - the exact problem this replaces.
Passwordless auth, live slug availability, discipline templates, and AI resume import.
Drag-and-drop editing on the live page, per-block visibility, publish-on-save with a change log.
Connection requests and approvals that gate restricted blocks; analytics on how a shell is viewed.
Which blocks actually carry a visit - the signal that tells someone what to write more of.
Requesting and granting access should feel social, not administrative.
Plus continued design upgrades that roll out to existing shells without asking anyone to rebuild.
Owning every layer - product, design, frontend, and database - means every scope decision is also an engineering decision. The hardest part of ShellScholars hasn't been building blocks; it's been deciding what the product refuses to do, so the thing it does do stays sharp: give one person one link that tells the right story to the right reader.
