DEV Community: Mohamed Sadok

I Got Tired of Rebuilding the Same Support Portal. So I Built One I Could Reuse.

Mohamed Sadok — Fri, 16 Oct 2026 07:46:56 +0000

Every client wants a slightly different help desk. But underneath all those requests? The same familiar Laravel features, the same repetitive setup, and the same hours spent rebuilding things you’ve already built.

At some point, you have to ask yourself: Why am I building the same application for the fifth time?

If you work with Laravel, you probably know the situation.

A client needs a support portal. Nothing too complicated, they say.

Just authentication. Customer accounts. Support tickets. Priorities. Replies. File attachments. Email notifications. An admin dashboard. Agent permissions. Maybe internal notes so the support team can discuss a ticket without the customer seeing everything.

Oh, and could we have a dashboard with a few useful statistics?

Sure. No problem.

Then you open your editor, create the Laravel project, configure the database, set up authentication, build the ticket system, write the policies, create the dashboard, and start connecting everything together.

A few days later, you're looking at code you've written before. Not exactly the same code, of course. That would be too convenient. It's an older implementation from another project, with different assumptions, different dependencies, and just enough inconsistencies to make copying it more work than starting over.

I've been there.

So I decided to stop treating support portals as a new project every time and build a reusable foundation instead.

That's how NEXORA, my Laravel support portal starter kit, came together.

The goal wasn't to build another flashy SaaS dashboard with beautiful cards and meaningless charts. It was to package the repetitive, easy-to-overlook engineering work into something developers could actually use as a starting point.

And some of that work is more interesting than it sounds.

First, let's talk about the boring stuff

I like modern JavaScript frameworks as much as the next developer, but not every application needs a separate frontend, an API layer, and another build pipeline to maintain.

For this project, I kept things deliberately straightforward:

Laravel 13 and PHP 8.3 for the application.
MariaDB 10.11 for the database.
Blade, Tailwind CSS, Alpine.js, and Vite for the interface.
Laravel Breeze for authentication.
DDEV for a reproducible development environment.

No separate SPA. No unnecessary API layer. No complicated frontend architecture just to display a list of tickets.

The objective was simple: give developers a foundation they can understand, customize, and extend without spending their first afternoon figuring out how everything fits together.

The environment is containerized, dependencies are locked in composer.lock, and the setup process is designed to be straightforward.

Because the last thing you need when starting a new project is to spend two hours debugging your local environment before you can even see the login page.

Three roles. One rule: permissions must actually mean something.

NEXORA has three main roles:

Customer: Creates tickets, follows progress, and communicates with the support team.
Support Agent: Manages tickets, responds to customers, and adds internal notes.
Super Admin: Manages users, configuration, and the overall support operation.

That sounds pretty standard. The interesting part is how those permissions are enforced.

Hiding an admin button from a customer isn't security. Neither is hiding a URL in the navigation menu.

The application uses Laravel policies, middleware, and user-scoped queries to enforce access on the server.

For example:

public function view(User $user, Ticket $ticket): bool
{
    return $user->isStaff()
        || $ticket->user_id === $user->id;
}

The rule is simple: staff can access tickets according to their permissions, while customers can only access their own.

And that rule isn't just sitting in a PHP file looking impressive. It's backed by automated tests.

If Alice tries to access Bob's ticket by manually changing the URL, the application rejects the request.

The same principle applies to replies, attachments, and other customer-specific resources.

I also included safeguards against a surprisingly unpleasant administrative problem: accidentally locking yourself out of your own application.

The system prevents the final active Super Admin from being demoted or deactivated, and prevents an administrator from deactivating their own account.

These aren't the features that make a product look impressive in a screenshot. They're the features you appreciate when something goes wrong.

The tiny problem that becomes a big problem: ticket numbers

Imagine a customer submits a support request.

They receive a reference number:

SUP-2026-000123

Looks simple enough.

Now imagine two customers submit tickets at almost exactly the same time.

If your application generates numbers using a naive MAX(id) + 1 approach, concurrent requests can interfere with one another. You might end up with duplicate numbers or unexpected failures.

It's an easy detail to overlook when you're building a prototype. It's less amusing when a real customer contacts support about ticket number SUP-2026-000123 and another customer has the same reference.

NEXORA uses a per-year sequence table, database transactions, and pessimistic row locking to coordinate number generation.

The simplified idea looks like this:

$sequence = DB::table('ticket_sequences')
    ->where('year', $year)
    ->lockForUpdate()
    ->first();

$next = $sequence->last_number + 1;

DB::table('ticket_sequences')
    ->where('year', $year)
    ->update(['last_number' => $next]);

return sprintf('SUP-%d-%06d', $year, $next);

The sequence update happens within the ticket creation transaction, and a unique database constraint provides an additional safeguard.

The important detail isn't the formatting of the reference number. It's the fact that generating it is treated as a concurrency problem rather than a string-formatting problem.

That's the difference between code that works in a quick demo and code designed for real application behavior.

Internal notes: the feature that must stay internal

Here's a familiar customer request:

“Can our support agents leave private notes on a ticket without the customer seeing them?”

Of course.

But consider what happens after you implement it.

The note doesn't appear on the customer-facing ticket page. Great.

Then a search query returns it. Or an email notification includes it. Or an export accidentally exposes it.

Suddenly, a feature that seemed simple has become a privacy problem.

For NEXORA, internal notes are handled as a data-access rule, not a visual preference.

Customer-facing ticket queries explicitly exclude internal replies:

'ticket' => $ticket->load([
    'replies' => fn ($query) => $query
        ->where('is_internal', false)
        ->with(['user', 'attachments']),
]);

The same separation applies to search results, notifications, and activity timelines.

An internal note must not be sent to the customer through an email notification. Internal activity must not appear in the customer's timeline. Customer searches must not expose private note content.

I wrote tests specifically for these cases, including a test that uses a secret string in an internal note and checks that it doesn't leak through the customer-facing page, search, or email notifications.

This is the kind of feature where "it seems to work" isn't good enough.

The system needs to behave correctly even when someone accesses it in an unexpected way.

File uploads: because not every attachment should be public

Support tickets often contain screenshots, PDFs, documents, and other files.

Convenient, until you realize that a file uploaded by one customer shouldn't automatically become accessible to everyone with a URL.

NEXORA stores attachments on Laravel's private local disk, using UUID-based filenames. Original filenames are stored in the database rather than used directly as storage paths.

Downloads pass through a controller that:

Authenticates the requester.
Checks whether that user is authorized to access the attachment.
Restricts internal attachments to staff.
Streams the file as a download instead of rendering it inline in the browser.

Uploads are validated server-side against a configurable extension allowlist and file-size limit.

For example, PHP files are rejected by the upload validation rules, and unauthorized download attempts are covered by tests.

There's also an important limitation worth mentioning: the starter kit does not include malware scanning.

An extension allowlist is useful, but it isn't a replacement for antivirus scanning or a complete file-security strategy. Applications with stricter requirements should integrate an appropriate scanning service, such as ClamAV, and configure storage and access controls for their deployment environment.

I'd rather document that limitation clearly than pretend a validation rule solves every upload-security problem.

A Kanban board is easy. A correct workflow is harder.

The agent dashboard includes a Kanban-style board for moving tickets between statuses.

It's a familiar interaction: drag a card from Open to In Progress, and the board updates.

But the browser shouldn't be the authority on whether a transition is allowed.

A user can modify client-side code, send a direct HTTP request, or simply bypass the interface entirely.

That's why NEXORA validates ticket transitions on the server.

The lifecycle includes:

Open
In Progress
Waiting for Customer
Resolved
Closed

Not every transition is valid. Moving a resolved ticket directly back into progress, for example, shouldn't be allowed simply because someone managed to drag a card there.

A dedicated TicketService::changeStatus() method validates the transition, updates the relevant timestamps, records an activity entry, and performs the operation inside a database transaction.

The Kanban board uses that same service.

If a transition is invalid, the server rejects it, the interface displays feedback, and the card returns to its previous position.

The principle is straightforward: the interface can make an action convenient, but the backend must decide whether it's permitted.

That keeps the workflow consistent whether a status change comes from a drag-and-drop interaction or another request to the application.

Dashboard statistics shouldn't be works of fiction

We've all seen dashboards that look impressive until someone asks where the numbers came from.

NEXORA calculates first-response and resolution averages from actual timestamps.

When there isn't enough data, it displays a message explaining that rather than inventing a statistic to fill an empty card.

It sounds obvious, but there's a meaningful difference between a dashboard that looks complete and one that tells the truth.

Seed data is useful for exploring the interface locally. It shouldn't become a substitute for real application metrics.

For a support team, these numbers can eventually influence staffing, workload planning, and service improvements. Their definitions should be clear, and their calculations should be grounded in actual events.

The test suite is part of the product

I didn't want NEXORA to be just a collection of controllers, models, and attractive dashboard screens.

The starter kit includes 78 automated tests covering 177 assertions.

The suite covers scenarios such as:

Guests being blocked from protected areas.
Disabled accounts losing access.
Customers being prevented from viewing or modifying another customer's tickets.
Unauthorized attachment downloads being rejected.
Internal notes being excluded from customer-facing pages, search, and notifications.
Role-escalation attempts being rejected.
Invalid ticket transitions being blocked.
Oversized or disallowed uploads being rejected.
Administrative safeguards preventing the last active Super Admin from being removed.

The tests run against an in-memory SQLite database, keeping the test environment isolated from the application's normal data.

Before releasing a version, I run the suite with:

ddev exec php artisan test

Of course, a passing test suite doesn't prove that an application is free of vulnerabilities. It does provide something valuable: repeatable evidence that important behaviors work as intended.

It also makes the code easier to understand.

Want to know what happens when a customer tries to reopen a closed ticket? There's a test. Wondering whether internal notes trigger customer emails? There's a test for that, too.

Documentation explains how a system is supposed to work. Tests help demonstrate how it actually behaves.

What NEXORA doesn't include

I could describe this as a complete, production-ready support platform and fill the product page with ambitious promises.

That wouldn't be particularly useful.

NEXORA is a starter kit, not a finished enterprise help desk. It provides a foundation you can adapt to your own requirements.

It deliberately leaves some things outside its current scope:

No built-in malware scanning for uploaded attachments.
No rich-text message rendering; messages use escaped plain text.
No two-factor authentication.
No multilingual help-desk interface.
No dedicated SLA-management or advanced reporting module.

You'll also need to handle the usual deployment responsibilities: HTTPS, backups, secret management, server patching, and environment-specific security configuration.

The idea isn't to solve every possible support workflow. It's to avoid making you rebuild the same core functionality before you can start solving the problems that make your project different.

Who is this for?

I built NEXORA with a few types of developers in mind.

Freelancers and agencies who repeatedly build customer portals for different clients and want a reusable foundation instead of another from-scratch implementation.

SaaS founders who need a support workflow without spending their first development sprint rebuilding authentication, ticket management, and role-based access.

Small teams that need an internal help desk for tracking requests, assigning responsibility, and managing conversations.

Laravel developers who prefer starting with a structured codebase and adapting it rather than assembling every familiar feature again.

There's also a static HTML/CSS/JavaScript demo included in the bundle, so you can explore the interface and present the visual direction to a client before setting up the Laravel application.

Getting started

The development workflow uses DDEV, so you don't need to install the application's PHP and database dependencies directly on your host machine.

The basic setup looks like this:

ddev start
ddev composer install
ddev exec php artisan key:generate
ddev exec php artisan migrate --seed
ddev npm install
ddev npm run build

Once the environment is running and the setup is complete, you can explore the portal, review the code, and start adapting it to your project.

For local development, the seeded demo accounts are:

Admin: admin@nexora.test
Support agent: agent1@nexora.test
Customer: alice@nexora.test

The demo password is password. These credentials are intended for local testing only and must never be used for a production deployment.

So, why did I package it?

Because I'd rather spend my time solving new problems than repeatedly rebuilding the same foundation.

Every support portal will eventually develop its own requirements. One client will need a different workflow. Another will need custom fields. Someone else will want integrations, SLA rules, or a completely different dashboard.

