DEV Community: Vladyusha

The 2026 SaaS Stack: What You Actually Need to Launch a SaaS Today

Vladyusha — Fri, 28 Aug 2026 19:37:53 +0000

A new SaaS project rarely starts with the thing that makes it interesting.

You open your editor because you have a product idea. Maybe it's a workflow tool, a niche CRM, an AI product, a developer utility, or a small internal tool you're turning into a business.

Then the setup begins.

Create the Next.js app. Configure TypeScript. Add the database. Set up authentication. Build a login page. Add OAuth. Figure out sessions. Add email verification. Set up transactional email. Work out password resets.

Then payments.

Then webhooks.

Then file uploads.

Then analytics.

Then error monitoring.

Then deployment.

A week later, you have a well-structured application with a polished authentication flow, billing infrastructure, analytics events, and absolutely no interesting product.

The tools for doing all of this have never been better. Yet developers keep rebuilding roughly the same foundation for every SaaS they start.

That raises a more useful question than "What's the best SaaS stack?"

Which parts of a SaaS should you build yourself, and which parts should you reuse?

That is the question this stack is really about.

The short answer

There isn't one correct SaaS architecture. A company with millions of users, a bootstrapped B2B product, and a weekend MVP have very different constraints.

For a typical web SaaS in 2026, though, a sensible baseline looks something like this:

Layer	Practical default	Why
Framework	Next.js	Full-stack React application with routing, server rendering, server-side logic and a large ecosystem
Language	TypeScript	Better tooling and type safety across a growing codebase
UI	Tailwind CSS + shadcn/ui	Fast custom UI without locking the product into a traditional component library
Auth	Better Auth	Sessions, OAuth, verification and account flows without building the system from zero
Database	PostgreSQL	Mature relational database with a broad feature set
ORM	Drizzle or Prisma	Typed database access without giving up the underlying database
Billing	Stripe or Polar	Depends largely on whether you want to own more tax and billing complexity
Email	Resend	Developer-focused transactional email API
File storage	Cloudflare R2 or another S3-compatible store	Appropriate for user-uploaded files and other objects
Product analytics	PostHog	Events, funnels, retention and related product analysis
Monitoring	Sentry	Error tracking and application performance visibility
AI	Vercel AI SDK + provider of choice	Keeps model integration from becoming tightly coupled to one provider
i18n	next-intl or equivalent	Introduce localization structure before translation becomes painful
Deployment	Vercel or another managed platform	Minimal deployment infrastructure for a Next.js application

This is an opinionated baseline, not a prescription.

You can build an excellent SaaS without half of these products. You can also use completely different technologies and make better decisions for your particular constraints.

The point is to know why each piece exists.

Next.js's App Router is built around React Server Components, Suspense and Server Functions, which makes it a reasonable default for applications that combine a public website, authenticated application, server-side logic and dynamic data in one codebase. ([Next.js][1])

PostgreSQL remains a particularly strong general-purpose choice because it combines relational modeling with features such as JSON types, indexing and extensibility. The project continues to maintain multiple supported releases, with PostgreSQL 18.6 released in August 2026. ([PostgreSQL][2])

The more interesting part, however, is not the list.

It's the reasoning behind it.

1. Framework: Next.js is a strong default, not a requirement

For a modern SaaS, the framework has to do more than render a landing page.

You usually need a marketing site, authentication, dashboards, server-side data access, API endpoints, background operations, webhooks, metadata, forms, and sometimes a public API.

A full-stack framework can keep much of that in one project.

That's where Next.js makes sense.

The App Router provides file-system routing and is designed around React Server Components and other newer React primitives. ([Next.js][1])

For a small team, that matters less because Next.js is fashionable and more because reducing the number of architectural boundaries reduces the number of things you have to operate.

You can have:

app/
  (marketing)/
  (auth)/
  dashboard/
  api/

and keep the application, its UI, server-side logic and route structure close together.

That's useful.

It doesn't mean Next.js is automatically the best choice.

A highly interactive client-heavy application may be perfectly happy with React + Vite and a separate API. A team already standardized on another backend framework may not gain anything by moving to Next.js. A service with unusual runtime requirements might also fit better elsewhere.

The mistake is choosing a framework before deciding what architecture your product actually needs.

For many web SaaS products, though, Next.js is a reasonable starting point because it lets one small team operate a lot of functionality without splitting the application into multiple repositories and deployment systems.

For deployment, Vercel is the obvious path because Next.js is its native framework and deployment is essentially zero-configuration. But Next.js can also be self-hosted, so this is a convenience trade-off rather than a technical requirement. ([Vercel][3])

2. TypeScript: the default is boring for a reason

TypeScript isn't an exciting architectural decision.

That's probably why it works so well.

As a SaaS grows, data moves through a lot of boundaries:

Database
   ↓
Server logic
   ↓
API / Server Action
   ↓
Client
   ↓
Analytics
   ↓
External service

Type errors caught while you're writing code are generally cheaper than discovering the same mismatch through a production bug.

TypeScript adds a type system on top of JavaScript, allowing the compiler to identify classes of unexpected behavior before runtime. ([TypeScript][4])

The real value becomes more obvious when the codebase gets larger.

You change a database model.

The type system tells you which parts of the application are now inconsistent.

You rename a property.

Your editor tells you where the old contract is still being used.

You introduce a billing state.

You can make the valid states explicit instead of passing arbitrary strings around.

This isn't glamorous work. It compounds over time.

3. UI: Tailwind and shadcn/ui are less about components than ownership

Tailwind CSS is useful because it keeps styling close to the component and lets you define your own design tokens instead of accepting a fixed visual language. Its current system is built around theme variables that generate the utility classes available to the project. ([Tailwind CSS][5])

shadcn/ui takes a different approach from conventional component libraries.

Instead of installing an opaque package and importing components forever, its CLI adds component source code directly into your project. You own that code and can modify it. ([Shadcn UI][6])

That distinction matters more than the component catalog.

A SaaS product usually needs to look like its own product.

You don't want your UI architecture to prevent you from changing a button, form, modal or data table six months later because the library's abstractions don't quite fit.

The combination of Tailwind and shadcn/ui gives you a useful middle ground:

Don't design every primitive from scratch, but don't surrender ownership of the UI either.

There are alternatives. Radix-based systems, Material UI, Chakra, Base UI and custom design systems can all be sensible depending on the project.

