DEV Community: Aniq UI

How to Build an LMS with Live Classes in Next.js

Aniq UI — Sun, 18 Oct 2026 20:44:06 +0000

Originally published on the Aniq UI blog.

By the end of this guide you will know how to build an online course platform with recorded lessons, live classes, quizzes, certificates and paid checkout, using Next.js, NestJS and the Learnio LMS template from Aniq UI. You will not have to build a student site, an admin panel and an API separately.

We follow one example school from its first plan to launch. Each step names the screen or setting involved, and the commands come straight from the template's documentation. The same path works for a solo course creator, a training company, or an agency building an LMS for a client.

About this example

Ledgerline Academy is an illustrative business we use to show the steps. It is not a client story, and the numbers in it are examples, not results.

The brief

Ledgerline Academy is a small online school that teaches bookkeeping to people changing careers. Two instructors teach. The school wants to start with a few courses and grow. Here is what it needs:

A free introductory course that anyone can take, so visitors can try the school before paying.
Paid courses with recorded lessons, personal notes and downloadable worksheets.
A live class every week for each cohort, held inside the platform instead of a separate meeting link.
Quizzes with a pass mark, and assignments that an instructor marks with feedback.
A certificate at the end of a course, with a page where an employer can check it.
Two instructors who each manage only their own courses and students.
An English and an Arabic version of the whole school.

How the template covers the brief

Need	Where it lives	What you use
Free and paid courses	Student site and API	Course pages and checkout; a price of 0 skips payment entirely
Course content	Admin dashboard	The curriculum builder with sections, lessons and draft or published states
Notes and worksheets	Student site	The course player, with notes and downloadable resources per lesson
Weekly live class	Admin dashboard, student site, your meeting server	Live classes, the course calendar, and a Jitsi Meet server you run
Quizzes and assignments	Admin dashboard and student site	The quiz editor, assignment grading, graded on the server
Certificates	Student site	Certificates page and the public verify page
Instructors see their own courses	Admin dashboard and API	The Instructor role with an instructor profile linked to the account
Taking payment	API and student site	Stripe Checkout and a signed webhook
English and Arabic	All three apps	/en and /ar routes, message files, courses written in both languages

Before you start: decisions to make

Course platforms have a few decisions that are hard to undo once students and payments exist. Make them on paper first.

Free, paid, or both?

A course with a price of 0 enrolls the student immediately and never reaches a payment processor. A paid course goes through checkout and enrolls the student only after the processor confirms payment. Ledgerline uses both: a free intro to build trust, and paid courses behind it.

Recorded, live, or both?

The catalog can be filtered by live or recorded. Recorded courses need only lessons and a media bucket. Live courses also need a meeting server that you host. Decide whether live classes are part of launch, because the server is a separate piece of infrastructure with its own cost.

Who teaches, and what may they touch?

If one person does everything, you can use one super admin account. If you have several teachers, plan an instructor profile and a linked account for each.

Which payment processors?

The template supports Stripe cards and PayPal. The checkout always lists both, so plan to configure both before taking real money. If you want only one, plan a code change to the checkout.

Which languages?

English and Arabic ship ready. Course content holds exactly two languages: an English and an Arabic value for each title, description and lesson. A third interface language is possible, but a third content language means changes in the API and the admin editors.

Where do video and files live?

Course art, lesson video and handouts go to a Cloudflare R2 bucket or another S3-compatible store. Decide who owns the bucket and what you will do about backups.

What do you tell people when they buy?

Receipts and enrollment confirmations go through Resend, which needs a verified sending domain. Plan the domain and the sender address before you test email.

Step by step

Step 1: Choose the package

Learnio is three apps: a student website, an admin and instructor dashboard, and a NestJS API behind both. You can buy them together as the Full Stack package, or one at a time. The student site alone runs on bundled sample data. The admin dashboard alone runs on an in-browser mock, and most of its screens stay empty until an API is connected.

Ledgerline needs students, instructors and a database that all agree, so it takes the Full Stack package. If you already have an API, a single frontend can point at it. The commercial license covers unlimited projects, including work you deliver to a client.

Look at the My templates page: pick the ZIP that matches the package you bought.

What to check: the extracted folder for the full stack is learnio-lms, and it contains admin-dashboard, back-end, frontend and docker-compose.yml. Single-app packages extract to a folder of their own, with a Dockerfile, package.json and .env.example.

Step 2: Run everything with Docker

Download the ZIP from My templates, unzip it, and open a terminal in the learnio-lms folder. With Docker running, start the three apps:

docker compose up --build

The first start builds three images and seeds the database with demo data, so it takes a few minutes. Afterward the student site is at localhost:3030, the admin at localhost:3031, and the API at localhost:8000. If a port is busy, add SITE_PORT, ADMIN_PORT or API_PORT to a .env file next to docker-compose.yml and run the command again.

Three demo accounts let you see each side: a student (demo@learnio.com, password Demo@123), a super admin (admin@learnio.com, password Admin@123) and an instructor (emily-davis@learnio.com, password Teach@123). Sign in as each one and click around before you change anything. Without Docker, you need Node.js 22 or 24, corepack enable, and one terminal per app, API first.

This still shows the terminal opened inside the extracted folder, the place every command here assumes you are standing.

Watch the build output: three images are built, and the two frontends hold back until the API reports healthy.

The admin runs in its own terminal on port 3031 once the API is up.

This is the administrator overview you should see after signing in as the super admin: cards and charts for the platform.

What to check: open localhost:8000/api/health, which should answer with a status of ok, then sign in on each app with the demo accounts. If a page carries a notice about sample data, that app could not reach the API.

What usually goes wrong:

Docker is not running, or a port is taken. Free port 3030, 3031 or 8000, or set SITE_PORT, ADMIN_PORT or API_PORT.
The first start seems stuck. It is seeding the demo data, and the frontends start only when the API is healthy.
Yarn reports version 1.22. Run corepack enable and install again.
A fresh run on a database you keep does not reset anything. docker compose down -v deletes the volume and the next start seeds fresh demo data.

Step 3: Set the school's name, logo and colors

The brand lives in files, and the student site and the admin keep separate copies, so change both:

Student site: src/config/site.ts holds the name, description and social handles. src/config/brand.config.ts names the student dashboard.
Admin: src/config/brand.config.ts holds the name, short name, company and the metadata base address.
Logos: replace public/assets/brand/learnio-wordmark.png and learnio-mark.png with your own transparent PNGs at the same names.
Colors: src/styles/theme-variables.css in each app, with light values under :root and dark values under .dark.

The App Settings tab in the admin does not rebrand the apps. Its site_name and support_email only change the emails the API sends. Search both message folders for the old name in English and Arabic, and set the site's public address in NEXT_PUBLIC_SITE_URL.

What to check: change the name in both apps, rebuild, and look for the old name on the sign-in pages, in the footer and in the browser tab, in English and in Arabic. Replace the favicon and the sharing images too, since link previews use them.

What usually goes wrong: only one of the two apps is rebranded, or the logo is stretched because its proportions differ from the declared size. If your artwork has another shape, update the declared width and height where the sidebar brand and the logo component set them.

Step 4: Build the first course

Open Courses in the admin and create the free intro course. Add sections, then lessons inside them, and drag to reorder. A lesson can be a video, a reading, a quiz or an assignment. Attach worksheets as lesson resources, and leave the course as a draft until it is ready. Only published public courses reach the catalog.

Titles, descriptions and lessons are stored once with an English and an Arabic value, and the editors give you a tab for each. Ledgerline writes both before publishing. A free course has a price of 0 and needs no payment processor at all.

Uploads (video, handouts, course art) go to a Cloudflare R2 or other S3-compatible bucket once you set the five R2_* variables in back-end/.env. Until then the demo's bundled sample files still play, and only new uploads fail.

Build it in this order:

Create the course with its title, description, price and category, in both languages.
Add sections, then lessons inside each section, choosing a lesson type.
Attach worksheets and handouts to the lessons that need them.
Flag a lesson as a free preview if you want visitors to see a sample. Only free-preview lessons expose their content and video on the public course page.
Publish the course when it is ready. Until then it stays a draft and the public API answers not found.

Look at how sections hold their lessons, each with a handle you drag to change the order.

What to check: open the public course page in another browser. It should show the overview, syllabus, price and the enroll action. Then sign in as the demo student and open the course player to see lessons, notes and resources.

What usually goes wrong: a course is visible in the admin but not on the site because it is still a draft or is not set to public. Another common one is a missing Arabic title, which makes the Arabic page fall back to empty fields.

Step 5: Add quizzes, assignments and certificates

In the quiz editor, add questions and answer options, then set a passing score and an attempt limit, or allow unlimited attempts for practice. The server grades every attempt, so students cannot change a score in the browser. Required quizzes count toward finishing the course.

Assignments appear in the student's calendar, where they hand in a submission. The instructor opens the submissions, saves a grade, and writes feedback for that student. After every finished lesson and every passed quiz, the API re-checks whether the course is complete. When it is, the enrollment is marked complete, a certificate is issued and the student gets a notification. Anyone can then check a certificate number at /en/verify-certificate, with no account.

Look at the submission waiting to be marked: the instructor sets a grade and writes feedback addressed to that student.

What to check: take a quiz as the demo student and fail it on purpose, then pass it. Confirm the attempt limit stops you when it should. Submit an assignment from the calendar, mark it as an instructor, and look for the notification on the student side.