That's normal.

But authentication, ticket ownership, private notes, attachment permissions, status transitions, and basic administration shouldn't have to start from zero every time.

NEXORA is my attempt to turn that repetitive groundwork into something reusable, understandable, and easier to extend.

If you're building a support portal, an internal help desk, or a SaaS application with customer support, you can explore the demo and decide whether it's a useful starting point for your next project.

Explore the live demo: https://supportticketdemo.vercel.app/

Get NEXORA on Gumroad: [Insert your Gumroad product URL]

And if you do build something with it, I'd be interested to see what you create.

Tags: Laravel, PHP, Web Development, SaaS, Software Engineering

I Built a Laravel RBAC Starter So I Could Stop Rebuilding Admin Panels

Mohamed Sadok — Thu, 15 Oct 2026 09:08:41 +0000

Every new Laravel project starts with a simple idea.

Build a SaaS app. Create a CRM. Launch a client portal.

Then the requirements arrive:

Admins can manage everything.
Managers can manage some things.
Editors can edit content but cannot delete users.
Regular users should only access their own features.

Suddenly, your weekend project needs a role management system, a permissions catalog, protected routes, user administration, and authorization tests.

Congratulations. You are building an administration framework before building your actual product.

I've been there. So I built something to make that setup less repetitive.

The problem isn't authentication. It's everything around it.

Laravel provides excellent authentication and authorization tools. Spatie Laravel Permission makes managing roles and permissions much easier.

But integrating the pieces into a usable application still takes work.

You need to connect permissions to roles, build an interface to manage them, protect sensitive actions, and verify that unauthorized users cannot bypass the UI by calling an endpoint directly.

That last part is important.

Hiding a button is not access control.

If a user cannot see the Delete button but can still submit a request to the deletion endpoint, your authorization implementation has a problem.

The server must enforce the rules.

What I built

I created Laravel Roles & Permissions Starter, a reusable foundation for Laravel applications that need role-based access control and an admin panel.

The stack includes:

Laravel 12 and PHP 8.2+
Spatie Laravel Permission 8
Laravel Breeze
Blade, Tailwind CSS, and Alpine.js
Vite and PHPUnit
DDEV configuration for local development

Here's what is included.

1. Five predefined roles

The starter includes:

Super Admin
Admin
Manager
Editor
User

It uses permission keys such as users.view, roles.delete, and permissions.manage.

You can create, edit, and duplicate roles, assign permissions, and manage users with multiple roles. Protected-role safeguards help prevent accidental deletion of important roles.

2. Server-side authorization

The application uses Laravel Gates and Policies to protect administrative functionality.

Super Admin bypass logic is centralized, and protected roles and accounts have additional safeguards.

The sidebar also adapts to the current user's permissions, but the backend remains responsible for enforcing access.

3. User administration

Manage registered users, assign roles, change account status, and delete users with confirmation.

These are useful building blocks for SaaS applications, internal tools, CRMs, and business dashboards.

4. Audit logging

Role, user, and permission changes are recorded with details such as the actor, action, subject, metadata, IP address, and user agent.

Recent activity appears on the dashboard, and the underlying records can be queried from the database.

A dedicated audit-log browsing interface is not included in this release.

5. A dashboard with real database data

The dashboard displays counts for users, roles, permissions, and audit events, alongside an access overview and recent activity.

No hardcoded dashboard numbers pretending to be production analytics.

6. Thirty-three automated tests

The starter includes 33 tests covering authentication, profile management, and role-based access control.

Examples include guest restrictions, authorization failures, role assignments, permission persistence, and default-role assignment during registration.

Run them with:

composer test

Tests are not a guarantee that every future customization will be secure, but they give you a useful baseline for ongoing development.

Try the demo before looking at the code

I prefer showing developers what they're getting rather than asking them to trust a sales page.

Live demo: https://laravelrolesstarter.vercel.app/

Explore the interface and see whether it fits your next project.

Get the source code: https://boukataya.gumroad.com/l/xqmkag

The package includes the application source code, migrations, seeders, factories, tests, setup instructions, and DDEV configuration.

What it doesn't include

To keep expectations clear, this release does not include REST API endpoints, a dedicated audit-log browser, an administration settings screen, or Docker Compose configuration.

It focuses on the existing Laravel web application and its authentication, RBAC, user management, dashboard, and audit-logging functionality.

You can extend it to fit your own architecture and requirements.

When is this useful?

Consider it if you're building a SaaS application, CRM, client portal, e-commerce back office, or internal business tool and don't want to assemble the same administration foundation from scratch.

The goal isn't to eliminate development. It's to reduce repetitive setup so you can focus on the features that make your application different.

Demo: https://laravelrolesstarter.vercel.app/

Product: https://boukataya.gumroad.com/l/xqmkag

What part of a new Laravel project do you find yourself rebuilding most often: authentication, authorization, user management, or something else?

I Built 8 SaaS Landing Pages. Here Are the 11 Sections That Make Them Work.

Mohamed Sadok — Wed, 14 Oct 2026 14:24:08 +0000

What I learned from building eight different landing page templates about structure, trust, product demos, pricing, and turning visitors into potential customers.

Most SaaS landing pages don’t have a design problem.

They have a clarity problem.

The headline sounds impressive but says very little. The features section lists everything the product can do. The pricing page hides behind a “Contact us” button. And somewhere between the hero section and the footer, visitors lose interest.

I’ve seen this pattern often enough that I wanted to approach it differently.

Instead of building another landing page and tweaking it endlessly, I built eight complete SaaS landing page templates for different types of products: AI tools, B2B platforms, developer tools, analytics software, billing systems, automation products, startups, and pre-launch waitlists.

The goal was simple: understand what makes each page useful, what changes depending on the product, and what stays the same.

One thing became clear.

Good SaaS landing pages don’t need to look alike. But they do need to answer the right questions in the right order.

Here are the 11 sections I focused on.

Navigation: Make the next step obvious Your navigation should help visitors understand where they are and where they can go next.

It doesn’t need nine links, three dropdowns, and a button competing for attention.

Start with the essentials:

Your product name or logo
A few useful links
Pricing or documentation, where relevant
One clear call to action
Also, don’t forget mobile users. The menu should open, close properly, and support keyboard interaction.

Small details matter because they reveal whether the website was built carefully or merely made to look good in a screenshot.

Hero section: Explain your product without making people think The hero section is your first opportunity to answer three questions:

What is this? Who is it for? Why should I care?

Compare these two headlines:

“An AI-powered platform for the modern enterprise.”

“Automate repetitive support tasks without building workflows from scratch.”

The first sounds like marketing. The second tells me what the product does and why I might need it.

A practical hero section includes:

A specific headline
A short supporting sentence
One primary call to action
A secondary action if necessary
A reassurance line when relevant
Don’t try to explain your entire business in the headline. Give visitors a reason to keep reading.

Product preview: Show what you’re actually selling A landing page can make almost any product sound impressive.

A real product interface makes the promise easier to understand.

Depending on what you’re building, show a dashboard, terminal, workflow editor, analytics chart, or chat interface.

This gives visitors something concrete to evaluate before they sign up.

When building landing pages, I prefer interface mockups made with editable code when practical. They can adapt to different screen sizes, and the sample content can be changed without redesigning an image.

One important distinction: demonstration data should be clearly labelled. A convincing mockup is useful; pretending it represents real customers or actual performance is not.

Trust section: Don’t manufacture credibility Social proof can be powerful when it’s genuine.

Real customer logos, verified testimonials, relevant certifications, and credible case studies can help people feel more comfortable choosing your product.

But what if you’re launching your first SaaS?

Don’t invent customers. Don’t create fictional testimonials and present them as real. Don’t display compliance badges you haven’t earned.

Instead, communicate things you can actually substantiate.

Explain your pricing clearly. Show the product. Link to documentation. Describe your cancellation policy. Make it easy to understand how the service works.

Trust isn’t something you can manufacture with a row of logos.

It’s the result of giving visitors good reasons to believe you.

Features: Focus on what deserves attention Your product might have dozens of features.

Your landing page doesn’t need to explain all of them.

Start with the capabilities most relevant to your ideal customer. For each feature, explain what it does and why the visitor should care.

For example:

Feature: Automated payment retries.

Why it matters: Help recover failed payments without manually chasing every transaction.

The second sentence connects the functionality to a practical outcome.

If a feature doesn’t support the main reason someone would buy your product, consider moving it to the documentation.

Benefits: Translate functionality into outcomes Features describe capabilities. Benefits describe what those capabilities make possible.

Consider a project management tool.

“Real-time task synchronization” describes functionality.

“Keep everyone working from the same up-to-date task list” explains the benefit.

Neither statement is inherently wrong. They simply serve different purposes.

A good landing page connects the two so visitors can understand both what the product does and how it fits into their work.

One simple editing technique is to ask “So what?” after every feature statement.

If the answer isn’t obvious, rewrite it.

How it works: Reduce uncertainty about getting started Visitors don’t just evaluate whether your product is useful.

They also consider how much effort it will take to get value from it.

Become a Medium member
If your product is easy to set up, explain the process in three or four steps.

For example:

Connect your existing tools.
Configure your workflow.
Review the results.
Adjust the setup to fit your needs.
Use steps that reflect the actual product. If implementation takes a day, don’t promise that it takes five minutes.

The purpose of this section is to make the onboarding process understandable, not to make it sound magically effortless.

Pricing: Answer the question visitors are already asking People want to understand what a product costs before investing time in it.

If your business model supports transparent self-service pricing, put the information on the page.

Explain what each plan includes, who it suits, and which limitations apply.

A monthly/annual toggle can help visitors compare billing options, but it should actually update the displayed prices. Decorative interactions create confusion rather than confidence.

If you’re still validating your business model, label example prices clearly.

And if your product requires custom enterprise pricing, explain why and make the next step straightforward.

The goal isn’t to force every business into the same pricing layout. It’s to remove unnecessary uncertainty.

Testimonials: Use real experiences or leave them out A testimonial should represent an actual person’s experience with your product.

When you have permission to publish genuine customer feedback, include relevant context such as the person’s name, role, or organization where appropriate.

When you don’t have testimonials yet, focus on demonstrating the product and explaining its value.

You don’t need to fill every section just because another SaaS website has it.

A landing page is not a checklist of fashionable components. Every section should earn its place.

FAQ: Address the objections that prevent a decision The FAQ section is an opportunity to answer questions that might otherwise stop someone from moving forward.

Depending on your product, visitors might want to know:

Does this work with my existing tools?
Can I cancel whenever I want?
What happens to my data if I leave?
Is there a free trial?
What is included in each plan?
Do I need technical knowledge to use it?
Answer these questions directly.

If a feature isn’t available yet, say so. If a particular integration isn’t supported, don’t imply otherwise.

Clear limitations help the right customers make informed decisions and reduce misunderstandings after purchase.

Final call to action: Make the next step clear After visitors have explored your product, features, pricing, and FAQs, give them a clear next step.

It could be starting a trial, creating an account, booking a demo, joining a waitlist, or purchasing a product.

Keep the message consistent with the rest of the page.

Don’t introduce a completely new promise in the final section. Reinforce the value you’ve already explained and make the action easy to find.

A visitor who has read the entire page shouldn’t have to search for what to do next.

What building eight landing pages taught me
The biggest lesson wasn’t about gradients, typography, animations, or which button color looks best.

It was about structure.

Different SaaS products need different visual identities. An AI assistant shouldn’t necessarily look like a billing dashboard, and a developer tool doesn’t need to imitate a productivity platform.

But each page still needs to explain the product, demonstrate its value, establish credibility, answer questions, and help visitors decide what to do next.

That common structure makes the design process easier to reason about.

It also gives you a useful starting point when you’re building a new product and don’t want to spend days deciding what sections to add.

The visual design still matters. Accessibility matters. Performance matters. And none of these sections guarantees a particular conversion rate.

But a clear page gives visitors a better opportunity to understand your offer.

That’s a worthwhile place to start.

