Identity & Launch. Giving a small product a face, a voice and a first day.

Warm-up: what do you already believe?

Most builders carry two quiet beliefs about marketing. The first is that it is a separate, slightly grubby activity that starts after the "real" design work. The second is that it is mostly about being loud. This guide argues against both. The outward-facing parts of a product are designed artefacts with users, jobs and failure modes, just like a settings screen. And for small, calm products, the winning move is almost never loudness. It is clarity, specificity and consistency.

Answer the two questions below before you read on. Do not look anything up. The point is to notice what you believe now, so you can see what changes.

How to study this guide

1. Pick your product. Everything works best applied to a real thing you are building or have shipped. If you have nothing yet, use the worked example that runs through the guide: Margin, a fictional calm app for saving book highlights and writing notes about them, made by one person.
2. Read a part, then do its exercises. Part one (identity) takes about a weekend of exercises. Part two (the marketing site and pricing) takes another. Part three (launch) runs alongside your release.
3. Keep a "launch folder". A single folder with your brand sheet, headline drafts, screenshots, press kit and changelog. By the end of the guide it will hold everything you need on launch day.
4. Use the demos. Four labs let you test a headline, run a five-second test, see an icon shrink to 16 px, and flip a pricing page between honest and manipulative. Interaction teaches these better than prose.

For a small product, a brand is three things working together: a promise (what you will reliably do for someone), a personality (how it feels to deal with you), and consistency (keeping both, everywhere, for years).

Marty Neumeier's short book The Brand Gap (2003) popularized a useful definition: a brand is not what you say it is, it is the gut feeling people have about your product. That definition is liberating for a solo creator, because it means a brand is not something you buy from an agency. It is something that accumulates every time someone touches your product. Each experience either confirms the expectation they had or breaks it.

That gives you the mechanism. People form a prediction ("this app is fast and quiet and won't nag me"), then they test it at every touchpoint. Confirmed predictions build trust, and trust is what lets someone recommend you, pay you, and forgive your bugs. A logo is just a shortcut that lets people recall the prediction quickly. Without the experiences behind it, the logo recalls nothing.

Brand starts with positioning, not with pictures

Positioning, which you met in Problems Worth Solving, decides what your product is, for whom, compared to what, and why it is better for them. April Dunford's Obviously Awesome (2019) breaks it into competitive alternatives, unique attributes, value, target customers and market category. Brand sits on top of positioning: it is how that position feels and sounds. If your positioning is fuzzy, no amount of visual polish will fix your brand, because there is no clear promise for the visuals to express.

So the order is: positioning, then promise, then personality, then expression (name, icon, colors, type, words). Most builders do it backwards. They pick a font and a gradient first, then try to reverse-engineer what the product stands for.

Brand attributes: "this, not that"

Personality is easiest to define as a short list of attributes, each paired with its opposite that you reject. "Friendly" alone means nothing, because every product claims it. "Friendly, not chummy" or "precise, not cold" draws a line you can actually design to. Mailchimp's public voice and tone guide is a well-known example of this "this, not that" style. Three to five pairs are enough. More than that and you will not remember them while you work.

Kathy Sierra's Badass: Making Users Awesome (2015) adds the most important correction: the brand people love is rarely about the product. It is about who they become by using it. People do not want to be better Margin users, they want to be better readers. Write your promise about their result, not your features.

In the wild

• MailchimpIntuit, voice guide public since the 2010s
  Its published voice and tone guide describes how the voice stays constant while the tone shifts with the reader's situation: lighter on success, plainer when something has gone wrong. Personality is a constant voice with a flexible tone.
• ThingsCultured Code, Things 3 in 2017
  The app, the website, the support pages and the release notes all share the same calm spacing, blue accent and careful prose. Nothing anywhere shouts. Consistency is the brand; there is no separate "marketing voice".
• iA WriterInformation Architects, 2010 onward
  Its promise, writing with fewer distractions, shows in the product (focus mode, a single typeface family) and in the company's long essays explaining its decisions. A narrow promise is easy to keep everywhere.
• ZerodhaIndian brokerage, 2010
  Built much of its trust through plain, educational content (its Varsity lessons) and a stance against pushing customers to trade more. In a category people distrust, a credible promise beats a clever logo.

For software, most brand impressions are made inside the product and around its edges: the details of the interface, the words, the motion and sound, and the emails and support replies people get when something goes wrong.

Big consumer brands spend on advertising because most of their customers rarely touch the product. Software is the opposite. Your users touch the product dozens of times a week. The interface is the brand's main channel, and the marketing site is a small entrance hall. That changes where you should invest.

Don Norman's three levels of design (from Emotional Design, 2004) are a helpful map. The visceral level is the first impression of the icon and the screen. The behavioral level is how it feels to use: speed, feedback, whether it does what you expected. The reflective level is the story people tell themselves about using it ("I'm the kind of person who uses a careful notes app"). A brand that only works at the visceral level is a coat of paint.

Six places to put your brand

1. Interface details

Corner radius, spacing, the accent color, how a selected row looks, the shape of the cursor in your editor. Users will not name these, but they recognize them. See Visual Design.

2. Copy

Button labels, empty states, confirmations, settings descriptions. This is where personality is loudest. Write it with your attribute pairs in front of you. See Words.

3. Motion

A calm product moves calmly: short, eased transitions, no bounces unless playfulness is an attribute. Durations of roughly 150–250 ms feel quick without feeling abrupt. See Motion & Feel.

4. Sound and haptics

Optional, and powerful when used once. Slack's short notification sound became so recognizable that people react to it outside the app. If you use sound, use one, keep it under a second, and let people turn it off.

5. Emails

Welcome, receipts, password resets, trial ending, export ready. Many are sent by default templates from your payment or auth provider. Customize every one you can.

6. Support and docs

