If you're building a software product, at some point someone will ask about the website. Maybe it's your board. Maybe it's a donor or a potential user. And the honest answer is that "the website" and "the app" are two different things that happen to live on the internet under the same brand.
This distinction is not obvious. The software industry doesn't explain it clearly upfront, and most conversations about building a product focus entirely on the product itself. The infrastructure that helps people find it, trust it, and decide to use it is a separate discussion that deserves its own attention.
Here's what you need to understand.
Two Products, Two Audiences
Every software product that grows eventually needs two things: the app itself, and a separate site that introduces it to the world. They serve completely different audiences at completely different moments.
A web app is a tool. Your users log in, accomplish something, and log out. The experience is built entirely for people who already made a commitment to use it. Think about a platform like Gospel Infrastructure, which helps churches manage congregation data. A pastor logs in to run a giving report or update a member record. The interface exists to serve someone who is already inside the relationship. It has no reason to pitch anyone on anything.
A marketing site is a different product entirely. It serves someone who has never heard of you, isn't sure they need what you offer, and hasn't decided whether to trust you. Every page, every headline, and every call to action is working to move that person from curious to convinced. It doesn't need all the features of your app. It needs to answer one question: why does this exist, and why should I care?
Building one well doesn't mean you've built the other.
What This Looks Like With Products You Already Use
The clearest way to see this is to look at tools you probably already use. In each case, the marketing site and the app are distinct products built for distinct purposes — and you can see it in the URLs.
Built for strangers. Benefit-focused copy, social proof, pricing, and conversion. Optimized for search so newcomers can find it.
Built for committed users. You log in here. Everything inside assumes you already made the decision to use Notion.
Targets finance teams and CTOs who need to justify a vendor decision. Case studies, developer docs, pricing for comparison shoppers.
The merchant dashboard. Completely separate from the marketing site. Designed around task completion, not persuasion.
Resource-rich and SEO-heavy. Built for people still in research mode comparing email platforms. Serves a wide audience from solo creators to mid-size teams.
Campaign management, audience lists, analytics. A completely separate surface. Logging in takes you somewhere designed for action, not browsing.
Targets distinct buyer types with separate landing pages for support, sales, and product teams. Structured around educating different kinds of decision-makers.
Where your support team actually works. Inbox, customer profiles, conversation routing. Built for people doing the job, not evaluating the tool.
In each case, the company made a deliberate decision to build these as separate products. The marketing site converts prospects. The app serves customers. They share a brand but not a codebase.
Why They're Built Differently
The distinction isn't just strategic. It's technical, and understanding it helps explain why you actually need two separate things.
How apps are built
Most modern web apps are built as Single Page Applications, or SPAs. The browser loads a shell once, and JavaScript takes over from there, pulling in data, rendering interfaces, and responding to user actions. Frameworks like React and Vue are designed for this. The experience is fast and responsive for logged-in users. The tradeoff is visibility: a pure SPA is essentially invisible to search engines. If your app is a pure SPA with no public-facing layer, someone searching "church management software" or "nonprofit fundraising platform" is unlikely to find you.
How marketing sites are built
A marketing site needs to be discoverable. That means content needs to exist in plain HTML that search engines can read the moment they arrive — a model called server-side rendering, or SSR. It also needs to load fast for a stranger on a mobile connection who has no patience and no prior reason to trust you. These are fundamentally different technical requirements than the ones that make a great app experience.
Authentication adds another layer
Your app lives behind a login. Everything important happens after someone proves who they are. A marketing site is entirely public — no login, no account, no friction. The infrastructure that handles authenticated sessions in your app has nothing to do with how a stranger lands on your homepage.
Content updates work differently
Your app's content is usually dynamic, stored in a database, changing based on what each user needs to see. Your marketing site needs to be updated regularly by your communications team — new landing pages, blog posts, pricing updates — without requiring a developer to push code. That's a different system with different tooling.
When you treat the app and the marketing site as the same project, you end up making tradeoffs that hurt both. The app gets burdened with SEO concerns it wasn't designed for. The marketing site ends up inflexible or hard to find. Separating them clearly lets each do its job.
Three Ways to Approach This
Fully separate properties
The marketing site lives at yourdomain.com. The app lives at app.yourdomain.com. Different codebases, different deployment pipelines, different update cycles. This is the cleanest model. It forces clarity because the two can't share complexity. Most mature software products land here eventually, and most of the examples above use this approach.
A hybrid framework
Tools like Next.js let you run a single codebase that serves both a public marketing layer and an authenticated app layer. Public pages get server-rendered for SEO. App pages sit behind authentication. This works well for early-stage products where resources don't support fully separate builds yet. The discipline required is keeping the two layers genuinely distinct within the codebase, or the benefits of each start to erode.
A headless CMS paired with the app
A headless Content Management System like Contentful or Sanity sits in front of your marketing layer and lets your communications team update content without touching the app codebase. For mission-driven organizations where the person running communications and the person managing the product are rarely the same, this separation often becomes essential.
How to Think About Your Own Situation
The right question isn't just "what should the app do?" It's also "how will the people who need this actually find it and decide to use it?"
Those are connected questions with different answers that require different work. Your app can be excellent and still fail to attract users if there's no marketing infrastructure behind it. A compelling marketing site can only take you so far if the product it sends people to doesn't deliver.
At Hillcraft, we scope these as distinct deliverables from the start, because they require different decisions, different technical approaches, and different ongoing maintenance. Understanding the difference before you build saves you from having to retrofit one after the other is already done.
If you're working through how your product, your marketing presence, and your overall digital strategy fit together, that's a conversation worth having early.
Hillcraft is a strategy-first software agency for mission-driven leaders. We build with clarity about what you're building, who it's for, and why it matters.
Sorting out the app and the site at the same time?
A Clarity Day is the fastest way to map out both — what the product needs to be, and the marketing infrastructure that will help the right people find it.
Learn About Clarity Day