The important decision is not "which component library is best?"

It's "how much of my UI am I prepared to own?"

4. Authentication is where "simple" products start getting complicated

Authentication looks like a screen.

It isn't.

A production authentication system quickly becomes a collection of edge cases:

sessions;
cookies;
password hashing;
OAuth callbacks;
email verification;
password reset;
account linking;
revoked sessions;
expired tokens;
suspicious login behavior;
authorization;
organization membership.

You can build all of this yourself.

You probably shouldn't.

The problem with custom authentication isn't that a competent developer can't write a login system. They can.

The problem is that authentication has a very poor risk-to-reward ratio for custom engineering.

The interesting software in your SaaS isn't the session cookie.

Mature auth libraries also tend to expose the less obvious parts of the system. Better Auth, for example, supports multiple authentication methods and account linking, and its documentation explicitly deals with the security implications of implicit OAuth linking and provider verification. ([Better Auth][7])

That's the sort of complexity you usually discover after launch rather than during the first afternoon of development.

Build your authorization model.

Build your permissions.

Build the user experience around identity.

Don't spend your product's early development cycles inventing authentication infrastructure.

5. PostgreSQL is still the sensible default

There is a recurring temptation in early SaaS development to pick a database because a particular feature sounds convenient.

That is usually backwards.

Start with the shape of your data.

A SaaS commonly has relationships like:

User
 ├── Projects
 ├── Subscriptions
 ├── Files
 ├── API keys
 └── Activity

Relational databases are very good at this.

PostgreSQL is mature, extensible and designed for complex data workloads. It also gives you the option to mix conventional relational data with more flexible structures such as jsonb when the domain actually calls for it. PostgreSQL's documentation specifically notes that jsonb supports indexing and is generally preferable to plain json for most applications. ([PostgreSQL][2])

That makes PostgreSQL a good default partly because it doesn't force you to predict everything about the product upfront.

You can start relational.

Add indexes when queries require them.

Use JSON where it makes sense.

Add extensions when the problem demands them.

And keep the option of running far beyond the scale of a typical early-stage SaaS.

6. Drizzle vs Prisma: this is mostly a question of preference

ORM arguments tend to become strangely religious.

They don't need to.

Both Drizzle and Prisma give TypeScript developers a way to work with relational databases without hand-writing every database interaction.

The meaningful distinction is how much abstraction you want.

Drizzle has a SQL-oriented style and keeps your schema and queries relatively close to the underlying database concepts. Its documentation also provides relational query APIs on top of that model. ([Drizzle ORM][8])

Prisma leans harder into a schema-driven developer experience with generated, typed access to your data and an increasingly opinionated tooling ecosystem. ([Prisma][9])

For a SaaS starter, I generally prefer the ORM that makes the database easier to inspect and reason about rather than the one that hides the most database details.

That preference can lead you to Drizzle.

It can also lead you to Prisma.

The important part is being able to answer these questions:

Where is the source of truth for the schema?
How are migrations generated?
Can I inspect the SQL?
Can I recover from a bad migration?
Can another developer understand the data model without learning a proprietary abstraction first?

The database will outlive several UI frameworks.

Choose an ORM that keeps you close enough to it that you can still make decisions confidently.

7. Payments: Stripe and Polar solve different problems

"Add Stripe" is not a billing strategy.

A real SaaS billing system has to answer more questions:

What happens when a subscription renews?
What happens when payment fails?
Who owns the customer record?
Where are invoices generated?
How are cancellations handled?
How are entitlements updated?
Who handles sales tax?
What does the customer portal look like?
What happens when your webhook arrives late or twice?

Stripe is extremely flexible here.

Its subscription system supports recurring payments, Checkout, customer portals, webhooks and Stripe Tax, among other pieces. ([Stripe Docs][10])

The flexibility is the advantage.

It's also the responsibility.

A Merchant of Record is a different model. The MoR is the entity legally responsible for a transaction, including responsibilities around the sale itself and, depending on the arrangement, taxes, refunds and disputes. ([Stripe Docs][11])

Polar positions itself as a Merchant of Record and states that it assumes liability for international sales tax compliance on sales through its platform. ([Polar][12])

That creates a real trade-off.

	Stripe	Polar
Billing flexibility	Very high	High
Ecosystem	Extremely broad	Smaller
Control	More	Less
Merchant of Record	Depends on setup	Yes
International tax burden	More on you	More handled for you
Best fit	Products needing billing depth and flexibility	SaaS products optimizing for simpler international selling

For an enterprise product with unusual billing requirements, Stripe's flexibility can be decisive.

For a small software company selling subscriptions globally, reducing tax and billing administration can be worth more than having every possible billing primitive.

Neither is universally better.

8. Email should almost always be somebody else's problem

Transactional email is one of those systems that seems trivial until production finds the edge cases.

You need:

domain authentication;
deliverability;
templates;
retry behavior;
bounce handling;
verification links;
password resets;
billing notifications;
email event tracking.

A service like Resend gives you an API specifically for sending email, plus domain and webhook functionality around it. ([Resend][13])

This is exactly the type of infrastructure I wouldn't build.

There is almost no strategic advantage in owning your own SMTP infrastructure for a small SaaS.

Your users don't care that you wrote the mail queue.

They care that the password-reset email arrives.

9. File storage belongs outside the database

Putting user-uploaded files directly into PostgreSQL is usually a sign that you're making the database responsible for something it wasn't chosen to do.

Store metadata in PostgreSQL.

Store the actual object somewhere designed for objects.

For example:

PostgreSQL
----------------
file_id
user_id
name
mime_type
size
storage_key

Object Storage
----------------
storage_key → actual bytes

Cloudflare R2 is one practical option. It exposes an S3-compatible API, so existing S3 tooling can be reused, and Cloudflare currently advertises no egress fees for R2 storage. ([Cloudflare Docs][14])

As of August 2026, standard R2 storage is listed at $0.015 per GB-month, with request charges for Class A and Class B operations and no egress bandwidth charges. ([Cloudflare Docs][15])

There are plenty of alternatives.

Amazon S3 is the obvious one.

Cloudinary makes more sense for image-heavy products.

Supabase Storage can be convenient when you're already deeply invested in Supabase.

The architectural principle stays the same:

The database stores the record about the file. Object storage stores the file.

10. Analytics and monitoring are not the same thing

This is one of the most common infrastructure mistakes in early SaaS applications.

A product can have excellent analytics and terrible monitoring.

It can also have excellent monitoring and no idea what users are doing.

They answer different questions.

Analytics asks:

What are users doing?

Examples:

signup_started
signup_completed
project_created
checkout_started
subscription_started
feature_used

You use this to understand funnels, retention and behavior.

PostHog's product analytics, for example, is built around events, funnels, retention, paths, lifecycle analysis and related product insights. ([PostHog][16])

Monitoring asks:

What is broken?

Examples:

TypeError
Database timeout
Webhook failure
500 response
Slow server action

That's where something like Sentry belongs.

The distinction sounds obvious, but architecture gets messy when teams treat analytics as a generic logging system.

I want both.

I also want the events to share a sensible vocabulary.

A messy analytics taxonomy becomes technical debt surprisingly quickly.

Define event names intentionally.

Track the events that correspond to actual product decisions, not every click on every div.

11. AI should be an integration layer, not your entire architecture

AI applications encourage a different kind of technical coupling.

A developer picks a model provider, calls its API directly from five places, stores provider-specific configuration in business logic, then discovers three months later that the model is too expensive or unavailable for a particular workload.

Now changing providers means rewriting the application.

That's avoidable.

An abstraction layer doesn't make models interchangeable in some magical sense. Models have different capabilities, quality, pricing, latency and tool-calling behavior.

The point is to isolate the provider-specific part.

The Vercel AI SDK is useful here because its core APIs sit above individual model integrations. It supports functions such as generateText and streamText, with provider and model selection occurring behind the SDK interface. ([AI SDK][17])

A simple architecture is:

Product feature
      ↓
AI service
      ↓
AI SDK
      ↓
Model provider

That also makes experimentation easier.

Use one model for classification.

Another for generation.

A cheaper one for background tasks.

A better one for high-value user requests.

The abstraction doesn't remove the trade-offs. It makes the trade-offs easier to change.

12. i18n is mostly about making a decision early

Not every SaaS needs ten languages.

Many only need one.

That doesn't mean internationalization should always be ignored.

Localization tends to become painful when text is scattered throughout the codebase:

<h1>Welcome back</h1>

becomes:

<h1>{t("welcomeBack")}</h1>

only after hundreds of screens have already been written.

Then formatting dates, pluralization, currency, URLs and metadata gets involved.

Libraries such as next-intl provide localization primitives designed specifically for Next.js, including message handling, formatting and locale-aware routing. ([Next Intl][18])

You don't need to localize the application on day one.

You do want to avoid making localization structurally impossible.

A good compromise is to decide early:

We support one language now, but the application architecture doesn't assume one language forever.

That's usually enough.

13. Deployment should be boring

A deployment system is successful when you stop thinking about it.

That's an underrated property.

For a Next.js SaaS, Vercel is an obvious default because the framework and platform are closely integrated. Vercel describes Next.js deployment there as zero-configuration while also noting that Next.js can be self-hosted. ([Vercel][3])

That doesn't mean Vercel is mandatory.

You may choose:

AWS;
Cloudflare;
Railway;
Fly.io;
a VPS;
Kubernetes;
Docker on your own infrastructure.

Those decisions become more justified when your requirements demand them.

The mistake is adopting operational complexity because it feels more "serious."

A startup with five hundred users doesn't need a distributed infrastructure architecture designed around the problems of a company with fifty million.

Use the simplest deployment system that satisfies your actual constraints.

You can always make the system more complicated.

You can't easily make an organization forget a process it has already built around.

14. What should you actually build yourself?

This is the part that matters more than the technology list.

A useful distinction is between product infrastructure and product differentiation.

Build these

Core product logic

The thing that solves the user's problem.

Domain-specific workflows

The steps, rules and interactions that make your product different from a generic CRUD application.

User experience

The places where customers feel the quality of your software.

Your internal business rules

Pricing logic, permissions, workflow states and whatever makes the product yours.

Reuse these

Authentication

Unless identity itself is your product.

Payment infrastructure

Unless you're building billing software.

Email delivery

Unless you're building email infrastructure.

Object storage

Unless you're building storage infrastructure.

Analytics

Unless analytics is the product.

Error monitoring

Unless observability is the product.

There's an obvious principle underneath this:

Infrastructure should support the product, not become the product.

Of course there are exceptions.

A security company may need custom authentication.

A developer platform may need to build its own storage layer.

A fintech may have reasons to control pieces of its payments architecture.

The decision isn't "never build infrastructure."

The decision is:

Are we building this because it's strategically important, or because nobody has connected it yet?

Those are very different reasons.

15. From scratch vs boilerplate vs SaaS starter

There are three common ways to approach a new SaaS foundation.

Build everything from scratch

You choose every dependency, every folder, every integration and every convention.

The upside is control.

The downside is that your first milestone often becomes "finish the foundation."

This approach is excellent when the architecture itself is part of the problem you're trying to solve.

It's less attractive when the product is already clear and infrastructure isn't your competitive advantage.

Best for

Teams with unusual requirements, strong architectural preferences, or products where infrastructure is itself strategically important.

Use generic boilerplate

A boilerplate gives you a head start.

You might get authentication, a dashboard, a database and some components.

The problem is that many boilerplates solve the first 20 percent and leave you with the hardest architectural decisions.

You still have to understand how everything is connected.

Sometimes the code is so generic that replacing one piece creates more work than starting clean would have.

Best for

Developers who want a head start but still expect to reshape the architecture significantly.

Use a production-oriented SaaS starter

A more opinionated starter tries to solve not just the first screen, but the boring infrastructure around the first real product.

That can include:

Auth
Database
Billing
Email
Storage
Analytics
Monitoring
AI
i18n
Deployment

The advantage is not simply that some files already exist.

It's that somebody has already made the decisions between them.

That's a different type of leverage.

You're inheriting architecture, which means you're also inheriting assumptions.

That is the price.

A starter that makes a decision you disagree with can be worse than a blank repository.

So the quality of a SaaS starter shouldn't be measured only by how much code it contains.

It should be measured by how easy it is to understand, replace and extend.

16. How much time does all this infrastructure actually take?

This is where SaaS starter discussions often become dishonest.

