Building an app landing page that converts (you probably don't need much)

Why bother with a website

Your App Store listing is doing most of the heavy lifting for people who discover you through search. But a lot of traffic comes from places where an App Store link feels abrupt. Someone mentions your app on Reddit. A blogger links to it. You share it on Twitter. In all these cases, sending people to a webpage first, instead of straight to the store, lets you control the first impression.

The App Store listing is also constrained. You get a subtitle, a description most people won't read, and a few screenshots that have to follow Apple's format. A landing page lets you show the app in context. A phone mockup with your UI. A one-sentence value proposition. A real explanation of who this is for. You can say things on your own website that would sound weird in an App Store description.

There's also the SEO angle. Your App Store listing ranks for your app name (usually), but a landing page can rank for the problem your app solves. If you're building a Pomodoro timer, your landing page can target "focus timer for deep work" and capture people who don't know your app exists yet.

One more thing: press, bloggers, and anyone writing about your app will link to your website, not your App Store page. Those backlinks accumulate over time and compound your search visibility. If you don't have a website, you're leaving that SEO equity on the table.

Above the fold: the only part most people see

Here's the uncomfortable truth about landing pages: most visitors never scroll. The percentage varies by source and device, but a reasonable assumption is that 40-60% of visitors see only what fits on the first screen. So everything that matters has to be there.

Above the fold, you need three things:

1. A headline that says what the app does, not what it is. "Budgety: Smart Budget Tracker" tells me nothing I couldn't guess from the name. "See where your money went this month in under 10 seconds" tells me what it does for me. The headline should make a visitor think "oh, I want that" before they even see a screenshot.

2. A visual of the app. This should be a screenshot or phone mockup showing the actual interface, not an illustration of a person holding a phone. People need to see what they're getting. If your app looks good, show it. If your app doesn't look good yet, fix that before building the landing page. A screenshot of a nice UI does more conversion work than three paragraphs of copy.

3. A download button. App Store badge, Google Play badge, or both. Big enough to tap on mobile. Don't make people hunt for it. Don't hide it behind a "Learn More" section. Some visitors arrive already convinced by whatever linked them to you. Let them download immediately.

That's it. Headline, visual, button. If you do nothing else, this is enough to outperform most indie app websites I've seen.

Below the fold: for the people who need convincing

The 40-60% who do scroll are doing it because the headline interested them but they're not sold yet. They want more detail before committing to a download. Your job below the fold is to answer their objections, not to repeat your pitch louder.

Feature highlights (2-4, not 12). Pick the features that differentiate you. Not a feature list; a feature highlight. Each one gets a short explanation and a screenshot showing it in action. If your Pomodoro timer has a unique way of handling breaks, show that. If it syncs across devices, show that. Skip the features every app in your category has. Nobody downloads a timer app because it has a "start" button.

Social proof, if you have it. A press mention, an App Store rating badge, a review quote, a download count. Anything that signals other people use this and like it. If you don't have social proof yet, skip this section entirely. Fake testimonials are worse than no testimonials. Your mom saying "great app!" does not count.

A brief FAQ or objection handler. Think about what would stop someone from downloading. "Is it free?" "Does it work offline?" "Will it sync with my existing data?" Answer those in 2-4 short questions. This is especially important if your app has a paid component. People want to know what the pricing looks like before they commit to downloading.

Another download button. Yes, repeat it. Someone who scrolled to the bottom should not have to scroll back up. This is one of the most common mistakes.

What to leave out

Every section you add is a section someone might get stuck on instead of downloading. More is not better.

Skip the "About the developer" section. I know this feels counterintuitive if you've read advice about building personal brands. But your landing page is about the app. Your personal story belongs on your blog, your Twitter, your About page. On the landing page, it's a distraction. The one exception: if being a solo developer is part of your selling point ("built by a teacher who actually uses it in the classroom"), then a one-liner is fine.

Skip the animated hero. I've seen indie devs spend a week building a parallax scrolling hero with floating phone mockups. That time would have been better spent on the app itself, or on writing a better headline. Animation rarely affects conversion rates. A static mockup works.

Skip the comparison table. Unless you have a direct, well-known competitor that your audience is actively comparing against, a feature comparison table just raises awareness of alternatives. You don't want someone visiting your page and thinking "oh, I should check out that other app too."

Skip the newsletter signup on your landing page. I know. Everyone says to collect emails. And you should, but not here. Your landing page has one job: get people to download. A newsletter popup interrupts that. Put the email signup on your blog, on a separate page, or inside the app itself. Don't compete with your own download button.

Skip the video. Most people won't play it. The ones who do will judge you on production quality. Unless you can make something that looks professional (which is expensive and time-consuming), a video hurts more than it helps. A good screenshot communicates faster anyway.

Before you launch: the waitlist page

If your app isn't on the store yet, your landing page has a different job. Instead of driving downloads, it's collecting email addresses so you have an audience on day one.

The pre-launch page is even simpler: a headline explaining what the app will do, one mockup or screenshot (even if it's a beta build), and an email field. That's all. The conversion rate on pre-launch pages is higher when they're short because the ask is small. You're not asking someone to download and use something. You're asking for an email address.

If you want to validate demand before building, the pre-launch page doubles as a validation tool. Run some ads to it, or post it in a few communities, and see if anyone signs up. Fifty signups in a week from a niche subreddit is a stronger signal than any amount of survey data.

Once you launch, swap the email field for the App Store badge and send an email to everyone on the list. Some of them will have forgotten by then, which is fine. The ones who remember are your earliest users and most likely reviewers.

Most of your traffic is on a phone

This seems obvious for a mobile app landing page, but I keep seeing pages that look great on a 27-inch monitor and terrible on an iPhone. The phone is where your visitor is going to download the app. If the page doesn't work well on mobile, you're adding friction right before the conversion event.

Test your page on an actual phone. Not the Chrome device emulator, an actual phone. Load it on cellular, not WiFi. Check that:

• The headline is readable without zooming
• The app screenshot/mockup isn't tiny
• The download button is above the fold on a standard phone screen
• The page loads in under 3 seconds on a mediocre connection
• Nothing is horizontally scrollable (a common layout bug)

If you have both iOS and Android versions, detect the visitor's platform and show the right badge first. Showing both is fine, but put the relevant one in the primary position. An iOS user shouldn't have to scan past a Google Play badge to find the App Store link.

Page speed is a feature

A slow landing page is a broken landing page. You're going to lose visitors to every extra second of load time, and you'll lose them disproportionately on mobile where connections are slower.

Keep the page lightweight. A landing page has no reason to be more than a few hundred kilobytes. If you're using a framework like Next.js or Astro, make sure the page is statically generated. If you're using a page builder like Carrd or Framer, run your URL through Google PageSpeed Insights and check the mobile score. Anything below 90 is worth investigating.

The biggest offenders are usually images. Compress your screenshots. Use WebP or AVIF instead of PNG. A phone mockup image does not need to be 3000 pixels wide when it displays at 400. Lazy-load anything below the fold.

Fonts are the other common problem. Custom fonts add network requests and rendering delay. If you're using Google Fonts, limit yourself to one family and two weights. Or just use system fonts. Nobody notices system fonts. Everybody notices a page that takes four seconds to render text.

Writing copy when you're not a copywriter

Most developers are bad at writing marketing copy, and there's no shame in that. It's a different skill from writing code. But you don't need to be a copywriter to write a decent landing page. You need to follow a few rules.

Describe what the user gets, not what the app does. "Automatic expense categorization using machine learning" is a feature. "Know where your money goes without manually tagging anything" is a benefit. Lead with benefits, mention features as supporting evidence.

Be specific. "Helps you stay focused" is vague. "25-minute work sessions with break reminders and a daily focus score" is concrete. Specificity builds trust because it sounds like you're describing a real thing.

Cut your word count in half, then cut it again. The first draft of your landing page copy is probably three times longer than it needs to be. Every word that doesn't move someone toward downloading is a word that might move them toward closing the tab.

Read it out loud. If you stumble over a phrase, it's too complicated. Landing page copy should sound like you're explaining the app to a friend at lunch. If it sounds like a press release, start over.

If you're struggling with the headline, try this formula: [Outcome] + [timeframe or qualifier]. Examples: "Track your habits without the guilt trips." "Journal entries in 60 seconds." "Learn Japanese while you commute." Not every app fits this pattern, but it's a useful starting point.

What to build it with

You don't need to custom-code your landing page. Unless your landing page is also your app's marketing site with a blog and documentation, a hosted page builder is faster and good enough.

Carrd ($19/year) is the simplest option. Single-page sites with custom domains. Plenty of indie devs use it. The pages load fast, look clean, and you can set one up in an afternoon. The constraints are actually helpful because you can't add twelve unnecessary sections.

Framer gives you more design control if you want something visually distinctive. The free tier works for a basic page. The downside is that it's easy to over-design and end up with something that looks like a portfolio piece instead of a functional page.

Next.js or Astro make sense if you already know React or want the landing page to be part of a larger site (blog, docs, changelog). Astro is lighter if you don't need interactivity. Next.js is the better pick if you're planning to add dynamic features later. Either way, deploy to Vercel or Netlify and don't think about hosting.

WordPress is fine if you're comfortable with it, but overkill for a single landing page. The performance overhead is real, and you'll spend time managing updates and plugins instead of working on your app.

Whatever you use, make sure you own your domain. Not yourapp.carrd.co. Buy yourapp.com (or .app, or whatever TLD makes sense) and point it at your page. It costs $12 a year and looks significantly more professional. It also means you can change your page builder later without breaking every link people have shared.

SEO for your landing page

Your landing page probably won't rank for competitive keywords right away. But it can rank for your app name (which it should, and if it doesn't, something is wrong), and it can start building domain authority for future content.

The basics: your title tag should include your app name and what it does. "Budgety - See Where Your Money Goes" is better than just "Budgety" and miles better than "Budgety - Home." Your meta description should be a compelling two-sentence pitch. Both of these show up in Google results, so treat them as ad copy.

Add Open Graph tags so your page looks good when shared on Twitter, Discord, Slack, and anywhere else that unfurls links. An og:image of your app screenshot in a phone mockup against a clean background works well. If you skip this, shared links will either show nothing or pull some random element from your page.

If you're planning to write blog content (and you should, for SEO), keep the blog on the same domain as your landing page. Blog posts at yourapp.com/blog pass their SEO authority to your landing page. Blog posts at medium.com/yourapp don't.

Submit your sitemap to Google Search Console. If your page is new, it can take days or weeks to get indexed otherwise. The zero-budget marketing guide covers more on SEO as a long-term acquisition channel.

Smart app banners and deep links

Apple has a feature called Smart App Banners. Add a meta tag to your page and Safari on iOS will show a banner at the top linking to your app in the App Store. If the user already has the app installed, it opens the app instead. It's a single line of HTML:

<meta name="apple-itunes-app" content="app-id=YOUR_APP_ID">

This is free, takes thirty seconds to add, and gives mobile Safari users a native-feeling download prompt. I don't know why more indie developers don't use it. Probably because they don't know about it.

On Android, you can do something similar with a Digital Asset Links file and an intent filter, though it's more involved. For most indie apps, a Play Store badge link is sufficient.

If you're doing any kind of marketing or community posting, consider adding UTM parameters to your landing page links so you can see which channels bring traffic. Google Analytics or whatever analytics you're using will break down visits by source, which tells you where to spend more time.

Localization: probably not yet

If you're targeting multiple markets, you might wonder whether your landing page should be translated. For most indie developers at launch, no. Get the English version working first. See if you get traction. If a particular non-English market starts showing up in your analytics, that's when it makes sense to localize the page for that market.

When you do localize, don't just translate the text. Adjust the messaging for that market. What resonates with Japanese users is different from what works in the US. The localization mistakes article covers common pitfalls. The short version: machine translation without human review will make you look amateur in markets where trust is already harder to earn.

Measuring whether it works

The metric that matters is click-through rate on your download button. Not bounce rate, not time on page, not scroll depth. How many visitors click the App Store or Play Store badge? That's your conversion rate.

You can't easily track what happens after the click (Apple and Google don't let you see individual conversions from web to install), but you can see directional trends. If you make a change to your landing page and the click-through rate goes up while your App Store install rate stays the same, the landing page change probably helped.