What usually goes wrong: a required quiz is left unpassed, so the certificate is not ready, and the student is told so. Also check that the passing score is a number the questions can actually reach.

Step 6: Take payments in test mode

Out of the box the checkout uses a built-in simulator. It contacts no processor and charges nobody, and a card number that ends in 0 is rejected, which lets you rehearse a failed payment. Run a full purchase this way first, as the demo student.

To move to Stripe, create test keys in your Stripe account and put STRIPE_SECRET_KEY, STRIPE_PUBLISHABLE_KEY and STRIPE_WEBHOOK_SECRET in back-end/.env. Then add a webhook endpoint in Stripe that points at your API's address followed by /api/webhooks/payments/stripe. A student is enrolled when the webhook confirms the payment, not when they return to the site. Without the webhook, orders stay pending.

PayPal has its own keys: PAYPAL_CLIENT_ID, PAYPAL_CLIENT_SECRET, PAYPAL_WEBHOOK_ID and PAYPAL_ENV. Read the warning in the mistakes section below before you go live.

This is the checkout a student sees: choose card or PayPal, and the form follows the method you picked.

What to check: buy a paid course three ways. First on the simulator, to confirm the seat appears. Then decline a payment with a card number that ends in 0 and confirm no seat is granted. Then, once Stripe test keys are in, buy again and confirm the order moves from pending to paid after the webhook arrives. The order page in the admin shows each order with its course, method and status.

What usually goes wrong:

The order stays pending. The webhook endpoint address is wrong, or STRIPE_WEBHOOK_SECRET does not match that endpoint.
A signed-out visitor presses pay and is sent to sign in. Paying needs a student account.
The wrong processor handles a test. A method with no keys still runs the simulator.

Step 7: Set up live classes

Live classes run on a Jitsi Meet server that you host. The template does not include one, and the hosting cost is yours. Without it, the calendar shows live classes as unavailable. Put the server's details in back-end/.env (the example file lists the variables), and the API issues the tokens that let students and instructors into the room.

An instructor schedules a session from the dashboard, and it appears in the course calendar next to assignment deadlines. Students open it from /en/dashboard/calendar. The room opens shortly before the start time, with a prejoin screen first, and the instructor gets host controls. Ledgerline schedules one session per week per cohort.

Look at how live sessions and assignment deadlines share one calendar, so a student sees the whole week in a single place.

What to check: schedule a session as an instructor, then open the student calendar and confirm the class appears. Open the class page close to its start time and confirm the room becomes available.

What usually goes wrong: the calendar marks classes unavailable because no meeting server is configured, or the room is opened too early. The room opens shortly before the class, not when it is scheduled.

Step 8: Add instructors with the right limits

Students and staff sign in at different endpoints and receive tokens that only their own routes accept. The seed creates six staff roles: Super Admin, Admin, Manager, Editor, Viewer and Instructor. The Instructor role covers live classes, assignments, curriculum, and course editing, plus a read of students, enrollments and reviews.

The key detail is the link between an admin account and an instructor profile. A linked account is also limited to its own courses: it sees only those courses and their students, and any attempt to write elsewhere gets a 403. The seeded emily-davis@learnio.com account shows the setup. Ledgerline creates both instructors this way, and keeps the super admin for the owner.

What to check: sign in as the instructor and confirm the course list shows only that instructor's courses. Then try to change another instructor's course and confirm the change is refused.

What usually goes wrong: an instructor sees too much because the account is not linked to an instructor profile. Or the reverse: a teacher cannot create lessons because the role lacks the curriculum permission. Edit the role on the roles screen and the change reaches signed-in staff.

Step 9: Connect email and, if you want, the AI assistant

Verification links, password resets, receipts and enrollment confirmations go out through Resend, in English and Arabic. Put your RESEND_API_KEY in back-end/.env and verify a sending domain with Resend. Without a key nothing breaks: each message is printed in the API log instead, which is handy while testing.

The admin dashboard also has an AI assistant. It can look up courses, instructors and enrollments, turn a single request into a course draft, including the Arabic title and description, schedule classes and draw registration charts. It runs on a Google, OpenAI or DeepSeek key that you pay for. With no key in back-end/.env, it asks the admin for a key in the browser. Treat what it creates as a draft and review it before publishing.

The chat shows a single request turned into a draft course, which an admin then reviews and edits like any other course.

What to check: trigger a receipt by buying a paid course, then look in your inbox. Ask the assistant for a small draft course and open the result in the course editor to confirm both languages were filled.

What usually goes wrong: email goes nowhere because the key is missing or the domain is not verified. Until a key exists, messages appear in the API log. The assistant also does not work on the admin's offline sample data.

Step 10: Go live

Generate a secret with node -e "console.log(require('crypto').randomBytes(48).toString('hex'))" and use it as JWT_SECRET.
In back-end/.env set NODE_ENV=production, CORS_ORIGIN (list both frontend addresses, separated by commas) and FRONTEND_URL (the student site).
In each frontend's .env set NEXT_PUBLIC_API_BASE_URL with /api on the end, set NEXT_PUBLIC_SITE_URL to the real domain, and rebuild. These values are compiled in.
Set NEXT_PUBLIC_WEBSOCKET_BASE_URL in the admin so live notifications work.
If you use R2, add your bucket's public host as NEXT_PUBLIC_MEDIA_HOSTNAME (or MEDIA_HOSTNAME with Compose) and rebuild.
Change the published demo passwords, or start from empty tables.

For MySQL, create an empty database, set the driver and connection in back-end/.env, and run yarn seed. On a live site, yarn db:sync creates the tables without writing any rows.

What to check after going live: make a real test purchase with a small amount or a discounted course, watch the order settle, confirm the enrollment email arrives, and verify the certificate page opens for someone who is not signed in.

What usually goes wrong:

The API refuses to start with an example JWT_SECRET or an empty CORS_ORIGIN, and prints what to fix.
A frontend still shows the sample data notice, because its API address was missing at build time.
Checkout rejects a purchase from a page in a language the API does not list. Add the language to both sides before opening it.

Running it day to day

After launch, Ledgerline's team works from a handful of screens.

Watching the platform

The overview shows cards and charts for the platform. Admins also receive notifications when a student is given a seat, finishes a course, leaves a review, registers, or when a course is published. An instructor hears only about their own courses.

Marking and replying

Instructors open the submissions waiting to be marked, save a grade, and leave feedback. Students and instructors keep a conversation per course, with history and image attachments, and an unread indicator.

Looking after orders

Each order carries a status of pending, paid, failed or refunded, and a gateway that names the processor, the built-in simulator, or a free course. Revenue figures leave free orders out of the average order value, so a free intro does not drag it down. If you need to add a seat that was paid for elsewhere, an admin can record it by hand.

An order page like this shows the course, the payment method and the payment status in one place.

Moderating reviews

Reviews move through published, pending and hidden. If you set reviews_require_approval to true, new reviews stay pending until someone with moderation rights publishes them. Each change updates the course rating and the instructor rating.

People and recycle bins

Deleting a student, instructor, course, category, review or post moves it to a recycle bin where it can be restored, so a slip is not permanent.

An example launch plan by week

This schedule is an example for Ledgerline, not a promise about how long your launch will take.

Week 1, understand. Run the stack, sign in as each role, and settle the decisions list.
Week 2, brand and first course. Rebrand both apps and build the free intro course in both languages.
Week 3, assessment and payments. Add quizzes, assignments and certificates, then test purchases on the simulator and with Stripe test keys.
Week 4, live classes and staff. Stand up the meeting server, create the instructor accounts, and run a trial class with colleagues.
Week 5, production. Set the production environment, connect email, rebuild the frontends, and make one real purchase.
Week 6, soft launch. Open the free course first, then the paid ones.

Launch checklist

Names, logos, icons and colors replaced in both apps, plus sharing images.
Courses published in both languages, with prices set.
Quizzes have reachable passing scores, and required quizzes are marked.
Stripe and PayPal both configured, with webhook subscriptions in place.
A real test purchase completed and an enrollment email received.
Meeting server running and a trial class held.
Instructor accounts linked to instructor profiles and tested.
JWT_SECRET, CORS_ORIGIN and FRONTEND_URL set for production.
Frontend API addresses, site address and media host set, then rebuilt.
Published demo passwords changed or removed.
Resend domain verified.
Backups planned for the database and the media bucket.
Privacy and terms pages reviewed for your own business.

Template, from scratch, or a hosted course platform

A hosted course platform

You can have a school online quickly, with hosting, video and payments handled for you. The price is ongoing fees, limits on layout and workflow, and student data on someone else's system. It is a good fit when you want to teach and do not need custom behavior.

Building from scratch

You decide everything. You also build accounts for two audiences, a curriculum editor, a lesson player, quizzes, grading, certificates, checkout with webhooks, email, live class tokens and two languages before you teach your first lesson.

Starting from a template

You get those pieces already wired, with source code you own and can change. You host it, update it and fill the gaps that this guide names: a meeting server, your own payment accounts, a mail domain. It fits a school that wants its own brand and rules, or an agency building the platform for a client.

What it costs to run

Learnio packages start from $79 for a single app, and the Full Stack package Ledgerline uses is $179. It comes with a commercial license and lifetime support. The rest is what you switch on:

