02 SaaS & technology website design
SaaS website design for products that have outgrown their site
Products change every quarter; marketing sites often do not. New features, integrations and use cases pile up in a site built for the first version of the product, and every launch needs a developer. We design and build SaaS and software company websites as page systems your product marketing team can extend on its own.
- Feature, use-case and integration pages generated from structured content
- Pricing, demo and signup journeys designed with sales and product
- A marketing site, separate from your application and its release cycle
- Product marketing sitewww.
- Producttpl: Overview
- Platform
- How it works
- Featurestpl: FeatureNote 1
- One page per capability
- Use casestpl: Use caseNote 2
- By job
- By team
- By industry
- Integrationstpl: Integration
- Directory
- Detail pages
- Pricingtpl: PricingNote 3
- Plans
- Enterprise
- Trusttpl: Page
- Security
- Customers
- Changelog
- Producttpl: Overview
01 Diagnosis
Signs your website is behind your product
- S1
Features live in a single long page
Buyers cannot link to, search for or share the one capability they care about, and search engines see one page instead of twenty answers.
- S2
Use cases are written as product tours
Visitors arriving with a job to do have to translate your feature names into their problem themselves.
- S3
Pricing raises more questions than it answers
Plan differences are unclear, limits are hidden, and the enterprise path is just “Contact us”.
- S4
Every launch needs a ticket
Marketing waits on engineering for new pages, so launches ship with a blog post instead of a proper page.
- S5
Screenshots are out of date
The UI changed twice since the site was designed; product visuals now misrepresent the product.
02 Structure
The structure of a product marketing site
Product, features, use cases, integrations, pricing and trust - each a section built from its own content type, linked to the others.
Plate 1 markers
Feature pages
Generated from a Feature content type, each with its own URL, summary, visuals, related use cases and integrations.
Use-case pages
Written from the buyer’s job, linking to the features and integrations that do it.
Conversion points
Pricing and every feature page lead to signup or demo - whichever your sales model uses for that buyer.
| Page type | Answers | Built from | Leads to |
|---|---|---|---|
| Product overview | What is it and who is it for? | Overview template | Features, use cases, demo |
| Feature | Can it do this specific thing? | Feature entries | Use cases, integrations, signup |
| Use case | Will it solve my job? | Use-case entries | Features, customer stories, demo |
| Integration | Does it work with our stack? | Integration entries | Docs, signup |
| Pricing | What will it cost us? | Plan entries | Signup or enterprise contact |
| Security | Can we approve this vendor? | Page + policy documents | Trust documents, enterprise contact |
| Changelog | Is the product moving? | Release entries | Features |
03 Page systems
Feature and use-case pages as a system
A SaaS site is mostly a set of repeating page types: features, use cases, integrations, customer stories, comparisons, changelog entries. Each type is a content model and a template, so a new feature page is a CMS entry, not a design job.
Relationships do the cross-linking. A feature knows which use cases and integrations it belongs to; a use case lists its features. Pages stay connected as the product grows, and internal links stay accurate without anyone maintaining them by hand.
Content types
6–10
- Feature
- Use case
- Integration
- Customer
- Plan
Relationships
Typed references
- Feature to use case
- Feature to integration
Templates
6–12
- Feature
- Use case
- Pricing
- Comparison
Pages
Grows with product
- Built from entries
- Linked automatically
04 Pricing page
A pricing page that answers before it asks
- 01
Plans people can compare
Two to four plans with the differences that matter for choosing, and a full comparison table below for those who want it.
- 02
Limits stated, not hidden
Seats, usage and feature limits visible on the page, so the sales call does not start with surprises.
- 03
A real enterprise path
What enterprise adds - security reviews, SSO, contracts, support - and a dedicated contact route with the right questions.
- 04
Pricing questions answered
Billing, trials, discounts, cancellations and currency in a short FAQ next to the plans.
- 05
Plans managed in the CMS
Prices and plan features maintained as structured data, so a pricing change is an edit, not a deployment.
05 Journeys
Demo and signup journeys
Sales-led and product-led motions need different paths - many SaaS companies run both. Each path is designed end to end, including what happens after the website.
- Demo requestShort form: role, company size, use case.
- Qualify & routeRules in the CRM assign the right owner.
- BookQualified requests pick a slot directly.
- CRM recordSource, pages viewed and consent attached.
- SignupMinimal fields; SSO where possible.
- Hand to productAccount created in your app, not on the site.
- OnboardingLifecycle email and in-app guidance.
- AttributionCampaign and landing page carried into product analytics.
06 Product visuals
Showing the product honestly
- 01
Simplified UI, not screenshots
Focused, redrawn product views that highlight one idea and survive minor UI changes, instead of full screenshots that date in months.
- 02
Real data, never invented metrics
Product views use plausible neutral data; we do not put fabricated results into dashboards to imply outcomes.
- 03
Diagrams for the invisible
Architecture, data flow and integrations explained with diagrams that technical evaluators can read.
- 04
Lightweight motion
Short, optional animations for workflows; content and meaning never depend on them.
07 Marketing autonomy
Launch new pages without developers
Product marketing works in the CMS: a new feature, integration or plan is an entry with relationships, previewed in context and released on the day of the launch.
- Feature entryProduct marketing fills structured fields.
- RelationsLinked to use cases, integrations, plans.
- PreviewReviewed in context on staging.
- Scheduled releaseGoes live with the product launch.
- DistributedChangelog, sitemap and search updated.
08 Engineering
Engineering a marketing site, not an app
- E1
Separate from the app
The marketing site deploys independently of your product, so launches and fixes never wait for an app release.
- E2
Static-first and fast
Pages rendered to HTML and served from a CDN. Core Web Vitals “good” thresholds are the design budget.
- E3
Docs and app on their own subdomains
Clear boundaries with documentation and the app, with consistent navigation and analytics across them.
- E4
Analytics with a tracking plan
Named events for demo, signup and pricing interactions, agreed with growth and product before build.
Scope: this service covers your marketing website. Building the SaaS product, an MVP or a customer portal is a separate Comtau engagement.
09 Questions
SaaS website design - questions
What is SaaS website design?
Designing the marketing website of a software-as-a-service company: the pages that explain the product, its features, use cases, integrations and pricing, and that move visitors to a demo or a signup. It is different from designing the application itself.
What pages does a SaaS website need?
Usually a product overview, individual feature pages, use-case pages, an integrations directory, pricing, security and trust pages, customer stories, a changelog and resources. The exact set depends on whether you sell through sales, self-serve signup or both.
Webflow, WordPress or a headless CMS for a SaaS website?
Webflow suits smaller teams that want visual control over a defined set of pages. WordPress works well for content-heavy sites with many editors. A headless CMS fits when features, integrations and plans are structured data reused across the site, docs and app. We decide from your content model and team.
How do you show the product without out-of-date screenshots?
We redraw focused product views that illustrate one idea each, rather than full screenshots, and keep them as components that are easy to update. Where real screenshots are needed, they are captured from your product with neutral data.
Do you build the SaaS product itself?
Not as part of this service. This page covers the marketing website. Application, MVP and portal development are separate Comtau engagements.
How long does a SaaS website take?
Typically two to five months, depending on the number of page types, how much content needs writing and the integrations involved. A redesign of an existing product site adds migration work for URLs and content.
Launching a single product or campaign page rather than a site? See product landing pages. Selling to buying groups with long cycles? The B2B website design page covers evaluation content and CRM handoff. Building the SaaS product itself is a separate engagement: see SaaS application development, or SaaS MVP development for a first release. Both site types are part of our corporate website development service.
Next step
Tell us about your product and your site
What you sell, how customers buy (demo, signup or both), what the site runs on today and what launches are coming.
Send a SaaS website briefA senior lead reads it
Comtau engagements are led by senior people, and the brief goes to them rather than to a sales queue.
Specific questions
Questions about scope, content and platform in writing, or a short call if that is faster for you.
A proposal, or a straight answer
Phases, deliverables, acceptance criteria and price. If Comtau is not the right fit, we say so.