Claims like "this saves you 40 hours" sound impressive, but they're difficult to defend.

A competent developer can connect a database quickly.

They can add Google OAuth quickly.

They can integrate Stripe quickly.

They can send an email quickly.

The problem is that production work isn't the first successful API call.

The real work looks more like this:

Integration
  ↓
Configuration
  ↓
Environment variables
  ↓
Error handling
  ↓
Webhooks
  ↓
Retries
  ↓
Edge cases
  ↓
Testing
  ↓
Production deployment
  ↓
Documentation
  ↓
Maintenance

Authentication works until password reset doesn't.

Billing works until a webhook is delivered twice.

Email works until the sending domain isn't configured correctly.

Uploads work until someone sends a 2 GB file.

Analytics works until event names become inconsistent.

That is where the time goes.

And even that isn't the whole value of a starter.

There is also the cost of repeated decisions.

Every new project asks some version of:

Where should auth live?
How should sessions work?
Where do billing entitlements come from?
How should webhooks be structured?
Where do uploaded files go?
How are environment variables organized?
How does analytics get initialized?
What is the folder structure?
Which patterns do server and client code follow?

The value of a good foundation is partly that those decisions have already been made once.

You can still change them.

You just don't have to make them at 2 a.m. for the seventh time.

17. The stack behind Motoko Base

I kept running into this problem myself.

Every new SaaS project seemed to start with the same checklist.

I wasn't interested in making a giant template full of every possible feature. I wanted a foundation that handled the infrastructure I found myself rebuilding, while leaving the actual product architecture open.

That's what became Motoko Base.

The stack is intentionally opinionated:

Next.js
TypeScript
Tailwind CSS
shadcn/ui

Better Auth
PostgreSQL
Drizzle

Polar
Resend
Cloudflare R2

PostHog
Sentry

Vercel AI SDK
i18n

There is nothing uniquely magical about these choices.

That's the point.

They are ordinary technologies assembled into one coherent starting point.

The authentication layer should work with the database.

Billing should expose clear entitlements to the application.

Webhook handling should be treated as infrastructure, not scattered through product code.

Files should go to object storage.

Analytics and monitoring should be distinct.

AI integrations should be isolated from provider-specific code.

The goal is not to make every SaaS identical.

It is to remove the part where every developer spends the first few days rebuilding the same foundation.

Motoko Base is one implementation of that philosophy.

18. The bigger idea is composability

A fixed starter only solves part of the problem.

Because there isn't one universally correct stack.

You might want:

Stripe instead of Polar
Prisma instead of Drizzle
S3 instead of R2
Clerk instead of Better Auth
No AI at all
Two languages instead of one

That's perfectly reasonable.

The longer-term direction I'm interested in is therefore less about creating one "perfect" starter and more about making the foundation composable.

Instead of:

Download this stack and accept every decision.

The better model is closer to:

Choose the pieces you need, and generate a project around those choices.

That naturally leads toward a CLI-based workflow.

The important abstraction isn't the CLI itself.

It's the idea that infrastructure should be modular.

A developer should be able to say:

Next.js
PostgreSQL
Drizzle
Better Auth
Stripe
R2
PostHog

and get a coherent project rather than manually wiring eight unrelated integrations together.

That is where SaaS starters become more interesting.

Not as giant repositories full of code, but as a way to package proven architectural decisions.

19. The real 2026 SaaS stack is smaller than it looks

One useful side effect of thinking in layers is realizing how little of the stack is actually yours.

A typical SaaS might contain fifteen technologies, but only a handful of them are where the company's engineering advantage lives.

Something like:

Your code
├── Domain logic
├── Product workflows
├── UX
└── Business rules

Managed infrastructure
├── Auth
├── Database
├── Billing
├── Email
├── Storage
├── Analytics
├── Monitoring
└── AI providers

That isn't a weakness.

It's normal software engineering.

Modern SaaS development is mostly composition.

The skill is not knowing how to rebuild every layer.

The skill is knowing where composition ends and differentiation begins.

20. A practical SaaS launch checklist

Before spending serious time on product features, I want the foundation to answer these questions.

Application

[ ] Framework selected
[ ] TypeScript configured
[ ] Project structure agreed on
[ ] UI system established

Data

[ ] PostgreSQL configured
[ ] ORM selected
[ ] Migrations working
[ ] Backups understood

Authentication

[ ] Sessions working
[ ] OAuth configured if needed
[ ] Email verification decided
[ ] Password reset working
[ ] Authorization model defined
[ ] Account linking behavior understood

Billing

[ ] Billing provider selected
[ ] Plans defined
[ ] Entitlements defined
[ ] Checkout working
[ ] Customer portal available
[ ] Webhooks verified
[ ] Failed payments handled
[ ] Tax strategy understood

Email

[ ] Sending domain configured
[ ] Transactional email provider connected
[ ] Verification email working
[ ] Password reset email working

Storage

[ ] Object storage configured if needed
[ ] Upload limits defined
[ ] Access control defined
[ ] Database metadata separated from file contents

Product analytics

[ ] Analytics provider configured
[ ] Core events defined
[ ] Signup funnel tracked
[ ] Activation event tracked
[ ] Billing events tracked

Monitoring

[ ] Error monitoring configured
[ ] Production alerts configured
[ ] Server-side errors captured
[ ] Critical webhook failures visible

AI

[ ] Model providers selected
[ ] Provider integration isolated
[ ] Token/cost tracking considered
[ ] Failure behavior defined

Localization

[ ] Language strategy decided
[ ] User-facing strings structured for translation
[ ] Dates, numbers and currencies considered

Deployment

[ ] Production environment exists
[ ] Environment variables documented
[ ] Database migrations deploy safely
[ ] Domain configured
[ ] Logs available

None of this needs to be perfect.

It needs to be deliberate.

The stack is not the product

There is a certain irony to the modern SaaS ecosystem.

We have never had more tools for building software quickly.

And we have never had more ways to spend an entire week deciding which tools to use.

The answer isn't to stop caring about architecture.

It's to care about the right parts.

Use PostgreSQL because a relational database is a strong fit for the problem.

Use an authentication library because identity infrastructure is rarely your differentiator.

Use Stripe or Polar based on your billing and tax requirements, not because one is fashionable.

Use object storage for objects.

Use analytics to understand behavior and monitoring to understand failures.

