How to Introduce Your Side Project So People Click by Line Three
You spend three months building something. On launch day, you spend ten minutes writing the description. Then nobody clicks.
That ratio is backwards, and here is why it matters: on any listing page, your project gets a title plus two or three lines of text. That's it. People scrolling past decide inside those three lines whether to open your page or keep going. Three months of work, decided by ten minutes of writing.
So it's worth turning those ten minutes into an hour. This post gives you a four-paragraph fill-in template, a bad and a good example for each paragraph, and a blank version at the end you can copy as-is. You need no tools beyond a place to type.
First, some good news: writing an introduction requires zero programming. What it requires is explaining one thing to an outsider so they actually get it. If you're a teacher, a marketer, a salesperson, or you run a shop, you do this every day. Most bad project descriptions I've seen were written by engineers (mine included, early on), because the builder stands too close to the thing. They open with implementation details and forget the reader doesn't yet know what the thing even is. You talk to non-experts for a living. Here, that's an advantage.
The template is four paragraphs, two or three sentences each:
- What this is
- Why I made it
- How I built it
- Where it stands
The order matches the order questions pop up in a reader's head. Let's go through them.
Paragraph one: what this is
Two sentences, three answers: who it's for, what it does, what you see when you open it. You can use this sentence shape directly:
This is a (website / app / form / document) that helps (who) do (what). Open it and you (one concrete action).
Bad example:
An innovative AI-powered learning platform dedicated to improving the learning experience for everyone.
After reading that, do you know who it's for? What appears on screen? No. Swap a few nouns and the sentence describes any product on the market, which means it says nothing.
Good example:
This is a website that helps middle schoolers memorize English vocabulary. It gives you 10 words a day, and the ones you miss come back tomorrow.
There's an audience (middle schoolers), an action (memorizing vocabulary), and a picture (10 a day, misses come back). A reader can decide in two seconds whether this concerns them. That decision is the doorway to everything else.
This paragraph always goes first, because the listing page excerpts the top of your text. Your "three lines" are, in practice, this paragraph.
Paragraph two: why I made it
This paragraph tells the specific moment that made you start building. Its job is to convince the reader the problem is real, and to let them meet you as a person along the way.
Bad example:
The vocabulary apps on the market aren't good enough, so I decided to build a better one.
"Not good enough" is a verdict with no scene attached. Not good enough at what? For whom? The reader can't tell whether the problem exists or you imagined it.
Good example:
I teach middle school English. My students went through three vocabulary apps, and every time the pattern was the same: diligent for a week, gone by week two. My guess is 30 words a day was simply too many. So I built a version that gives you 10.
A person, an observation, and a judgment call ("my guess is"). Note those words: if you haven't done research, write "my guess" instead of faking data. It's more honest, and readers respond to it.
Paragraph three: how I built it
Non-engineers get nervous here and feel they should say something technical to sound credible. Do the opposite. State your tools and your process, plainly.
Bad example:
Built with cutting-edge AI technology and a modern architecture, balancing performance and scalability.
Same disease as paragraph one's bad example: it fits any project, so it carries zero information. Worse, readers who actually know architecture will ask follow-ups you can't answer.
Good example:
I can't code. I described the interface to Claude sentence by sentence and revised from there; the word bank is a spreadsheet I compiled myself. Three weekends, start to finish.
Admitting you can't code helps you here. Half the people reading your project page can't code either, and the question they're silently asking is "could I do this too?" Your paragraph is the evidence. If you're wondering what free tools to start with, see this tool list.
Paragraph four: where it stands
Bad example:
Continuously improving. Stay tuned.
Good example:
Live for two weeks. So far the only users are the 26 students in my own class. Known issue: on phones, the keyboard covers the input box. Next up: audio pronunciation.
The point of the status paragraph is to show helpful people where to help. Faced with "stay tuned," a reader can only hit like and leave. Faced with "the keyboard covers the input box," someone who's fixed that before will tell you how, and someone who's used similar products will tell you whether audio is worth building. Write down what's broken and the quality of feedback you receive changes completely.
Include numbers if you have them; skip them if you don't. "26 students" is tiny, but it's true, and a true small number beats a vague big phrase ("many users already") ten times over.
The short version: the elevator test
The four paragraphs are for your project page. Also prepare a version under 60 words for social posts, comment-section intros, and the moment someone asks "so what have you been working on?"
The method: compress paragraphs one and two into a sentence each, delete paragraph three entirely (nobody cares how you built it in the first ten seconds), keep one sentence of paragraph four. Example:
I built a website that helps middle schoolers memorize English vocabulary: 10 words a day, misses come back tomorrow. My students quit every other app within two weeks. 26 kids are using it now. It's rough, and I'd like to hear where it feels off.
That's 45 words. The test: read it aloud in under 20 seconds, then ask your listener to repeat back who it's for, what it does, and where it stands. Try it on someone who knows nothing about your project. If they can't repeat it, rewrite.
Three common mistakes
Listing features without naming the audience. "CSV export, dark mode, multi-language interface" earns a shrug: so what? Before writing any feature, ask yourself who would click because of that line. No answer, cut it. Features are evidence; the audience is the claim. Make the claim first, then bring evidence.
Stacking adjectives. "Innovative," "powerful," "minimal," "intuitive" carry zero information, because nobody ever describes their own project as dated, weak, cluttered, or confusing. Replace every adjective with one concrete fact: "minimal interface" becomes "the homepage is a single input box"; "powerful search" becomes "search works with partial spelling." An adjective you can't convert into a fact didn't deserve the space anyway.
False modesty. "Just a silly little thing I hacked together, please don't judge." That opening forces readers to reassure you first, after which honest criticism feels rude, so you've locked the most valuable feedback out with your own hands. No self-deprecation, no inflation. State the actual condition: what works, what's still broken.
The blank template, copy it
[What this is]
This is a (website / app / form / document) that helps (who) do (what).
Open it and you (one concrete action or screen).
[Why I made it]
(The specific scene that made you start. One to three sentences.)
(What about the existing options you couldn't stand. One sentence.
If you're guessing, say "my guess is".)
[How I built it]
I built it with (tool names). (Can you code? Say so either way.)
It took (time).
[Where it stands]
(How long it's been live, who uses it. Numbers if real, skip if not.)
Known issues: (one or two, real ones.)
Next up: (just one.)
One last check after you fill it in: pull out paragraph one on its own. That's what strangers see on the listing page. Scrolling past it, would you click?
This post comes from SideShip, a place for sharing side projects. If you have one half-built, or finished and unseen, post it here — three required fields, no email verification, two minutes. When you publish, I'll personally leave the first piece of feedback.