I turned that approach into NEXORA
While working on these eight designs, I wanted more than a folder of screenshots or a collection of empty starter components.

I wanted a kit that I could explore, preview, and customize.

That’s why I built NEXORA — a SaaS Landing Page Kit featuring eight complete landing page templates for different product categories.

The kit includes:

Eight distinct SaaS landing page designs
A built-in gallery with live template previews
Desktop, laptop, tablet, and mobile-width testing
Editable product interface mockups
Interactive pricing toggles and FAQ accordions
Search and category filtering
Documentation covering installation, customization, and deployment
The technology stack is React 19, Vite 7, Tailwind CSS v4, and TypeScript. This is a React-based project, not a plain HTML/CSS template pack, so you’ll need Node.js 20+ to run and build it.

Sample content is identified as demonstration content, and the waitlist form requires a provider or backend integration before it can collect submissions.

If you’re building a SaaS product and want a starting point you can adapt rather than designing every section from scratch, you can explore the kit here:

Get NEXORA on Gumroad https://boukataya.gumroad.com/l/hrpgjy

You can also explore the project before purchasing:

https://nexora-saas-landing-page-kit.vercel.app/

And if you’d rather build everything yourself, start with the eleven sections in this article. You don’t need to buy a template to put the principles into practice.

One question for other builders
When you’re creating a landing page for a new SaaS product, which section takes you the longest to get right: the headline, the product preview, the features, or the pricing?

I’d be interested to hear what other founders and developers struggle with most.

I Was Tired of Rebuilding SaaS Dashboards. So I Built NEXORA.

Mohamed Sadok — Wed, 14 Oct 2026 10:40:26 +0000

Every new project seemed to start the same way: an empty dashboard, hours of repetitive CSS, and the same components I had already built dozens of times. I decided to turn that repetition into something reusable.

The Problem With Starting Every SaaS Project From Scratch

If you've ever built a SaaS application, you probably know the routine.

You start with a promising idea. You set up the project, plan the architecture, and get ready to build the features that make your product unique.

Then comes the dashboard.

You need a sidebar, navigation, statistics cards, charts, tables, filters, settings pages, and a consistent design system. Before you know it, you've spent days building an interface that looks remarkably similar to the one you built for your last project.

And the frustrating part? Most of that work doesn't make your product more valuable. It simply gets you to the starting line.

The usual alternatives aren't always ideal:

Complex starter kits: Powerful, but they can introduce frameworks, dependencies, and setup requirements you don't actually need.
Free admin templates: Useful for getting started, but customization, responsiveness, and consistent styling can become a project of their own.
Design mockups: Great for planning, but someone still needs to turn those designs into working code.

I wanted something different: a professional dashboard that was ready to customize, easy to understand, and simple to integrate into different projects.

That's why I built NEXORA.

Introducing NEXORA — A SaaS Dashboard UI Kit

NEXORA is a reusable SaaS admin dashboard built with HTML, CSS, vanilla JavaScript, Tailwind CSS, Chart.js, and Lucide icons.

It includes 12 complete pages, 20+ reusable components, interactive charts, data tables, and light and dark themes in one organized package.

No React setup. No npm installation. No build pipeline.

Open index.html and explore the interface.

Try the live demo: https://nexora-saas-dashboard-template.vercel.app/

Get the complete UI kit: https://boukataya.gumroad.com/l/qydmik

What's Included?

NEXORA isn't just a dashboard homepage. It's a collection of coordinated pages designed to cover common SaaS administration needs.

1. Overview Dashboard

Start with a complete overview featuring KPI cards, revenue charts, traffic breakdowns, recent transactions, and activity feeds.

2. Analytics

Explore acquisition metrics, conversion funnels, growth charts, date-range controls, and period comparisons.

3. Customer Management

Work with searchable, sortable, and filterable customer tables, pagination, and add/edit modals.

4. Transactions

Display payment histories, filter transactions by status, and export data to CSV.

5. Plans and Billing

Build subscription management interfaces with pricing cards, monthly and annual billing options, feature comparisons, and usage indicators.

6. Team Management

Organize team members, display roles, and manage pending invitations through a consistent interface.

7. Notifications

Handle notification lists, read and unread states, filters, and bulk actions.

8. Profile and Settings

Provide personal profile information and five organized settings panels covering general preferences, profiles, notifications, security, and appearance.

9. Help and Support

Include an FAQ accordion and a contact form for common support workflows.

10. Components Library

Explore reusable buttons, badges, inputs, switches, modals, dropdowns, toasts, tooltips, tabs, alerts, avatars, progress bars, and more.

11. Documentation

Keep integration guidance close to the code, making customization easier to follow.

All of this is designed to work together as one consistent dashboard experience.

The Real Advantage: A Customizable Design System

A dashboard can have dozens of components, but changing its visual identity shouldn't mean editing every component individually.

NEXORA centralizes its design tokens in CSS variables.

For example:

:root {
  --accent: #6366f1;
  --radius-lg: 16px;
  --bg: #f6f7f9;
}

Want a different accent color? Change the variable.

Prefer sharper corners? Adjust the radius.

Need to adapt the interface to your client's branding? Customize the design tokens instead of hunting through the entire stylesheet.

The same design system supports both light and dark themes, helping maintain visual consistency across the dashboard.

This makes NEXORA useful as more than a ready-made interface. It becomes a starting point you can adapt to your own product.

Interactive Components, Not Just Pretty Screens

A good dashboard template should provide more than static cards and placeholder layouts.

NEXORA includes interactive frontend functionality such as:

Search, sorting, filtering, and pagination for data tables.
CSV export for transaction data.
Interactive charts powered by Chart.js.
Modals, dropdowns, tabs, and toast notifications.
Light and dark theme switching.
Responsive sidebar and mobile navigation.
Keyboard-accessible interactions and visible focus states.

The goal is to reduce the repetitive frontend work that usually comes before connecting a dashboard to real application data.

One Central Place for Sample Data

The dashboard's sample data is organized centrally, making it easier to understand where the displayed information comes from.

Instead of searching through multiple page components to locate customer records or transactions, you can start with the existing data structure and replace it with your own API responses.

For example, the integration workflow could look like this:

Identify the sample data used by a page.
Replace the mock data with data from your backend.
Connect the appropriate actions to your API.
Adapt the fields and validation rules to your application.

The template provides the frontend foundation. Your backend, authentication, database, and business logic remain yours to implement.

Why Vanilla JavaScript?

Modern frontend frameworks are excellent tools. But not every dashboard needs another framework or a complex build process.

I chose vanilla JavaScript for three practical reasons.

Simplicity: You can explore the code without first learning a framework-specific architecture.

Portability: The HTML, CSS, and JavaScript can serve as a starting point for projects built with Laravel, PHP, Django, Rails, or other backend technologies that render HTML.

Control: You can customize the interface without depending on a particular frontend framework or component library.

NEXORA also uses Tailwind CSS through a CDN, along with Chart.js and Lucide icons. Those external libraries require an internet connection in the default configuration.

The objective isn't to replace every frontend stack. It's to provide a straightforward option when you want a reusable dashboard without a full frontend build setup.

Small Details Make a Difference

The difference between a basic template and a useful development starting point often comes down to the details.

NEXORA includes features such as:

Skeleton loading states for dashboard metrics.
Global search with a Ctrl+K keyboard shortcut.
Visible keyboard focus indicators.
Empty states with useful actions.
Toast notifications that stack and dismiss automatically.
Comfortable and compact density options.
Semantic HTML and ARIA labels for interactive elements.
Reduced-motion considerations.

These details are easy to overlook when building a dashboard from scratch, yet they contribute to a more complete interface.

Who Is NEXORA For?

NEXORA can be a useful starting point for:

Developers building a SaaS MVP.
Freelancers creating client dashboards.
Indie hackers validating a new product.
Developers building internal business tools.
Teams that need a reusable admin interface.
Designers and developers who want to customize an existing UI.

You can adapt the interface to your own branding, connect your data sources, and build the application-specific functionality around it.

Get NEXORA

If you're tired of rebuilding the same dashboard components for every project, NEXORA gives you a reusable foundation to start from.

Explore the live demo first:

https://nexora-saas-dashboard-template.vercel.app/

Get NEXORA on Gumroad:

https://boukataya.gumroad.com/l/qydmik

Your purchase includes the dashboard source files, centralized styling, JavaScript application logic, and documentation.

NEXORA comes with a single-seat commercial license for personal and client projects. You can customize it and integrate it into your applications, but you cannot redistribute or resell the original template as a standalone product.

Please note: NEXORA is a frontend UI kit, not a complete SaaS application. Backend integration, authentication, database connectivity, and payment processing must be implemented separately.

Final Thoughts

I built NEXORA to solve a repetitive problem: spending valuable development time recreating dashboard interfaces instead of building the features that make an application different.

A reusable UI kit won't eliminate every development task, but it can give you a more structured place to begin.

If you're working on your next SaaS project, take a look at the demo and see whether NEXORA fits your workflow.

Live demo: https://nexora-saas-dashboard-template.vercel.app/

Get the UI kit: https://boukataya.gumroad.com/l/qydmik

Build faster. Customize freely. Spend more time on what makes your product unique.

Tags: Web Development · SaaS · HTML · Tailwind CSS · JavaScript · Dashboard UI · Developer Tools

I Built AssetOps Images: A Full Laravel + React App That Optimizes 2,000 Images in Batches

Mohamed Sadok — Mon, 12 Oct 2026 08:49:58 +0000

WebP and AVIF conversion, image resizing, metadata removal, SEO-friendly filenames, background jobs, usage tracking, and an admin dashboard. Here’s how I put the pieces together.

Imagine receiving a folder containing 1,500 product images.

They need different dimensions, smaller file sizes, SEO-friendly filenames, and no sensitive GPS metadata. Once everything is processed, the files need to be organized, packaged, and delivered to the client.

You could handle everything manually. You could write a collection of scripts. Or you could build a proper application that handles the entire workflow.

I chose the third option.

Meet AssetOps Images — a complete, self-hosted image optimization web application built with Laravel 13, React 18, and TypeScript.

It started with a straightforward problem: image processing is easy until you need to do it consistently, at scale, and without losing track of what happened to every file.

The interesting part wasn’t converting JPEGs to WebP. It was building everything around that process.

Want to explore the finished product?

Get AssetOps Images on Gumroad

The real problem isn’t resizing images
Resizing an image takes a few lines of code. Building a reliable batch-processing workflow is a different challenge.

A useful image optimization platform needs to:

Accept large batches of images in different formats.
Analyze dimensions, orientation, EXIF data, GPS information, and color profiles.
Apply reusable processing configurations.
Resize images without unnecessarily upscaling them.
Convert images to WebP, AVIF, JPG, or PNG.
Remove sensitive metadata.
Generate consistent, SEO-friendly filenames.
Package the results into downloadable ZIP archives.
Track usage and enforce configurable quotas.
Handle failures without forcing users to restart an entire batch.
And there’s one more requirement: the application must remain responsive while all this work happens.

That last point influenced almost every architectural decision.

The stack behind AssetOps Images
I wanted a clear separation between the frontend, backend, and image-processing infrastructure.

LayerTechnologyBackendLaravel 13, PHP 8.3+FrontendReact 18, TypeScriptStylingTailwind CSSRouting and stateReact Router, ZustandDatabasePostgreSQL 16Background jobsRedis and Laravel queuesAuthenticationLaravel SanctumImage processingIntervention ImageDevelopment environmentDocker / DDEVBuild toolingVite

The frontend is a single-page application, while Laravel handles the API, authentication, business logic, and static frontend delivery.

The API exposes more than 60 documented endpoints, with API Resources providing consistent response structures.

The result is a straightforward deployment model: one application, clearly separated responsibilities, and infrastructure that can be configured without rewriting the core logic.

Background jobs: the foundation of the entire workflow This was one of the most important decisions.

Imagine processing 2,000 images inside a single HTTP request. Even if it works locally, you’re creating an unnecessary risk of timeouts, memory pressure, and failed operations.

Instead, AssetOps splits the workflow into three stages.

Stage 1 — Analyze the files