A reply from the person who built the product is a brand moment no large company can match. Chapter 17 covers this.

In the wild

• Mailchimpthe "high five"
  After you send a campaign, a cartoon hand gives you a high five. It marks the moment of greatest anxiety (pressing send to thousands of people) with relief. Put the personality where the emotion already is.
• Asanacelebrations
  Completing tasks can occasionally trigger a creature flying across the screen, and users can turn it off. Delight should be rare, earned and optional.
• Slacknotification sound
  A short, distinctive sound that became part of how people recognize the product. One sound, used consistently, becomes brand; many sounds become noise.
• Basecamp / HEY37signals
  Support replies, help pages and product announcements read like they were written by the same opinionated people who built the product. Voice consistency across support is a competitive advantage for small teams.

A good product name is easy to say, easy to spell after hearing it once, available where you need it, legally usable, and harmless in the languages your users speak. Meaning matters less than you think; memorability and availability matter more.

Names feel enormously important because they are permanent and public. In practice, a name is a container. People pour the experience of your product into it. "Apple" and "Amazon" meant nothing about computers or shopping. What made them work was that they were short, concrete, easy to say and easy to remember, and the companies then filled them with meaning. So the job of a name is mostly to not get in the way: not be misheard, misspelled, confused with a competitor, or unavailable.

Four kinds of names

Indian products show every type. Zerodha is a compound of "zero" and the Sanskrit "rodha" (barrier). Razorpay and PhonePe are compounds with a clear category word. Zomato and Swiggy are invented. Jio is a real Hindi word ("live!") used as a metaphor. Paytm started as a compression of "pay through mobile". Notice that the invented names needed large budgets to fill with meaning. A solo creator usually cannot afford that, which is one reason compound and metaphor names are a good default for you.

Seven tests for any name

Domains, stores and trademarks, briefly

You do not need the .com. Many respected products use other domains: Linear lives at linear.app, and plenty of tools use .so, .io or a country domain. A common pattern is a prefix: get[name].com, use[name].com, [name]app.com. What matters is that the domain is short, unambiguous when spoken, and that you own the name in the places your users search. The .app domain requires HTTPS, which is a sensible default anyway.

Trademarks are a legal topic and this is not legal advice, but the basics are simple. Trademarks are registered per class of goods and services under the Nice Classification; software products typically fall in class 9 (downloadable software) and class 42 (software as a service). Search the free databases before you fall in love: the USPTO's trademark search for the US, the IP India public search for India, and WIPO's Global Brand Database across many countries. An identical or very similar mark in the same class, for a similar product, is a red flag. If your product earns real money, pay a trademark lawyer for a proper clearance once.

In the wild

• Linearlinear.app, 2019
  A real word with a strong association (straight lines, steady progress) on a non-.com domain. Nobody doubts it is a serious product. A metaphor name on a clean alternative domain beats a contorted .com.
• ThingsCultured Code, 2009
  A plain, almost generic word for a to-do app. It works because the product filled it with a strong identity over many years. Plain words become distinctive through consistency.
• InstapaperMarco Arment, 2008
  "Instant" plus "paper": you understand it once you know it saves articles to read later. Compounds explain themselves with one sentence of context.
• ZerodhaIndia, 2010
  A compound with an English half and a Sanskrit half, meaning roughly "zero barriers". It sounds distinctive to everyone and means something to people who know the word. Indian languages are a rich source of distinctive, meaningful names.

Good names come from volume and filtering: generate a hundred or more candidates from several directions, cut fast with hard tests, then live with three finalists for a few days before choosing.

The mistake most people make is looking for "the" name in their head. Names come out of a process with a wide mouth and a narrow exit. The wide mouth is word lists from many sources: your product's job, its metaphor, the feeling it should evoke, words from other languages, and plain objects. The narrow exit is a set of tests that are cheap to run and unforgiving.

Six directions to generate from

The hard cut and the soft decision

1. Hard cut (30 minutes). Strike every candidate that fails say-it-once, is over three syllables, or is a known product in your category. Do not argue with yourself. You should drop to about twenty.
2. Checks (2 hours). For the twenty, check domain options, app store search, trademark databases in classes 9 and 42, and a quick web search for slang meanings. Drop to three to five.
3. Native speakers (1 day). Send the finalists to friends who speak the languages your users speak. Ask "does this mean or sound like anything?", not "do you like it?".
4. Live with it (3 days). Write each finalist into your app's title bar, a mock icon, an email signature and a tweet. One will start to feel like the product. The others will feel like costumes.
5. Decide and register. Buy the domain, claim the handles, reserve the app store name (Apple lets you create the app record early). Then stop thinking about it.

In the wild

• BearShiny Frog, 2016
  A concrete, drawable object name for a writing app, which gave it an instantly recognizable icon. A name you can draw makes the icon easy.
• MeeshoIndia, 2015
  Widely reported to come from "Meri Shop" (my shop), compressed into a short, sayable word for its audience of small resellers. Compression of a meaningful phrase can produce a short, friendly name.
• GumroadSahil Lavingia, 2011
  A playful, concrete compound that is easy to say and spell, for a tool for creators to sell things. Playful compounds suit products whose brand is approachable.

Start with a wordmark: your name, set carefully in one good typeface. Add a simple mark only when you need a symbol for small, square places, and test both at 16 pixels and in a single color.

Paul Rand argued in his 1991 essay "Logos, Flags, and Escutcheons" that a logo gets its meaning from the quality of the thing it represents, not the other way round. Sagi Haviv, whose firm designed marks for organizations like Chase and the Smithsonian, makes the same point in practice: a logo should be simple, appropriate and distinctive; it does not need to explain what the company does. That is great news for a non-illustrator. Your logo's job is recognition, not description, and recognition comes from simplicity and repetition.

