SaaS website design for a product nobody can hold

A normal business site describes a service and asks for an enquiry. A SaaS site has to demonstrate a product nobody can touch, hand people into a trial, survive a procurement review it never sees, and carry a documentation library that often outranks the homepage.

Write the job your software does in one sentence a customer would recognise. Decide whether the site feeds a trial or a sales team. Design the pricing page around the unit you charge on. Then build what unblocks the rest of the buying committee: integrations, security, docs and a dated changelog.

For a paid campaign or a waitlist, one landing page is fine and often better. For a real product you need a site, because a landing page cannot hold documentation, integrations, a security page, a changelog or the long-tail content that brings organic traffic. Grow it into a site once you have paying customers.

Both, but as separate engagements with separate teams. This page covers the marketing site that sells the product. If you need the product itself built, an MVP, a portal or a dashboard, that is our web application development service, and it is a different scope, timeline and skill set.

A focused marketing site with a homepage, a small set of feature pages, pricing and the trust pages usually runs in weeks rather than months. What stretches it is not design, it is decisions: who the site is for, which motion it serves, and what the plan structure is.

A single page built for one audience and one action, usually starting a trial or booking a demo. No navigation competing with the call to action, one clear promise at the top, evidence in the middle, and the same action repeated on the way down. It does not have to serve everyone.

A first screen that names the job rather than the category. Proof a real person already got that outcome. A view of the actual product doing the work. One action, repeated. Most weak SaaS landing pages are not badly designed, they are trying to say four things at once.

If you are pre-revenue and still learning who the buyer is, yes. A good template on a fast builder gets you live in days, and you will rewrite the copy three times anyway. Move to a custom build when the template blocks a real pricing structure, docs or integration pages.

Worth it for validation, rarely worth it after that. Free templates tend to carry heavy page weight, generic layouts that fifty other startups also picked, and licence terms worth reading properly. Use one to test whether anyone wants the product, and replace it once someone does.

Because the reference set is a closed loop. Ten of the twelve US results for this term are inspiration galleries, template libraries or example roundups. Designers shop them, ship the forty-first version of what they saw, and submit it back. The way out is designing from the buyer and the sales motion.

State the unit you charge on first, in plain words. Show three or four columns with one anchored as the recommended plan. Keep each card short enough to scan and put the full comparison table below it. Finish with the objections your sales team hears most.

Almost always yes, at least in structure. Hiding it filters out serious buyers who will pick a competitor who told them. If your deals are genuinely custom, publish the model rather than the number: what you charge on, what changes it, and which plan suits which size of team.

Fewer than most teams build. A homepage, one page per major job the product does, pricing, about, contact, and the trust set: integrations, security, docs and changelog. Feature pages multiply later based on what people actually search for, not on your internal feature list.

In descending order of effectiveness: an interactive tour of the real interface, a short silent loop of the actual workflow, an annotated sequence of screens in the order a user meets them, and last a static screenshot. An angled screenshot with nothing labelled shows software exists, not what it does.

We will not put a figure on a page, because a number written without seeing your situation is aimed at an average rather than at you. What moves scope: how many product jobs need their own page, whether you sell self-serve or through a sales team, and whether docs have to be migrated.

Ask three questions. Can they explain your product back to you after one call. Have they shipped a pricing page and a signup flow, not just a homepage. And who personally does the work after the pitch. The visual portfolio is the easiest part to fake and the least predictive.

Usually not. Marketing needs to ship changes daily without a deploy review, and the product needs stability. Keep them separate, share a design token set and a component library so they look like one company, and put real effort into making the seam invisible at the signup handoff.

Yes, in the ordinary sense. It is software you access over the internet on a subscription, with no installation and no infrastructure to manage, which is the definition of software as a service. The underlying model is often sold separately as an API, which sits closer to platform territory.

Neither, strictly. Netflix is a subscription streaming service: what you are buying is content, not software functionality. It runs on cloud infrastructure and feels like SaaS because of the billing model, but SaaS normally means software that does a job for you. Arguments about it come down to delivery model versus what is actually sold.

It is being reshaped, not replaced. What is under pressure is thin software whose only value was a tidy interface over a simple database, because that is now cheap to rebuild. What holds up owns real workflow depth, proprietary data, integrations and compliance obligations. Generic capability claims have stopped persuading.

The consistent pattern is vertical depth over horizontal breadth: software built for one industry, doing something regulated, operational or expensive to get wrong. Categories with steady pull include compliance and security tooling, revenue and billing operations, healthcare workflow, and anything that removes a compliance burden a business cannot ignore.