The AnalyzeBatchFiles job inspects the uploaded images, extracts relevant metadata, detects GPS information, and generates thumbnails for the interface.

Stage 2 — Transform the images

The TransformBatchFiles job applies the selected settings: resizing, format conversion, quality adjustments, and metadata removal.

Stage 3 — Package the results

The PackageBatch job creates a ZIP archive containing the processed images, a metadata.csv manifest, and a processing-report.json file.

Processing is divided into chunks of 25 files per job. A batch of 2,000 images can therefore be distributed across approximately 80 manageable chunks rather than handled by one oversized job.

That provides a more practical foundation for retries, error isolation, and per-file failure reporting.

Users can retry individual files instead of starting the entire process again.

The takeaway: queues aren’t just a performance optimization. For workloads like this, they’re part of the product design.

Upload validation: never trust the browser A file extension doesn’t prove what a file actually contains.

A file named product.jpg isn't necessarily a JPEG. Likewise, a client-supplied MIME type isn't a security guarantee.

AssetOps validates uploaded files using content inspection with PHP’s finfo, rather than relying solely on information supplied by the browser.

The application supports JPG, PNG, WebP, GIF, AVIF, HEIC, and TIFF inputs, subject to the capabilities of the configured processing environment.

This is a small implementation detail, but small details like this matter when you’re accepting files from users.

Make infrastructure configurable, not hard-coded A self-hosted application should be usable in different environments without requiring developers to modify application code for every deployment.

AssetOps uses configurable image-processing and storage options.

For image processing, Intervention Image provides a common interface for supported drivers such as GD and libvips.

For storage, the application can use local storage or an S3-compatible configuration.

The principle is simple: deployment-specific decisions belong in configuration wherever practical.

A small deployment shouldn’t need the same infrastructure as a high-volume production environment. Keeping these concerns configurable makes the application easier to adapt.

Of course, actual performance depends on the server, image sizes, available memory, and selected processing driver.

SEO-friendly filenames without the manual cleanup Image optimization isn’t only about file size.

For e-commerce stores, descriptive filenames also help keep product assets organized and provide useful context for search engines.

AssetOps supports customizable filename templates, for example:

{brand}-{product}-{color}-{index}

A filename might become:

acme-running-shoes-black-001.webp

A dedicated filename-planning service handles slug generation and collision-safe indexing to avoid duplicate names within the generated output.

Users can also rename individual files or make bulk changes through the interface.

Become a Medium member
It’s a relatively small feature, but it eliminates a tedious part of preparing large product catalogs.

Privacy, secure downloads, and usage tracking There are three additional concerns that are easy to overlook when building image-processing software.

Metadata privacy

Images can contain more information than their visible pixels. GPS coordinates and other EXIF, IPTC, or XMP metadata may reveal details users don’t intend to publish.

AssetOps provides metadata-removal options to help reduce that risk. The resulting files should still be verified against the application’s configured stripping behavior and the desired privacy requirements.

Secure downloads

Processed files are delivered through signed, expiring download URLs rather than relying on permanently public file links.

The configured expiration limits how long a generated download link remains valid.

Usage tracking

The application records processing activity and tracks usage against configurable limits.

Users can review usage statistics and savings, while administrators can manage quotas and monitor platform activity.

Together, these features help turn an image-processing utility into a more complete application.

The admin dashboard: the difference between a script and a product A working processing pipeline is only part of the job.

AssetOps also includes:

User registration, authentication, and password recovery.
Projects for organizing processing work.
Reusable presets for common optimization settings.
Batch and per-file management.
Usage statistics and configurable quotas.
Account settings and account deletion.
Administrative user management and quota overrides.
Failed-job monitoring.
Gumroad license activation.
Optional AI-generated ALT-text suggestions through an OpenAI integration.
None of these features is particularly exciting in isolation. But without them, users are left with a processing engine instead of a usable application.

The dashboard, error states, download workflow, and administration tools are what connect the underlying services into a complete user experience.

Thirty-two automated tests — and why they matter The backend includes 32 automated tests covering important application workflows, including:

Authentication.
Batch upload, processing, and download.
File-content validation.
Quota enforcement.
Projects and presets.
License activation and deactivation.
Download-token expiration.
SEO filename generation.
The frontend is built using strict TypeScript settings, with type checking included in the build process.

Tests don’t prove that every deployment scenario is flawless. They do provide a repeatable way to verify key behaviors and reduce the risk of breaking existing functionality during future development.

When evaluating a codebase, I’d rather see meaningful tests around the core workflows than a long feature list with no verification behind it.

What I learned building AssetOps Images
A few principles stood out during development.

Design for failure, not just the happy path.

Large batches will encounter invalid files, processing errors, and interrupted jobs. Independent jobs and retryable operations make those failures easier to manage.

Keep deployment choices configurable.

Storage drivers, processing engines, and other infrastructure settings shouldn’t require unnecessary code changes.

Treat security as part of the workflow.

Upload validation, authorization, quotas, and expiring downloads aren’t optional extras when users are uploading and processing files.

Don’t stop when the core feature works.

Authentication, projects, presets, administration, usage reporting, and useful error messages are what make the application practical to use.

Build the entire workflow, not just the impressive part.

Converting an image is easy. Getting thousands of images from upload to a reliable, organized download is the actual engineering challenge.

Want the complete source code?
AssetOps Images is available as a complete source-code product.

The package includes the Laravel backend, React and TypeScript frontend, database migrations, seeders, demo data, development setup instructions, API documentation, and a launch-and-test guide.

It’s intended for developers, agencies, e-commerce teams, and builders who want to explore, customize, or deploy a self-hosted image optimization application instead of starting from an empty repository.

Get AssetOps Images here:

→ View AssetOps Images on Gumroad
If you’re building a Laravel application that handles uploads, background processing, or large batches of files, I’d also be interested to hear how you’re approaching job retries, storage, and processing limits.

Tags: Laravel, PHP, React, TypeScript, Image Optimization, WebP, AVIF, Software Architecture, Side Projects, SaaS Development

Animations Play. Interactions Respond.

Mohamed Sadok — Mon, 05 Oct 2026 15:25:03 +0000

I kept rebuilding the same web effects for different projects. Eventually, I stopped rebuilding them and started building a library.

There is a folder on my machine where most of my motion experiments go to die.

Magnetic buttons.
Distorted images.
Liquid text.
Particle fields.
Scroll effects.
Shader experiments.

Some were useful. Some were terrible. Some looked impressive for about five minutes.

And some made me realize something:

Animations play. Interactions respond.

That distinction became the foundation for LIQUID REALITY.

Instead of building another collection of fade-ins, slide-ups and hover animations, I wanted to explore interactions that actually react to the person using the website.

Move the cursor and something changes.

Scroll faster and the interface responds differently.

Touch an image and it distorts.

Move toward a button and it pulls back.

Drag an object and it behaves like something with weight.

The interface isn't simply performing an animation.

It is reacting to you.

The problem with most "premium" animation

Modern websites have become very good at motion.

Almost too good.

You can add a scroll library, write a few GSAP timelines and suddenly everything moves.

Elements fade in.

Headlines slide upward.

Cards scale slightly.

Images reveal themselves.

The problem isn't that these techniques are bad.

They're useful.

They're just predictable.

After seeing hundreds of websites using the same patterns, users stop consciously noticing them.

I wanted to build interactions that were harder to ignore.

Not because they were louder.

Because they were responsive.

1. Input is easy. Making it perceptible is the hard part.

A pointer position is easy to capture.

const x = event.clientX;
const y = event.clientY;

That's not interesting.

What happens with that information is where the interaction begins.

For example, pointer velocity can control multiple properties simultaneously.

A fast movement can increase distortion while also increasing the intensity of a visual effect.

A slow movement can make the same interface settle back into a calmer state.

The code isn't necessarily complicated.

The important part is the relationship between the input and the visual response.

That relationship is what makes an interface feel intelligent.

2. Magnetic buttons need more than `translate()`

Magnetic buttons are everywhere.

Most implementations are essentially:

transform: translate(pointerX * 0.3, pointerY * 0.3);

It works.

But it doesn't necessarily feel good.

The difference comes from introducing different physical behaviours.

The button shell can respond quickly.

The label can follow more slowly.

The two can settle at different speeds.

Now the button doesn't just move.

It has weight.

const shell = new Spring2(210, 17);
const text = new Spring2(90, 12);

shell.to(x * strength, y * strength);
text.to(x * strength * 0.55, y * strength * 0.55);

Add a little skew based on movement and the interaction starts feeling less like CSS and more like a physical object.

That's the type of detail I wanted throughout the library.

3. The cursor should be an input system, not an animation trigger

Once you start building interactive effects, you quickly run into a problem.

Every component wants to listen to the cursor.

The hero wants it.

The button wants it.

The image wants it.

The particle field wants it.

The shader wants it.

You can easily end up with dozens of listeners and animation loops doing almost the same work.

So I started treating pointer data as a shared input system.

One pointer listener.

One animation loop.

Shared mutable values.

Effects consume the data they need.

That means the interaction architecture can stay simple even when the page becomes visually complex.

The same pointer can drive:

Position
Velocity
Distance
Direction
Distortion
Magnetic force
Particle movement
Shader uniforms

One input.

Multiple responses.

4. One shader can become many experiences

One of my favourite parts of building LIQUID REALITY was experimenting with shaders.

A basic image distortion effect doesn't need an enormous rendering system.

You can start with a texture, a plane and a fragment shader.

Then expose a few useful parameters:

uTexture
uPointer
uVelocity
uProgress
uIntensity
uRadius
uDetail
uChroma

From there, completely different experiences can emerge.

Liquid distortion.

Ripple.

Melt.

Chromatic displacement.

Refraction.

Fragmentation.

Glass-like distortion.

The interesting part isn't using GLSL because GLSL sounds impressive.

The interesting part is using the GPU to create behaviour that would be difficult or expensive to reproduce with ordinary DOM animation.

That's the rule I kept coming back to:

If the shader can only be described by the technique used to build it, it probably isn't interesting enough.

"Voronoi experiment" isn't a product feature.

"Image fragmentation" is.

The technology is underneath.

The interaction is what the user experiences.

5. Motion should never become a usability requirement

There is a trap with interactive websites.

You can become so focused on the visual experience that you forget the website still has to work.

That's why reduced motion became part of the design process rather than something added at the end.

If a user prefers reduced motion, the page should not simply stop halfway through an animation.

The interface should resolve into its usable state.

Motion can disappear.

Content shouldn't.

For example:

const intensity = reducedMotion ? 0 : config.intensity;

And instead of leaving an element hidden because its reveal animation never happened, its final state should be applied directly.

The principle is simple:

Motion enhances the interface. Motion should never be the interface.

6. Mobile isn't desktop with less space

Interactive effects become particularly interesting on mobile.

A cursor doesn't exist.

Hover doesn't work in the same way.

Performance constraints are different.

So instead of treating mobile as a smaller desktop, I started thinking about different inputs.

Touch can replace pointer interaction.

Device orientation can become an input.

An effect can automatically drift when the user isn't interacting.

For example, a background can react to device movement instead of cursor movement.

The goal isn't to perfectly reproduce desktop.

The goal is to preserve the feeling of interaction.

7. Performance is part of the interaction

A beautiful effect that destroys the user's laptop isn't a premium interaction.

It's a benchmark.

That meant being deliberate about how the effects run.

Avoid unnecessary layout reads inside animation loops.

Measure elements when their dimensions change rather than repeatedly calling:

getBoundingClientRect();

during every frame.

Cache what can be cached.

Use transforms where possible.

Pause expensive work when the effect isn't visible.

Use IntersectionObserver.

Limit pixel density when necessary.

Clean up animation loops, listeners, textures and WebGL resources.

And most importantly:

Don't animate something just because you can.

Performance is part of the design.

What I actually wanted to build

After enough experiments, I realized I didn't want to make a giant animation framework.

I wanted something closer to a box of interaction ideas.

Something a frontend developer could open when a normal implementation felt too ordinary.

Need an image that reacts to the cursor?

