What makes a landing page convert for an indie SaaS?

Three things above the fold: a headline that names the specific outcome your target user wants, a subheadline that explains how you deliver it in one sentence, and one clear action to take. Below the fold, stack whatever social proof you have before the feature list, write features as outcomes rather than capabilities, and show the price in plain numbers. The whole page must answer one question for the visitor: is this for me, and is it worth trusting?

How do I write a headline for my SaaS if I'm not a copywriter?

Use the outcome-plus-audience formula: '[Specific result] for [specific person], without [the painful alternative].' Then talk to three real users and find the exact phrase they use to describe the problem. That phrase is almost always a better headline than anything you could invent on your own. Write the headline last, after you understand the user's language, not first.

How do I get social proof for a brand-new indie SaaS with no customers?

Start with whatever honest, specific evidence you have: the number of people on your waitlist, early access users, build-in-public posts with real reactions, screenshots of people saying they want the product, or a public changelog that proves the product is actively being built. Specific and honest always outperforms vague and polished at the early stage.

Should I show pricing on my landing page?

Yes. For indie SaaS targeting solo founders and indie hackers, hiding the price adds friction and filters out your best buyers at the top of the funnel instead of converting them. Show a simple free tier and one paid tier with a clear per-month price and an annual equivalent. Add a brief note handling the main price objection, and put a CTA button inside the pricing section itself.

How often should I update my landing page?

Every time you ship a feature worth mentioning, hear a better way to describe the problem from a real user, or notice visitors bouncing at a section that used to work. A practical cadence is a quick review after every significant release and a deeper review once a month. The page should always describe the product you have today, not the product you had at launch.

← All articles

Published October 29, 2026·8 min read

How to write a landing page that converts for your indie SaaS

Most indie SaaS landing pages lose visitors in the first ten seconds because the value proposition is buried. Here is how to write a landing page that converts, from headline to pricing, without a marketing team or copywriter.

TL;DR

A landing page that converts for an indie SaaS needs three things above the fold: a headline that names the outcome your buyer cares about, a subheadline that explains how you deliver it, and one clear action to take. Below the fold, stack proof before features, and keep the pricing visible and simple. Every sentence should answer the question every visitor asks first: is this for me, and why should I trust it?

On this page

Write the headline last. After you hear a real user describe the problem in their own words, the headline almost writes itself.
Your hero section has one job: stop the right person from leaving. Optimize for clarity over cleverness.
Social proof without testimonials is still proof: usage numbers, build-in-public posts, early user quotes, and a public changelog all reduce risk for skeptical visitors.
Features sell nothing on their own. Rewrite every feature bullet as the outcome it enables, then ask 'so what?' once more.
Put the price on the page, in plain numbers. Hiding it filters out serious buyers before they can convert.
Treat the landing page as a living product. Update it every time you ship something worth mentioning or hear a better way to describe the problem from a real user.

Most indie SaaS landing pages share the same failure mode: a generic hero headline, a wall of feature bullets, and a pricing section the founder was too nervous to finalize. The page took two weekends to build, but the visitor is gone in eight seconds because they could not answer the one question every landing page visitor asks first: is this for me? Writing a page that converts is not a design problem or a budget problem. It is a clarity problem, and clarity is a writing skill anyone can practice.

Start with the headline, not the hero section

The headline is the one sentence that either earns the next ten seconds of attention or ends the visit. Yet most indie hackers write the hero section first and never revisit the headline after the initial build. That is backwards. The headline is the highest-leverage sentence on the page. A visitor who understands it immediately will scroll; a visitor who does not will close the tab, no matter how strong the rest of the page is.

The formula that converts best for indie SaaS is outcome plus audience: '[Specific result] for [specific person], without [the painful alternative].' For example: 'Ship your side project every day without losing track of what matters' tells a developer-founder what changes (daily shipping), who it is for (someone with a side project), and what it replaces (losing track). It is specific enough to filter out the wrong visitor and direct enough to hook the right one.

Write your headline after talking to three real users, not before. The exact phrase they use to describe the problem is almost always stronger than the phrase you invented to describe the solution.

What the hero section actually needs to do

Above the fold, your only job is to stop the right visitor from leaving. Not to explain everything, not to impress design critics. The hero section earns one thing: enough trust to keep reading. That requires four elements working together.

A headline that names the outcome, not the feature. 'Get 3x more subscribers' beats 'Newsletter analytics dashboard.'
A subheadline that explains the how in one sentence. Keep it under twenty words.
A visual that shows the actual product, not an abstract illustration. A real screenshot of a clean UI converts better than a stock photo every time.
One primary call to action. Not two options, not 'sign up or see demo.' One.

The objection solo founders dread most is 'I don't have testimonials yet.' The good news is that social proof is a broader category than polished five-star reviews. Anything that reduces a visitor's sense of risk counts, and a solo founder who launched three weeks ago has more options than they think.

The key is to be honest and specific. Vague claims ('loved by hundreds of founders') erode trust; specific, verifiable claims build it. Visitors know an indie SaaS is early, and they often respect that honesty. What they will not forgive is a polished but hollow page that promises enterprise outcomes for a product with no visible traction.

Early user count: '47 indie hackers are already tracking projects here' is stronger than zero social proof.
Real quotes from X or Discord: a screenshot of someone saying 'this is the tool I've been looking for' is a testimonial, just captured differently.
A public changelog: a visible history of shipped features proves the product is alive and the founder is serious about building it.
Usage numbers: tasks created, projects launched, streak days held are all concrete evidence of real adoption that any visitor can verify.

