Chupin Resume - A Resume Shouldn't Be an Attachment That Expires

The Resume Market Actually Sells Three Unrelated Things

On the surface it's all called "making a resume", but underneath there are three separate businesses.

First, selling layouts. Super Resume, Wubaiding, Canva, Resume.io, Novoresume and the like. On the shelves are dozens of covers: two columns, timelines, skill progress bars, avatars, icon clouds. The user's anxiety is very specific — "my resume doesn't look formal enough". The product's solution is: swap in a skin that looks more formal.

Second, selling getting past machines. Jobscan, all kinds of ATS scoring, pasting the job description in to "optimize keywords". Online application systems want parseable fields: company name, start and end dates, job level. Two columns, text boxes and icons often parse into a mess of garbage. So a business in the opposite direction appears: taking the pretty template you just picked and compressing it back into a plain file that machines like.

Third, selling continuous presence. LinkedIn, Maimai, some portfolio sites. There is no ritual of "sending out a file" here; instead there's a profile that is forever half-public, plus a feed. What it solves is being found and being browsed, not "this week a referral goes out and the other side can read the whole thing as soon as they open it".

All three can make money, because job seekers' pain is real. But they rarely ask the same question: is there anything on this page that someone else can check with a single click?

Numbers, links, shipped work. Without these, changing covers and stuffing keywords just puts the same job description into a different container.

Template Sites Do the Wrong Problem Right

The layout market has latched onto aesthetic anxiety, not a reading problem.

A recruiter's first glance isn't to admire the design. The Ladders' 2018 eye-tracking study, cited to death, says the initial screening takes about 7.4 seconds (the 2012 edition said 6 seconds).¹ You needn't treat a lab number as a law, and some people will go on to spend thirty seconds or two minutes reading a solid resume to the end. But the initial screening really is a scan, not a savoring: job title, the most recent experience, and a few results that hold up. Decoration doesn't help, and may even block the view.

What's more troublesome is that the job seeker's optimization target and the recruiter's are opposite.

• Job seekers want to "look different from everyone else", so they pick two columns, illustrations, a row of colored skill bars.

• Recruiters want to "find evidence relevant to this role within ten seconds", so they need a stable order of information: who you are, what you've done, what the results were, where the work is.

• Application systems want "fields that can be extracted", so they hate exactly the differences you just picked.

So a very common farce appears: the same person maintains three resumes. One pretty one for "companies with taste", one plain one for the ATS, and one in Chinese for domestic online applications. The numbers don't line up, the project names are inconsistent, and an outdated performance claim is still sitting in "the pretty one".

The template sites aren't running the wrong business. They meet the need of "pick a nice-looking one" precisely. The problem is that this need helps little with applying and has a negative effect on maintenance cost. Every time you switch templates, you re-typeset a page. The content hasn't changed, yet the typesetting labor is treated as the product itself.

My own judgment is narrow: layout should be a constraint, not a shelf. The point of a constraint is to let you spend your time on the numbers and work that can show what you can do, rather than on "should this column become a timeline" — you're making a resume, not doing flashy web design.

Files Go Stale; a Link Is the Current Version

The attachment model has a flaw that is rarely talked about: it has no address.

With no address, there's no "current". What you send A is the March version, what you send B is the July version, and on your own disk there's also "final", "final-revised" and "final-really-final". The person who refers you casually forwards it, and as it gets passed along it turns into an archaeological artifact.

A web page is the opposite. The point of a stable URL isn't to be "more modern" but one pointer, with content that can change. Change a project, add a number, and whoever opens it sees this version. It's the same kind of thing as a Git repository, a personal site, or product documentation. Especially in the future of the information age, this is still the trend.

So why isn't PDF dead? Because it's a compatibility layer, not a truth layer.

Application systems at China's big companies and headhunters want attachments, and some processes require printing. Recruiting systems won't cancel "upload a resume" next year just because we like web pages. So the sensible structure isn't "replace PDF with a web page" but: the web page is the primary deliverable and the channel for fast iteration. The PDF is an export of the same sheet of paper. What you see on screen and what you send out should be the same layout, not two things each typeset separately. Otherwise you've only upgraded "three resumes" to "one website plus a PDF that doesn't match it".

Notion resumes and personal blogs used as resumes have already moved in this direction. Their problem usually isn't being "online" but "not looking like a page you can submit": the information architecture is meant for the owner, the density is meant for browsing, and on a phone you have to scroll a long way to reach the work. A portfolio site is for being browsed. A resume is for being skimmed to the end.

These two kinds of reading shouldn't be built into the same kind of site.

AI Writes Resumes and Turns Everyone into the Same Person

Over the past two years the resume market has gained another layer: paste in a job description and generate "more professional" bullets.

It solves the fear of the blank page. The cost is also clear. What models are good at is the job-description tone — "responsible for driving", "empowering the team", "end-to-end delivery". What they aren't good at is your facts: whether that metric was really yours, whether the link opens, whether the timeline adds up. So a batch of pages appears that read as very full but can't be checked. After seeing enough of them, recruiters become allergic to this kind of slick sentence.

This isn't "don't use AI". Typing less is a legitimate need. What's dangerous is treating generating and publishing as the same step.

The line I drew for myself: AI can read the PDF, Word or Markdown you already have, fill it into fixed fields, and turn it into a draft awaiting confirmation. A person must go through the numbers, links and roles. Work with no link that opens can't be published. A model has never owned those projects for you, so it shouldn't claim on your behalf that you did.

