Sell a Website, or Sell What Makes One Yours
There are two different things you can sell here. A finished website, the whole real thing, to as many buyers as want a copy. Or a Content Package, real words and pictures made to drop into one specific website someone already sells, so a buyer can make it look like their own business instead of someone else's demo. A free tool called the Content Installer is what connects the two together automatically.
The Two Things You Can Sell
Both are stored the same honest way everything sold on this site is stored: never a copy sitting on this site's own servers. This site only ever remembers a name and the address of a real code-storage website account called GitHub, one that the seller already owns and keeps control of. Buying either one is meant to work the same way buying a program from this site already does: sign in, click buy, and the download button appears on your own account page.
1. A Website Listing
A whole, finished website — the real code for every page. One listing can be sold to many
different buyers, the same way a program or a template normally is. It can also be given away for
free. A seller gives it a name and pastes in the address of the GitHub repository that holds the
real files; everything else shown about it (a description, a price, screenshots) is read live from
a short, plain block of text near the top of that repository's own README.md file, so
the seller only ever has to update it in one place.
2. A Site Customization Package
Real words and pictures made for exactly one specific Website Listing, never more than one, because
the words and pictures only make sense for that one site's own layout. Where the "Media Package"
already used for marketing campaigns on this site is a loose folder of files, a Site Customization
Package is that same idea made stricter and checkable: one real file, manifest.json,
naming every piece of content by exactly the name the target website is expecting it under.
The Content Installer: How the Two Actually Connect
A website that wants to accept Site Customization Packages marks every real replaceable spot in its own page — a headline, a paragraph, a photo, a video — with one small, plain comment placed right before it. That comment names the spot, says what kind of content belongs there, and says the largest size allowed, so nobody guesses and gets it wrong:
A free, public tool called the Content Installer reads a whole site marked this way
and does two real things with it. Point it at a site and ask it to scan, and it hands
back a full, exact list of every spot needing content, along with the size each piece is allowed to
be — this is the list a Site Customization Package's own manifest.json has to match.
Point it at that finished manifest.json and ask it to install, and it
drops every real piece of content into exactly the right spot, automatically, with no manual copying
and pasting file by file.
Why Your Pictures Never Come Out Stretched or Squished
A picture that gets placed at the wrong size looks obviously wrong — stretched sideways, squashed flat, or cropped in a strange spot. The real reason this normally happens is simple: nobody told the picture, ahead of time, exactly how much space it was going to fill. This project's standard fixes that by deciding the real width and real height first, before any picture is even chosen, and writing that exact number into the site itself.
If you build or fix up a site using Claude Code, a real, free instruction file called CLAUDE.md
(published in easy-life-content-installer)
tells it exactly how to do this: find every real spot on the page where a photo belongs, and write the
real width and real height that spot needs directly into the comment marking it, the same way
hero_image above says width=1200 height=600. Claude Code does this thinking
for you — you never have to guess or measure it yourself.
Once that's done, the Content Package builder's own "Fill in the content" form shows you those exact numbers right next to each picture field, before you upload anything. Make your picture that exact size — a real photo editor, or asking an AI image tool for "a 1200 by 600 pixel image of …," both work — and the finished site looks the way a real designer built it, because in every real sense, it was: the space was decided first, on purpose, and the picture was made to fit it.
What You Can Actually Do Today, Step By Step
Every step below is real and working right now, checked directly against the live site rather than described from memory. Two things are not finished yet, and they are marked plainly rather than glossed over, because saying a thing works when it does not is worse than saying nothing at all.
See a real, live example first
A real free listing is already on this site today: Easy Life Test Website, a small real page marked with five
real content spots. Three real, finished Content Packages already exist for it, one for a
bakery, one for a law firm, one for a fitness studio, in the
easy-life-test-site-customizations
repository, so you can see finished, real manifest.json files before writing your
own.
Mark your own site's real content spots
The easy-life-content-installer
repository is free and public, and holds both the real tool and a plain set of rules an AI coding
assistant like Claude Code can follow to mark up a site correctly on its own, whether that site
already exists or is being built from scratch. Once marked, run the tool's own scan
command against your site to get back the exact list of what it's asking for — a real
self-check, not a guess.
Build a Content Package for the live demo site
Sign in, then open the
Content Package builder for the real demo
listing above. One tab reads that site's own real content spots straight from its GitHub repository
and gives you one real form field per spot, with a live counter that turns red if you go over the
limit, and builds a real manifest.json for you to download. The other tab lets you
point at a repository that already holds a finished package and register it as a real listing of
its own, for free or for sale.
Push it to your own GitHub account, then list it
Put the finished manifest.json in a repository you own — private if you plan
to sell it, public if you're giving it away — then paste that repository's address into the
same builder page's other tab. This site never asks for a copy of the file itself, only the real
address of where you're keeping it, the same rule this site already follows for every Media
Package used in a marketing campaign.
Getting paid
The plan is the same click-to-buy, click-to-download flow this site already uses for its own paid programs: a buyer signs in, pays once, and a download button appears on their own account page from then on, exactly like re-downloading software you already own.
How Getting Paid Is Meant To Work, Once It's Real
The honest plan, not a promise of what it will earn: when a buyer pays for a Website Listing or a Content Package, the payment is meant to split automatically the moment it's built — most of it straight to the seller, a small amount held back by this site for arranging the sale safely. That kind of automatic split between two different people is a real, named feature of the payment company this site already uses for its paid subscriptions, called Stripe, through a part of it called Stripe Connect.
What GitHub Itself Might Charge You, Checked Directly
This site never charges anything for the repository or the live preview a website listing needs — those live entirely on GitHub, in an account you already own. Every number below was checked directly against GitHub's own real, current pricing and documentation pages, not guessed at.
Storing your code — the repository itself
A repository, public or private, costs nothing to store on GitHub's own free plan. Public repositories are free on every plan, with no storage or bandwidth charge at all. GitHub does ask you to keep a whole repository under about 5 gigabytes as a strong recommendation (1 gigabyte is the comfortable target), and it will refuse any single file over 100 megabytes outright — a real website's HTML, pictures, and video usually stay well under both of those without any special handling.
Showing a live preview — GitHub Pages
GitHub Pages, the free feature that turns a repository into a real, live website at a
github.io address, is completely free when the repository holding the site is public.
That is the free path, and it's the one this project's own demo listing actually uses.
If you want your real, sellable source code kept in a private repository instead, GitHub Pages will not work from a private repository at all on the free plan. Turning a private repository into a live Pages site needs a paid GitHub Pro account, which costs $4 a month for a personal account (GitHub Team, for an organization account, is the same $4 per person each month). One real catch worth knowing before paying for it: even with Pro, the resulting Pages website itself is still visible to anyone with the link by default — paying for Pro does not hide the finished site from the public, it only lets a private repository be the source of one.
Once a live Pages site is up, GitHub gives it a real, generous free allowance: up to 1 gigabyte for the whole published site, a soft limit of 100 gigabytes of visitor traffic every month, and up to 10 rebuilds an hour whenever the source changes. A single small business website sits nowhere close to any of those numbers.
Everything Real, In One Place
easy-life-content-installer.