End-user guide

What is an end-user guide?

An end-user guide is documentation written for the people who use your product to get something done. It walks them through the real tasks: creating an account, uploading a file, generating a report, changing a setting, and recovering when something goes wrong.

The defining trait is the reader. An end-user guide assumes no technical knowledge. It talks about buttons, screens and outcomes, never about functions, files or databases. If a sentence mentions a variable or an endpoint, it has stopped being an end-user guide.

Good end-user guides are task-shaped ("How do I invite a teammate?") rather than feature-shaped ("The Members module"), because that's how users actually think.

Who is an end-user guide for?

An end-user guide is for your customers and anyone else who operates the app without touching its code. That includes trial users deciding whether to buy, paying customers doing daily work, and support staff answering tickets.

It is not for developers. Engineers read developer docs and the README. You, the founder, read the founder runbook. Three readers, three documents.

Why it matters if you built with AI

When you build with a tool like Lovable, Bolt or Cursor, you get a working app but no guide for the humans who'll use it. The AI wrote the code; it didn't write your customer's how-to. So the moment real users arrive, you're answering the same questions by hand.

Most guide tools don't solve this from your code either. Tools like Scribe, Supademo and Guidde build genuinely good step-by-step guides, but they do it from a human screen recording or capture session. You record yourself using the app, and they turn that into steps. That works well, but it captures what you happened to click, not what your code can actually do, and every screen change means re-recording.

Explain My Build takes the other path: it reads your actual source code and produces the end-user guide from what the app really does. See user guide from code vs screen recording.

A worked example

Say you built an invoicing app. A feature-shaped developer note might read: InvoiceController.create() persists to the invoices table. Useless to a customer.

The end-user-guide version of the same thing reads:

Create your first invoice
1. Click "New invoice" on the dashboard.
2. Choose a client, or add one with "+ New client".
3. Add line items; the total updates as you type.
4. Click "Send" to email it, or "Save draft" to finish later.

If sending fails, check that the client has an email address on file.

Same feature, written for the person clicking the buttons. Explain My Build drafts this from your code, then you review and edit it before publishing, so it reads like you wrote it.

Turning your code into an end-user guide

Explain My Build reads your repo (public repos are read on our server then deleted; private repos and local folders run entirely in your browser or via CLI so code never leaves your machine) and drafts the end-user guide from the source. You review it, then publish it as a share link with an access code, embed it as an in-app Help widget, or export it.

The end-user guide plus sharing is $19/month, or $12/month founding for the first 100. The founder runbook and code-verified fix-list are free. Start at document your AI-built app or see how it works.