There's an interaction for that.

Need a magnetic CTA?

There's an interaction for that.

Want a liquid visual?

There's an interaction for that.

Want a shader-based distortion?

There's an interaction for that.

Want to experiment with particles, scroll velocity, typography or WebGL?

Same idea.

Pick the interaction.

Open the source.

Understand it.

Change it.

Use it.

Why I called it LIQUID REALITY

The name came from the feeling I was trying to create.

Interfaces are normally rigid.

Boxes.

Cards.

Buttons.

Images.

Text.

Grids.

LIQUID REALITY asks:

What if these things behaved less like pixels on a screen and more like physical materials?

What if an image could ripple?

What if typography could bend?

What if a button could feel magnetic?

What if a cursor could affect an entire visual field?

What if scrolling changed the physical behaviour of the page?

The goal isn't to make websites complicated.

It's to make them responsive in unexpected ways.

The result

I packaged the experiments into a downloadable source product for developers.

The focus is not on giving you another dependency-heavy animation package.

It's on giving you reusable interaction implementations that you can inspect, modify and integrate into real projects.

React. TypeScript. GSAP. WebGL. GLSL. Canvas.

Use one effect.

Combine several.

Change the parameters.

Replace the assets.

Rewrite the shader.

Take the idea somewhere completely different.

That's the whole point.

If I were building a website today

I wouldn't start by asking:

"What animation should this section have?"

I'd ask:

"What should this section respond to?"

Cursor?

Scroll?

Velocity?

Touch?

Proximity?

Drag?

Time?

Once you define the input, the animation becomes much more interesting.

That's the shift I'm interested in.

From:

Animation → Interaction

From:

Timeline → Response

From:

Element moves → Element reacts

And ultimately:

A website shouldn't just show motion. It should feel like it is listening.

LIQUID REALITY

I built LIQUID REALITY as a collection of these experiments — interactive effects designed for developers who want their websites to feel less static and more alive.

You can explore the live demo here:

https://liquid-reality.vercel.app/

And if you want the source and want to experiment with the interactions yourself:

LIQUID REALITY is available on Gumroad.

https://boukataya.gumroad.com/l/ygshkz

Build something interesting with it.

Then break it and make it better.

How I Built 50 Web Interactions Without Turning My React App Into a Performance Nightmare

Mohamed Sadok — Fri, 02 Oct 2026 13:51:48 +0000

How I Built 50 Web Interactions Without Turning My React App Into a Performance Nightmare

I kept rebuilding the same small interaction ideas for different projects.

A magnetic button.

An image that reacts to the cursor.

A menu transition.

A scroll-controlled composition.

A little physics experiment for typography.

The individual effects were fun. The problem was that each project ended up with its own component, its own assumptions, and its own implementation details.

Eventually I realized I wasn't building new interactions.

I was rebuilding the same ones.

So I decided to build a proper system for them.

That became MOTIONFORGE: 50 interaction experiments built with React + TypeScript, organized across ten categories.

You can play with the live collection here:

MOTIONFORGE — Live Demo

The interesting part wasn't creating 50 animations.

It was figuring out how to make them reusable without making them feel identical.

The Goal

I started with a simple rule:

Every interaction should have a reason to exist.

I didn't want a collection of random "cool effects."

Each experiment needed to answer:

What is the user doing?
How does the interface respond?
What makes the response feel intentional?
Which parameters actually matter?
What happens on touch?
What happens with reduced motion?
Can this realistically be integrated into another project?

The final collection contains:

Hero effects
Text reveals
Magnetic buttons
Cursor effects
Image distortions
Scroll animations
Page transitions
3D interactions
Liquid effects
Navigation effects

Five experiments per category.

50 total.

The Architecture

The main abstraction is an InteractionStage.

Its job is to handle the things that shouldn't have to be implemented 50 times:

Configuration
Pointer state
Pointer interpolation
Reduced-motion detection
CSS variable updates
Animation lifecycle
Cleanup

A simplified usage looks like this:

<InteractionStage
  interaction={getInteraction("liquid-image")!}
  config={{
    ...defaultConfig,
    distortion: 68,
  }}
/>

The important part is the separation.

The stage handles shared infrastructure.

The interaction handles the actual visual behavior.

That means a new experiment doesn't need to reinvent pointer handling, lifecycle management, or accessibility detection.

Why I Didn't Store Pointer Position in React State

One thing I wanted to avoid was turning every pointermove event into a React render.

For high-frequency interactions, that gets expensive quickly.

Instead, pointer input updates an internal target position.

A requestAnimationFrame loop interpolates toward that target and exposes the result through CSS variables.

Conceptually:

pointer event
     ↓
target position
     ↓
requestAnimationFrame
     ↓
interpolated position
     ↓
CSS variables
     ↓
visual interaction

React handles the component structure.

The browser handles the high-frequency visual updates.

That separation made the interactions much easier to reason about.

The Explorer Doesn't Run 50 Animations

This was another important decision.

Imagine opening a page containing 50 interactive demos and actually mounting all 50 animation systems.

It would work.

It would also be a terrible idea.

Instead, the explorer initially renders lightweight previews.

The real interaction is mounted only when the card becomes relevant:

Hover
Focus
Tap

So the index page can display a large collection without running 50 independent animation systems in the background.

The same principle applies to Canvas-based interactions.

If there is nothing left to animate, the loop stops.

When the component unmounts:

Animation frames are cancelled
Event listeners are removed
Observers are disconnected
Canvas resources are cleaned up

The browser shouldn't keep working on an interaction nobody is looking at.

Choosing the Technology After the Interaction

I also wanted to avoid the classic creative-coding trap:

"I need an animation, therefore I need a big animation library."

Not necessarily.

Most interactions use browser primitives:

CSS

Transforms, transitions, perspective, clipping and compositing.

SVG

Useful for certain displacement and distortion effects.

Canvas

Used when the interaction actually needs individual particles, trails or ripple simulations.

GSAP

Used where a controlled timeline or complex choreography genuinely makes the implementation easier.

CSS 3D

Several interactions create a convincing sense of depth without requiring WebGL or Three.js.

That last one was intentional.

If CSS perspective communicates the idea, introducing a WebGL runtime is unnecessary complexity.

Reduced Motion Wasn't an Afterthought

This turned out to be one of the more interesting design constraints.

An interaction shouldn't depend on its animation to communicate the content.

If the movement disappears, the interface still needs to work.

So reduced motion isn't simply:

animation: none;

The component needs a meaningful static state.

For example:

Animated:

WORD → letters separate → letters rearrange → WORD

Reduced motion:

WORD

The information survives.

Only the unnecessary movement disappears.

That approach also made the components easier to integrate into real products.

Hover Isn't a Mobile Interaction

Cursor experiments created another problem.

Desktop gives us a pointer.

Touch doesn't.

A hover interaction therefore can't simply be copied to mobile and called responsive.

Depending on the interaction, I used:

Tap states
Press states
Static compositions
Simplified transitions
Reduced interaction intensity

Sometimes the correct mobile implementation is not a smaller version of the desktop effect.

It's a different interaction.

The Difficult Part Was Timing

Making something move is easy.

Making it feel like it has weight is harder.

This became especially obvious with magnetic interactions.

Move an element toward the cursor.

Easy.

Make it return naturally.

Much harder.

Return too quickly:

It feels mechanical.

Return too slowly:

It feels broken.

Add too much interpolation:

It feels disconnected from the user's input.

Remove the interpolation:

It feels like a DOM element being dragged around.

The interesting part of these interactions often lives in the return phase.

The user doesn't consciously think about the easing curve.

But they definitely notice when something feels wrong.

Reusable Doesn't Mean 20 Configuration Options

Another problem I ran into was configuration.

It's tempting to make everything configurable.

Strength.

Speed.

Radius.

Delay.

Easing.

Scale.

Resistance.

Decay.

Noise.

Randomness.

Before long, you have 20 sliders and no idea what half of them actually do.

I tried to expose parameters that map directly to the behavior.

For example:

strength → how strongly the element reacts

radius → how far the interaction reaches

distortion → how much the surface changes

return → how quickly it settles

A configuration option should answer a question.

If I can't explain what a parameter changes, it probably shouldn't be exposed.

Performance Is Part of the Design

"60 FPS" is a useful target.

But it doesn't mean much if the demo is running on an empty page.

Real websites have:

Images
Fonts
Layout work
Other JavaScript
Analytics
Third-party scripts
Multiple components

So I tried to keep each interaction reasonably isolated.

Some of the decisions were simple:

Don't render through React unnecessarily.

Stop Canvas loops when there's nothing to draw.

Prefer transforms and opacity when appropriate.

Avoid expensive rendering when a browser primitive can do the job.

Clean everything up on unmount.

The goal isn't to make every interaction magically "60 FPS."

The goal is to avoid wasting work.

What I Learned Building 50 of Them

After building enough of these, a few patterns became obvious.

1. Start with the input

Before thinking about the animation, decide what the user is doing.

Hover?

Move?

Click?

Scroll?

Drag?

Touch?

The input determines the interaction.

2. Motion needs a rule

If you can't describe why something moves, it's probably decoration.

3. The return matters

A believable interaction isn't just about the initial response.

How the element settles back into its normal state often determines whether it feels physical.

4. The simplest technology usually wins

CSS can do a lot.

SVG can do a lot.

Canvas can do a lot.

You don't automatically need WebGL because something looks "3D."

5. Accessibility changes the design

Reduced motion and touch aren't annoying edge cases to solve at the end.

They force you to understand what the interaction is actually communicating.

From 50 Experiments to a Reusable System

The biggest change happened when I stopped asking:

"How do I build this effect?"

and started asking:

"How do I make this effect easy to reuse?"

That changed the architecture.

The shared layer handles:

Input
Configuration
Lifecycle
Accessibility
Cleanup

The individual experiments handle:

Visual behavior
Interaction rules
Material
Personality

That separation makes experimentation much cheaper.

And that's really what MOTIONFORGE became.

Not a collection of animations.

A system for experimenting with interaction.

Try It

All 50 experiments are available in the live explorer.

You can interact with them, browse the categories, and see how the ideas behave before deciding whether something is useful for your own project.

Explore MOTIONFORGE

If you want the complete collection and source:

MOTIONFORGE on Gumroad

Final Thought

The hardest part wasn't making 50 things move.

It was making 50 different interactions share infrastructure without making them feel like the same interaction repeated 50 times.

The solution was to keep the boring parts consistent:

Input.

Lifecycle.

Configuration.

Accessibility.

Cleanup.

Then leave the creative layer free to experiment.

That's probably the biggest lesson I took from the project:

Don't build a library of effects. Build a system that makes experimentation cheap.

If you're building interaction-heavy interfaces, I'd be interested to know:

What's the hardest part for you to make reusable — input handling, animation, accessibility, performance, or integration?

I Wanted a Website That Felt Alive. So I Built MOTIONFORGE.

Mohamed Sadok — Thu, 01 Oct 2026 09:16:47 +0000

Fifteen experiments in making the web less ordinary, without forgetting the people using it.
There is a moment on a good interactive website when you stop scrolling on autopilot.

Not because something shouted at you. Not because a modal interrupted you.

Something simply responded in a way you did not expect.

A word leaned toward your hand. An image opened into another world. A product came apart, and suddenly its construction made sense.

For a second, the website stopped feeling like a stack of rectangles.

It felt like a place.

That moment is what I wanted to explore with MOTIONFORGE.

The Problem Wasn’t a Lack of Animation
We already have animation everywhere.

Headings arrive. Cards lift. Buttons grow. Sections drift into view. Somewhere, a line of text is moving endlessly across the screen.

None of that is inherently bad. These techniques solve real problems.

But useful motion and memorable interaction are not always the same thing.

The question I kept coming back to was more interesting:

What would a motion library look like if the goal wasn’t to decorate a website, but to give it a physical character?

I didn’t want another drawer full of interchangeable entrance animations.

I wanted systems with behavior.

Systems you could push, pull, interrupt, and reshape.

Start With a Feeling. Then Choose the Technology.
The first temptation in creative development is to reach for the biggest tool available.