For analytics, keep it simple. Plausible, Fathom, or PostHog are all lightweight and privacy-friendly. Google Analytics works but adds more weight than necessary for a single landing page. Add a click event to your download buttons and check it once a week. Don't build a dashboard. Don't check it daily. The numbers are too small at the indie scale to mean anything on a daily basis.

If you want to test changes, use the techniques from the A/B testing guide, but be realistic about traffic. If you get 200 visitors a week, you cannot run meaningful A/B tests on your landing page. Instead, make a change, wait two weeks, compare the numbers. Not as rigorous as a proper test, but at indie traffic levels it's the best you can do.

Patterns from landing pages that convert well

I've looked at a lot of indie app websites while building the scanners, and some patterns keep showing up among the ones that seem to do well (based on App Store ranking and review volume trends):

Dark background, bright app screenshots. The app UI pops against a dark page. This is why Apple's own marketing uses dark backgrounds. Your screenshots become the brightest thing on the page, which is where you want the visitor's eyes.

The headline mentions a specific outcome. Not "the best meditation app" but "fall asleep in 10 minutes." Not "project management for teams" but "see who's blocked without asking in standup." Specificity converts.

One rating badge, not a wall of press logos. A single "4.8 stars, 2,000+ ratings" badge near the download button is more effective than a row of publication logos. Users trust aggregate ratings from other users more than press mentions they may not have read. If your rating is strong, show it.