A wordmark is the name itself, set in type with care. It is the right default for a new product because it does two jobs at once: it is the logo and it teaches the name. Many respected software brands are wordmarks or lean heavily on one (Stripe, Linear's name in its site header, iA's simple lettering). A mark (symbol) is something you add for places where the full name will not fit: the app icon, the favicon, the avatar on social sites.

Making a wordmark without being a type designer

1. Pick a typeface that matches your attributes. A calm, bookish product suits a well-made serif or a humanist sans; a technical tool suits a crisp grotesque or a monospace. Use a typeface whose license allows logo use (most open-source fonts on Google Fonts do, under the SIL Open Font License). See Typography for choosing faces.
2. Set it at a large size and choose a weight. Medium or semibold usually reproduces best at small sizes. Very thin weights disappear.
3. Adjust the spacing by eye. Fonts are spaced for running text. At logo size, letter pairs often look uneven. Tighten slightly overall, then fix individual pairs (like "r" next to "g") until the gaps look even. This is called kerning.
4. Decide on case. Lowercase feels friendlier and more informal; title case feels like a proper name; all caps feels formal and needs extra letter spacing.
5. Convert to outlines (paths) so it renders the same everywhere, and export as SVG.
6. Optional single tweak. One small custom detail (a shortened descender, a joined pair) can make it ownable. One. Not three.

The two tests every mark must pass

The 16 px test. Shrink the mark to 16 by 16 pixels, the size of a browser favicon, and look at it at arm's length. Fine lines merge, small gaps close, and detail turns to mud. What survives is the silhouette and one or two big shapes. If you cannot recognize it, simplify until you can. The monochrome test. Render the mark in pure black on white and pure white on black. A mark that depends on a gradient or on two close colors to be readable will fail on invoices, embossed stickers, notification icons, and the iOS tinted icon mode. Good marks work as a single flat shape first and get color second.

In the wild

• Stripewordmark
  The brand is carried mostly by a simple lowercase wordmark and, for small spaces, a single letter "S" on a solid shape. A wordmark plus a one-letter mark covers almost every use.
• Notionmark
  A black and white "N" drawn as a slightly skewed block, which works in pure monochrome. Monochrome-first marks feel at home in calm, document-like products.
• Thingsicon and mark
  A checkbox with a tick: the one idea of a to-do app, drawn so boldly it survives any size. The most obvious idea, executed carefully, is often the best mark.

An app icon has one job: to be found and recognized in a grid of other icons, at sizes from 1024 px down to 16 px. One idea, a strong silhouette, no text, and a color that stands apart from its neighbors.

Your icon is the most-viewed piece of brand you will ever make. People see it every time they unlock their phone, look at their dock or switch tabs. But they rarely look at it. They scan for it, among 20 to 30 others, in a fraction of a second. That is the mechanism to design for: visual search. Visual search runs on preattentive features (color, shape, size, orientation; see The Human Mind). An icon that differs from its neighbors on one of those features pops out. An icon that blends in on all of them must be read, and nobody reads icons.

Platform shapes and sizes

Five icon principles

1. One idea. A single object or symbol. A camera lens, a checkbox, a bear's head, a page. If you need two, you are explaining, not identifying.
2. Recognizable silhouette. Fill the shape with black: can you still tell what it is? Silhouette is what survives at 29 pt and in the tinted mode.
3. No text. Words in icons are unreadable at small sizes and repeat the label underneath. A single letter can work if it is drawn as a shape, not typed.
4. Distinct in a grid. Look at the most common icons on your users' screens. If they are mostly white and blue, a dark or warm icon will be found faster.
5. Consistent with the product. The icon's color and shape should appear in the app (accent color, the same glyph in the empty state), so the icon promises what opening the app delivers.

In the wild

• OvercastMarco Arment, 2014
  A bold broadcast symbol in a warm orange. Instantly found among the blue and white icons common on iPhones. Color is your cheapest pop-out feature.
• HalideLux, 2017
  A camera lens reduced to a few bold geometric shapes, consistent with the app's precise, pro-tool personality. Simplified objects carry personality through proportion and color.
• Things 3Cultured Code
  A white checkbox with a tick on blue. It shows the product's one job and stays legible at every size. The obvious symbol, drawn with care, is not a failure of imagination.
• Google Workspace icons2020 redesign
  The 2020 redesign gave Gmail, Calendar, Drive and others the same four-color palette. Many users complained the icons became hard to tell apart in a row of tabs. Family resemblance can destroy the distinctness a single icon needs.

A small product needs a small identity kit: one accent color plus neutrals, one or two typefaces, an imagery rule, an illustration rule (often "none"), and a voice. Write it on one page so every future decision can be checked against it in a minute.

Massimo Vignelli's Canon (2010) argued for a disciplined, small set of typefaces and a grid, applied with rigor. The point was never minimalism for its own sake. It was that a small vocabulary used consistently is more recognizable than a large one used loosely. For you, the identity kit is also a time-saver: when you design a new screen, an email or a launch image at midnight, you are choosing from five options, not five hundred.

The five parts

Color

One accent that is yours, used sparingly (for the primary action, selection and the icon), plus a neutral scale for text and surfaces. Define it as tokens (see Systems & Platforms) with light and dark values. Check contrast for text uses (see Accessible & Inclusive).

Type

One family for interface and marketing, or a pair: a reading face and an interface face. Name the sizes you use for headlines on the site. Using the same type in the app and on the site is one of the strongest consistency signals you have.

Imagery

A rule for pictures. For software, the best rule is usually "real product UI, cropped close, on a plain background". No stock photos of people pointing at laptops.

Illustration

Decide whether you use illustration at all. If yes, one style (line weight, color use, level of detail), drawn by one hand. If you cannot draw, "none, use the product" is a strong and honest rule.

Voice

Your attribute pairs from Chapter 1, three example sentences that sound like you, and a short list of words you never use. See Words.

