Landing Pages

If you’re building a SaaS app, you need a landing page. Even if your app is free. Even if it’s open source. Even if it’s “just a side project.”

The landing page isn’t about selling - it’s about clarity:

• What is this?
• Who is it for?
• Why does it exist?
• How can I use it?

You don’t need to hire a designer. You don’t need a fancy marketing funnel. But you do need something people can link to, share, and understand in under 15 seconds.

Build a Minimum Viable Landing Page

Here’s what every good landing page should have:

Write a Headline

A one-liner that explains what it is and who it’s for.

• ✅ “Track your subscriptions from the terminal. Self-hosted. No BS.”
• ✅ “Simple coworking space bookings. Built for small teams.”
• ❌ “Next-gen platform for dynamic synergy.”

Add a Short Paragraph

A sentence or two giving a bit more context. Think of it like your README intro, but in plain English.

Set a Call to Action

What do you want people to do?

• Clone the GitHub repo?
• Try the live demo?
• Sign up for the hosted version?
• Join the waitlist?

Make it easy. Big button. Clear action.

Show Screenshots or GIFs

Show the thing. Real pixels. Don’t use mockups with shadows and gradients unless you really know what you’re doing.

List Features

Bullet points are your friend.

Keep it honest. Don’t oversell.

Add Trust Signals

• GitHub stars or forks
• Testimonials (even if it’s just a friend who used it)
• “Used by…” or logos (if legit)
• Link to your changelog or roadmap

Choose Domain and Hosting

You don’t need a big stack. A simple static site does the job. Assuming you already have a domain, the actual URL for your landing page can be something like:

• exampleapp.com
• exampleapp.com/landing
• exampleapp.com/info
• exampleapp.com/about
• exampleapp.com/start

Mixing Marketing with Product

You really need two bits of public presence:

• Landing page: Explains what it is, who it’s for, and how to use it.
• Product page: The actual app or service itself.

So the question is, what’s the best way to structure this? For example, your www and root domain could be your landing page. When they click “Try it now” or “Get started,” they go to the product page at app.exampleapp.com or exampleapp.com/app - or exampleapp.app.

For a few reasons though, you really should keep these separate, in separate GitHub repositories, and ideally separate hosting. This way, you can iterate on the landing page without worrying about breaking the app, and vice versa. Also, if your app or hosting provider goes down, your entire platform isn’t dead. For example:

flowchart LR
    subgraph GitHub
        WWW["<i class='fab fa-github'></i> github.com/example/www-site"]
        APP["<i class='fab fa-github'></i> github.com/example/app-site"]
    end

    subgraph Hosting
        CF["www\.exampleapp\.com<br/><i class='fab fa-cloudflare'></i> Cloudflare Pages"]
        VPS["app\.exampleapp\.com<br/><i class='fa fa-server'></i> Racknerd VPS"]
        STATUS["status\.exampleapp\.com<br/><i class='fab fa-atlassian'></i> Atlassian StatusPage"]
    end

    WWW --> CF
    APP --> VPS
    STATUS

This diagram shows how you can keep your landing page, app, and status page separate. Each lives in its own repo and hosting environment, so you can update or fix one without breaking the others.

Compare Hosting Options

Deploy via:

• Cloudflare Pages
• Netlify
• Vercel

All of these have solid free tiers.

Link Everything Up

Your landing page should include links to:

• GitHub repo (if OSS)
• Docs (if available)
• Changelog or version history
• Support or contact info
• Status page (if applicable)

This creates a self-contained experience. Nobody should be confused about where to go next.

Use Dev-Friendly Landing Page Builders

If you don’t want to roll your own:

Focus on OSS First, SaaS Second

If you’re building both a self-hosted OSS version and a paid SaaS:

• Let the landing page focus on the problem it solves
• Give users a choice:
  • “Run it yourself” → link to GitHub
  • “Use our hosted version” → link to signup

This avoids the hard sell, and builds trust with dev-minded users.

Wrap Up

You don’t need to become a marketing expert. But you do need to explain:

• What you built
• Why it exists
• Who it helps
• How to try it

Once you’ve got that written down and deployed, you now have a product - not just a repo.

Keep it simple. Iterate as you go.