JustPaste
HomeCategoriesAboutDonateContactTerms of UsePrivacy Policy
JustPaste

Free online notepad — write and share instantly

Navigate

  • Home
  • Timeline
  • Categories

Info

  • About
  • Donate
  • Contact

Legal

  • Terms of Use
  • Privacy Policy

© 2026 JustPaste.app. All rights reserved.

Made with ♥ by JustPaste

Untitled Page | JustPaste.app
5 days ago6 views
💻Technology

IMPORTANT — START WITH ANALYSIS + PLAN ONLY.
DO NOT MODIFY ANY FILES YET.
After completing the analysis and plan, STOP and wait for my approval before making any changes.

OBJECTIVE

I want to redesign the EXISTING categories/app browsing UI of the website.

The current categories section looks bad and should be replaced with a polished, modern UI inspired by the general concept of Playerok’s app/category browsing interface.

CRITICAL:
REPLACE THE EXISTING CATEGORY UI — DO NOT CREATE A SECOND CATEGORY SECTION.

Do not add another categories section beside or below the existing one.
Find the current categories implementation and replace/refactor that UI while preserving the existing underlying category/product architecture wherever possible.

1. NEW CATEGORY / APP TILE DESIGN

The new interface should use polished cards/tiles for apps/categories.

Examples of apps/categories may include:

  • ChatGPT

  • Gemini

  • Claude

  • Telegram

  • Spotify

  • YouTube

  • Canva

  • Discord

  • and other categories already available in the project.

Each tile can contain:

  • App/category icon

  • Localized name

  • Optional product count if useful

  • Clear hover/active state

  • Smooth but subtle transitions

  • Proper spacing

  • Responsive layout

  • Clean modern visual hierarchy

The design should be inspired by Playerok’s concept, NOT copied pixel-for-pixel.

Do not copy Playerok’s branding, exact layout, assets, or proprietary design.

The result should feel like an original professional digital-products marketplace.

2. USE THE EXISTING CATEGORY SYSTEM

Before implementing anything, inspect the existing project architecture.

Determine:

  • Where categories are stored

  • How products are associated with categories

  • How categories are displayed

  • Whether there is already an admin category management system

  • Whether icons/images already exist

  • Whether translations already exist

Prefer extending/reusing the existing system.

DO NOT create a duplicate category database/table/system unless the existing architecture genuinely cannot support the requested functionality.

3. ADMIN MANAGEMENT

The categories/apps shown in the new UI should be manageable from the existing Admin Dashboard.

Admin should be able to:

  • Add category/app

  • Edit category/app

  • Delete category/app

  • Enable/disable category/app

  • Upload/change icon

  • Remove icon

  • Set ordering/position

  • Set localized name:

    • English

    • Arabic

    • Russian

  • Associate the category/app with the appropriate existing products/categories

  • Optionally configure a custom destination URL if the current architecture supports this cleanly

Do not create a separate admin system if category management already exists.

Use the existing authentication and authorization system.

4. ICONS

Icons must be database-driven/configurable rather than hardcoded into the frontend.

The admin should be able to manage the icon.

Support the project’s existing image/upload/storage architecture where possible.

Do not introduce an unnecessary third-party icon service.

5. PAGE SCOPE

This app/category browsing UI must NOT appear globally across the entire website.

It should only appear on the existing dedicated category/application browsing page.

If the project already has an appropriate route, reuse it.

If there is no suitable route, determine the cleanest route during analysis (for example /apps), but do not create unnecessary duplicate pages.

Do NOT place this section on:

  • Homepage

  • Product details

  • Cart

  • Checkout

  • Orders

  • Account/profile

  • Admin

  • Telegram pages

  • Other unrelated pages

unless the existing architecture technically requires a shared component.

6. GLOBAL LIGHT MODE + DARK MODE

The website currently has Light Mode, but Light Mode does not work correctly throughout the entire site.

Fix the theme system properly.

Inspect the existing implementation first, including:

  • Tailwind configuration

  • CSS variables

  • global CSS

  • theme provider/context

  • next-themes if present

  • hardcoded colors

  • component-specific colors

Implement a reliable global Light/Dark Mode system without redesigning unrelated parts of the website.

Both themes must remain readable and visually consistent.

Light Mode requirements:

Ensure there are NO cases of:

  • White text on white backgrounds

  • Light-gray text on white backgrounds when unreadable

  • Dark text disappearing on dark components

  • Invisible placeholders

  • Invisible borders

  • Invisible icons

  • Buttons with unreadable text

  • Cards with insufficient contrast

  • Inputs/selects with incorrect colors

Dark Mode requirements:

Ensure:

  • Text remains readable

  • Icons remain visible

  • Borders remain visible

  • Inputs remain readable

  • Buttons remain readable

  • Cards have appropriate contrast

  • Placeholders remain visible

Theme preference must persist after:

  • Page refresh

  • Navigation

  • Browser reopen

Avoid theme flashing and hydration mismatch where applicable.

The implementation must continue supporting:

  • Arabic RTL

  • English LTR

  • Russian LTR

7. RESPONSIVE DESIGN

The new category/app interface must work properly on:

  • Mobile phones

  • Tablets

  • Desktop

  • Large screens

Do not simply shrink desktop elements.

Use an appropriate responsive grid/horizontal layout based on the existing site’s design system.

8. VISUAL QUALITY

The final UI should feel:

  • Modern

  • Professional

  • Clean

  • Fast

  • Premium

  • Consistent with a digital-products marketplace

Use subtle hover/active animations where appropriate.

Do not overuse animations, gradients, shadows, or excessive rounded elements.

Do not make the interface look AI-generated or generic.

9. PRESERVE EXISTING FUNCTIONALITY

Do NOT modify unrelated systems.

Especially DO NOT change:

  • Telegram bot

  • Telegram product publishing

  • Telegram custom emoji system

  • Telegram queue

  • Telegram webhooks

  • Product button functionality

  • Authentication

  • Checkout

  • Orders

  • Payments

  • Product purchasing

  • Existing product data

  • Existing admin permissions

  • Existing APIs

  • Existing database logic

unless a directly necessary change is identified during analysis.

Avoid unrelated refactoring.

Use the smallest safe implementation that achieves the objective.

10. EXISTING DESIGN SYSTEM

Before creating new components, inspect the project’s existing:

  • Components

  • CSS

  • Tailwind utilities

  • Design tokens

  • Buttons

  • Cards

  • Typography

  • Spacing

  • Theme implementation

Reuse existing components/styles where appropriate instead of creating duplicate versions.

11. SEO / ACCESSIBILITY

Keep the existing SEO behavior intact.

Make the new category/app cards accessible:

  • Proper semantic elements

  • Keyboard navigation

  • Visible focus states

  • Meaningful accessible labels for icons

  • Proper contrast

  • Do not make an entire card inaccessible if it contains interactive elements

12. PERFORMANCE

Do not add unnecessary dependencies.

Avoid loading huge icon/image assets unnecessarily.

Use the project’s existing image optimization/storage mechanism where available.

Do not introduce a client-side architecture unnecessarily if the existing page can remain server-rendered.

13. BEFORE ANY CODE CHANGES

Perform a complete analysis of the repository.

Identify:

  1. Current category UI files/components

  2. Current category database/schema

  3. Product-category relationships

  4. Existing admin category management

  5. Existing image upload/storage system

  6. Existing localization/i18n system

  7. Existing theme system

  8. Existing dedicated category/app browsing route

  9. Any duplicated category implementations

  10. Any risks or dependencies

Then provide:

ANALYSIS

Explain what currently exists.

IMPLEMENTATION PLAN

Give the exact files/components/database changes you intend to make.

RISK CHECK

Explain anything that could affect existing functionality.

FILE CHANGE LIST

List every file you expect to create/modify/delete and why.

VALIDATION PLAN

Explain how you will verify:

  • Categories display correctly

  • Existing products still work

  • Admin management works

  • Arabic/English/Russian work

  • Light Mode works

  • Dark Mode works

  • Mobile layout works

  • Desktop layout works

  • Existing unrelated functionality remains intact

  • TypeScript/build passes

FINAL RULE

DO NOT MODIFY THE PROJECT DURING THIS FIRST STEP.

Only perform:

ANALYSIS + PLAN ONLY

Then STOP and wait for my explicit approval.

Do not create files.
Do not edit files.
Do not run migrations.
Do not change the database.
Do not install dependencies.
Do not change configuration.

Wait for my approval after presenting the analysis and plan.

← Back to timeline