Hosting for the three apps, and a database if you move past SQLite.
Stripe and PayPal charge their own processing fees. See Stripe's pricing page and the PayPal merchant fees page.
Resend for email, plus a domain you can verify.
A Jitsi Meet server for live classes, with its own hosting cost.
An S3-compatible bucket such as Cloudflare R2 for video and files.
An AI key, only if you use the assistant.

Local work is free. SQLite needs no database server, the checkout simulator charges nobody, and free courses never need a processor.

What to customise next

Categories and the catalog. Set the catalog page size with the courses_per_page setting.
Review moderation. Set reviews_require_approval to true so new reviews wait for a moderator.
Blog. The admin has a blog editor, and the student site publishes the posts. It is a quiet way to bring in search traffic.
Default language. Open in Arabic by setting defaultLocale to ar.
A third language. Add a locale to each app and the API. Course content itself holds exactly two languages.
Roles. Edit what each role may do on the roles screen and the change reaches signed-in staff.

Common mistakes

Skipping the webhook

If students pay and nothing happens, the webhook is the first thing to check. Enrollment follows the processor's confirmation, so a missing subscription leaves orders pending.

Configuring Stripe but not PayPal

The checkout always offers card and PayPal. An order paid through a method with no keys uses the simulator and completes without charging anyone. Configure both before you take real orders.

Expecting live classes without a meeting server

The template provides the scheduling, tokens and room screens. The meeting server is yours to run. No server means the calendar marks classes as unavailable.

Broken course images after connecting a bucket

A frontend shows pictures only from hosts that were listed when it was built. Add your bucket's public host, with no https://, and rebuild.

Treating App Settings as a rebrand

The tab changes the emails only. Names, logos and colors come from files in each app.

FAQ

How do I build an LMS with Next.js?

Start from a template that already covers courses, progress, assessment and payment, then adapt the brand and content. Learnio gives you a Next.js 16 student site, an admin dashboard and a NestJS API that already work together.

Does it support live classes?

Yes, on a Jitsi Meet server that you run. Students and instructors join inside the platform, from a course calendar that also shows deadlines.

Can I use it for clients?

Yes. The license covers unlimited projects, including ones you hand over to a customer. You cannot resell the source code or release it as a template.

Does it support Arabic and RTL?

Yes. All three apps ship in English and Arabic, and Arabic runs right to left. Course content is entered in both languages.

Do I need a backend?

For a real school, yes. The frontends can run alone on sample data, but accounts, payments and progress need the API, which comes in the Full Stack and Backend API packages.

Can I sell courses with PayPal as well as Stripe?

The template includes PayPal integration code and a PayPal webhook route next to Stripe's. Both need your own accounts and keys.

Can I offer free courses?

Yes. A course priced at 0 enrolls the student straight away and never reaches a payment processor.

Can instructors see only their own courses?

Yes. An account linked to an instructor profile is limited to that instructor's courses and their students, and writes outside them are refused.

What happens when a payment fails or is refunded?

The processor's webhook events settle, fail or refund the order. The seat is created only when the payment is confirmed, so a failed payment never grants one.

Can I add another language?

Yes, for the interface. Add the code to the student site's locale list, to the admin's lists and to the API's supported list, then translate the message files. Course content itself holds only English and Arabic.

Try it yourself

Open the student website demo and the admin and instructor demo. Then read the Learnio documentation or visit the Learnio product page. More options are in the education and LMS templates category and the best Next.js templates guide.

Learnio is also one of the ten templates in the Next.js Templates Bundle.

How to Build a SaaS Admin Panel With an AI Assistant in Next.js

Aniq UI — Sun, 18 Oct 2026 20:43:47 +0000

Originally published on the Aniq UI blog.

By the end of this guide you will have an internal admin panel with an AI assistant running on your computer and ready for a server. It is a Next.js dashboard with its own API behind it, and you build it from the Aniq UI Admin Dashboard Template 2 instead of starting from an empty folder.

The steps work for a SaaS admin panel, a back office for a small company, or any internal tool where a team needs lists, roles and a way to ask questions about their own data. To keep it concrete, we walk one made-up company through the whole job, from the first download to a live address, and we stop at every point where something usually goes wrong.

About this example

Larkspur Software is an illustrative business we use to show the steps. It is not a client story, and the numbers in it are examples, not results.

Before you start: decisions to make

Most of the pain in an internal tool comes from choices made late. Settle these six before you open a terminal, and the rest of the guide goes faster.

Who signs in, and what may each person do? Write the list of roles on paper first. The template ships five (Super Admin, Admin, Manager, Editor, Viewer) and you can reshape them, but it is easier to reshape with a plan.
What are your records? The template comes with users, projects, tasks and app settings. If your business revolves around something else, such as orders or tickets, decide now whether you will rename what exists or add a new module to the API.
Which languages? English and Arabic ship. A third language is possible but is more work, so know before you start whether you need it.
Who pays for AI? Either the company holds one provider key on the server, or each person brings their own. The choice changes your bill and your privacy story, and step 8 covers both.
Where will it run? A single small server using Docker, or Vercel for the dashboard with the API on a Docker host. Pick the shape early so you set the right addresses once.
Which database? SQLite is the default and needs no setup. MySQL is a configuration change. A host without a persistent disk is the usual reason to pick MySQL.

The brief

Larkspur Software is a small agency that builds web apps for other companies. The office needs one place to run its work. Here is what the team asks for:

A sign-in for staff, with different levels of access: the owner sees everything, developers edit projects, contractors only read.
A list of every client project, with its status, its environment (staging or production) and its current version.
A list of client accounts, with a quick way to find the ones who never verified their email.
An assistant that answers plain questions such as "which projects are blocked?" and shows the answer as a table or a chart.
English and Arabic, because two client teams read Arabic.
A first run on a laptop, then a small server on the agency's own domain.
Control over who can use the assistant, since it can change records and the AI provider bills for usage.

How the template covers the brief

Need	Where it lives	What you use
Staff with different access	Dashboard and API	Admin Management and Admin Roles screens; permissions named like projects.edit
Client project tracking	Dashboard and API	Projects screen with status, environment, version and an English and Arabic name
Client accounts	Dashboard and API	Users and Deleted users screens, filters, verify and restore actions
Plain-language questions	Dashboard and API	AI Assistant screen, with a provider key from you
English and Arabic	Dashboard	/en and /ar addresses, message files under messages/
Laptop, then a server	Docker and configuration	Docker Compose, .env files, a web server in front
Control over the assistant	API	The ai_chat.use permission on a role

`` ``

Template, from scratch or a hosted builder

There are three honest ways to get an admin panel with an AI assistant, and each fits a different team.

From scratch. You get exactly the structure you want and nothing extra. You also build sign-in, roles with live updates, filtered lists, a chat interface that renders tables and charts, and the API behind all of it. This suits teams with an unusual product and plenty of engineering time. For everyone else it means a long stretch spent on screens that every admin panel needs.

A hosted builder. A low-code or internal-tool service gets you a working screen quickly and handles hosting for you. In exchange you work inside its component set and its pricing model, and moving away later usually means rebuilding. Check what it charges per user, what you can export, and whether it supports right-to-left layouts before you commit.

A template with source code. You start with finished screens, a working API and an assistant, and you own the code. You pay once for the template, host it yourself, and change anything you like. The cost is that you must be comfortable with Next.js, and later with NestJS if you extend the API. The license does not let you publish or resell the source, but it does cover unlimited projects, including ones for clients.

Larkspur has developers on staff and wants to keep client data on its own server, so it takes the template route. If nobody on your team writes code, a hosted builder is the more realistic choice.

An example launch plan by week

This is a sample schedule for Larkspur, not a benchmark. Your own pace will differ.

Week 1, get it running. Download the ZIP, start it with Docker, click through every screen, and try both sample accounts. Decide the six questions above.
Week 2, make it theirs. Brand it, rebuild the roles, create the real staff accounts, and delete the sample admins.
Week 3, load the work. Enter real projects and client accounts, add provider keys, and let two or three people use the assistant with real questions.
Week 4, harden and ship. Set production environment values, deploy to the server, check the health address, and walk through the launch checklist near the end of this post.

Step by step

1. Choose the package

The template comes in three packages. The Full Stack package holds the dashboard and the NestJS API. The Admin Dashboard package is the dashboard alone, running against a small mock server built into it, with the sample records stored in your browser. The Backend API package is the API alone.

Larkspur wants real data and a real assistant, so it takes Full Stack. If you only want to design screens first, the Admin Dashboard package is enough, and you can point it at an API later. If you already have a front end and only need the server, the Backend API package gives you the routes, the roles logic and the assistant's tools.

Check: after the download, your account should show a ZIP named for the package you bought. Usually goes wrong: buying the dashboard package and expecting an API in it. The dashboard alone cannot store anything outside the browser.

2. Run it locally with Docker

Install Docker Desktop (or Docker Engine on Linux) and nothing else. Then work through these sub-steps.

2a. Download. Open My templates in your Aniq UI account and download the Full Stack ZIP.

Look at which package is chosen on the download page, because the folder names in the later steps depend on it.

2b. Unzip and open the folder. Unpack the archive and start a terminal inside the dashboard-2-full-stack folder (on Windows, unpack it with File Explorer first).

Look at the folder contents: you should see back-end, front-end and docker-compose.yml side by side.

2c. Start both apps.


bash
docker compose up --build

On the first start Docker builds two images and seeds the database, so give it a few minutes. Later starts take seconds.