In the wild

• Linearsite and app
  The marketing site uses the same dark surfaces, typography and real product UI as the app. The site feels like a window into the tool. The best identity kit for software is the product itself.
• iAInformation Architects
  The company uses its own typefaces (iA Writer Mono, Duo and Quattro, derived from IBM Plex) across the app and website. One type family can carry an entire identity.
• MUJIKenya Hara as art director
  A restrained palette of natural colors, simple type and "emptiness" as a deliberate quality, applied to thousands of products. A small, strict vocabulary scales better than a rich one.

A landing page answers a visitor's questions in the order they ask them: What is it? Is it for me? Why should I believe it? What does it cost me (in money, time, risk)? What do I do now? Sections exist to answer those questions, not to fill a template.

Steve Krug's Don't Make Me Think (2000) observed that people do not read web pages, they scan them, pick the first reasonable option, and muddle through. On a landing page that means most visitors read the headline, glance at the picture, maybe read a subheading, and decide. A few will scroll and read everything; they are often your most serious prospects. A good page serves both: the scanner gets the answer in the top screen, and the reader finds every objection handled further down.

The hero: what, who, why

The hero is the top screen: headline, a one- or two-sentence subheadline, a primary call to action, and a product visual. Together they must say what the product is (category, in plain words), who it is for (or what situation), and why it is better for them (the outcome or the difference). The headline can carry one or two of those; the subheadline carries the rest. The visual proves it.

Notice that "what" usually needs a category word. "A notes app", "an issue tracker", "a podcast player". Builders often avoid the category because it feels unoriginal. But a category word lets the visitor load a whole mental model instantly; your differentiator then says how you differ from that model. Without it, the visitor has to build a model from scratch, and most will not bother. Dunford makes this point forcefully: the category is a frame of reference, and choosing it is a positioning decision.

Benefits over features (with features as proof)

A feature is what the product has. A benefit is what the user gets. "Full-text search across all highlights" is a feature. "Find that quote you half-remember in two seconds" is a benefit. Lead with the benefit, then give the feature as proof, because benefits without features sound like empty promises and features without benefits make the visitor do the translation.

Social proof, objections and the call to action

Social proof works because people use others' behavior as evidence when they are uncertain. It only works if it is believable: specific testimonials with a real name and context ("Found a quote from 2019 in seconds", Priya, editor) beat vague praise ("Amazing app!!"). Before you have users, skip proof rather than fake it. A short note from you about why you built it is more credible than borrowed logos.

Objections are the reasons a willing visitor still hesitates. For most small software they are the same handful: price and how billing works, privacy and where data lives, lock-in and export, platform support, and "will this be around next year?" (a real worry with solo products). Answer them plainly in an FAQ. Answering "what if you stop working on this?" honestly (export formats, a promise of notice) is a strong trust signal precisely because few companies do it.

The call to action should be one primary action, worded as what happens ("Download for Mac", "Start free trial") rather than a vague "Get started". Put the risk-reducers right next to it: "Free for 14 days, no card", "One-time purchase". Repeat it at the end of the page for readers who scrolled.

In the wild

• Basecamp37signals
  Its homepage has long used plain, direct language, a clear statement of what the product replaces, and a long-form explanation for people who scroll, written in the founders' voice. Long pages work when every paragraph answers a real question.
• Thingsculturedcode.com
  The product page is mostly large, real screenshots of the app with short captions. The product does the persuading. When the UI is the differentiator, show it big.
• Plausible Analytics2019
  A small team's analytics product whose page leads with what it is against (privacy-invasive analytics) and answers data-ownership objections directly. Naming the alternative makes your difference instantly clear.

A landing page headline should make the right visitor think "that's for me" in one reading. It does that by being specific about the outcome, the audience or the category, and by sounding like the words customers already use.

David Ogilvy wrote in Ogilvy on Advertising (1983) that far more people read the headline than the body copy, so the headline is most of the ad's value. On the web the ratio is even more extreme. The headline is also the hardest thing to write because it has to be short and specific at once, and specificity feels risky: it excludes people. But exclusion is the point. A headline that tries to include everyone speaks to nobody.

Joanna Wiebe's method at Copyhackers is to steal the words from your customers: read reviews, support emails, forum posts and interviews, and collect the exact phrases people use to describe their problem and their wished-for outcome. Customers' words beat your words because visitors recognize their own thoughts. "I forget everything I read" is a better seed than "knowledge retention".

Six headline formulas

Test it without traffic

You do not need thousands of visitors to test a headline. Write ten versions. Show each, alone, to five people in your audience for five seconds, and ask "what does this product do, and who is it for?" (the next chapter turns this into a method). The headline that gets the most accurate answers wins, even if it is not the one you like best. A/B testing on a small site rarely reaches significance; qualitative tests on the right people tell you more.

In the wild

• Stripecirca 2010s
  For years its homepage framed the company as payments infrastructure for the internet, aimed squarely at developers, with code on the page. Category plus audience is enough when the audience is precise.
• Slackearly marketing
  Early messaging was built around a short outcome ("be less busy") rather than a feature list. An outcome headline works when the subhead immediately says what the product is.
• Marketing ExamplesHarry Dry, 2020 onward
  A newsletter and site that collects before-and-after copy rewrites, almost all of them moves from vague to concrete. Study rewrites, not just finished headlines.

Show your hero to someone in your audience for five seconds, hide it, and ask what the product is, who it is for and what they would do next. If they cannot answer, the page does not work, however good it looks.

The five-second test works because it simulates the real decision. Visitors land from a link, glance, and judge whether to stay. In five seconds a person can take in the headline, the general type of image, and the main button. They cannot read paragraphs. So the test isolates exactly what the top of your page communicates at a glance. It costs nothing, and five people are usually enough to show the big problems (testing with small groups is covered in Testing & Iteration).

