How to write a founder story about why you built it

To write a founder story about why you built something, tell one true moment when the problem got in your way, say what you tried first and why it fell short, name the one choice in your product that came from that, then say plainly what it does today and who it is for. Leave out the mission statement. A founder story works best when it reads like a person explaining a decision, not a company describing itself.

This guide takes each part in turn, gives you a five-part template, and ends with a short worked example you can copy the shape of.

What a founder story is for

A founder story answers one question: why does this exist? Your product page already says what it does. The founder story says why you made it.

Write it for a reader who has the same problem you had. They want to see whether you understand it the way they do. So a good founder story does three jobs:

• It shows you have lived the problem, or watched it up close.
• It explains, fairly, why the options you had were not enough for you.
• It makes your main design choice make sense once the reader knows the backstory.

Everything else is optional. Your childhood, your funding, your team photo: leave them out unless they change one of those three things.

Find the moment the problem became yours

Many founder stories open too wide. "I have always been passionate about productivity" tells the reader nothing they can picture.

Open on a single moment instead: a day, a place, a thing that went wrong. Ask yourself:

• When did I first get annoyed enough to do something about this?
• What was I trying to finish when it broke?
• What did it cost me: time, money, a client, a night's sleep?

Write that moment in two to four sentences, with concrete details you remember. "At 11pm the night before a deadline, I was copying rows between two spreadsheets by hand" gives the reader a scene; "I struggled with data entry" does not.

Describe the problem in your reader's words, not your product's. After months of building, you may call things "workflows" or "sync layers". Your reader says "I keep losing track of which version is current." Write down how you would explain the problem to a friend who has never seen your product, and use that sentence.

Say what you tried first, and be fair about it

List the two or three things you tried before you built your own. For each, give one sentence on what it did well and one on where it fell short for you. If a tool suits most people and simply did not fit your case, say so.

This part shows that you built something because the problem needed it, not only because you wanted to build. Keep it fair: a reader who uses one of those options will notice a sneer. The rules in how to write a comparison article that stays fair apply here too, even when the comparison is only a few paragraphs.

Include the cheap fixes as well: the spreadsheet, the script, the sticky notes. Your reader may be using one of them right now, and seeing it named tells them you were where they are.

Name the one choice that came from it

Now describe what you made, in one short paragraph with no feature list. Then give one paragraph to the single decision that sets it apart.

Pick one choice, not five. Some shapes a defining choice can take:

• "It works offline first, because the problem always hit me on trains."
• "It does one thing, because every tool I tried did ten and I used one."
• "It shows the answer before the settings, because I never wanted to configure anything."

Each one ties back to the moment or to what you tried. That tie is the point: the reader should finish this part thinking the product works that way because of what happened to you.

Say what it does today, limits included

The story is yours, but this part is for the reader, so keep it to facts anyone can check.

Use only numbers you can stand behind. If you say it saves time, say how you know: your own notes, a test you ran, a count you made. If you have no number, do not make one up; a plain before and after is enough.

Point to proof. Link a demo, a changelog or a write-up of one real project. A detailed account of the product in use belongs in its own article; see how to write a case study about your own work.

Say what it does not do yet. One or two sentences on a known gap or a trade-off you made on purpose, such as "It does not support teams yet; I built it for one person first." A reader deciding whether to try it needs to know where it stops.

Then end with who it is for: one sentence naming the reader it fits, and one next step they can take.

How to write a founder story: a template and a worked example

Here is the shape. Each part is about one paragraph.

1. The moment. One real scene where the problem got in your way, in your reader's words.
2. What you tried. Two or three attempts, fairly described, and where each fell short for you.
3. The choice. What you built, in one paragraph, and the one decision tied back to the moment.
4. What it does today. Plain facts, the proof you can show, and what it does not do yet.
5. Who it is for. One sentence naming the reader, and one next step.

Here is a short example. Ines, her book club and her app are all made up for this example, so the story asserts nothing about any real product:

One Thursday our book club met and three of us had read different books. The group chat had agreed on the next title two weeks earlier, but forty messages later nobody could find it. We tried pinning the message, but the pin changed whenever someone pinned a photo. We tried a shared spreadsheet, which worked, but most of us read the chat on our phones and never opened it. So I built a one-page list for the club. The one choice: only one book can be "next" at a time, and it sits at the top in large type. That came straight from that Thursday. Today it shows the next book, the meeting date and who suggested it. It sends no reminders, and only I can change the list, so someone still has to tell me. If you run a small reading group from a chat, it may suit you; the link to try it is below.

Notice what the example does not do: it claims no measured result, and its limits are in plain sight. A full founder story can run longer, but the bones are the same. Write the moment last: once the rest is done, you will know which moment best sets up your one choice.

Frequently asked questions

Should a founder story be in the first person?

Usually, yes. "I" or "we" makes it a person explaining a decision, which is the point of the piece.

How is a founder story different from a case study?

A founder story explains why you built something. A case study shows what happened when it was used on one real project. They pair well: link the founder story to a case study as your proof.

Can I change my founder story after I publish it?

On Electrified, yes: you can edit a published post with Save changes, and it keeps its address, so links to it still work. Date any change to a fact, such as a limit you have since fixed.

Where should my founder story live?

Somewhere with a stable address you can link from your product page. On Electrified it sits on your own page at /@handle, filed under topics you choose, such as Promote your work.

Get started

Electrified is a site to write and be read, and anyone can make an account to write about a product, a topic or an idea. Here is how a founder story fits into it:

1. Make an account. You choose a handle, and your page is at /@handle.
2. Open the editor and choose Article. A note is a short post of up to 500 characters with no title, which is too small for this; an article has a title and as many sections as it needs.
3. Use the five parts as your sections. Start each with ## and a heading, such as ## What I tried first, and check the Preview tab, which looks like the published page.
4. Save a draft. A draft is seen only by you and never by a search engine, so rewrite the moment as often as you need.
5. Add up to 5 topics, separated by commas; each topic links to a page of every post about it.
6. Publish it yourself. A writing assistant with a personal token can start and edit drafts, but publishing is always done by a person on the site.

Once it is published, readers can follow you from your page or read your posts in a feed reader, and like or comment on the post. A founder story, a case study and a fair comparison on the same page start to build a body of knowledge around your product or idea.

Make an account on Electrified: write about your product, topic or idea on your own page, one article at a time, and let readers follow along.