WebGL can look extraordinary. Three.js can build entire worlds. A shader can make a flat image appear to have material properties.

But technology is not the idea.

For MOTIONFORGE, the more useful question became:

What is the simplest mechanism that can make this interaction feel convincing?

Magnetic typography doesn’t need a 3D scene.

It needs individual glyphs with positions, velocities, a spatial force field, and springs that know how to settle.

A liquid button doesn’t need a game engine.

It needs a deformable boundary, SVG turbulence, real displacement, and a stable native button underneath.

A product explosion does need three dimensions.

Without actual depth, camera perspective, and component separation, the illusion falls apart as soon as you look closely.

Choosing the technology became part of the art direction.

Press enter or click to view image in full size
Press enter or click to view image in full size
Press enter or click to view image in full size
Press enter or click to view image in full size
Press enter or click to view image in full size
Three Interactions That Changed the Shape of the Project
Liquid Reality Reveal
The idea started with a simple question:

What if an image had another reality underneath it?

The obvious implementation would be a circular mask following the cursor.

It would work.

It would also look exactly like a circular mask following the cursor.

The more interesting version uses turbulence and radial displacement. The boundary refracts. Movement creates a wake. Pointer velocity influences the distortion. An alternate image isn’t simply placed on top; it is sampled through a responsive lens.

The result is less about revealing content and more about making the surface feel uncertain.

Magnetic Typography
Typography normally behaves itself.

It sits on a baseline, follows a grid, and waits for you to read it.

In this experiment, the word becomes a collection of small physical bodies.

Each glyph reacts according to where your pointer is. Each one carries velocity. When you move away, it doesn’t teleport back to its original position.

It resolves the force that moved it.

That distinction is relatively small in code and surprisingly large in feel.

The text stops being decoration.

It becomes an object.

Scroll-Scrubbed 3D Product Explosion
This is the practical side of the same idea.

There is a difference between telling someone that a product is carefully engineered and allowing them to see its construction separate in space.

The example uses a procedural headphone assembly.

As scroll progression changes, individual components move from stable origins along defined explosion vectors.

The scene isn’t a sequence of pre-rendered frames.

It is a construction that can be explored.

And that makes the motion useful.

It explains something.

Fifteen Different Ways to Respond
Those experiments eventually became a collection of fifteen systems:

Liquid image refraction
Magnetic typography
Melting text
Cinematic image disintegration
Infinite 3D product carousel
Dimensional image trail
Scroll-scrubbed product explosion
Liquid magnetic button
Portal image transition
Holographic glass cards
Scroll tunnel
Procedural aurora field
Physics-based navigation
Controlled signal glitch
Geometry morphing
The variety matters, but it isn’t the point.

The point is that every effect has a different relationship with input.

Some follow velocity.

Some respond to proximity.

Some use scroll as a narrative timeline.

Some create atmosphere without demanding attention.

Become a Medium member
Some are deliberately playful.

Others are designed to communicate how something works.

A good collection shouldn’t give every website the same signature.

It should give developers enough room to find their own.

A Beautiful Demo Is the Easy Part
The less photogenic work starts after the first successful interaction.

What happens when the viewport changes?

What happens when the user is touching a screen instead of holding a mouse?

What happens when a component mounts twice?

What happens when an image finishes loading after the component has already been destroyed?

What happens when the browser cannot create another WebGL context?

And what happens when the user has explicitly asked the operating system for less motion?

Those aren’t cleanup questions.

They’re part of the creative work.

MOTIONFORGE uses a shared lifecycle so effects can be configured, paused, resumed, and destroyed consistently.

The gallery initializes effects near the viewport and releases scenes when they leave it.

Pixel ratio is bounded.

Mobile rendering can be reduced.

Late texture requests are guarded.

Scroll effects own their triggers instead of blindly deleting someone else’s.

The goal is smooth performance on suitable modern hardware.

That is deliberately different from promising a universal frame rate.

The final implementation still needs to be profiled against the browsers and devices that actually matter for a project.

I’d rather make that boundary explicit than turn an aspiration into a marketing statistic.

Reduced Motion Isn’t a Second-Class Experience
One of the most important design decisions was deciding what remains when movement is removed.

The answer cannot be:

Nothing.

Text should remain readable.

Images should remain available.

Navigation should still work.

A button should still be a button.

Under reduced motion, decorative behavior can stop or become a static composition. The underlying content and functionality remain intact.

This turned out to be more than an accessibility requirement.

It became a useful creative constraint.

If an interaction only makes sense while it is moving, perhaps the underlying design needs more thought.

Let People Explore Before They Read the Source
I wanted the public experience to feel more like an exhibition than a documentation dashboard.

The demo opens with a large MOTIONFORGE wordmark and a liquid-metal composition.

From there, the collection becomes a series of live experiments.

There is no wall of code competing with the motion.

No source-download buttons.

No pricing table interrupting the gallery.

Visitors can explore an effect, open a larger preview, adjust parameters, and save a preset locally.

The developer experience is deliberately separate.

The purchased project can be run locally, where the same collection becomes something different:

Actual source code.

Copyable examples.

Documentation.

Architecture-aware customization prompts.

Two contexts.

Two different jobs.

The public demo helps you decide whether the motion belongs in your idea.

The local edition helps you make it belong in your codebase.

Reusability Shouldn’t Mean Removing the Personality
There is a familiar tradeoff in creative tools:

The more reusable something becomes, the more generic it can feel.

I tried to avoid that by making the behavior configurable without flattening its character.

Intensity isn’t simply a larger scale.

Timing isn’t just a slower fade.

A spring can become tighter or more languid.

A liquid field can become quieter or more viscous.

Geometry can change its phase and material while remaining part of the same underlying system.

The API is intentionally small.

Every effect has a target, a clear configuration surface, and a lifecycle that can be reasoned about.

That predictability is what makes the unusual behavior usable.

The Web Doesn’t Need to Be Louder
It needs to be more intentional.

Not every page should melt.

Not every navigation bar needs inertia.

Not every product deserves an exploded view.

But when an idea calls for something expressive, the interaction should feel designed rather than borrowed.

That’s the ambition behind MOTIONFORGE:

Production-ready animations for websites that refuse to look ordinary.

Not motion for the sake of filling a timeline.

Motion that gives a website a little gravity.

A little materiality.

A reason to pause.

Explore the live playground
https://motionforge-2.vercel.app/

Move slowly.

Then quickly.

Pull a word apart.

Open a portal.

Take a product apart and put it back together.

The interesting part isn’t watching an animation.

It’s discovering what happens when the animation responds to you.

Get MOTIONFORGE
https://boukataya.gumroad.com/l/ybyvxk

Your Website’s Animations Are Boring — Here’s the Engineering That Fixes That

Mohamed Sadok — Wed, 30 Sep 2026 15:32:46 +0000

I Built 15 WebGL Animations. The Hard Part Wasn’t the WebGL.
What I learned about render loops, WebGL context limits, real physics, performance, and reduced motion while turning a collection of experiments into a production-ready animation library.

There is a particular kind of link a client sends you.

No brief.
No Figma file.
Just a URL and four words:

“Can we do that?”

On the other end is a site where the cursor drags liquid across a photograph, where a headline’s letters lean away from your pointer like iron filings, where scrolling tears a product apart into its components.

It looks like magic.

It is not magic.

It is a signed-distance field, a spring integrator, and somebody’s very long afternoon.

I spent that afternoon fifteen times.

Then I threw the afternoons away and kept the system.

This is what the system looks like — and the four engineering decisions that turned “a folder of cool demos” into something you can actually hand to a client.

The Rule That Made This Possible: Lowest-Complexity Technology Wins
The instinct, when you know WebGL, is to reach for WebGL.

It is almost always wrong.

Take the image trail effect: copies of a photo stacked behind your cursor as it moves.

The lazy version is fifteen DOM nodes with decreasing opacity.

It looks like a PowerPoint transition.

The over-engineered version is a render-target ping-pong with a velocity buffer.

The right version is Canvas 2D with actual perspective maths.

Each trail instance has a real Z depth. Its corners get rotated in 3D, divided by the focal plane, and the resulting affine basis is written straight into setTransform().

Depth drives scale, draw order, and atmospheric tint.

The result is about 90 lines, runs at 60fps on integrated graphics, and — crucially — doesn’t consume a WebGL context.

Because a WebGL context is one of the scarcest resources on the page.

The same logic killed three shader passes.

The holographic cards use thin-film interference maths in CSS instead of a refraction shader:

2 · n · d · cos(θ)

mapped through the visible spectrum into gradient stops.

The liquid button uses the blur() → contrast() metaball trick on a small canvas because that is real viscous merging.

WebGL appears exactly where WebGL is the only honest answer:

Displacement fields. Dissolves. Portals. Tunnels. Aurora.

Decision #1: There Is One Render Loop, and It Is Not Yours
Fifteen animations means fifteen requestAnimationFrame loops if you build them the obvious way.

Fifteen loops means fifteen independent clock reads.

Fifteen delta-time calculations.

And, more importantly, fifteen things continuing to run after the user has scrolled past them.

So the library owns a single ticker.

Effects subscribe to it.

The loop cancels itself when there are no subscribers.

Delta-time needs a ceiling
A backgrounded browser tab can return with a four-second dt.

A stiff spring integrated over four seconds doesn’t politely ease back into place.

It launches itself into NaN.

So the delta is clamped.

Subscribers need to be copied
An effect is allowed to unsubscribe during its own tick.

That’s exactly what happens when an effect tears itself down mid-frame.

The pointer gets the same treatment.

One passive pointermove listener publishes:

position
smoothed velocity
normalized energy
It is reference-counted, so fifteen magnetic effects still cost one listener.

The sampler switches itself off when nothing is reading it.

Decision #2: Budget Your WebGL Contexts Like Memory
Here is the bug that ends careers.

Browsers can silently drop older WebGL contexts when too many are alive.

You don’t necessarily get a useful error.

Your hero canvas simply goes black.

Usually on the pages with the most content, on the machines with the most going on, weeks after launch.

A library with fifteen effects — several of them WebGL — can hit that ceiling surprisingly quickly.

So the engine treats contexts as a scarce resource with an explicit budget.

The rules are simple:

Four surfaces may be live at once.
Each surface reports a visibility score.
When a fifth requests a context, the least-visible surface is suspended.
Suspended contexts are properly destroyed with WEBGL_lose_context.
When the surface becomes visible again, it re-initializes.
Effects are initialized lazily when they approach the viewport.
releaseOnExit tears them down when they leave it.
This means a page can mount all fifteen effects while remaining inside the context budget.

The demo even ships with a HUD showing the live count so you can watch the system work.

Live demo: https://motionforge-lyart.vercel.app/

Decision #3: Physics Is Not a Metaphor
Two effects in the library are physical simulations.

Both fall apart if you fake them.

The navigation is a Verlet rope.

Each item is a body with a position and previous position. Velocity is implicit.

Bodies are pinned to their rest anchors by constraints and coupled to their neighbours through distance constraints.

The constraints are relaxed over five iterations per step.

The cursor applies a repulsion field with a squared falloff.

Dragging pins a body to the pointer.

Releasing it writes the pointer’s measured velocity into px and py.

That’s how you throw it.

Nothing is tweened.

There is no:

ease: "elastic"
anywhere near it.

And you can feel the difference.

Elastic easing is a curve pretending to have mass.

The core is simply:

integrate(points, dt, gravity, drag);
satisfy(constraints, 5);
The typography works the same way.

Every glyph owns a critically damped spring.

Inside the influence radius, cursor attraction falls off with distance squared, while the glyph inherits a slice of pointer velocity as skew.

Because the springs are per-glyph and slightly detuned, a fast swipe sends a wave through the word instead of moving the entire word as one block.

That wave only exists because the numbers are real.

Write on Medium
The same principle applies to the shaders.

The liquid reveal isn’t a blurred circle mask.

It uses nine spring-chained metaballs merged with a polynomial smooth-min. Its boundary normal is sampled again to create the refractive rim.