Look at the terminal: it prints build progress first, and the dashboard waits until the API reports itself healthy.

2d. Open it. Go to localhost:3030 and use the account admin@example.com with the password Admin@123. Arabic lives at /ar. The API answers at localhost:8000/api/health once its database is ready.

What to check: the health address should answer, and the dashboard should list data on its first screen. What usually goes wrong: a port is already in use. If another program holds 3030 or 8000, create a file named .env next to docker-compose.yml and set DASHBOARD_PORT=3040 (or API_PORT for the API), then run the same command again. A start that seems stuck is normally still seeding sample data.

To stop the apps, press Ctrl+C. Your data stays in a Docker volume. Be careful with docker compose down -v: the -v deletes the volume, and the next start brings back fresh sample data.

3. Know the other ways to run it

You will not use all of these, but each solves a real situation.

The dashboard alone. With the Admin Dashboard package, you build one image and start one container. With no API address set, it runs on its mock server and needs no back end.

Look at the folder name in the terminal: this package extracts to a different folder than the Full Stack one.

Look at the build output: the dependencies and the build both happen inside the image, so the first build needs an internet connection.

The API alone. With the Backend API package, you build an image and run it with a volume that holds the database file. The first run seeds that database with the sample records and accounts. Every route sits under /api, and you check it with the health address.

Look at the files in the folder, which include a Dockerfile, package.json and .env.example.

Look at the image being built: the API image is separate from the dashboard's.

Look at the health check at the end: a working API answers with an ok status.

Without Docker. Install Node.js 22.9 or newer and run corepack enable once. Start the API first, because the dashboard reads all its data from it. In back-end, copy the example settings, create the database with yarn seed, then run yarn dev. In front-end, copy the example settings and start it the same way.

Look at the first terminal, which runs the API.

Look at the second terminal, which runs the dashboard against the API from the first.

The same approach works for the single-app packages.

Look at how little is needed here: no .env file means the mock server answers.

Look at the API terminal staying open while you use it.

What usually goes wrong: a Node.js older than 22.9, which makes yarn dev fail on reading .env; a Yarn that answers with version 1.22 because Corepack is off; and a dashboard that shows sample data even though you meant to use your API, because the API address was missing when it was built.

4. Explore the sample data before you change anything

The seed loads a small company's worth of records: a dozen admins, five roles carrying 25 permissions, 15 users, 15 projects, 10 tasks and 13 app settings, plus some deleted users and projects to practise restoring. Click through the sidebar from top to bottom, ending on the page that lists every UI component.

Look at how the sidebar groups the screens, since you will rename and prune this menu later.

Look at the top of the overview: key figures, charts, a calendar and quick tasks share one screen, and the widgets can be rearranged.

Then sign out and sign in as john.smith@admin.com with the password admin123. This account has the Viewer role. It can read every list but cannot create, edit or delete anything, and it cannot open the assistant. Seeing that difference early tells you how the permission system behaves, which matters for step 6.

What to check: you can explain, in one sentence each, what Super Admin and Viewer can do. What usually goes wrong: people edit sample records first and then forget which data is real. Keep the sample data untouched until you are ready to replace it in bulk.

5. Put the agency's name on it

All branding sits in the dashboard folder (front-end in the Full Stack package). Run yarn dev there while you edit and the page reloads on every save. Four places matter most:

src/config/brand.config.ts holds BRAND_CONFIG: the name, the company, the page metadata and the installed-app details, in English and Arabic.
public/assets/images/logo-for-lightmode.png and logo-for-darkmode.png are the two logos. Replace the files and keep the names.
src/styles/theme-variables.css defines every colour once for light and once for dark. The brand colour is --primaryColor.
messages/<namespace>/en.json and ar.json hold every word on screen. Edit both languages together.

Larkspur changes the name, swaps both logos and picks one new primary colour. That is enough for the dashboard to feel like theirs. Components read colours through variables such as bg-[var(--surface)], so any component you add later keeps both themes if it does the same.

Look at the component page: it is the quickest way to see your new colour on every kind of control at once.

What to check: switch between light and dark in the header, then open the component page in both. What usually goes wrong: a logo with a baked-in background colour that looks wrong in one theme. Export both logos with transparent backgrounds.

6. Set up staff and roles

The seed ships five roles: Super Admin, Admin, Manager, Editor and Viewer. One person can carry more than one role, and they receive the combined permissions of all of them. Permissions are named module.action, for example users.view, projects.edit or settings.edit, and there are 25 of them across admins, roles, users, projects, settings and the assistant.

Larkspur maps its team like this: the owner stays Super Admin, the two project leads become Manager, developers become Editor, and contractors become Viewer. Do it in three passes:

Open Admin Roles and read what each role grants. Rename or trim until the roles match the paper plan.
Open Admin Management and create each real person, then assign their roles.
Sign in as one person per role and try the actions that role should and should not have.

If you change a role while someone is signed in, their menus and buttons update without a reload, because the API tells their dashboard over a WebSocket.

Look at the role chips on each account: they show at a glance who holds which role.

Look at how permissions are grouped by module, which makes it easy to grant "view" without "edit".

Before anything else, change the passwords of the sample admins under Settings, Security, or delete those accounts. The seed creates them with passwords printed in the public documentation, and the template's guides warn about this more than once for good reason.

What usually goes wrong: deleting the Super Admin before another admin can manage roles, or giving the Admin role to everyone because it is easier. Start strict and loosen when someone asks.

7. Load projects and client accounts

Open Projects and replace the sample rows with Larkspur's real work. A project carries a name and description in English and Arabic, a status (in-progress, ready or blocked), an environment, a version and an optional picture. Deleting is a soft delete: deleted projects move to their own screen and can be restored.

Users work the same way. You can narrow the list by username, email, phone, name or join date, and the top of the page counts verified, unverified and deleted accounts. For Larkspur, that is the screen for client staff who got an invitation and never confirmed it. The resend-verification route answers success but sends no mail, so connect your own mail service before you rely on it.

Look at the counts above the table and at the status chips on each row.

If your own product has other records, the API is plain REST under /api, so you can add modules beside the existing ones. Sign in with POST /api/auth/login to get the token every other call needs, and send it as a bearer token. Lists take page and page_count, capped at 100 per page.

What to check: create a project in English and Arabic, reload, and confirm both names appear when you switch language. What usually goes wrong: filling only the English name, which leaves the Arabic list with an empty label.

8. Turn on the AI assistant

The assistant is its own screen. You type a question in English or Arabic and the answer is built from the dashboard's data, drawn with the same stat cards, tables, lists, donuts and charts the rest of the panel uses. It can also act: add, change, remove or bring back users, and adjust app settings. It does this only inside the permissions of the person asking.

It runs on Google Gemini, OpenAI or DeepSeek, chosen in a model picker. Conversations are saved per admin in a history sidebar. You have two ways to supply a key:

Put the provider's key in back-end/.env and restart the API (with Docker Compose, run docker compose up again). Then everyone with access uses your key.
Leave the server without a key. The assistant then asks each person for their own, and it stays in their browser.

Larkspur starts with the second option, so nobody's usage lands on the agency's bill by accident. The docs say Gemini works with free keys, while OpenAI needs billing enabled on the key. A free key can run out of quota, and the assistant says so; pick another model or wait.

Control access with the ai_chat.use permission. Because the assistant can write, give it only to roles you would trust with those writes. Contractors on the Viewer role get none.

Look at how the reply mixes a written summary with a chart built from the dashboard's own numbers.

Two optional extras exist. A Cloudflare R2 bucket lets people upload profile pictures and image attachments; without it, uploads answer that they are not set up and everything else works. An MCP key you choose switches on the API's MCP endpoint; without one, that endpoint refuses every request.

What to check: ask three questions you already know the answer to, such as how many projects are blocked, and compare. What usually goes wrong: the "asks for an API key" dialog, which only means the server has no key for the model you picked. Paste your own, or add the provider's key to the server file and restart.

9. Check Arabic and the other language details

Open /ar. The page sets lang="ar" and dir="rtl" before it draws, so the sidebar moves to the right and tables and menus read right to left. The API also answers in Arabic when a request sends Accept-Language: ar, and projects, settings and countries carry both languages in the database.

Anything you add should use logical Tailwind classes such as ms-2, pe-4, start-0 and text-start instead of ml-*, pr-*, left-* or text-left, or the Arabic page comes out wrong. If a third language is ever needed, you add its code in three locale lists, copy each en.json file under the new code, and add it to the language menu. The API keeps answering a new language in English until you add its translations in back-end/src/i18n/.

What to check: walk every screen you changed in Arabic, including the assistant. What usually goes wrong: a text added to en.json only, so the Arabic page shows a missing key.

10. Go live on a server

The same docker-compose.yml that ran on the laptop also runs on a server. Give the dashboard and the API each a domain behind Caddy or Nginx, which adds HTTPS, and route the first domain to port 3030 (the dashboard) and the second to port 8000 (the API).

Create .env beside docker-compose.yml and set DASHBOARD_URL and API_URL to the two public addresses. The dashboard bakes the API's address into its built code, and the API takes the same two lines for CORS_ORIGIN and FRONTEND_URL. Put your AI keys and TRUST_PROXY=1 in back-end/.env. Then start it in the background:


bash
docker compose up --build -d

In production the API refuses to start with the example JWT_SECRET or an empty CORS_ORIGIN. With Docker it generates a secret for you and keeps it in the data volume, or you can make your own:


