
Product design · SaaS
Alignify
Customers, orders, inventory and revenue analytics in one CRM dashboard built for sales teams.
View case studyB2B SaaS product design and build, from Dhaka
I'm Maniruzzaman Jubayer, a design engineer, and founders who search for a B2B SaaS design agency get me and the senior team of designers and developers I lead. We design the product, its dashboards and its website, then build them in TypeScript, React and Next.js. You get the senior people an agency would bill for, and you talk to them directly.
Seven B2B SaaS case studies on this site, from a sales CRM to a micro-task platform, built by my team in React, Next.js, React Native and Flutter.

Design engineer and product design lead, with a senior team behind me
04 problems
Four I hear in almost every intro call, and what I do about each one.
The sign-up works, the first screen is empty, and nobody on the team can say what a good first session looks like. I name one activation event with you, then design backwards from it: fewer fields, a first-run screen with one action, and empty states that teach. My notes on SaaS onboarding design set out the method.
It shows every number the database holds, so nobody can tell what needs attention this morning. I start from the decision the person makes when they open it, keep the few metrics that change that decision, and give each one a comparison so it can be read in seconds. The rest moves to reports, where it belongs.
Figma says one thing, production says another, and every new feature adds a third version of the table. I fix it at the source: one set of tokens and components, named the same in Figma and in code, and a team that designs and builds. That is what design engineering means in practice.
The first large deal brings a security questionnaire and an accessibility form: SSO, roles, audit logs, data export, a VPAT. These are product screens as much as policies, so I design them with the core flows rather than in a panic before the contract is signed. The rules section below names each one.
A sales CRM, a micro-task platform, an AI marketing platform, a healthcare SaaS, and the websites and landing pages that sell SaaS products.

Product design · SaaS
Customers, orders, inventory and revenue analytics in one CRM dashboard built for sales teams.
View case study
Product design · SaaS
A two-sided platform for labelling, QA and content tasks, designed for both the teams and the workers.
View case study
Product design · Marketing tech
Discover creators, negotiate and manage campaigns with AI agents, all from one dashboard.
View case study
Website design · HR tech
A new website for core.hr, the HR tech company formerly CoreHR, designed together with its app visuals.
View case study
Product design · Healthcare
A healthcare platform with more than 50 screens, from the design process to the final dashboard.
View case study
Landing page · Fintech
A finance management SaaS landing page, from the layout grid to the final page.
View case studyTrials signing up and going quiet? Let's look at your first session together.
Start a projectSix kinds of product my team works on, each with its own users, data and pressure points.
Pipelines, deal views and performance numbers that a sales team checks many times a day. The work is speed: filters that remember, bulk actions, and a record page that answers the next question. My team designed Alignify, a sales CRM that shows performance in real time.
Products with two sides, such as the team that posts the work and the people who do it, each needing its own view. My team designed OpsLoop, a micro-task platform for teams and workers.
People data is personal data, so roles, permissions and privacy defaults matter from the first screen. My team designed Core.hr, a new website for an HR tech company.
Dense tables, charts and settings for people who live in the product. I design the empty, loading, error and stale states before the busy screen, because those are the states a real account sees first.
Campaign, creator and approval tools where many people touch one piece of work, often with AI suggesting the next step. My team designed Markly, an AI influencer marketing platform.
The site that has to explain the product in one line, show it working, and price it honestly. My team designed a product website for a fintech SaaS and FundFlo, a landing page for a finance SaaS.
These are the documents enterprise buyers and their security, privacy and accessibility teams check against. What follows is design guidance from the official texts, not legal advice: your lawyer and your auditor have the last word.
A SOC 2 report covers a company's controls over security, availability, processing integrity, confidentiality or privacy, measured against the AICPA's Trust Services Criteria. It audits your company, not your interface, but the product has to give those controls a place: roles an admin can read at a glance, a way to remove someone the same day, and an audit log that says who changed what, and when. I design those screens early.
Article 7 says withdrawing consent must be as easy as giving it. Article 20 gives people their data in a "structured, commonly used and machine-readable format". Article 25 asks for data protection by default, and Article 28 has a processor help its customers answer data requests. On screen that means a toggle that turns off where it turned on, a real export, private sharing defaults and admin tools to find a person's data. For Germany, see my notes on SaaS UX for the German market.
Three of the new level AA criteria hit B2B products hardest. Anything done by dragging, such as a board or a sortable list, needs a single-pointer way to do it too (2.5.7). Targets are at least 24 by 24 CSS pixels, or spaced as if they were (2.5.8), which catches the small icons in table rows. A focused element must not be entirely hidden behind a sticky header or footer (2.4.11). My WCAG 2.2 React checklist has the fixes.
The EAA applies to listed services provided to consumers after 28 June 2025, e-commerce among them, and a consumer is a person buying outside their trade or profession. A tool sold only to companies usually sits outside it. A self-serve plan that individuals can buy online may not, so I look at who can sign up and pay before we decide what the checkout must meet. My EAA notes for the Netherlands go further.
SCIM, published by the IETF as RFC 7644, is an HTTP protocol for managing identities between an enterprise and a cloud service, so a company's directory can create, update and remove your users. Sign-in itself usually runs on SAML or OpenID Connect. I design the settings an IT admin completes with their identity provider's values, a sign-in that sends work emails to the right provider, and a clear mark on each user who is managed by the directory rather than the app.
Larger buyers, and US federal agencies in particular, ask for an Accessibility Conformance Report, usually written on ITI's free VPAT template. ITI publishes four editions: Revised Section 508, EN 301 549 for the EU, WCAG 2.2, and an international one with all three. A report is only as good as the testing behind it, so my team keeps an accessibility record per component while we design and build, and your report can be written from that.
The same four steps as every project, with the checkpoints a SaaS product needs added to each.
We talk about who buys the product, who sets it up and who uses it every day, because in B2B those are often three different people. I ask what activation means for you and which enterprise requests have already arrived.
The scope names the activation event, the core flows, and which enterprise items are in or out: SSO, roles, audit log, export, accessibility report. You get one fixed quote for the whole project. No retainer, nothing billed by the hour.
A review call each week and a written update in Slack every 48 hours. Admin, permission and settings screens are designed alongside the core flows, and the WCAG 2.2 criteria are checked against the flows before handoff, not after launch.
My team builds the front end in TypeScript, React and Next.js, with tokens and components named the same in Figma and in code. We use AI coding tools where they save time, and a person who knows the design reviews every change.
Everything a SaaS team needs to ship the product and keep it consistent after we leave.
The one event that shows a new account got value, the path to it, and the sign-up, first-run and empty states that shorten that path.
Metrics chosen for the decision behind the screen, each with a comparison, plus the empty, loading, error and stale versions of every module.
The parts of a B2B product people use all day, designed once and reused: sorting, saved views, selection, bulk edit and CSV export.
Members and invitations, roles and permissions, SSO and directory-managed users, the audit log, and data export and deletion.
Tokens and components with the same names in both, in light and dark, documented so your developers can add features without asking us.
A record of how each component meets WCAG 2.2 AA, kept as we design and build, ready for whoever writes your VPAT.
A site that says what the product does in one line and shows it working. See website design.
React and Next.js connected to your APIs, by the same team that designed it. See development.
Most SaaS projects use two or three of these together.
Each figure is quoted as the publisher wrote it, with its year. I don't use market-size numbers from vendor reports.
An honest comparison, including the rows where another option is the better fit.
| What you get | My team | Large agency | Freelancer |
|---|---|---|---|
| Senior people doing the work every week | Yes | Varies by project | Yes |
| You talk directly to the people doing the work | Yes | Sometimes | Yes |
| Product design and front-end build in one team | Yes | Often | Rarely |
| Admin, roles and SSO screens designed with the core flows | Yes | Yes | Depends on the person |
| Cover when someone is ill or leaves | Yes | Yes | No |
| Several squads on a very large rollout at once | No | Yes | No |
| In-person workshops in your city | No | Often | Sometimes |
| One fixed quote for the whole scope | Yes | Sometimes | Sometimes |
Working with Jubayer and the team has been a blast. Their creativity has honestly taken our platform to new heights. Incredibly professional and so proud to work with, we’re over the moon with their results, and we can’t wait to team up with them again.