The dissolve isn’t a simple wipe either.

An FBM field determines the order in which pixels disappear. Surviving pixels near the burn front are displaced, stretched through a second turbulence pass, desaturated, and surrounded by hashed ember cells that continue moving after the original pixel is gone.

Decision #4: Reduced Motion Is a State, Not a Checkbox
prefers-reduced-motion is where many motion libraries get quietly dishonest.

They disable an opacity transition and call it accessible.

That isn’t enough.

Every effect in this library ships with a documented fallback that preserves the content and the API.

For example:

The liquid reveal displays the photograph in full colour with no shader or canvas.
The 3D carousel becomes a scroll-snap strip using the same panels.
The scroll tunnel becomes seven concentric CSS frames.
The physics navigation becomes a static row using the same real elements.
The morph renders its first shape with the geometry intact.
The glitch effect becomes a single 60ms flash on hover instead of looping automatically.
The media query is also observed live.

Changing the operating-system preference reinitializes the page without requiring a reload.

The demo includes a switch that forces the same code path.

Because if you cannot see your fallbacks, you don’t have fallbacks.

You have intentions.

What the Fifteen Actually Are
Each effect ships as its own folder containing an index.ts and a detailed README covering:

installation
configuration
advanced configuration
React usage
vanilla usage
mobile behaviour
accessibility
performance
troubleshooting
Every effect starts with the same base configuration:

target
intensity
duration
mobileMode
respectReducedMotion
lazy
releaseOnExit
And every effect follows the same lifecycle contract:

const fx = createPortalTransition({
target: el,
images,
twist: 2.4
});
fx.setOptions({ duration: 2 });
fx.open(clientX, clientY);
fx.destroy();
That last method is probably the least exciting part of the API.

It’s also one of the most important.

destroy() removes the nodes, listeners, textures, and contexts.

In an SPA, that’s the difference between a portfolio site and a memory leak.

The Part I’d Hand to an AI
Every effect also ships with a customization prompt.

Not a generic:

“Make this animation cooler.”

A real engineering brief.

The prompt tells a coding agent which architecture must remain intact:

lifecycle wrapper
shared ticker
WebGL context budget
reduced-motion branch
The agent can change:

colours
intensity
timing
visual treatment
page integration
without quietly replacing the underlying physics with:

transition: all 0.3s;
That distinction matters.

AI is very good at changing what you can see.

It is much less trustworthy when you ask it to preserve the engineering decisions you cannot see.

The customization prompt exists to protect those decisions.

What I’d Do Differently
Measure earlier
The WebGL context budget exists because I found the black-canvas bug the hard way.

If you’re building something with more than three WebGL contexts, build the budget first.

Beware filter costs
SVG feTurbulence can look incredible on a headline.

It can also become catastrophic when applied to a large amount of text every frame.

Never read layout inside a tick
Every getBoundingClientRect() inside a per-frame callback can trigger expensive layout work.

Measure on resize.

Cache the values.

Interpolate.

Design teardown with the effect
Don’t bolt cleanup on at the end.

Lifecycle management should be part of the effect’s architecture from the beginning.

See It Move
The whole system runs directly in the browser.

Fifteen live specimens.

Each one can be opened and reconfigured in real time.

The HUD reports:

FPS
live WebGL contexts
ticker subscribers
So the performance claims aren’t just theoretical.

You can actually watch the system work.

→ Live Demo: https://motionforge-lyart.vercel.app/

If you build websites where motion is part of the argument rather than decoration, I packaged the complete system:

15 effects + engine + documentation + customization prompts + demo source.

→ MotionForge on Gumroad: https://boukataya.gumroad.com/l/cqzizd

Built with TypeScript, WebGL/GLSL, Three.js, GSAP ScrollTrigger, Lenis, and an unreasonable amount of coffee.

Questions in the responses — I answer all of them.

I Built a Tool to Find the Tests Developers Have Stopped Trusting

Mohamed Sadok — Tue, 29 Sep 2026 08:36:54 +0000

I Built a Tool to Find the Tests Developers Have Stopped Trusting

A test fails in CI.

You look at it.

You run it again.

It passes.

You run it again.

It passes.

You rerun the pipeline.

Everything is green.

So you merge the pull request.

A few hours later, the same test fails again.

At some point, the team stops treating that failure as useful information.

That's the real problem with flaky tests.

They don't just make CI unreliable.

They make developers stop trusting CI.

The problem isn't writing tests

Modern JavaScript projects already have excellent testing tools.

Playwright is great for browser testing.

Vitest and Jest are great for unit and integration testing.

CI platforms can execute thousands of tests.

The problem starts after the tests exist.

A growing project eventually accumulates:

Tests that fail intermittently
Tests that take too long
Tests that haven't failed in months
Tests that fail only in CI
Tests that fail because of timing
Tests that produce almost identical errors
Tests that nobody wants to touch

The test suite becomes a second system that needs maintenance.

And most teams don't have a good way to measure its health.

So I built TestOps Kit

The idea is simple:

Don't replace the test runner. Analyze what it produces.

TestOps Kit consumes machine-readable test results and builds a reliability layer around them.

The workflow looks like this:

Playwright / Vitest / Jest
            ↓
       Test results
            ↓
       TestOps Kit
            ↓
 ┌──────────┼───────────┐
 ↓          ↓           ↓
History   Reliability  Performance
 ↓          ↓           ↓
Flaky     Quarantine   Slow tests
tests
            ↓
        Dashboard

The existing testing workflow stays intact.

TestOps simply adds another layer of information.

The first feature I wanted was flaky-test detection

A single failed test doesn't necessarily mean a test is flaky.

You need history.

For example:

Run 1 → PASS
Run 2 → PASS
Run 3 → FAIL
Run 4 → PASS
Run 5 → FAIL

That pattern is much more interesting than a single failure.

TestOps tracks test behavior across runs and calculates reliability metrics from the available history.

The goal isn't to say:

"This test is definitely broken."

The goal is to say:

"This test has demonstrated inconsistent behavior and deserves investigation."

That's a much more useful signal.

Then came quarantine

Once you identify unreliable tests, the next problem is operational.

What do you do with them?

TestOps can generate a quarantine manifest based on a configurable flakiness threshold.

For example:

Flaky tests

checkout/payment.spec.ts     42%
account/login.spec.ts        31%
orders/create.spec.ts        27%

Instead of relying on someone's memory, the team now has a concrete list.

The important part is that quarantine is treated as a temporary reliability workflow, not a way to permanently hide failures.

Slow tests are another form of test debt

A test doesn't have to fail to become expensive.

Imagine a suite containing:

1,200 tests

and a handful of tests account for a significant portion of the runtime.

Those tests affect every developer.

Every pull request.

Every CI run.

Every deployment.

So TestOps also tracks duration and highlights slow tests.

The goal is straightforward:

Find the tests that are costing the team time.

Visual regression belongs in the same conversation

Testing isn't only about pass and fail.

UI changes can also introduce unexpected regressions.

TestOps includes deterministic snapshot checking so a CI pipeline can detect changed snapshot content.

For example:

npx testops snapshot snapshots --strict

If a snapshot changes unexpectedly, the command returns a failure.

That makes it possible to use the same reliability workflow in CI.

I also wanted a boring CLI

Developer tools don't need complicated installation procedures.

The basic workflow should be something like:

npx testops analyze --input test-results.json

Then:

npx testops report

And you get a dashboard.

The dashboard focuses on the questions developers actually care about:

How many tests do we have?

How many are failing?

Which ones are flaky?

Which ones are slow?

What happened in previous runs?

Testing the tester

One of the most important parts of building a developer tool is testing it against something real.

A synthetic demo can prove that the software works in theory.

It doesn't prove that developers can use it in their projects.

So the validation workflow is:

Existing project
      ↓
Existing tests
      ↓
Generate real test report
      ↓
Feed report into TestOps
      ↓
Compare metrics
      ↓
Create intentional flaky test
      ↓
Run repeatedly
      ↓
Verify detection
      ↓
Create slow test
      ↓
Verify performance detection
      ↓
Modify snapshot
      ↓
Verify regression detection
      ↓
Run inside CI

This is the test that matters.

Not whether the landing page looks good.

Not whether the dashboard has impressive charts.

Whether it can survive a real repository.

What I learned

The interesting part of test infrastructure isn't necessarily generating more tests.

It's understanding the tests you already have.

A team can have 5,000 tests and still have a reliability problem.

More tests don't automatically mean more confidence.

Sometimes the real question is:

Which tests can we trust?

That's the problem TestOps Kit is designed around.

The goal

The long-term idea is bigger than a CLI.

A mature version could understand:

Test history
CI environments
Failure patterns
Code changes
Test ownership
Dependency relationships
Visual changes
Performance regressions
Failure clusters

Eventually, the system could answer questions like:

Which tests became unreliable after this deployment?

Or:

Which changed files are responsible for most of the tests we need to run?

Or:

Which tests have consumed the most CI time this month?

But the first version starts with something much simpler:

Measure test reliability instead of guessing about it.

Because once developers stop trusting their test suite, the test suite has already become technical debt.

And that's a problem worth measuring.

TestOps Kit — Flaky Test Detection, Test Reliability & CI Toolkit

TestOps KitProduction Test Reliability Toolkit for Modern JavaScript TeamsYour test suite is supposed to give you confidence.Instead, you get: Random CI failures Tests that pass locally but fail in CI Slow test suites Repeated failures nobody investigates Visual regressions Hundreds of test results to manually inspect Flaky tests that waste hours every week TestOps Kit turns raw test results into actionable test reliability data.It analyzes your existing test reports, tracks test history, detects flaky tests, identifies slow tests, generates quarantine manifests, checks visual snapshots, and produces a standalone reliability dashboard.No need to replace your existing test framework.What you getFlaky Test DetectionTrack test behavior across multiple runs and identify tests that repeatedly switch between passing and failing.See: Flakiness percentage Failure frequency Run history Test duration Failure information Test Reliability DashboardGet a single view of your test suite: Total tests Pass rate Failed tests Flaky tests Slow tests Test duration Historical runs Failure details Test QuarantineGenerate a quarantine manifest for tests that exceed your configured flakiness threshold.Instead of manually maintaining a list of unreliable tests, let TestOps identify them from actual test history.Slow Test DetectionFind tests that are consuming disproportionate CI time.Use duration history to identify tests that deserve optimization.Visual Regression ChecksCreate deterministic snapshot baselines and detect unexpected changes using content hashing.Useful for: HTML snapshots JSON snapshots Generated assets Test fixtures Visual regression workflows CI ReadyDesigned to fit into existing CI pipelines.Use it with GitHub Actions and your existing test infrastructure.Multiple Report FormatsThe toolkit supports common machine-readable test reports including: Playwright JSON Vitest/Jest-style JSON JUnit XML Test Impact AnalysisIdentify candidate tests related to changed files so you can focus testing where changes actually occurred.Stress TestingRun the same command repeatedly to expose intermittent failures.Example:npx testops stress --command "npm test" --runs 20 Developer CLIEverything is accessible from the command line.npx testops analyze --input test-results.json npx testops report npx testops quarantine npx testops snapshot snapshots --strict npx testops stress --command "npm test" --runs 20 Built for JavaScript developers TypeScript developers SaaS teams Freelancers Agencies QA engineers DevOps engineers CI/CD-heavy projects Teams using Playwright, Vitest or Jest Requirements Node.js 18+ npm Git Existing automated test reports Included TestOps CLI Reliability analyzer Flaky test detector Test history Quarantine generator Slow-test analysis Stress runner Visual snapshot checker Git impact analysis Standalone dashboard GitHub Actions integration Demo fixtures Complete documentation Example configuration MIT license Why TestOps?Test generation is only half the testing problem.The other half is knowing whether the tests you already have can actually be trusted.TestOps focuses on that problem.Know which tests are stable. Know which ones are flaky. Know which ones are slowing CI down.Build with confidence instead of debugging CI noise.

boukataya.gumroad.com

How We Built a Production-Ready SaaS Billing Engine (And How You Can Ship Yours Today)