Features lie, outcomes sell

The most common mistake after the hero section is a feature list dressed up as marketing copy. 'AI task generation,' 'impact-per-minute scoring,' 'email reminders with mark-as-done links.' These are features. A visitor who does not already know they need those things will skip every one of them. The fix is to start each feature claim with the outcome: what does the visitor's life look like after they use this feature?

Rewrite every feature bullet by asking 'so what?' exactly once. 'AI reads your source code' becomes 'Your task list writes itself from your actual codebase, so you never start a work session wondering what to do next.' That sentence is longer, but it sells. Features answer what the product does; outcomes answer why the reader should care. When every bullet passes the 'so what?' test, the features section stops being a liability and starts being a reason to convert.

The test for every feature line: if a first-time visitor said 'so what?' after reading it, is the answer already in the sentence? If not, rewrite until it is.

Pricing on the page, not behind a form

Hiding your price behind a 'contact us' button or a sign-up gate is a pattern borrowed from enterprise software that makes no sense for indie SaaS. Your ideal customer is a solo founder or indie hacker who has seen five competing products today, is comparing options quickly, and will disqualify you immediately if the price is not visible. Put the price on the page, in the pricing section, in plain numbers.

Keep the pricing section simple: one free tier that lets people try the core product, one paid tier that unlocks the full value, a clear list of what each includes, and an annual discount with the savings made obvious. The goal is to remove every reason a qualified buyer has to hesitate. If the price creates a question ('does that include X?'), answer it in the pricing copy or a FAQ, not three days later via email.

Show the free tier clearly so visitors know there is zero risk in starting.
Name the paid tier's price in euros or dollars per month, with the annual equivalent beside it.
List three to five concrete things the paid tier unlocks that the free tier does not.
Add one sentence under the price that handles the most common objection: 'cancel any time' or 'no credit card to start.'
Put a CTA button right in the pricing section, not only in the hero.

Keep the page alive as you ship

A landing page is not a launch artifact; it is a living product. The best solo founders update their landing page every time they ship a feature worth mentioning, hear a user describe the problem in a new way, or realize the original value prop was slightly off. Six months of shipping without updating the page means the page describes an old product in language that stopped matching the real audience weeks ago.

The simplest update habit is this: when a task ships, check whether the landing page reflects it. If you maintain a public build-in-public page alongside your project (tools like shipsolo generate one from your shipped tasks automatically, with no extra writing), you can link to it from the landing page so visitors see ongoing progress and active development at a glance.

Start the page today, improve it every week

You do not need a perfect page at launch. You need a clear page: a real headline written in your user's language, features rewritten as outcomes, pricing in plain numbers, and one action to take. Write the headline by borrowing your best user's exact words. Cut every feature bullet that cannot answer 'so what?' Add whatever social proof you can honestly claim today. Ship it. The page will get sharper every week you listen to real users and keep the product moving forward.

Frequently asked questions

What makes a landing page convert for an indie SaaS?: Three things above the fold: a headline that names the specific outcome your target user wants, a subheadline that explains how you deliver it in one sentence, and one clear action to take. Below the fold, stack whatever social proof you have before the feature list, write features as outcomes rather than capabilities, and show the price in plain numbers. The whole page must answer one question for the visitor: is this for me, and is it worth trusting?
How do I write a headline for my SaaS if I'm not a copywriter?: Use the outcome-plus-audience formula: '[Specific result] for [specific person], without [the painful alternative].' Then talk to three real users and find the exact phrase they use to describe the problem. That phrase is almost always a better headline than anything you could invent on your own. Write the headline last, after you understand the user's language, not first.
How do I get social proof for a brand-new indie SaaS with no customers?: Start with whatever honest, specific evidence you have: the number of people on your waitlist, early access users, build-in-public posts with real reactions, screenshots of people saying they want the product, or a public changelog that proves the product is actively being built. Specific and honest always outperforms vague and polished at the early stage.
Should I show pricing on my landing page?: Yes. For indie SaaS targeting solo founders and indie hackers, hiding the price adds friction and filters out your best buyers at the top of the funnel instead of converting them. Show a simple free tier and one paid tier with a clear per-month price and an annual equivalent. Add a brief note handling the main price objection, and put a CTA button inside the pricing section itself.
How often should I update my landing page?: Every time you ship a feature worth mentioning, hear a better way to describe the problem from a real user, or notice visitors bouncing at a section that used to work. A practical cadence is a quick review after every significant release and a deeper review once a month. The page should always describe the product you have today, not the product you had at launch.

Put this into practice

shipsolo turns advice like this into scored tasks for each of your apps.

Try shipsolo free

Keep reading

✨

Shiny object syndrome: how solo founders stop chasing and start finishing

You have four half-built projects, a fresh idea you cannot stop thinking about, and a shipping streak that peaked at day three. That is not a motivation problem. It is shiny object syndrome, and it has a systematic fix.

💰

How to bootstrap a SaaS to 10k MRR as a solo founder

10k MRR is not a vague dream for solo founders anymore. It is a series of concrete gates: idea, MVP, launch, first customer, ramen profitable, and finally 10k. This guide walks through each one, what gets founders stuck at each stage, and how to build a shipping habit that carries you all the way to the goal.