bash
node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"

When it is up, open https://api.your-domain.com/api/health (with your own domain) and look for "status":"ok". If you prefer, the dashboard alone can go to Vercel from a private Git repository: set ENABLE_EXPERIMENTAL_COREPACK to 1, then NEXT_PUBLIC_API_BASE_URL, NEXT_PUBLIC_WEBSOCKET_BASE_URL and NEXT_PUBLIC_BASE_URL. Redeploy after changing any NEXT_PUBLIC_* value, because it is compiled in at build time. Leave NEXT_PUBLIC_DEMO_MODE off unless the site is a public demo.

The default database is SQLite, kept in the /data volume. MySQL is a configuration change: create an empty database, set DB_TYPE and the connection in back-end/.env, and seed it. Pick MySQL if your host has no persistent disk. If you run the API without Docker in production, yarn seed:prod creates the tables once; run it a single time, because a second run resets app settings and the built-in roles' permissions to their sample values.

What to check: sign in from a different computer, change a role, and watch a second signed-in session update. That proves the WebSocket address is right. What usually goes wrong: empty pages with a CORS line in the browser console. The API only answers browsers from the addresses in CORS_ORIGIN, so add the dashboard's real address there and to FRONTEND_URL.

Running it day to day

Once Larkspur is live, the work becomes small, repeatable routines.

Onboarding a person. Create the admin in Admin Management, assign one role, and send them the address. Do not share the Super Admin account.
Offboarding. Delete the admin account the same day. Because roles update live, you can also strip a role from someone who is still signed in and their buttons disappear without a reload.
Changing what a role may do. Edit it on the Admin Roles screen and tell the team. Test with a real account for that role.
Restoring mistakes. Users and projects are soft deleted. Open the matching Deleted screen to bring one back.
Backups. With SQLite in Docker, the data lives in one volume. Back that volume up on a schedule that suits how often records change. With MySQL, use your database host's backup tool.
Updating. After you change code, build the images again, because a running container is a snapshot of the code at build time.
Watching the assistant. Review who has ai_chat.use now and then.

What it costs to run

The template is a one-time purchase from $99, and the package matters: the Full Stack package that this guide uses costs more than the entry price, and the product page lists each one. The licence covers an unlimited number of projects, client work included, as long as you do not share the source code publicly.

Beyond that, you pay for what you add:

Hosting for the dashboard and the API. A Docker-capable server runs both; Vercel can host the dashboard alone.
AI usage, if you put a provider key on the server. Google, OpenAI and DeepSeek bill by their own pricing pages. If each person brings their own key, the bill is theirs.
A Cloudflare R2 bucket, if you want picture uploads, and a WeatherAPI.com key if you want the weather in the greeting. Both are optional.
A domain name and, if you use it, a mail service for verification emails.

What is free: local development on SQLite, the sample data, the built-in mock API in the dashboard package, and every optional feature you leave switched off.

What to customise next

Roles that match your company. Rename the five roles and trim their permissions until each one grants only what the job needs.
Your own records. Add a module to the NestJS API for something Larkspur tracks that is not a project, such as invoices or support tickets, and a screen to match. Each domain in the API has its own module, so a new one slots in beside the others.
New assistant tools. The assistant routes through an MCP registry that is built to be extended, so you can teach it questions specific to your data.
A third language. Copy the message files, add the code to the three locale lists, and add the API's translations.
Cleaner production code. Once your own API is the permanent source of data, the yarn remove:mock script deletes the built-in mock server, and yarn remove:demo removes the public-demo switch. Commit first, since both rewrite files.

Launch checklist

Sample admins deleted or their passwords changed.
Your own JWT_SECRET set, or Docker's generated one confirmed in the data volume.
CORS_ORIGIN and FRONTEND_URL hold the dashboard's real address.
NEXT_PUBLIC_API_BASE_URL points at the API with /api, and the dashboard was built after you set it.
HTTPS in front of both the dashboard and the API.
The health address answers "status":"ok".
Every role tested with a real account.
ai_chat.use granted only where intended, and provider keys placed where you decided.
Arabic checked on every screen you changed.
Data volume or database backup scheduled.
Demo mode off.

Common mistakes

Going live with the sample admins

Every seed creates admins with published passwords. Change them or delete them before anyone else can reach the panel, and set your own JWT_SECRET.

Editing a NEXT_PUBLIC value and expecting a change

Those values are compiled into the dashboard when it is built. Rebuild (or restart yarn dev) after any edit, and never put a secret in one: anyone can read them in the browser.

Wiping data with the wrong stop command

docker compose down keeps your data. Adding -v removes the volume, and everything you created goes with it.

Pages stay empty and the console mentions CORS

The API only answers browsers from the addresses in CORS_ORIGIN. If the dashboard runs on a new domain or port, add it there and in FRONTEND_URL.

Handing the assistant to everyone

The assistant can change users and settings. Grant ai_chat.use to the roles that should have that power and nobody else.

Passing the example environment file to Docker

The API image runs in production mode. If you start it with a copy of the example environment file, that file sets development mode over the image's own value. Pass each value you need with -e instead.

FAQ

How do I build an admin panel with an AI assistant in Next.js?

Start from a dashboard that already has the roles, lists and chat screen, then connect your data and a model provider. In this template, the assistant reads from the same API as the rest of the panel, so you add a key and your records instead of writing chat plumbing.

Do I need a backend?

Only for real data. The Admin Dashboard package runs on a mock server inside the browser, which is enough for design work. For a live panel you need an API, and the Full Stack package includes a NestJS one.

Which AI providers does the assistant support?

Google Gemini, OpenAI and DeepSeek, picked from a model list. Each person can paste their own key, or you can set one key on the server.

Does it support Arabic and RTL?

Yes. Every screen, including the assistant, exists in English and Arabic, and the Arabic pages are laid out right to left.

Can I use it for clients?

Yes. The commercial licence covers unlimited projects, including work you build for a client and hand over. You may not publish the source code or resell it as a template.

Can I change what the assistant is allowed to do?

You decide who may use it through the ai_chat.use permission, and the assistant acts only within that person's own permissions. Adding new tools is done through its MCP registry in the API.

Can I try it without installing anything?

Yes. The live demo runs the same dashboard. For your own machine, the Admin Dashboard package runs on its built-in sample data with no API or AI key at all.

Can I remove the sample data and the mock server?

Yes. Two scripts, yarn remove:mock and yarn remove:demo, strip the mock server and the public-demo switch from the code. Commit first, since they rewrite files.

Try it yourself

Open the live demo to click through the dashboard and the assistant. The Admin Dashboard Template 2 product page lists the packages, and the documentation covers every step above in detail. More options live in the admin dashboard templates category, and the guide to admin dashboard templates by industry helps if your use case differs from this one.

This template is also one of the ten in the Next.js Templates Bundle, if you expect to build more than one kind of product.

How to Build an Online Store with an Admin Panel in Next.js

Aniq UI — Sun, 18 Oct 2026 20:42:57 +0000

Originally published on the Aniq UI blog.

By the end of this guide you will know how to build an online store with an admin panel, using Next.js, NestJS and the e-commerce template from Aniq UI. You will have a storefront, an order desk for your team, and an API that holds the catalogue, customers and orders.

We follow one example shop from its first plan to launch day. Each step names the screen or setting involved and uses the exact commands and file paths from the documentation. The same path works for a founder launching a store, or an agency building one for a client.

About this example

Cedar & Cloth is an illustrative business we use to show the steps. It is not a client story, and the numbers in it are examples, not results.

The brief

Cedar & Cloth is a small shop that sells linen shirts and canvas bags. The owner runs it with two people who pack orders. Here is what the shop needs:

A catalogue of about thirty products, each with sizes and colors, written in English and in Arabic.
Guest checkout, so a first-time visitor can buy without making an account, and track the order afterward.
Payment by card, or cash on delivery for customers who prefer it.
Free shipping above a set order total, and a flat fee below it.
An order desk where the owner has full control and the packers can only view orders.
A home page the owner can rearrange without touching code.
Clean product photos on a plain background, made from phone shots.
A way to see where visitors come from, using Google Analytics.

How the template covers the brief

Need	Where it lives	What you use
Bilingual catalogue with variants	Admin dashboard and API	Products and Categories screens, with size and color variants
Guest checkout and tracking	Storefront	The checkout page and Track Order, which asks for order number and email
Card or cash on delivery	Storefront and API	Stripe for cards, cash on delivery selected by default
Shipping rule	Storefront and API	A shipping config file and the orders service, kept in sync
Order desk and permissions	Admin dashboard	Orders, Admin Management and Admin Roles
Editable home page	Admin dashboard	The Home Page screen, section by section
Product photos	Admin dashboard	The product form's AI studio and background removal
Visitor analytics	Storefront	Tag ids pasted into the storefront's environment file

Before you start: decisions to make

A store touches money, customers and legal duties, so a few decisions are worth making before you write a line of configuration.

What exactly are you selling?

Count your products, and for each one decide which options a shopper chooses: size, color, or neither. Variants carry their own SKU, price adjustment and stock, so the shape of your catalogue decides how much data entry you face. Cedar & Cloth sells shirts in several sizes and colors and bags in one size.

Which languages will you sell in?

English and Arabic ship ready, including a right-to-left layout. Products and categories hold a name and description in both. A third language is possible for the interface, but it takes edits in several files.