How to run it for real

1. Screenshot the top screen of your page at a common laptop size and at phone size.
2. Find five people in or near your audience. Friends of friends, a community you belong to, or a remote testing service. Not other founders who know your product.
3. Show for five seconds, then hide. Ask: "What is this product? Who is it for? What would you do next? What do you remember?"
4. Write down their exact words. Count how many got "what" and "who" right. Under four of five means rewrite.
5. Change one thing (usually the headline or the image) and test again with new people.

The fold: myths and what is true

Two opposite myths circulate. One says "everything important must be above the fold, nobody scrolls". The other says "the fold is dead, everyone scrolls". Both are wrong. The top screen does get the most attention, so it must answer what and who. But people scroll happily when the top earns it, so you do not need to cram the whole page into the hero. And remember the fold is not a fixed line: it moves with every screen size. Test the hero on a phone, where the fold is very high and the product visual often lands below it.

In the wild

• Lyssnaformerly UsabilityHub
  Remote testing tools offer five-second tests as a standard method: upload an image, set questions, and get answers from a participant panel. The method is cheap enough to run on every major page change.
• Mobile-first heroescommon pattern
  Many product sites stack headline, subhead and button above the fold on phones, with the product image just below, so the one-glance answer survives the small screen. On phones, words must do the first-glance job.

The most persuasive thing on a software marketing page is the software. Show it real, cropped close to the part that matters, annotated with a few words, and moving only when motion explains something a still cannot.

Tufte's advice for charts, to show the data rather than decoration, applies directly to product marketing: show the product, not a metaphor for it. A real screenshot does three jobs. It answers "what is it" faster than words. It proves the product exists (a surprisingly real worry with new products). And it lets the visitor imagine using it, which is the moment they start to want it.

The classic story here is Dropbox. Before its public launch, Drew Houston made a short screencast showing files syncing between computers, and its waitlist reportedly jumped from about 5,000 to 75,000 people overnight, as Eric Ries recounted in The Lean Startup (2011). Syncing is invisible and hard to describe; a few minutes of seeing it work did what paragraphs could not.

Four rules for screenshots

1. Real UI, real-looking data. Use your actual app with realistic content (real book titles, plausible notes), not "Lorem ipsum" or obviously fake "Task 1, Task 2".
2. Crop to the point. A full-window screenshot at landing-page size makes every element tiny. Crop to the panel that proves the benefit, at a size where its text is readable.
3. Annotate sparingly. One or two short labels with thin leader lines, saying the benefit, not the control name ("Finds it even with a typo", not "Search field").
4. Keep it current. Out-of-date screenshots are a broken promise. Automate them if you can, or put "update screenshots" on your release checklist.

When to use motion

Use video or animation when the benefit is a change over time: syncing, importing, a fast keyboard flow, an undo, a transition that shows where something went. Keep loops short (about 5–15 seconds) and focused on one action. Autoplay only if muted, without sound by default, with a still poster frame, and respect prefers-reduced-motion by showing the still instead. A longer demo (one to three minutes) belongs behind a play button, for the visitors who want it. Add captions; many people watch with sound off.

In the wild

• Dropbox2008 screencast
  A simple screen recording of syncing made an invisible benefit visible and built a waitlist before launch. If your benefit is invisible, show it happening.
• Linearlinear.app
  The homepage relies on real, crisp product UI, often in short animated sequences that show keyboard-driven flows. Speed is a benefit you can only prove with motion.
• Raycastraycast.com
  Shows the actual command palette, with real commands typed and results appearing. For keyboard tools, show the keys and the result together.

Great product sites are not great because of a template. Each makes one strong strategic choice that matches its product (show the speed, show the calm, explain the thinking, invite the developer, delight the craftsperson, make access scarce, pick a fight) and executes it consistently.

When you study a site, do not copy its surface (dark gradients, glowing borders, big type). Surfaces get copied so widely that they become the new generic. Ask instead: what is the one choice this site made, why does it fit this product's promise and audience, and what would the equivalent choice be for mine? The descriptions below are patterns as they have appeared over the years; sites change often, so visit them yourself and look for the choice, not the details.

In the wild

• Superhuman2017 onward
  Founder Rahul Vohra described in a 2018 First Round Review essay how the team surveyed users with the question "how would you feel if you could no longer use Superhuman?", aiming for at least 40% "very disappointed" (a benchmark from Sean Ellis) before scaling. The waitlist was a way to learn who the product was really for, not just a hype device.
• PlaydatePanic, 2019 announcement
  A playful site for a small yellow handheld console, full of personality, that matched the strange, delightful product. When delight is the promise, the site must be delightful too.

A pricing page should make it easy to pick the right plan, understand exactly what you will pay and when, and know how to leave. Use anchoring and plan structure to help people choose, never to trick them.

Pricing pages are where design meets money, so they attract the most manipulation. That is also why honesty there is so visible. A visitor on your pricing page is already interested. Their job is to answer: which plan fits me, what will I be charged (total, including tax, and how often), what happens at the end of a trial, and can I get out? Every element should help answer one of those.

Patrick McKenzie (patio11) has argued for years that independent software makers tend to charge too little, and that plans should be differentiated by the value different customers get, not by arbitrary limits. Madhavan Ramanujam's Monetizing Innovation (2016) adds that you should design the product around what people will pay for, rather than pricing it at the end. For you, that means pricing is a design decision you make early, not a number you add at launch.

Plans: good, better, best

Three plans is a common structure because it maps to three kinds of customers (trying, committed, heavy or team) and because the middle option is easy to choose. Each plan should be defined by who it is for, not by a random cut of features. "Free: for trying Margin with one book", "Pro: for readers", "Pro + Sync: for readers on several devices" is clearer than "Basic, Plus, Premium".