Mohamed Sadok — Mon, 28 Sep 2026 15:53:44 +0000

The complete blueprint for handling subscriptions, customer billing portals, and edge-case webhooks without losing your sanity.*

Every developer building a SaaS eventually runs into the same wall: Monetization Architecture.

Building the core features of an application is exciting. Writing billing logic, managing recurring cycles, handling failed credit card charges, generating PDFs, and wiring up webhook endpoints is usually where momentum slows down.

In this article, we'll walk through the architecture of a production-ready SaaS billing engine and examine the critical patterns needed to accept recurring payments reliably.

1. The Billing State Problem

Handling payments is not just a single API call to charges.create(). A production billing system must manage state transitions across multiple scenarios:

What happens when a renewal payment fails at 3:00 AM?
How do you handle plan upgrades with prorated charges mid-cycle?
What happens if a user cancels their subscription before the cycle ends?

The Core Subscription State Machine

A resilient subscription model requires tracking distinct statuses:

trialing
active
past_due
canceled
incomplete

[ Checkout ] ──► [ Active ] ──► (Cycle Renewal)
                      │                │
                      ▼                ▼
                 [ Canceled ]    [ Past Due ] ──► [ Inactive ]

2. Webhooks: The Single Source of Truth

Never rely solely on client-side redirect URLs (e.g., /checkout/success) to grant access to paid tiers. Network disconnects, closed browser tabs, or client-side crashes can prevent access from being granted.

Recommended Webhook Pipeline

Verify Signature: Ensure the payload originated from your payment gateway.
Idempotency Check: Store incoming event_id values to prevent processing duplicate events.
Queue Processing: Immediately return a 200 OK response to the payment provider and dispatch the actual processing task to a background worker.

// Example: Verifying and dispatching webhooks asynchronously
public function handleWebhook(Request $request)
{
    $event = $this->verifySignature($request);

    if ($this->hasBeenProcessed($event->id)) {
        return response()->json(['status' => 'already_processed'], 200);
    }

    ProcessBillingEventJob::dispatch($event);

    return response()->json(['status' => 'queued'], 200);
}

3. Customer Self-Service: The Billing Portal

Modern users expect to manage their own billing:

Updating expired credit cards
Downloading past VAT / Tax invoices
Upgrading or downgrading plans

Using hosted billing portals (like Stripe Customer Portal) eliminates the need to build custom PCI-compliant credit card updating forms on your frontend.

4. Get the Starter Kit

Rather than spending 40+ hours wiring up database schemas, webhook listeners, environment configs, and test suites, you can grab the complete SaaS Billing Engine Starter Kit.

Includes:

Complete source code with local DDEV / Docker support
Production-tested webhook handlers
Seeders, migrations, and plan definitions
Detailed documentation

https://boukataya.gumroad.com/l/shouoa

saa-s-billing-starter-kit-demo.vercel.app

How I Built a 1970s Retro Vinyl Store Web App in 1 Single HTML File (No Frameworks, No Build Step)

Mohamed Sadok — Fri, 25 Sep 2026 10:17:29 +0000

Every modern e-commerce website seems to look the same.

Clean white backgrounds.
Minimal cards.
Rounded buttons.
The same fonts.
The same SaaS-style layouts.

It works, but sometimes it feels completely soulless.

So I decided to build something different.

I wanted to recreate the feeling of walking into a small record store in the late 1970s — old vinyl sleeves, warm paper textures, bold typography, imperfect print effects, and even the subtle sound of vinyl crackling in the background.

The result is GrooveHaus, a retro vinyl store web app built entirely inside one HTML file.

No framework.
No build process.
No node_modules.
No complicated setup.

Just HTML, CSS, JavaScript, and a lot of experimentation.

🎧 Live Demo & Template

Live Demo:
https://groove-haus.vercel.app/

Template:
https://boukataya.gumroad.com/l/ytowj

The Idea Behind GrooveHaus

The goal wasn't simply to make an "old-looking" website.

I wanted the interface itself to feel like a physical object.

Think:

Vintage record sleeves
Printed paper textures
1970s-inspired typography
Burnt orange, mustard, cream and burgundy colors
Grain and imperfect print effects
Records that physically slide out of their sleeves
Analog vinyl crackle
Simple page transitions
A store experience that feels more like browsing a record shop than using a typical e-commerce dashboard

The interesting part was trying to create those sensations using only browser-native technologies.

The Constraint: One HTML File

I deliberately gave myself a strict constraint:

Everything had to live inside a single .html file.

That means no React.

No Vue.

No build system.

No npm installation.

No bundler.

No component library.

The page contains the markup, styling and JavaScript needed to run the application.

External resources are limited to things like fonts and CDN-hosted libraries.

This sounds restrictive, but it actually made the project more interesting.

Instead of asking:

"Which framework should I use?"

I could focus on:

"How much can I build with the browser itself?"

The Stack

The technology stack is intentionally simple:

HTML5 handles the structure and application views.

Tailwind CSS via CDN provides the utility classes and makes it easy to create the visual system.

Vanilla JavaScript handles routing, application state, rendering, filtering and interactions.

Web Audio API generates the vinyl crackle effect directly in the browser.

Google Fonts and Font Awesome provide typography and icons.

There is no backend because the goal was to create a self-contained frontend template.

Making the Browser Sound Like Vinyl

One of my favorite parts of the project is the analog noise effect.

Instead of shipping an audio file containing vinyl crackle, GrooveHaus generates the sound dynamically using the Web Audio API.

The browser creates an audio buffer containing low-level random noise combined with occasional louder pops.

The result is a subtle background texture that resembles an old record playing.

The important part is keeping it subtle.

The effect isn't supposed to become annoying background music. It's more like an atmospheric layer that you notice when you stop and listen.

Users can also turn the effect on or off.

This was a good reminder that the Web Audio API can do much more than simply play MP3 files.

A Tiny SPA Without a Framework

The application behaves like a small single-page application.

There are different views for things like:

Storefront
Catalog
Product details
Artists
Journal
Cart
Settings

Instead of installing a routing library, I used the browser's native URL hash.

For example, different hash routes determine which application view should be displayed.

When the URL changes, JavaScript hides the previous view, displays the appropriate one and renders the required content.

It's obviously not a replacement for a full routing solution in a large production application.

But for a self-contained template?

It works surprisingly well.

And there is something satisfying about realizing that you don't always need another dependency to solve a relatively small problem.

Making Vinyl Records Feel Physical

One of the visual details I wanted was the feeling of pulling a record out of its sleeve.

When hovering over a product card, the vinyl disc slides out from behind the album artwork while rotating.

It's a small interaction, but it changes how the product card feels.

Instead of:

Image → title → price → button

you get something closer to interacting with a physical record.

The effect is entirely CSS-based, using transforms and transitions.

No animation library required.

This is one of those cases where a few lines of CSS can create much more personality than another UI component ever could.

Recreating Printed Paper

Modern websites are usually extremely clean.

GrooveHaus deliberately isn't.

The background uses warm paper tones combined with subtle radial patterns to imitate the texture of printed material.

The color palette is built around:

Cream
Aged paper
Dark brown
Burnt orange
Mustard
Burgundy

Typography also plays a major role.

Instead of using one generic UI font everywhere, the design combines display and serif typefaces to create something closer to vintage posters, record sleeves and printed magazines.

The goal isn't perfect realism.

It's controlled imperfection.

Why I Didn't Use React

This project probably could have been built faster with React.

But that wasn't the point.

Sometimes constraints are useful.

Removing the framework forced me to think about what the browser already provides:

DOM APIs
URL hashes
CSS transitions
Web Audio
browser storage
native events
modern JavaScript

It also makes the final result extremely portable.

There is something nice about downloading one HTML file and knowing that most of the application is sitting right there.

Where Single-File Apps Actually Make Sense

I'm not suggesting everyone should abandon frameworks.

For a large SaaS platform, complex dashboard or production application with dozens of developers, a single HTML file would quickly become painful.

But there are some cases where this architecture makes a lot of sense.

For example:

Templates

A customer can download one file and immediately start customizing it.

Prototypes

You can experiment with an idea without spending time setting up infrastructure.

Landing pages

For a relatively simple marketing experience, a build pipeline may be unnecessary.

Digital products

A self-contained template is easy to distribute through marketplaces and digital stores.

Experiments

Sometimes you simply want to see how far native browser APIs can take you.

The Bigger Lesson

The most interesting part of building GrooveHaus wasn't actually the vinyl store.

It was realizing how much you can do before reaching for another dependency.

A browser already gives you a lot:

HTML for structure.

CSS for animation and visual effects.

JavaScript for application logic.

Web Audio for sound.

The URL for simple routing.

And modern browser APIs for everything in between.

Frameworks are incredibly useful.

But they aren't mandatory for every project.

Sometimes putting yourself inside a few artificial constraints leads to more creative solutions.

Final Thoughts

GrooveHaus started as a visual experiment:

"Can I make a website feel like a physical record store?"

It ended up becoming an experiment in something else:

"How much can I build with nothing more than a browser and a single HTML file?"

The answer is: quite a lot.

And honestly, building something that doesn't look like another SaaS dashboard was probably the most refreshing part.

Live Demo:
https://groove-haus.vercel.app/

Template:
https://boukataya.gumroad.com/l/ytowj

What retro web design trend would you bring back?

DEV Community: Mohamed Sadok

I Got Tired of Rebuilding the Same Support Portal. So I Built One I Could Reuse.

First, let's talk about the boring stuff

Three roles. One rule: permissions must actually mean something.

The tiny problem that becomes a big problem: ticket numbers

Internal notes: the feature that must stay internal

File uploads: because not every attachment should be public

A Kanban board is easy. A correct workflow is harder.

Dashboard statistics shouldn't be works of fiction

The test suite is part of the product

What NEXORA doesn't include

Who is this for?

Getting started

So, why did I package it?

I Built a Laravel RBAC Starter So I Could Stop Rebuilding Admin Panels

The problem isn't authentication. It's everything around it.

What I built

1. Five predefined roles

2. Server-side authorization

3. User administration

4. Audit logging

5. A dashboard with real database data

6. Thirty-three automated tests

Try the demo before looking at the code

What it doesn't include

When is this useful?

I Built 8 SaaS Landing Pages. Here Are the 11 Sections That Make Them Work.

I Was Tired of Rebuilding SaaS Dashboards. So I Built NEXORA.

The Problem With Starting Every SaaS Project From Scratch

Introducing NEXORA — A SaaS Dashboard UI Kit

What's Included?

1. Overview Dashboard

2. Analytics

3. Customer Management

4. Transactions

5. Plans and Billing

6. Team Management

7. Notifications

8. Profile and Settings

9. Help and Support

10. Components Library

11. Documentation

The Real Advantage: A Customizable Design System

Interactive Components, Not Just Pretty Screens

One Central Place for Sample Data

Why Vanilla JavaScript?

Small Details Make a Difference

Who Is NEXORA For?

Get NEXORA

Final Thoughts

I Built AssetOps Images: A Full Laravel + React App That Optimizes 2,000 Images in Batches

Animations Play. Interactions Respond.

The problem with most "premium" animation

1. Input is easy. Making it perceptible is the hard part.

2. Magnetic buttons need more than translate()

3. The cursor should be an input system, not an animation trigger

4. One shader can become many experiences

5. Motion should never become a usability requirement

6. Mobile isn't desktop with less space

7. Performance is part of the interaction

What I actually wanted to build

Why I called it LIQUID REALITY

The result

If I were building a website today

LIQUID REALITY

How I Built 50 Web Interactions Without Turning My React App Into a Performance Nightmare

How I Built 50 Web Interactions Without Turning My React App Into a Performance Nightmare

The Goal

The Architecture

Why I Didn't Store Pointer Position in React State

The Explorer Doesn't Run 50 Animations

Choosing the Technology After the Interaction

CSS

SVG

Canvas

GSAP

CSS 3D

Reduced Motion Wasn't an Afterthought

Hover Isn't a Mobile Interaction

The Difficult Part Was Timing

2. Magnetic buttons need more than `translate()`