Keep AI integrations replaceable.

Introduce localization structure before it becomes expensive to retrofit.

Deploy on the simplest platform that meets your requirements.

Then spend your engineering time on the thing somebody is actually paying you for.

That is what a modern SaaS stack should accomplish.

Not more infrastructure.

Less infrastructure standing between the idea and the product.

Motoko Base

I Built a SaaS Dashboard From Scratch — Here's What I Included

Vladyusha — Sun, 09 Aug 2026 09:27:13 +0000

I've built quite a few dashboards over the years.

And somehow, I keep rebuilding the same things.

Authentication.

Settings.

Tables.

Billing.

User management.

CRM screens.

Navigation.

The actual product is usually the interesting part. The dashboard infrastructure isn't.

So recently I decided to build a complete SaaS dashboard template that I could reuse for future projects.

What I wanted to build

I didn't want another template with a sidebar, three cards and a chart.

The goal was to have something that could actually be used as the starting point for a real SaaS application.

So I included the things I usually end up building anyway:

Authentication, dashboard pages, CRM modules, settings, billing and other common SaaS screens.

The idea is simple:

Start with the boring parts already done and spend your time building the actual product.

The stack

I wanted to keep the stack relatively simple.

The template is built with:

React 19
Vite
TypeScript
TanStack Router
TanStack Query
shadcn/ui
Tailwind CSS v4

I also wanted the codebase to stay easy to modify.

There is no complicated proprietary framework around it. It's a frontend codebase that you can take and adapt to your own application.

The Dashboard

The main dashboard contains the usual overview information, statistics, charts and recent activity.

But I tried to make it feel more like a real product than a demo.

The goal was to have enough structure that you could connect your own API and start replacing the mock data instead of rebuilding the whole interface.

CRM

I also added CRM-related screens.

Things like contacts, companies, activity and other views that are common in SaaS applications.

This was one of the parts that took more time than I expected because a CRM isn't really one component.

It's a collection of tables, filters, search, forms, details pages and different states.

Authentication

Authentication is another thing that almost every SaaS needs.

The template includes the basic authentication flow and corresponding screens.

Again, the point isn't to provide a complete backend authentication system.

It's to give you the UI and structure so you don't have to start from an empty project.

Settings

Settings pages are easy to underestimate.

There are usually a lot of small screens:

Profile.

Account.

Security.

Notifications.

Preferences.

I wanted these to already have a consistent visual system instead of creating each page from scratch.

Billing

Billing is another area where SaaS applications tend to look very similar.

The template includes billing-related UI and subscription management screens that can later be connected to whatever payment provider you use.

Why I built it

The main reason is actually pretty simple.

I was tired of starting every new SaaS project from zero.

Every time I would create the same sidebar.

The same authentication pages.

The same settings.

The same tables.

The same dashboard layout.

None of these things are particularly interesting to build for the tenth time.

So I decided to build them once and make the result reusable.

What I learned

The biggest thing I learned is that a dashboard template is much more than a collection of components.

The hard part isn't creating a beautiful button.

It's making dozens of screens feel like they belong to the same product.

Spacing has to be consistent.

Typography has to work everywhere.

Loading states need to make sense.

Empty states need to exist.

Tables need to work with different amounts of data.

And every page needs to feel like part of the same system.

That's where most of the work went.

What's next

I'm planning to keep improving the template based on feedback.

I'd also like to build more complete SaaS patterns rather than just individual components.

And I'm building Motoko UI alongside it, so some of the components and ideas will eventually become part of the open-source library as well.

For now, the Dashboard template is available for $49.

You can try the live demo here:

https://dash.motokoui.com/overview

I'd especially like to hear from other developers who build SaaS products.

What do you usually end up rebuilding every time you start a new project?

Why I Chose Copy-and-Paste Components Instead of an npm Package

Vladyusha — Wed, 29 Jul 2026 02:09:50 +0000

If you've used React for a while, you've probably installed dozens of UI libraries.

npm install some-ui-library

It feels like the obvious solution.

So when I started building Motoko UI, I asked myself:

Should this be another npm package?

The answer surprised me.

I decided not to build a traditional component library.

Instead, every component is copied directly into your project.

Here's why.

You Own the Code

One thing always bothered me about traditional UI libraries.

The moment you install them, part of your application lives inside node_modules.

If you need to tweak a component, you have three options:

Override styles
Wrap the component
Fork the library

None of them feels ideal.

With copy-and-paste components, the code becomes yours from day one.

Rename it.

Refactor it.

Delete half of it.

Change every animation.

No restrictions.

No Black Boxes

One of the best ways to learn React is by reading real components.

When the code is inside your project, everything is transparent.

You can immediately see:

how state is managed
how animations work
how accessibility is handled
how styles are structured

Nothing is hidden behind an API.

Easier to Customize

Every project has different requirements.

Different colors.

Different spacing.

Different animations.

Different coding styles.

Instead of designing hundreds of configuration options, I prefer something much simpler:

Just edit the component.

Better Long-Term Stability

Traditional packages evolve.

APIs change.

Breaking changes happen.

Version conflicts appear.

With copy-and-paste components, your project doesn't suddenly break because of a package update.

The component becomes part of your codebase.

You decide if—and when—to update it.

Less Dependency Weight

Every dependency introduces maintenance.

Even a small package has to be:

installed
versioned
updated
audited
kept compatible

Copy-and-paste components avoid adding another runtime dependency.

Once the component is in your project, it's simply your code.

Why the Registry Matters

Copying code manually doesn't scale very well.

That's why Motoko UI uses a registry compatible with the shadcn CLI.

Installing a component is as simple as:

npx shadcn@latest add @motokoui/theme-switcher

The CLI copies the files directly into your project.

No runtime package.

No hidden abstraction.

Just React components you own.

Are npm Packages Bad?

Not at all.

They're the right choice for many things:

state management
routing
data fetching
utilities

But UI components are different.

They almost always need customization.

For that reason, I think owning the source code is a better developer experience.

Final Thoughts

Building Motoko UI changed the way I think about component libraries.

Instead of creating another package that developers depend on, I wanted to create a collection of components they could truly own.

That philosophy influences every decision in the project—from the registry to the documentation to the component APIs.

I'm curious where the React ecosystem goes next, but for now, I believe copy-and-paste components offer one of the best experiences for building modern applications.