Anchoring and decoys, honestly

Anchoring means the first number people see shapes how they judge the next. A decoy is an option designed mainly to make another look better. Both are real effects, and you cannot avoid them, since any page with more than one price has anchors. The ethical line is simple: every plan you show must be a plan someone should rationally buy, and every number must be the real one. Showing a team plan first so the personal plan feels reasonable is fine if teams really buy it. Inventing a "Premium" tier at ten times the price that nobody can use is a trick. For the broader ethics, see Honest & Calm.

The details that matter

Annual toggle

Show the price you will charge for the period chosen. If you show a per-month equivalent for annual plans, also show the annual total right beside it. "2 months free" (about a 17% discount) is a common, easy-to-understand framing.

Feature comparison table

Below the plan cards, for people who want details. Group rows by job, not by internal feature names; use check marks and short text; keep plan names and prices in a sticky header so the columns stay meaningful on long scrolls (see Information & Data for table design).

Free trial with or without card

Requiring a card filters for serious buyers and tends to convert more trials to paid, but fewer people start, and some pay by accident and resent it. Not requiring a card gets more people in and makes you earn the conversion. If you do require one, send a clear reminder a few days before the trial ends, say so on the pricing page, and make cancellation one step.

One-time purchase

Many calm, local-first apps sell a one-time license, sometimes with paid major upgrades. It is honest and well liked; it needs a plan for ongoing revenue (paid upgrades, an optional sync subscription).

Cancellation

Say how to cancel on the pricing page and make it as easy as signing up. In the US, the FTC adopted a "click to cancel" rule in 2024, but a federal appeals court vacated it in July 2025; several US states and other countries have their own rules. Do it regardless: a hard cancellation is a dark pattern, and it turns customers into critics.

Regional pricing and India

A $10 monthly price is a coffee in San Francisco and a large share of a student's monthly spending money in many countries. Purchasing power parity (PPP) pricing adjusts prices by country so the product is similarly affordable everywhere. App stores make this partly automatic: Apple and Google set local prices per storefront, and you can adjust them. On the web, payment providers and merchant-of-record services let you set prices by currency or offer country-based discounts.

For India specifically: show prices in rupees, not converted dollars; consider UPI and local card support (your payment provider choice matters); remember that GST applies to digital services and consumers expect to see the final price; and know that RBI rules since 2021 require additional authentication for recurring card payments (e-mandates), which can make subscription renewals fail silently if your provider does not support them well. Many global services price far lower in India: Netflix, for example, offers a mobile-only plan there. Test your India price by asking your target users what they pay for comparable apps, not by converting your US price.

In the wild

• Basecamp37signals
  Has long promoted simple, flat pricing for businesses rather than per-seat charges, and explains the reasoning on the page. A pricing model can itself be a brand statement.
• Things 3Cultured Code
  Sold as one-time purchases per platform, with free sync. One-time pricing fits calm tools whose value does not need servers to grow.
• Obsidian2020 onward
  The core app is free for personal use; optional paid services (Sync, Publish) cover ongoing server costs. Charge for what costs you money to run; let the core be generous.
• Netflix Indiamobile plan
  Introduced a lower-priced, mobile-only plan for India. Regional pricing can come with a regional product shape, not just a lower number.

An app store page is a landing page with strict limits. Your icon, name, subtitle and first two or three screenshots do almost all the work, because that is what shows in search results. Make the screenshots tell a story, one benefit per frame.

In App Store search results, people see your icon, name, subtitle, rating and the first screenshots (or a preview video). Many never open the full page. So the first screenshots are your hero. They must answer what and why at a glance, at the size of a thumbnail. A grid of plain UI captures without captions rarely does that; a sequence with a short benefit caption above a cropped, readable UI usually does.

The limits you design within

Ratings prompts: timing is the design

On iOS, the system review prompt (requested through requestReview) is shown at most three times in a 365-day period per user, and the system decides whether to show it at all. So each request is precious. Ask right after a moment of success (the user finished their first daily review, or exported notes), never at launch, never in the middle of a task, and never after an error. Do not put your own "Do you love Margin?" gate before the system prompt to filter out unhappy users; Apple's guidelines discourage custom review prompts, and it is a manipulative pattern anyway. Make it easy for unhappy users to reach you directly from Settings instead.

Release notes as marketing

In the wild

• Slackrelease notes, 2010s
  Became known for warm, often funny release notes that people actually read and shared. Release notes are a recurring touchpoint with your most engaged users.
• HalideLux
  Its store presence and accompanying blog posts explain new camera features in depth, with real photos. For pro tools, depth is persuasive; link store pages to longer explanations.

The weeks before launch are for finding the first people who care, learning their words, and giving them a reason to come back on launch day. A waitlist and honest public progress notes do this cheaply, if you treat the people on them as collaborators rather than numbers.

A launch day with no one waiting is a launch into silence. The mechanism you need is simple: people who have already raised their hand (by joining a list, following your progress, or trying a beta) are many times more likely to show up, try the product and talk about it than strangers. So pre-launch work is about collecting and nurturing those hands. It is also research: every reply to a waitlist email is a customer telling you, in their words, what they want.

A waitlist page that is also research

A waitlist page is a landing page with a smaller ask: an email address. Keep the hero as clear as any landing page (Chapter 8), show whatever real UI you have, and say honestly when access is expected. Then add one optional question after sign-up: "What do you hope this will help you with?" or "What do you use now?" The answers are gold. They tell you who is signing up, in their words, and they start a conversation you can continue by email.

Some waitlists add referral mechanics ("move up the list by inviting friends"). Robinhood famously grew a large pre-launch waitlist this way, showing people their position in line. These mechanics can work, but they turn your early community into a scoreboard and can attract people who want the prize, not the product. For a calm product, a plain list and personal replies usually fit the brand better.