The page loads instantly. Not "fast." Instantly. The successful indie landing pages I've seen tend to be static HTML or very lightweight framework builds. No loading spinners, no layout shift, no waiting for fonts.

Short pages outperform long ones. The apps with strong conversion pages tend to have maybe 3-4 sections total. Headline, features, social proof, download. Some of the best ones I've seen are barely two screens tall. The impulse to add more content is usually about the developer's anxiety, not the user's needs.

The two-hour landing page

If you don't have a landing page yet, here's what you can do in two hours:

Hour one: Sign up for Carrd or open a new Next.js/Astro project. Write your headline (what the user gets, not what the app is). Take a screenshot of your best screen and put it in a phone mockup (there are free mockup generators like Screely or Shots). Add your App Store badge. Push it live.

Hour two: Add 2-3 feature highlights with screenshots below the fold. Write a one-paragraph description. Add a second download button at the bottom. Set up a basic analytics snippet. Add the apple-itunes-app meta tag. Add Open Graph tags. Push again.

That's a complete, functional landing page. You can refine it later, but don't let perfectionism stop you from having anything at all. A mediocre landing page beats no landing page. You can always improve it once you have actual traffic data telling you what to fix.

When to update your landing page

Most indie developers build their landing page at launch and never touch it again. Then a year later they wonder why it's not performing. Your page should be updated whenever:

• You ship a major feature (update the screenshots and feature highlights)
• Your rating crosses a threshold like 4.5 or 4.7 (add or update the rating badge)
• You get a notable press mention or award (add it as social proof)
• You pass a milestone like 10K or 50K downloads (add the number)
• Your App Store screenshots change (keep the landing page and store listing visually consistent)

Put a recurring reminder to review your landing page once a month. Not to redesign it, just to check if the content is still accurate and the screenshots match your current app. Five minutes of maintenance prevents the "this looks nothing like the app I downloaded" problem.

A landing page for an indie app doesn't need to be fancy. It needs to answer one question quickly: "what does this do and should I download it?" If your page answers that in the first screen, you're ahead of most indie developers who either have no page at all or have a page that makes the app harder to understand instead of easier.

If you're looking for apps to build, the opportunity scanners surface gaps in the App Store across six different angles. And if you're already building something, a decent landing page takes two hours and pays for itself the first time someone searches for your app name and finds a real website instead of nothing.