I highly recommend Jubayer for any design project. He quickly grasps complex concepts, excels in standard design practices, and responds promptly.

My longer notes on onboarding, dashboards, SaaS websites, pricing pages, the stack and design tokens.

SaaS dashboard design best practices for a product people open daily: start from the morning decision, then pick metrics, charts, states, alerts and colour.
Read post →
It depends on the number of core flows, the user roles, how much of the admin side you need (SSO, permissions, audit log), whether the website is included, and whether my team builds the front end. After a free 30 minute intro call I write a scope and give you one fixed quote for the whole project, with no retainer and no hourly billing. For market rates, see my guide to app design cost.
No. I'm a design engineer who leads a senior team of designers and developers, and you work with me directly. You get the range of a team and cover when someone is away, without an account layer between you and the people doing the work. We work remotely from Dhaka with founders in Europe, the US, the Gulf and Asia. You can read more about me.
Yes. I start with an audit of the current flows, your analytics and your support tickets, then fix the parts that cost you the most first. Changes ship in steps on a shared design system, so existing customers are never asked to relearn the whole product on one Monday morning.
Yes. Members and invitations, roles and permissions, SSO settings, users managed by a SCIM directory, the audit log, and data export and deletion are all product screens, and they decide whether an enterprise deal closes. I design them with the core flows so they share the same patterns, rather than as a rushed settings page before the first security review.
Both. My team builds web apps and front ends in TypeScript, React and Next.js, connected to your APIs and your auth provider, and mobile apps in React Native or Flutter. Tokens and components carry the same names in Figma and in code. If you have your own developers, we hand over the design system and stay available while they build.
I can make the product ready for one, but I don't audit or certify. SOC 2 reports come from an independent auditor, and there is no such thing as a certified VPAT. What my team does is design the screens reviewers ask to see, test components against WCAG 2.2 AA, and keep an accessibility record per component, so your security and accessibility answers rest on what the product really does.
It depends on the number of core flows, the roles involved and whether we also build. A focused first version is usually a matter of weeks, not months; a full redesign with an admin console and design system takes longer. The written scope after our intro call sets out the timeline flow by flow, so you can plan a launch or a sales conversation on real dates.
Yes. A B2B SaaS website has to say what the product does in one line, show the real product, and explain the pricing unit before anyone talks to sales. My team designed a product website for a fintech SaaS and Core.hr's website, and my notes on pricing page examples show what I check on a pricing page.