Building in public

Building in public means sharing your progress, decisions, numbers and mistakes openly while you build. Pieter Levels popularized a version of it with public revenue dashboards for products like Nomad List; Buffer published salaries and revenue in the 2010s. The benefits are real: an audience that knows your story before launch, feedback on decisions while they are cheap to change, and accountability. The costs are also real: time, distraction, the temptation to optimize for followers rather than users, and competitors who can watch.

A calm version works well: one short post a week about a real decision you made and why, with a screenshot. "This week I removed tags and replaced them with books as the only organizer. Here's why." That is useful to readers, honest about your process, and doubles as a design journal you will learn from yourself.

In the wild

• Nomad ListPieter Levels, 2014
  Built and grown in public, with revenue and decisions shared openly, by a solo maker. Openness can be a marketing channel and a brand trait at once.
• Superhumanwaitlist with onboarding
  Used its waitlist to survey and select users, then onboarded many personally. A waitlist is a research instrument, not only a hype device.
• Robinhoodpre-launch, 2013–2014
  Showed sign-ups their place in line and let them move up by referring friends, building a very large waitlist. Referral mechanics grow lists fast; decide whether the game fits your brand.

On launch day you are a guest in other people's communities. Bring something people can try immediately, describe it plainly, be present to answer every question, and never ask for votes. Then have everything ready that a curious person or journalist might need.

Launch platforms reward the same thing communities always reward: a useful contribution from a person who shows up. They punish what communities always punish: self-promotion that takes more than it gives. Think of launch day as a conversation, not a broadcast. The ranking is a side effect of how well that conversation goes.

Where to launch

The press kit

Journalists, newsletter writers and bloggers will not ask you for assets; they will use whatever they find or skip you. A press kit is one page with everything they need: a one-paragraph description, a short and a long version, key facts (price, platforms, release date, founder name, location), high-resolution screenshots, the icon and logo in several formats, a short video, a founder photo if you are comfortable, and a contact email. Rami Ismail's free presskit() format, made for indie game developers, popularized this simple, one-page structure.

In the wild

• Dropbox on HN2007
  Its early HN post drew a now-famous skeptical comment about building it yourself with existing tools; the product went on to great success. Criticism on launch day is data, not destiny.
• presskit()Rami Ismail, Vlambeer
  A free, simple press kit template widely used by indie game developers. Make it effortless for others to write about you.

After launch, your brand lives in the places people go when they are stuck, curious or deciding whether to stay: the help pages, your support replies, the changelog and the first emails. Design each as carefully as a screen.

The mechanism is trust under stress. People form their deepest opinion of a product when something goes wrong or when they are unsure. A fast, warm, specific support reply from the person who made the product turns a problem into loyalty. A clear help page lets someone succeed without asking. A living changelog shows the product is cared for, which addresses the biggest worry about solo products: "will this be abandoned?"

Documentation: four kinds

Daniele Procida's Diátaxis framework separates documentation into four kinds, because each serves a different need. Mixing them is why many help centers feel confusing.

Support replies are design

1. Answer fast, even if partially. "Got it, looking now" within hours beats a perfect answer in three days.
2. Repeat the problem in your own words. It proves you read it and catches misunderstandings.
3. Give the fix in steps, with a screenshot or a link to a how-to page. If the fix is a bug on your side, say so plainly.
4. Close the loop. When you ship a fix, email the person. This single habit creates more fans than any feature.
5. Turn repeats into pages and design changes. If three people ask the same thing, write a how-to; if ten do, change the product.

The changelog

A public changelog shows momentum and care. The Keep a Changelog convention groups changes under Added, Changed, Deprecated, Removed, Fixed and Security, with dates and newest entries first. For users, add a human layer: one sentence on why the change matters, a screenshot for anything visible, and thanks to people who reported issues. Offer an RSS feed or an email digest. Linear's public changelog, with visuals and regular entries, is often cited as a model.

Onboarding emails

The first emails after sign-up are part of onboarding (activation is covered in Problems Worth Solving). Their job is to help the person reach the first moment of value, not to sell. Behavior-based emails beat a fixed drip: send the "here's how to import" tip only to people who have not imported yet.

In the wild

• Stripe DocsStripe
  Long praised as a model of developer documentation: clear structure, runnable examples, and guides separate from the API reference. Docs can be the product's best marketing.
• Linear changeloglinear.app/changelog
  Regular, illustrated entries that make progress visible. A visible rhythm of improvement is a trust signal.
• Things supportCultured Code
  Help pages written in the same calm voice and careful layout as the app. Support pages are part of the product, not an afterthought.

People trust small products more when they can see the person behind them and understand what that person believes. A short, honest founder story and a manifesto-like statement of principles turn your opinions into a reason to choose you.

A big company competes on scale and features. You compete on point of view and care. The founder story makes both visible. It answers questions a careful buyer has about a small product: Who is behind this? Why do they care? Will they still care next year? What will they never do? iA's essays, written by Oliver Reichenstein and his team, explain why the company makes the decisions it does (one font, few settings, focus). 37signals has written books (Getting Real, 2006; Rework, 2010) and manifestos for products like HEY that are as much about beliefs as features. Both turned opinions into a brand people sign up for.

What goes in a small-product manifesto

• What we believe: two or three convictions about the problem ("Reading is wasted if you can't find what you read").
• What we will always do: promises you can keep ("Your notes export to plain Markdown, always").
• What we will never do: the most credible part ("No ads. No selling data. No streaks or guilt notifications").
• Who is behind it: your name, where you work from, how to reach you.
• How it is paid for: people trust what they understand. "You pay, so you are the customer."

The most credible part of any manifesto is the list of things you will never do, because it costs you something to promise.A principle for this course, drawn from the practice of iA and 37signals

In the wild