How will shoppers pay?

Shoppers can pay by card (Stripe) or choose cash on delivery, and PayPal is not part of the checkout. Stripe charges in US dollars. If you sell in another currency, that is a decision to settle before launch, not after.

What about shipping and tax?

The template ships one shipping rule: free from a set order total, a flat fee below it. It applies no tax. If your business must charge tax, plan for that in code or in how you price products.

Guests, accounts, or both?

Both work. Guests check out with an email and track orders by number and email. Customers with accounts also get saved addresses, order history and a wishlist.

Who handles email?

The template sends none: no confirmations, no shipping notices, no password resets. Choose a mail provider early, because customers expect at least an order confirmation.

Which AI tools, if any?

Each one needs its own key, and some need the media bucket. Decide which are worth turning on for launch. A shop that only needs clean product photos can enable background removal and nothing else.

Step by step

Step 1: Choose the package

The template has four packages: Full Stack (storefront, admin and API), Storefront alone, Admin Dashboard alone, and Backend API alone. The two frontends can each run by themselves on a built-in sample store inside the browser. That is useful for a design pass, but real orders, payments and AI features need the NestJS API.

Cedar & Cloth takes the Full Stack package. The commercial license covers unlimited projects, including stores you build and hand over to a client.

The My templates page lists a ZIP for each package, so choose the one you bought.

What to check: the Full Stack ZIP extracts to e-commerce-1, containing admin-dashboard, back-end, storefront and docker-compose.yml. Single-app packages extract to their own folder with a Dockerfile, package.json and .env.example.

Step 2: Run it locally with Docker

Download the ZIP from My templates, unzip it, and open a terminal in the e-commerce-1 folder. Start Docker, then run:

docker compose up --build

Docker builds three images on the first run and loads a demo store into the database, so expect a few minutes. The storefront opens at localhost:3030, the admin at localhost:3031, and the API at localhost:8000. A busy port can be moved with SITE_PORT, ADMIN_PORT or API_PORT in a .env file next to docker-compose.yml.

Sign in to the admin as the Super Admin (admin@example.com, password Admin@123) and to the storefront as a demo customer (john.doe@example.com, password password123). A read-only staff account, john.smith@admin.com with admin123, shows what the Viewer role sees. Place a test order as the customer, then find it in the admin.

One honest note: on the admin overview, several cards (revenue, sales, goal, visitors, conversion and the map) display placeholder figures until you connect your own numbers. Check which cards are wired to real data before you rely on them.

This still shows a terminal opened inside the extracted folder, which is where each command should run.

Look for the API passing its health check, since the two frontends start only after it does.

The Node.js route starts with the API, after the seed has created the database and demo store.

The admin dashboard runs in its own terminal on port 3031, beside the storefront on 3030.

The screenshot above is the admin overview you should see after signing in as the Super Admin.

What to check: open localhost:8000/api/health, which should answer with a status of ok. Then add a product to the cart as the demo customer, check out as a guest, and find the order in the admin.

What usually goes wrong:

Docker is not running, or port 3030, 3031 or 8000 is taken. Free it, or set SITE_PORT, ADMIN_PORT or API_PORT to a free number.
The first start seems stuck. It is seeding the demo store, and the frontends start only when the API is healthy.
A "Sample data" notice shows. The frontend was built without an API address and is running on its own sample store.
Yarn reports version 1.22. Run corepack enable and install again.

Step 3: Make it Cedar & Cloth

The brand lives in files, and the storefront and the admin keep their own copies. In the storefront, src/config/brand.config.ts holds the store name (it ships as a text wordmark), the browser tab name, the contact details and the social links, each with English and Arabic values. Set NEXT_PUBLIC_SITE_URL to your real domain, because canonical links, the sitemap and sharing cards use it.

The shipped copy describes a menswear shop. Three places carry that copy: the text blocks in brand.config.ts, the messages/home/ folder for the home page, and messages/seo/ for page titles. Cedar & Cloth sells menswear too, so it edits less than most shops will.

Each app keeps its colors in src/styles/theme-variables.css, as CSS variables, with a block for light and a block for dark. The accent is --primaryColor. The storefront loads Plus Jakarta Sans for Latin text and two Arabic fonts. The admin has its own brand file and uses the system font stack.

What to check: rebuild, then look for the old name in the browser tab, the footer, the sharing preview and the Arabic pages. Replace the placeholder contact details, since they ship as placeholders.

What usually goes wrong: the footer shows no social icons, because the links ship empty and only filled ones appear. Another is a sharing image that still shows the template's hero photo. Point meta.ogImage at your own picture.

Step 4: Add categories and products

Start with categories: a name and description in both languages, plus an image, a slug, a sort position and an on/off switch. They are one flat level. Then add products. A product takes:

A name and descriptions in both languages (only the English name is mandatory), a slug, a SKU and a category.
A price, an optional compare-at price, a cost price and a stock count.
Up to 12 images and videos in any order, one marked primary, each with alt text.
Variants such as Size with M, or Colour with its hex code. Each variant has its own SKU, price adjustment and stock.
Flags for active, featured and best seller, and free tags.

Uploads go to a Cloudflare R2 bucket, or another S3-compatible store, and fail with a 503 until you fill in the five R2_* variables in back-end/.env. The demo catalogue itself renders from bundled files, so you can build the whole flow before you set a bucket.

Work in this order, so nothing points at something that does not exist yet:

Create categories first, since every product needs one.
Add one complete product, with photos, variants and both languages, before you add the rest.
Open it on the storefront in English and Arabic and check the gallery, the variant picker and the price.
Only then repeat for the remaining products.

Look at the flat list of categories with their order and active switch: the sort order here shapes the categories row on the home page.

The compact view fits more rows on screen, which helps when you are checking stock and prices across many products.

What to check: deleted products have their own list, so check where one lands after you remove it. Variant SKUs must be unique, so use a clear naming pattern from the start.

What usually goes wrong: uploads fail with a 503, because the bucket variables are not set. Or images load at full size, because the frontends were not told your bucket's public host. Set NEXT_PUBLIC_MEDIA_HOSTNAME to that host, without https://, and rebuild.

Step 5: Arrange the home page

The Home Page screen in the admin decides, one section at a time, what shoppers see on the storefront's front page. Categories need only an order. The other sections take a capped number of products or texts: up to 3 style pillars, 2 editorial panels, 6 new drops, 8 best sellers, 6 spotlight items and 5 slides in the closing slider. If New drops is empty, it shows the newest products. Editing a section needs the products.edit permission.

What to check: add a product that uses every section, then open the storefront home page and confirm each section shows what you picked. Empty the New drops section and confirm it falls back to the newest products.

What usually goes wrong: a change does not appear because you lack the products.edit permission, or because the storefront is on its sample store and not reading the API.

Step 6: Set shipping, payments and the order flow

The checkout offers card through Stripe, and cash on delivery. Cash on delivery is selected by default, and the API always prices an order from its own catalogue, never from numbers the browser sends. There is no PayPal option.

The shipping rule ships as free from $75 and $9.99 below that, with no tax. It is written in two places, storefront/src/config/shipping.ts and back-end/src/modules/orders/orders.service.ts. Edit both in one change, or the cart and the charge will disagree.

To take cards, use Stripe test keys first:

Add both STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET to back-end/.env.
Put NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY in the storefront's .env and rebuild.
In the Stripe dashboard, create a webhook endpoint that points to your API address plus /api/payments/webhook, and have it listen for two events: payment_intent.succeeded and payment_intent.payment_failed.

A card order stays pending until Stripe calls that webhook, then becomes paid and confirmed. For local testing, the Stripe CLI can relay events to http://localhost:8000/api/payments/webhook. In the admin, an order moves one step at a time: pending, confirmed, processing, shipped, delivered, or cancelled before it closes. Add the tracking number when you ship, and download any order as a CSV file.

What to check: place a cash on delivery order and a card order with Stripe test keys. The first should be confirmed and unpaid. The second should be pending until the webhook arrives, then paid and confirmed. Fail a card on purpose and confirm the order is marked failed.

What usually goes wrong:

The card option is missing at checkout. The publishable key is empty or not a real test or live key, which leaves cash on delivery as the only choice.
Card orders stay pending. The webhook endpoint or its signing secret is wrong.
The storefront still shows the old publishable key. It is compiled in, so rebuild after changing it.

Step 7: Add staff and set their permissions

Staff accounts live under Admin Management, and their permissions under Admin Roles. The seed gives you a Super Admin with every permission and a Viewer role with every view permission, which leaves out the AI assistant. The Admin, Manager and Editor roles exist but start with nothing, so tick their permissions before you give them to anyone.

Cedar & Cloth keeps the owner as Super Admin. For the two packers it gives view access to orders, plus the edit permission that moving an order forward requires. Everything else stays hidden from them, because the sidebar and the API check the same permission names.

What to check: sign in as the Viewer account and confirm it can see lists but not change them. Then sign in as the packer role you created and confirm moving an order forward works.

What usually goes wrong: a new staff member sees almost nothing, because their role has no permissions ticked. Permission changes reach signed-in staff over a live connection, so they do not need to sign out.

Step 8: Add the AI tools you want

Each AI feature switches on only when its key is in back-end/.env, and a key still holding its example value counts as unset.