If recruiters later also use models in bulk to screen resumes, this line will only matter more. The cost for a machine to read an adjective is close to zero, and the cost of reading a 404 is also close to zero. Fabrication will be magnified, not covered up.

What Should Actually Stay on One Page

If you accept "skim to the end, not browse to the end", there are actually very few modules on a page, and the order shouldn't be something users have to invent themselves.

The order I eventually locked down is roughly:

1. Name, and a positioning line that holds up

2. Contact details you can click

3. Three to six evidence numbers, rather than "responsible for such-and-such"

4. A very short introduction

5. Experience, ordered by year

6. Work that's already live: role, action, result, plus a URL that opens

7. Skills, education, expectations — appear only when needed

I use "role / action / result" for work not because the framework is trendy but because it forces you to write things that can be checked. Work without a URL, in my view, is more like a line in your experience and shouldn't occupy the "work" slot.

Page count is also a constraint. One page not because of the motivational "less is more", but because reading the second page depends on the first page working first. The Ladders report actually says it too: some people do read the second page, but only if the first page is good enough. Most people's problem isn't that they lack paper; it's that the first page has no evidence that makes anyone want to keep reading, yet they keep piling up duties on the second.

Visually, I didn't invent a design language of my own. The colors, type and spacing of the page come from tw93's Kami (GitHub, MIT): warm cream paper, one ink blue, serif, dense setting. White is just the paper color for printing and sending attachments, not a second layout. Avatars, progress bars and a second accent color are things Kami itself advises against; when making a page for applications, they shouldn't be added back.

Chupin isn't a clone of Kami. Kami is a document design system for agents, and a resume is just one kind of paper in it. What I took is "how to typeset this one sheet of resume paper", and then I added structured data, publishing to a subdomain, and exporting a PDF from the same page.

To see what this paper looks like in a browser, open musk.chupin.site. It's a sample page with the same layout; the content is a demo, not real job-hunting material.

Who Shouldn't Turn Their Resume into a Web Page

Some people should stick with Word.

If you have nothing that can be opened — only a course list, internship duties and a job objective — a template site or a form from your school is faster. A web page won't conjure up work that never happened; forcing it only produces a very cleanly typeset blank.

If your main battlefield is application attachments and processes where nobody clicks links, a web page is superfluous. Keeping a clean single-column PDF is enough. The web page is for people who will click: referrals, emails, personal homepages, an address dropped into a chat.

People who build their personal brand as a multi-page case collection also shouldn't compress it into one page. That's a portfolio, and the way it's read is different. A one-page resume is a table of contents plus evidence, not an in-depth case study of every project.

These limits are product boundaries, and they are also my view of this market: not every job-hunting problem should be absorbed by an "online resume". What gets absorbed is just that one kind of person — someone who has made things that can be opened, needs a current version, and occasionally still has to hand over a file.

What Online Resumes Will Probably Become

I don't think "PDF will disappear in such-and-such a year". The file pipelines of recruiting change very slowly. What will really change is this: the file goes from being the primary deliverable to being a snapshot exported from a page.

A few things already visible:

A stable address will become the primary key of a person's work record. Like github.com/user, rather than a new file name every year. Change the content, not the pointer. A custom short domain just makes the pointer easy to remember; at heart it isn't a "personalized domain business".

People read web pages; machines read structure and files. Applications still need a PDF; more and more search and Q&A will go and scrape the names, work and dates on public pages. If a page has only decoration and no parseable structure, it's bad for both people and machines. This is the same thing as adding a set of Person / work structured data to a page, and doesn't need to be mythologized as an "AI recruiting revolution".

Checking will be worth more than wording. Models make sentences flow, and they also make sentences false. Links that open, numbers that can be explained, and timelines that line up will become the difference. A public page lowers the cost of checking — that's an advantage, and also a constraint. Content that isn't suitable to be public shouldn't be put up there.

Template shelves will still be around. New graduates, career changers, and people with no work yet will still buy that hour of "looking professional". That's another market. If an online resume becomes a second template market, it's just moving the shelf from PDF to the web, and not one reading problem has been solved.

One page and many pages will drift further apart. Portfolios, blogs and case studies will keep being sites. An application page will keep being a sheet of paper. Using one set of drag-and-drop tools to serve both kinds of reading usually ends up looking like neither.

If it has to be compressed into one sentence: the resume of the future is closer to "a current work record with an address" than to "an autobiography with a cover". The file is still there — it's just demoted to an export.

What Chupin Resume Hasn't Done and Won't Do

When building Chupin, I wrote a few things down as non-negotiable constraints, so that I wouldn't later add back the features the market is selling.

One layout, no skins, no drag-and-drop. Warm cream paper and white only change the paper color.

Structured data first, then render the page. The preview and the live page are the same HTML, and the PDF consumes it too.

No work links that really open, no publishing.

AI only fills in a draft awaiting confirmation; it can't auto-publish and can't fabricate numbers.

The brand is written Chupin, and in Chinese we call that page "Chupin" — literally "produced by". The visuals come from Kami, and the acknowledgment is on the About page.

These choices make the product narrow. The upside of narrow: you open the link and it's a resume page. Nothing steers you to browse templates. There's no second layout waiting for you to choose. What's left is rather plain work: write what you've done as sentences that can be checked.

If you're also tired of maintaining three mismatched attachments, take a look at chupin.site. If it doesn't fit, keep using Word. A resume tool shouldn't require everyone to turn job hunting into building a website.

+

Chupin Resume: https://chupin.site)