If you've built a component library yourself, I'd love to hear which approach you prefer: traditional npm packages or copy-and-paste components?

7 Lessons I Learned While Building an Open-Source React Component Library

Vladyusha — Wed, 29 Jul 2026 01:53:20 +0000

A few weeks ago, I started building Motoko UI, an open-source React component library.

The goal sounded simple: build beautiful, reusable components.

The reality was very different.

Here are seven lessons I've learned so far.

1. Building Components Is the Easy Part

The first few components took only a couple of days.

The documentation took longer.

The installation flow took longer.

The registry took longer.

It turns out that a component library is much more than a collection of components.

2. Developer Experience Matters More Than Fancy Animations

A beautiful component is useless if developers struggle to install it.

I quickly realized that reducing setup time was more valuable than adding another animation.

That's why I invested time in a registry and simple installation flow.

3. Documentation Is Part of the Product

I used to think documentation came after development.

Now I think documentation is development.

If users can't quickly understand how to use a component, the component effectively doesn't exist.

4. Small Releases Keep You Moving

Instead of waiting until everything was perfect, I started shipping small releases.

Every release adds a few components, fixes issues, and improves documentation.

That momentum makes the project feel alive.

5. Design Consistency Is Harder Than It Looks

Every new component introduces new decisions:

spacing
shadows
colors
border radius
animation timing

Without clear design principles, the library quickly becomes inconsistent.

6. Open Source Means Listening

Some of the best ideas didn't come from me.

They came from developers trying the project and asking:

"What if this component supported...?"

Those conversations improve the library more than coding alone.

7. The Project Is Never Finished

There's always another component.

Another improvement.

Another refactor.

I've stopped thinking about "finishing" the library.

Now the goal is simply to make it a little better with every release.

Final Thoughts

Building Motoko UI has already taught me far more than I expected.

Whether the project ends up with 100 stars or 10,000, the experience of designing, documenting, and maintaining an open-source library has been worth it.

If you're thinking about starting your own open-source project, my advice is simple:

Start before you think you're ready.

Website
Github

I Built Another React UI Library — Here's Why

Vladyusha — Wed, 29 Jul 2026 01:49:17 +0000

If you've been building React apps for a while, you've probably had the same thought:

"Not another React UI library..."

Honestly, I had it too.

The ecosystem already has amazing projects like shadcn/ui, Magic UI, Aceternity UI, Origin UI, and many others.

So why would anyone build another one?

It Started With Copying the Same Components

Every new project looked familiar.

I needed a modal.
Then tabs.
A tooltip.
A navigation menu.
A badge.
A hero section.

Sometimes I'd build them from scratch.
Sometimes I'd copy them from an old project.
Sometimes I'd spend an hour tweaking styles to match a new design.

Eventually I realized I wasn't building products—I was rebuilding the same UI over and over again.

I Wanted Components That Felt Production-Ready

Many libraries solve the problem of functionality.

I wanted to focus on something slightly different.

I wanted components that looked polished out of the box while still being easy to customize.

That meant:

Modern design
Smooth animations
Clean code
TypeScript-first
Tailwind CSS
Easy installation
No unnecessary abstractions

Why Not Just Use shadcn/ui?

I actually do.

Motoko UI isn't trying to replace shadcn/ui.

Instead, I see it as an extension of that ecosystem.

If shadcn/ui gives you the building blocks, Motoko UI focuses on higher-level components, interactive elements, and polished UI patterns that you can drop into real applications.

Building in Public

One decision I made early was to build everything in public.

Every component.
Every release.
Every improvement.

That keeps me accountable and gives other developers the opportunity to suggest ideas before they become part of the library.

The First Releases

So far I've added components like:

Accordion
Animated Tabs
Waves Shader
Theme Switcher
Badge
Modal
Tooltip

Along with:

Documentation
Registry support
Backgrounds & Shaders
Simple installation through the shadcn CLI

It's still a small project, but it's growing with every release.

What Comes Next

My goal isn't to create the biggest component library.

I want to create one that developers genuinely enjoy using.

Over the coming months, I'll be adding:

Dashboard components
Landing page sections
More shaders and animated backgrounds
Data visualization components
Better documentation
More polished developer experience

I'd Love Your Feedback

Open source gets better through feedback.

If you have ideas for components, improvements, or features you'd like to see, let me know.

And if you think Motoko UI is useful, I'd really appreciate a ⭐ on GitHub.

Thanks for reading.

Website
Github

Just Launched My Side Project — Would Love Your Feedback! 🚀

Vladyusha — Tue, 25 Feb 2025 08:57:13 +0000

Hey everyone! 👋

I’ve been working on a little side project called Rinkuit, and I’d love for you to check it out! It’s nothing too fancy, just something I built in my spare time, but I’m pretty excited about it. I’d really appreciate it if you could take a look, click around, and let me know what you think. Feedback is super welcome—good, bad, or ugly! 😄

👉 Visit Rinkuit

Thanks in advance, you’re awesome! 🙌

What’s New in React 19? A Quick Guide with Code Examples

Vladyusha — Mon, 02 Dec 2024 22:47:31 +0000

React 19 has arrived, bringing new features that make our apps faster and smarter while making development smoother. Here’s a quick look at the top highlights, complete with code snippets to get you started. 🚀

1. Enhanced Server Components

Server Components are now easier to use and more powerful. You can mix server-rendered and client-rendered components seamlessly.

Here’s a simple example:

// Server Component
export default function ServerComponent() {
  return <div>This is rendered on the server!</div>;
}

// Client Component
import ServerComponent from './ServerComponent';

export default function ClientComponent() {
  return (
    <div>
      <ServerComponent />
      <p>This part is interactive on the client.</p>
    </div>
  );
}

Result: Faster initial load times and better interactivity.

2. Smarter Concurrent Rendering

React 19 fine-tunes concurrent rendering. With useTransition, you can prioritize urgent updates while deferring others.

Example:

const [isPending, startTransition] = useTransition();

function handleClick() {
  startTransition(() => {
    setExpensiveState(someLargeData);
  });
}

Users won’t experience lag while React processes updates in the background.

3. Auto-Bundling for Lazy Components

Lazy-loading components is now simpler with auto-bundling, which ensures that only the required code is loaded.

Example:

