SaaS Website Design
For B2B SaaS teams whose website no longer matches the product or the buyer: too dense, too generic, or built one page at a time. I design the architecture, the pages and the system behind them, and I can take the design through to a production build.
By Krushna Palwe, senior visual designer. Best suited to B2B SaaS, technology and brand-system projects. Based in Pune, Maharashtra. Available for remote projects with teams in Pune, Mumbai and Bengaluru (Bangalore).
01 / Problems
When this is the right project.
- The site lists features but never says what changes for the buyer.
- Pages were added one at a time and no longer share a grid, a type ramp or components.
- Technical buyers read the diagrams first, and the diagrams don’t agree with each other.
- A hero carousel, buried CTAs and a mobile menu that breaks: the usual audit findings.
- Every new page needs a designer and a developer starting from scratch.
02 / Included
What’s included.
- UX audit
- The current site reviewed for hierarchy, navigation, CTA placement and mobile behaviour.
- Information architecture
- Site structure, page hierarchy and the path from first visit to a sales conversation.
- Page design
- Homepage, product, platform and resource pages, designed desktop and mobile.
- Technical diagrams
- A diagram standard for architecture and workflow visuals, so complex products read at a glance.
- Interactive tools
- Calculators and comparison tools designed as lead tools, not price lists.
- Build or handoff
- A production build (React and Tailwind, Astro or Shopify), or a documented handoff to your developers.
- QA
- Checked at real widths down to 320px, for contrast and keyboard use, before launch.
Scope boundary: Agree design, build, content and integration ownership separately. Hosting, paid tools and ongoing maintenance are not automatically included.
03 / Process
How the work runs.
Stages overlap on real projects. They’re the order decisions get made in, not a rigid schedule.
- 01
Audit
What the site says, what buyers need to read, and where the two disagree.
- 02
Architecture
Pages, hierarchy and the journey to a conversation, agreed before visual design.
- 03
System
Tokens and component rules, so every page is built from the same parts.
- 04
Pages
Key templates first, then the pages that reuse them.
- 05
Build
Local build, review, preview deploy, merge: each change visible before it goes live.
- 06
QA and launch
Responsive, accessibility and content checks. Done means live, not handed over.
04 / Relevant work
The evidence.
Enterprise SaaS · Cloud migration & disaster recoverySee the Datamotive website and TCO calculatorHomepage, product pages and an interactive TCO calculator for a B2B disaster-recovery platform.
Everyday apparel · Identity & commerceSee the BLANKSY Shopify storefrontA category-first storefront with a mobile layout of its own.
05 / Proof
Shipped, and checkable.
The Datamotive homepage and product pages were rebuilt on the new token system and are live at datamotive.io.
Datamotive case studyThe Datamotive disaster-recovery TCO calculator lets a buyer compare one-to-three-year costs before any lead form.
Datamotive case studyThe Datamotive site was designed and built in-house in React and Tailwind CSS on Sanity CMS, deployed on Vercel.
Datamotive case studyThe BLANKSY storefront is live at blanksy.in, designed for desktop and as its own mobile layout.
BLANKSY case study
06 / Questions
Asked before starting.
Do you also build the site?
Yes. I’ve taken designs to production in React and Tailwind on Sanity (Datamotive), Astro (this site) and Shopify Liquid (BLANKSY), directing AI-assisted development tools and reviewing every change. If you have developers, I hand off a documented system instead.
Can you redesign part of the site?
Yes. Usually the homepage and product pages come first, on foundations the rest of the site can adopt later.
Which CMS do you work with?
Sanity and Shopify in production. The design system doesn’t depend on the CMS.
How do you handle technical content?
With a diagram standard and outcome-first copy. Claims have to survive a cloud architect’s reading, so hype is replaced by specifics.
Do you design for mobile separately?
The system is responsive by default: the same tokens and hierarchy restack. Where the mobile experience needs its own layout, as on the BLANKSY store, it gets one.
Related notes
Discuss your SaaS website.
Share your current website, target buyer and the product story the new site needs to explain. Share what you know; missing inputs can be discussed together.
Best suited to B2B SaaS, technology and brand-system projects. Based in Pune, Maharashtra. Available for remote projects with teams in Pune, Mumbai and Bengaluru (Bangalore).