Admin assistant: needs a Google Gemini key. It answers questions about the shop, finds orders, edits products and stock, and draws sales charts, all within the signed-in admin's permissions.
AI product studio: in the product form. Its assistant mode needs a Gemini key and the media bucket. Its Animate mode needs a Higgsfield key and secret.
Fitting room: lets shoppers see a product worn on a model or on their own photo. It needs a Gemini key and the bucket.
Background removal: needs a model file on your own server and the bucket, but no key, and it costs nothing per image.

Cedar & Cloth turns on only background removal, so the phone shots become clean catalogue photos. The Docker image leaves the model out unless you ask for it when you build. Provider charges for the keyed features are yours.

What to check: open the AI Assistant page and ask for a sales summary. Confirm the answer comes with a chart drawn from your own data. For background removal, open a product photo and confirm the Remove background button appears.

What usually goes wrong: a feature reports itself off. Either its key is missing or still holds the example value, or it needs the media bucket as well. The studio, the fitting room and background removal all need the bucket. Also remember that the assistant and the studio are unavailable on the sample store.

Step 9: Wire up analytics

Six ad and analytics networks are built into the storefront. Paste an id into storefront/.env and rebuild. A blank id loads no script. The variables are NEXT_PUBLIC_GTM_ID, NEXT_PUBLIC_GA4_MEASUREMENT_ID, NEXT_PUBLIC_META_PIXEL_ID, NEXT_PUBLIC_TIKTOK_PIXEL_ID, NEXT_PUBLIC_SNAPCHAT_PIXEL_ID and NEXT_PUBLIC_PINTEREST_TAG_ID.

If you set only one, make it Google Tag Manager, which can load the others itself. If GA4 already runs inside your Tag Manager container, leave the GA4 variable blank, or every session counts twice. The storefront reports page views, product views, add to cart, begin checkout, purchase, search and sign-up. Set NEXT_PUBLIC_ANALYTICS_DEBUG=true to log each event in the browser console while testing.

The tags load as soon as a page does. If you sell to the EU or the UK, show a consent banner before they run.

What to check: turn on debug logging, click through a purchase and watch the events appear in the browser console in order: product view, add to cart, begin checkout, purchase. Then confirm the same events in Tag Manager's preview or your analytics tool.

What usually goes wrong: a change to an id has no effect, since ids are compiled in and need a rebuild. Or the purchase event fires without the right currency. Set NEXT_PUBLIC_ANALYTICS_CURRENCY if you do not sell in US dollars.

Step 10: Go live

Fix the gaps the template leaves open, then deploy:

It sends no email at all: no order confirmation, no shipping notice, no password reset. Connect a mail provider in the forgotPassword hook of back-end/src/modules/customer-auth/customer-auth.controller.ts and for orders.
Both the contact form and the newsletter signup acknowledge the visitor yet deliver nothing, and no terms or privacy pages come with the template. Connect the forms and write the pages.