const LazyComponent = React.lazy(() => import('./LazyComponent'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <LazyComponent />
    </Suspense>
  );
}

No extra configurations—React handles the bundling for you!

4. Faster Hydration

Hydration is now selective, meaning React hydrates only what’s visible first. No extra code is needed—it’s enabled out of the box.

// In React 19, hydration automatically prioritizes critical content:
ReactDOM.hydrateRoot(document.getElementById('root'), <App />);

This speeds up interactivity for users with large apps.

5. New Hooks: `useOptimistic` and `useEvent`

useOptimistic hook simplifies optimistic UI updates by managing temporary state.
Example:

const [optimisticLikes, setOptimisticLikes] = useOptimistic(0, (prev, newLike) => prev + newLike);

function handleLike() {
  setOptimisticLikes(1); // Update UI instantly
  postLikeToServer();    // Sync with server in the background
}

Instant feedback for users, even with slow network responses.

useEvent helps with stable event handlers, avoiding unnecessary re-renders.
Example:

const handleClick = useEvent(() => {
  console.log('Button clicked!');
});

<button onClick={handleClick}>Click me!</button>

Cleaner code and improved performance in scenarios with frequent event handling.

Conclusion

React 19 is all about speed, efficiency, and developer happiness. From smarter hydration to exciting new hooks.

What feature are you most excited about? Share your thoughts in the comments!

More features https://react.dev/blog/2024/04/25/react-19

The Operator Survival Guide for TypeScript Devs

Vladyusha — Tue, 26 Nov 2024 15:54:57 +0000