• iAessays, 2010s onward
  Long essays on writing, typography and focus that explain the product's choices. Explaining your decisions recruits people who share your values.
• HEY37signals, 2020
  Launched with a long, opinionated page about what was wrong with email and what HEY would do differently, written in the founders' voice. A strong point of view can be the main marketing.
• Getting Real37signals, 2006
  A book of principles about building smaller, simpler software, which also explained the company's products. Publishing your method builds an audience before and beyond any one product.

Track a few numbers that describe a simple funnel (visit, sign-up or download, first value, paid), look at them weekly rather than hourly, and pair them with words from real people. At small traffic, qualitative evidence beats split tests.

Analytics can turn a calm maker into an anxious one. The cure is to decide in advance which few numbers you care about and why. A conversion rate is the share of people at one step who reach the next. For a small product the useful ones are: visitors to sign-ups (or downloads), sign-ups to activated (reached first value), and activated to paid. Each tells you where to look. A low first rate points at the landing page; a low second at onboarding; a low third at value or pricing.

Why split tests rarely work at small scale

A/B tests need a lot of traffic to tell a real difference from noise. As a rough worked example: if 2% of visitors sign up now and you want to detect an improvement to 3% (a big 50% relative lift) with the usual statistical standards (95% confidence, 80% power), you need roughly 3,800 visitors per variant. Detecting a smaller lift, say 2.0% to 2.2%, needs tens of thousands per variant. Most small products do not have that traffic, so tests run for months or end with false winners. Use five-second tests, interviews and the "how did you hear about us?" question instead, and save A/B tests for when you have the traffic.

In the wild

• Plausible, Fathom2018–2019
  Small, privacy-focused analytics products that show a handful of metrics on one page instead of hundreds of reports. Fewer metrics, chosen well, lead to better decisions.
• Open startup pagesindie makers
  Many indie makers publish a simple monthly page of revenue and visitors, which forces a calm, monthly rhythm of looking. A fixed reporting rhythm protects you from daily noise.

Wrap-up

Everything in this guide follows from one idea: the outward-facing parts of your product are designed artefacts with users and jobs. A name must be said and spelled. An icon must be found in a grid. A headline must be understood in five seconds. A pricing page must be understood and trusted. A launch post must be useful to a community. A support reply must solve a problem. Treat each as a design problem, keep the same promise and voice across all of them, and your small product will feel larger and more trustworthy than its size.

Practice assignment for the next two weeks

Build your launch folder. Spread across fourteen days, about an hour a day, alongside your normal building:

1. Days 1–2: Brand core card (Ex. 1.1) and touchpoint audit with three rewrites (Ex. 2.1).
2. Days 3–4: Name check of your current name, or the full naming funnel if you are still unnamed (Ex. 4.1). Wordmark and mark in SVG (Ex. 5.1).
3. Days 5–6: App icon and favicon set, tested in real home screens (Ex. 6.1). One-page brand sheet (Ex. 7.1).
4. Days 7–9: Question-first wireframe, ten headlines, two rounds of five-second tests, three proof images and a loop (Ex. 8.1–11.1).
5. Days 10–11: Honest pricing page with local prices (Ex. 13.1) and store frames or social images (Ex. 14.1).
6. Days 12–13: Waitlist or launch kit, press kit, docs, changelog and onboarding emails (Ex. 15.1–17.1), plus your 200-word story (Ex. 18.1).
7. Day 14: Set up the measurement ritual (Ex. 19.1). Then reflect in writing: which artefact changed most from your first draft, and why?

Reading list

• The Brand Gap
  Marty Neumeier, 2003 · A short, visual book on brand as a gut feeling; the clearest starting point.
• Obviously Awesome
  April Dunford, 2019 · A practical positioning method. Do it before your landing page.
• Positioning: The Battle for Your Mind
  Al Ries and Jack Trout, 1981 · The classic on owning a place in the customer's mind; includes naming chapters.
• Badass: Making Users Awesome
  Kathy Sierra, 2015 · Why people love products that make them better at something they care about.
• Identify: Basic Principles of Identity Design
  Chermayeff & Geismar & Haviv, 2011 · Case studies of simple, enduring marks.
• Paul Rand, "Logos, Flags, and Escutcheons"
  Paul Rand, 1991 essay · Why a logo's meaning comes from what it represents.
• The Vignelli Canon
  Massimo Vignelli, 2010 · A short, free book on disciplined identity and type.
• Don't Make Me Think
  Steve Krug, 2000 (revisited 2014) · How people really scan pages; essential for landing pages.
• Copyhackers articles on voice-of-customer copy
  Joanna Wiebe · How to write headlines from your customers' own words.
• Ogilvy on Advertising
  David Ogilvy, 1983 · Old, opinionated and still sharp on headlines and specificity.
• Predictably Irrational
  Dan Ariely, 2008 · Anchoring and the decoy effect; read with the ethics guide alongside.
• Monetizing Innovation
  Madhavan Ramanujam and Georg Tacke, 2016 · Designing the product around what people will pay for.
• Getting Real and Rework
  37signals, 2006 and 2010 · Small, opinionated software, and how a point of view becomes a brand.
• "How Superhuman Built an Engine to Find Product/Market Fit"
  Rahul Vohra, First Round Review, 2018 · How a waitlist became a research instrument.
• The Minimalist Entrepreneur
  Sahil Lavingia, 2021 · Launching small, building community first, and selling to people you know.
• Diátaxis
  Daniele Procida, diataxis.fr · A simple framework for documentation that fits a solo product.
• Apple Human Interface Guidelines: App icons; Material Design: Adaptive icons
  Apple and Google, updated regularly · Always check the current versions before exporting icons.

Next: Testing & Iteration turns the five-second test and the weekly review into a full practice of learning from users. For the ethics behind honest pricing and calm marketing, read Honest & Calm.