Then configure the API in back-end/.env: a fresh JWT_SECRET (made with node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"), NODE_ENV=production, CORS_ORIGIN listing the storefront and admin addresses, and FRONTEND_URL set to the admin's address. Build the API, run yarn db:sync:prod once to create the tables, and start it. In each frontend set NEXT_PUBLIC_API_BASE_URL with /api on the end and rebuild. Set NEXT_PUBLIC_STOREFRONT_URL in the admin so its Go to storefront link works.

Do not use yarn railway:setup for a live shop: it drops every table each time it runs. Change the published demo passwords, or start from empty tables.

What to check after going live: place a real small order on your domain, watch it appear in the admin with a notification, move it through its statuses, and track it as a guest with the order number and email. Confirm the notification bell is live, which means the admin's address matches FRONTEND_URL.

What usually goes wrong:

Browsers are blocked by the API. CORS_ORIGIN must list both frontends exactly as the browser shows them.
Everyone gets "Too many attempts" behind a proxy. Each of those routes (sign-in, registration, password reset, guest tracking) accepts ten requests a minute from one address. Set TRUST_PROXY to how many proxies stand in front.
Password reset goes nowhere. In production the reset token is not delivered until you connect a mail provider.

Running it day to day

When the shop is live, the owner and packers use a short list of admin screens.

Starting the day on the overview

The overview sits at the top of the sidebar and shows the shop at a glance. Remember that several cards display placeholder figures until you connect real numbers, so keep a separate, trusted source for revenue until you do.

Look at the latest orders and the bell in the top bar, which is where new activity shows first.

Moving orders along

Filter the list by order status or payment status; the newest orders come first. Open an order, check the items, totals and addresses, add the tracking number when it ships, and move it forward one step. Cancel only before the order is closed. The payment status is set by the payment, never by hand.

The fulfilment progress on each row shows how far an order has moved, so packers can scan for what is still waiting.

Helping a customer

The customers screen lists the shop's customers, and deleted ones have their own list. A customer who cannot track an order needs the exact order number and the email used at checkout, because tracking asks for both.

Use this list to find a customer by account and open their record when they write to you.

Keeping the storefront fresh

Rearrange the home page sections when you launch a new product, add an offer, or want a best seller pushed forward. Those edits are made in the admin, so they need no code change.

Settings are stored values

The App settings tab holds key and value pairs, including payment, email and general ones. The shipped storefront and API do not read them yet, so changing one changes nothing until your own code does.

An example launch plan by week

This schedule is an example for Cedar & Cloth, not a promise about how long your launch will take.

Week 1, understand. Run the stack, place a test order, and settle the decisions list.
Week 2, brand and catalogue. Rebrand both apps, rewrite the shipped copy, and add categories and one complete product.
Week 3, the rest of the shop. Add the remaining products, arrange the home page, and set up bucket storage and photos.
Week 4, money and staff. Set the shipping rule, connect Stripe in test mode, create the roles for the packers, and run orders through every status.
Week 5, production. Set up hosting, the environment files and the tables. Connect a mail provider, add tracking tags, and write the missing terms and privacy pages.
Week 6, soft launch. Start with a small audience, then switch to Stripe live keys when you are sure.

Launch checklist

Store name, logos, icons, colors and fonts replaced in both apps.
Shipped menswear copy rewritten in the brand file, the home messages and the SEO messages.
Contact details, social links and sharing images replaced.
Categories and products complete in both languages, with variants and photos.
Shipping rule changed in both files, if you changed it at all.
Stripe live keys and the live webhook in place, after a full test-mode run.
Roles ticked for each staff member, and the demo passwords changed.
JWT_SECRET, CORS_ORIGIN, FRONTEND_URL and both frontend API addresses set for production.
NEXT_PUBLIC_SITE_URL set to the real domain.
A mail provider connected, and the contact form and newsletter form wired.
Terms and privacy pages written.
Tracking ids pasted, and a consent banner added if you sell to the EU or UK.
Demo checkout prefill left off.
Backups scheduled for the database and the media bucket.

Template, from scratch, or a hosted store builder

A hosted store builder

You can be selling quickly, with hosting, checkout and updates handled for you. You pay ongoing fees, work within the platform's design and rules, and keep your data on their system. It suits a shop that wants to sell, not to run software.

Building from scratch

You get exactly what you design. You also build a catalogue with variants, carts, guest checkout, order tracking, payment and webhooks, accounts for customers and staff, permissions, an admin, two languages and an API before the first order. You maintain all of it.

Starting from a template

You own the code, host the stack and change anything. The storefront, admin and API are already connected, so you spend your time on products and brand. In return you accept the work this guide lists: email, tax rules, terms pages, hosting and updates. It suits founders who want control, and agencies building stores for clients.

What it costs to run

Template packages start from $79, and the Full Stack package Cedar & Cloth uses is $179. It includes a commercial license and lifetime support. Beyond that you pay for what you switch on:

Hosting for the storefront, admin and API, and a database if you move past SQLite.
Stripe's processing fees, listed on Stripe's pricing page. Cash on delivery needs no processor.
A bucket such as Cloudflare R2 for product images.
A Google Gemini key for the assistant, studio or fitting room, billed by Google, and a Higgsfield account for video.
A mail provider and a domain.

Free parts: SQLite for local work, the demo store, cash on delivery, and background removal on your own server.

What to customise next

Copy and photos. Replace the home page messages and the page titles in both languages.
Shipping rules. Change the free-shipping threshold or fee in the two files together.
Another tracking network. The marketing tags are configured in src/config/analytics.config.ts, and the template describes adding one more as a single-file job.
Admin overview cards. Wire the sample revenue and conversion cards to your own numbers.
Roles. Build a role for each person on the team.
A third language. Add it to both frontends and the API. Products hold two languages, English and Arabic.

Common mistakes

Card orders that stay pending

An order flips to paid only after Stripe's webhook reaches your API; the shopper coming back to the site does not do it. Check the endpoint address, the two subscribed events and the signing secret.

Changing the shipping rule in only one place

The cart, checkout summary and API must agree. Edit the storefront config and the orders service in the same change.

Leaving the frontends on the sample store

Without NEXT_PUBLIC_API_BASE_URL, each frontend answers from sample data in the browser, shows a notice, and charges no one. Set the address and rebuild.

Counting every GA4 session twice

If GA4 loads from Tag Manager, leave the template's GA4 variable empty.

Handing out an empty role

Admin, Manager and Editor start with no permissions. A staff member given one sees almost nothing until you tick what they need.

FAQ

How do I build an online store with an admin panel in Next.js?

Use a template that already has the storefront, the dashboard and the API as one project, and change the brand and catalogue. This one gives you all three, with a seeder that fills the database with a demo store in one command.

Can I use it for clients?

Yes. The license covers unlimited projects, including stores built for a customer and handed over. You may not resell the code or release it as a template.

Does it support Arabic and RTL?

Yes. The storefront, the admin and the API ship in English and Arabic, with Arabic laid out right to left. Products and categories are stored with both languages.

Do I need a backend?

For real orders, yes. The frontends run alone on a sample store, but real orders, payments and AI features depend on the NestJS API, which comes with the Full Stack and Backend API packages.

Does it support guest checkout?

Yes. Guests check out with an email and track the order by number and email, with no account.

Which payment methods work?

Card payments run on Stripe, and shoppers can also choose cash on delivery. PayPal is not offered at checkout.

Which database does it use?

SQLite for local work and MySQL by configuration, with no code change.

Does it handle tax?

No. The shipping rule and checkout total apply no tax. If your business must charge it, add that to the pricing logic on both the storefront and the API so the totals stay equal.

Can customers pay in other currencies?

Card payments are charged in US dollars. Selling in another currency means changing that in code, and the tracking currency is a separate setting.

What happens when a card is declined?

The order is marked failed when Stripe reports the failed payment. Cash on delivery remains available for that customer.

Try it yourself

Open the storefront demo and the admin demo. Then read the documentation or visit the e-commerce template page. More choices are in the e-commerce templates category and the Next.js e-commerce templates guide.

The e-commerce template is also one of the ten templates in the Next.js Templates Bundle.

I built a full-stack Next.js 16 e-commerce monorepo: storefront, admin, NestJS API, and AI try-on

Aniq UI — Sat, 15 Aug 2026 10:08:11 +0000

I shipped a production e-commerce system as a single monorepo: a Next.js 16 storefront, a Next.js 16 admin dashboard, and a NestJS API. English and Arabic with full RTL, guest checkout, and three AI features that live inside the codebase instead of being bolted on top.

This is the build log. The decisions I would defend, the ones that cost me a week, and what I would do differently.

Three apps, not one

The obvious move is one Next.js app with /admin routes behind a guard. I split it into three.

The storefront and the admin have almost nothing in common at the boundary. The storefront is public, SEO-critical, and cached aggressively. The admin is authenticated on every request, data-heavy, and never indexed. Sharing a build means the storefront pays for Recharts, the data grids, and the admin's client bundle even when nobody signs in.

Splitting also made auth honest. Customers and staff are different tables with different token payloads and different refresh lifetimes. When they share an app you inevitably end up with one User model carrying an isAdmin boolean, and RBAC on top of a boolean is how privilege escalation bugs happen.

Cost of the split: three ports in dev, a shared types package, and CORS config you have to actually think about. Worth it.

RTL is a layout problem, not a translation problem

Arabic support is where most templates quietly fail. Translating strings is the easy half. The hard half is that every hardcoded margin-left, left-0, flex-row, and chevron icon is now wrong.

The rule that fixed it: no physical direction properties anywhere. Logical properties only.

/* breaks in RTL */
.card { margin-left: 1rem; padding-right: 2rem; }

/* works in both */
.card { margin-inline-start: 1rem; padding-inline-end: 2rem; }

Tailwind 4 makes this workable because ms-*, me-*, ps-*, pe-*, start-*, and end-* are first class. Once I banned ml-, mr-, pl-, pr-, left-, and right- from the codebase, the same components served both directions with no mirrored variants.

The leftovers that still bite:

Icons with implied direction. A "next" chevron has to flip. A logo does not. There is no automatic rule, you tag them by hand.
Carousels. Embla needs its direction option set from the locale or drag goes the wrong way.
Numbers and currency. Intl.NumberFormat with the right locale, not string concatenation.
Transforms. translateX does not mirror. Animations needed direction-aware values.

For messages I used next-intl with one file per feature per locale rather than one giant en.json. A 2000-line translation file is unreviewable and guarantees merge conflicts. checkout.en.json next to checkout.ar.json means a translator touches one file and you can diff it.

Guest checkout: the order is the identity

Forcing account creation before purchase kills conversion, so guest checkout was non-negotiable. It changes the data model more than you would expect.

If order.userId is non-nullable, every guest order needs a phantom user, and now you have a users table full of ghosts that break your customer analytics. Instead the order owns its own contact and shipping snapshot, and userId is nullable.

Snapshot is the key word. The shipping address on an order is a copy, not a foreign key to an address row. When a customer edits their saved address six months later, historical orders must not silently change. Same for line items: product name, variant, and unit price get denormalized onto the order line at purchase time. Prices change. Invoices should not.

Guest order tracking is then just order number plus the email used at checkout. No account, no magic link infrastructure, and the lookup is rate-limited so it is not an enumeration oracle.

Virtual try-on

A shopper taps a hanger icon on any product page and sees the garment worn, either on a built-in model or on their own uploaded photo.

The architecture that made it feel fast:

The upload goes straight to S3-compatible storage with a presigned URL. The API never proxies the image bytes.
Generation is a job, not a request. The client gets a job id immediately and subscribes over Socket.io.
Results are cached per garment plus model pair, so the same product on the built-in model is generated once, ever. That is most of the traffic.
Per-account quotas, enforced server-side. Image generation has real unit cost, and an unmetered endpoint is a bill waiting to happen.

The piece I underestimated: composition. Shoppers do not want one item, they want an outfit. Building up a look piece by piece meant persisting the try-on session state so the next garment composites onto the previous result instead of starting from a blank model.

The AI studio lives inside the product editor

Merchants do not want a separate AI tool. They want the product form to fill itself.

So the generation UI sits in the product editor: generate product imagery from a prompt, remove backgrounds, draft the listing copy from a single uploaded photo, and turn a still into a short product video with motion presets.

The detail that changed usage more than the model choice: three one-tap prompt suggestions sitting directly above the composer. "Write the product details." "Clean white studio shot." "Photograph this on a model." Tap, then Send. A blank prompt box gets ignored. Three buttons get pressed.

The admin assistant queries the database, not the internet

The dashboard assistant is a streaming chat, but the interesting part is that it answers from store data through an MCP tool registry rather than from general knowledge.

Each tool is a typed, scoped function: revenue for a period, orders awaiting fulfilment, top sellers, low stock. The model picks tools and composes the answer. It cannot free-form SQL, so it cannot leak or wreck anything the tool contract does not allow.

Two things fell out of this design:

Provider choice is trivial. Anthropic, Google, and OpenAI all speak tools, so the provider is config. Bring your own key.
Answers are auditable. Every claim traces to a tool call with real numbers, not a plausible hallucinated figure.

Suggested questions on the empty state again, for the same reason as the studio prompts.

Real-time without a state mess

New orders, status changes, and notifications push over Socket.io. The temptation is to write incoming events into a client store and treat that store as the source of truth. That path ends in two copies of your data that disagree.

What worked: the socket event carries an identifier, not a payload. The handler invalidates the relevant TanStack Query key and the normal fetch path refills it. One source of truth, no reconciliation logic, and a page that recovers correctly after a reconnect.

Redux Toolkit stays for genuinely client-owned state: cart, wishlist, UI preferences. Server state never enters it.

Boring things that mattered most

A one-command seeder. Products, variants, images, customers, orders across every status. Nothing kills first-run enthusiasm like an empty database and a broken chart.
Exact pinned dependencies with committed lockfiles. No carets. A template that installs a different tree next month is a support ticket generator.
Branding in one config file per app. Colors, logo, store name. If a rebrand means grepping for hex codes, the theming is fake.
No flash of the wrong theme. A blocking inline script reads the stored preference before paint. Tiny detail, immediately noticeable when missing.

What I would do differently

I would design the RTL rule on day one instead of retrofitting it. Auditing every physical property after the fact took a week of tedious work that a lint rule would have prevented from the start.

I would also make the AI features quota-gated from the first commit rather than adding limits later. Retrofitting metering into an existing generation flow is more invasive than it sounds.

Try it

The whole thing is available as a template if you would rather start from a working store than a blank create-next-app.

Stack: Next.js 16 App Router, React 19, TypeScript 5, Tailwind CSS 4, TanStack Query, Redux Toolkit, React Hook Form and Zod, next-intl, NestJS, TypeORM with MySQL or SQLite, Socket.io.

Happy to go deeper on any part of this in the comments. The RTL and the try-on caching are the two I have the most notes on.

How I Built My Own Next.js Template Store (And What I Learned)

Aniq UI — Fri, 10 Oct 2025 17:07:11 +0000

A few months ago, I decided to build my own Next.js landing page template store : https://www.aniq-ui.com/en.
I wanted a place to sell templates I designed and coded myself, but I also wanted it to reflect my taste in UI and performance.

Why I Chose Next.js ?

I’ve worked with React for years, and Next.js gave me the balance between speed, SEO, and developer control.
Its app router and server components made it easy to scale templates cleanly without messy state handling.

The Stack

Next.js for structure and SSR
TailwindCSS for consistent design
TypeScript for safety and scalability
Framer Motion for subtle motion design

Simple local JSON for i18n, later upgrading to a CMS

What I Learned

Designing for reusability is harder than it looks.

A fast page is nice, but good UX sells.

You don’t need a team, just focus, taste, and iteration.

🌍 Check It Out

You can see the result here: https://www.aniq-ui.com/en/templates