Picture this: You're debugging your TypeScript code at 2 a.m.
Sipping on your nth cup of coffee(I don't drink coffee), and staring at line like this:

if (a == b) { /* mysterious bug */ }

“What's the problem? They look equal enough!” you think. But then you remember your strict buddy ===, who clearly needs to step in here.

TypeScript, like any good mentor, loves precision and order. Operators are its way of making sure your code knows exactly what you want from it.

In this article, we'll dive into the world of TypeScript operators, discover who they are, how they differ, and when to befriend them (or avoid them entirely).

Content:

Logical operators
Relational operators
Bitwise operators
Ternary Operator
Type Operators

Logical operators

Logical AND (`&&`)

Explanation
The && operator checks if both conditions are true. If one fails, it's game over.

Example:
Imagine you're trying to buy snacks from vending machine. You need money and the machine needs to works.

const hasMoney = true
const machineWorks = false
if (hasMoney && machineWorks) {
  console.log("Yay! Got my snack!")
} else {
  console.log("No snack for you.")
}

“I had the money, but the machine didn't cooperate. Guess I'm snackless today.”

Logical OR (`||`)

Explanation:
The || operator checks if at least one condition is true. It's all about backup plans!

Example:
You're craving pizza, but the local pizza is closed. Luckily, you've got leftovers in the fridge.

const pizzaPlaceOpen = false
const haveLeftovers = true
if (pizzaPlaceOpen || haveLeftovers) {
  console.log("Dinner is saved!")
} else {
  console.log("Time to go hungry.")
}

“Pizza place closed? No problem. Cold pizza it is!”

Logical NOT (`!`)

Explanation:
The ! operator flips a condition. True becomes false, and false becomes true.

Example:
Your friends says they're not coming to the party. But you know them: if they says no, it usually means yes.

const friendSaidNo = true
if (!friendSaidNo) {
  console.log("Surprise! They’re at the party!")
} else {
  console.log("Guess they’re serious this time.")
}

“Told you, they always show up last minute!”

Relational Operators in Action (`==`, `===`, `!=`, `!==`)

Equality (`==`)

Explanation:
The == operator checks if two values are loosely equal. It doesn’t care about their type, as long as they look the same.

Example:
Imagine your friend asks for “5 apples,” but you only have “5” written on a sticky note. They shrug and say, “Close enough!”

const applesOnNote = "5"
const applesNeeded = 5
if (applesOnNote == applesNeeded) {
  console.log("Friend: Good enough, I’ll take it.")
} else {
  console.log("Friend: Nope, I need *real* apples.")
}

“Turns out, a number written on paper isn’t quite the same as an actual apple.”

Strict Equality (`===`)

Explanation:
The === operator is more picky. It checks both value and type. No shortcuts here!

Example:
This time, your friend insists: “I need 5 actual apples, not just a sticky note with the number!”

if (applesOnNote === applesNeeded) {
  console.log("Friend: Perfect, these are actual apples.")
} else {
  console.log("Friend: Hey, this is just a note! Not what I asked for!")
}

“Lesson learned: Strict friends need strict checks.”

Inequality (`!=`)

Explanation:
The != operator checks if two values are not loosely equal. It doesn’t mind small mismatches, like different types.

Example:
You promise your friend you’ll bring “not oranges.” You show up with a basket of bananas.

const fruitBrought = "bananas"
if (fruitBrought != "oranges") {
  console.log("Friend: Thanks! At least it’s not oranges.")
} else {
  console.log("Friend: Seriously? I said no oranges!")
}

“Bananas passed the test, but only because the bar was so low.”

Strict Inequality (`!==`)

Explanation:
The !== operator makes sure values are not equal in value or type. It’s the strict version of !=.

Example:
Your friend clarifies: “I don’t just want ‘not oranges,’ I want something completely different, like actual fruit!”

const gift = "orange"
if (gift !== "oranges") {
  console.log("Friend: Thanks, this is acceptable.")
} else {
  console.log("Friend: Come on, I said no oranges, and this is one.")
}

“When your friend’s picky, even being close isn’t good enough.”

Let's get some rest

Here you can go with a cup of tea or coffee

Bitwise Operators in Action

"When your computer starts playing with bits like building blocks."

Bitwise AND (`&`)

Explanation:
The & operator compares two numbers bit by bit and keeps a 1 only where both bits are 1.

Example:
Imagine two friends trying to agree on a movie night. They’ll only go if both want to see the same movie.

const myPreference = 0b1010 // Movies A and C
const friendPreference = 0b1100 // Movies B and C
const mutualChoice = myPreference & friendPreference // Only C (0b1000)

console.log(mutualChoice ? "Movie night is on!" : "No agreement, no movie.")

"Friendship survives, but only if we both agree!"

Bitwise OR (`|`)

Explanation:
The | operator compares two numbers bit by bit and keeps a 1 if either bit is 1.

Example:
This time, you and your friend decide to list all the movies you’d consider watching — even if only one of you likes them.

const combinedChoices = myPreference | friendPreference // A, B, C (0b1110)

console.log("Here’s our list of possible movies:", combinedChoices)

"Compromise: we’ll pick from everyone’s favorites!"

Bitwise XOR (`^`)

Explanation:
The ^ operator compares two numbers bit by bit and keeps a 1 only where the bits are different.

Example:
You and your friend each make a unique suggestion for dinner. XOR helps filter out any overlap.

const uniqueChoices = myPreference ^ friendPreference // A and B (0b0110)

console.log("These are unique picks:", uniqueChoices)

"Let’s focus on what makes us different — in a good way!"

Bitwise NOT (`~`)

Explanation:
The ~ operator flips all the bits of a number. A 1 becomes 0, and vice versa.

Example:
Your pessimistic friend looks at your list and says, “Here’s what’s NOT on the table.”

const allOptions = 0b1111 // All movies
const notMyPreference = ~myPreference & allOptions // Movies B and D

console.log("Movies I don’t want:", notMyPreference)

"Fine, let’s skip my least favorites..."

Left Shift (`<<`)

Explanation:
The << operator moves the bits of a number to the left, filling in with zeroes on the right. It’s like multiplying by 2 for every shift.

Example:
Imagine packing for a trip. Each bag can hold double the amount if you rent a bigger car.

const bags = 0b0010 // 2 bags
const biggerCar = bags << 2 // 8 bags

console.log("We can pack this many bags now:", biggerCar)

"Time to bring more snacks!"

Sign-propagating Right Shift (`>>`)

Explanation:
The >> operator shifts bits to the right, keeping the sign (positive or negative). It’s like dividing by 2 for every shift.

Example:
You’re splitting up leftovers. Start with a big portion and share until it’s all gone.

let leftovers = 0b1000 // 8 portions
const nextPortion = leftovers >> 1 // 4 portions

console.log("Leftovers after sharing:", nextPortion)

"Sharing is caring, but don’t leave me hungry!"

Zero-fill Right Shift (`>>>`)

Explanation:
The >>> operator shifts bits to the right, filling with zeroes. It works the same for positive numbers but ignores signs for negatives.

Example:
Imagine clearing out space in your garage by throwing out junk. New space is always clean (zeros).

const junk = -8 // Negative binary
const clearedSpace = junk >>> 1

console.log("Cleaned-up garage space:", clearedSpace)

"Who cares if it’s negative? Clean slate it is!"

Ternary Operator

Explanation:
The ternary operator (condition ? expressionIfTrue : expressionIfFalse) is a shorthand for making quick decisions. Think of it as flipping a coin when you need to make a choice, but smarter — it looks at the condition and picks the right answer for you.

Example:
Imagine you’re deciding whether to take an umbrella before heading out. If it’s raining, you take one; otherwise, you don’t bother.

const isRaining = true
const umbrella = isRaining ? "Take the umbrella!" : "No umbrella needed."

console.log(umbrella)

"The sky decides for me: rain or shine, I’m ready!"

When NOT to use it:
The ternary operator is great for short and simple choices, but if you’re stacking a dozen conditions, you’ll end up with something that looks like a spaghetti monster:

// Don’t do this!
const mood = isRaining ? "sad" : isSunny ? "happy" : isCloudy ? "meh" : "confused";

"Readable code is happy code. Don’t overdo it!"

Type Operators

`typeof`

Explanation:
The typeof operator is like a detective — it checks the type of a value at runtime or extracts the type of a variable for use in your TypeScript code.

Example:
Imagine someone hands you a mystery box. You use a label scanner (typeof) to figure out if it’s a fruit or a gadget.

const mysteryBox = "apple"
const boxType = typeof mysteryBox

console.log(boxType === "string" ? "It’s a fruit!" : "Unknown gadget.")

"When in doubt, always check the label."

`keyof`

Explanation:
The keyof operator creates a type that includes all the keys of an object. Think of it as flipping through a dictionary to see all the available words.

Example:
Your friend hands you a shopping list, and you check what categories (keys) they’ve written down:

type ShoppingList = {
  fruits: string[]
  veggies: string[]
  snacks: string[]
}

type ListCategories = keyof ShoppingList // 'fruits' | 'veggies' | 'snacks'
const chosenCategory: ListCategories = "fruits" // valid!

"When you know all the categories, choosing one is easy!"

`Mapped Types`

Explanation:
Mapped types let you apply the same transformation to all properties of a type. Think of it as photocopying a document but adding a filter to every page.

Example:
Suppose you have a task list, and you need to mark every task as optional.

type TaskList = {
  homework: string
  chores: string
  shopping: string
};

type OptionalTaskList = {
  [Key in keyof TaskList]?: TaskList[Key]
};

// Result: All tasks become optional
const myTasks: OptionalTaskList = { homework: "Math" } // Valid!

"It’s like giving yourself an excuse to skip a task — because now it’s optional!"

`Conditional Types`

Explanation:
Conditional types let you write logic to decide between types based on conditions. It’s like asking, “If this happens, what should I do?”

Example:
Imagine deciding the size of a meal based on hunger.

type MealSize<HungerLevel> = HungerLevel extends "starving"
  ? "large"
  : "small"

type MyMeal = MealSize<"starving"> // 'large'
type FriendMeal = MealSize<"full"> // 'small'

"If you’re starving, go big. If you’re full, maybe just dessert!"

Practical Use:
Conditional types are powerful for creating reusable, dynamic types in your code. For example:

type Response<T> = T extends "success" ? { data: string } : { error: string };

"Adapt your type to the situation!"

A Quick Note from Your Friendly Guide

Before we wrap up, I have to confess: I didn’t include every single operator here. Why? Well, some operators are so simple they don’t need much explaining (like the classic = — we’ve all seen that one in action). Others just didn’t make the cut because I wanted to keep things snappy and focus on the fun and fascinating ones.

But hey, don’t just take my word for it! TypeScript has a treasure trove of operators waiting for you to explore. Head over to the official TypeScript documentation and give them a look. Trust me, your future self (and your code) will thank you.

"Because even the small and simple operators deserve some love, right?"

End

Thx for reading)

Subscribe to my telegram