The modern dating app market demands sophisticated user experiences while managing different access levels based on subscription status. In this tutorial, we’ll explore how to implement permission layers in a Next.js dating app that restricts certain premium features to paid users.
We’ll build a Tinder-inspired application with standard features like profile swiping, likes, and matches. Our challenge is implementing a subscription model where free users have limited daily swipes and can only view the first photo of potential matches, while premium users enjoy unlimited swipes and full profile access.
We’ll implement features including daily swipe limits, premium photo viewing, and viewing who liked your profile. Throughout the process, we’ll use Next.js (App Router) for the frontend, Supabase for authentication and database, Tailwind CSS for styling, and <a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a> to manage role-based access control between free and premium users. This separation of concerns allows us to modify subscription tiers without changing application code.
<h2>What Are We Building?</h2>
We’re creating a dating app called “Flamer” that follows the familiar swipe-based matchmaking model famously related to Tinder. Our application demonstrates how modern dating platforms implement feature-gating through subscription tiers.
Core Features
Our app includes these essential dating app functions:
<ul>
<li>User authentication and profile creation</li>
<li>Swipe-based discovery of potential matches</li>
<li>Messaging between matched users</li>
<li>Profile management</li>
</ul>
Access Control Policies
We’re implementing a free and premium subscription model with these permission boundaries:
Free Users:
<ul>
<li>Limited to 10 swipes per day</li>
<li>Can only view the first photo of each profile</li>
<li>Cannot see who has liked their profile</li>
</ul>
Premium Users:
<ul>
<li>Unlimited daily swipes</li>
<li>Access to view all profile photos</li>
<li>Can see who has liked their profile</li>
<li>Priority placement in the discovery queue</li>
</ul>
Application Flow
User Registration: New users sign up:
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXcGoXK4TR2_YMnxxf_--hw_gpNDCQjPlzoi8Ub1A-8eTR-5fn4KILfhCPB97Eass5P0fbK-lZR2FFuuuyrCAXzMyZeGDNkeHgkGa1wO91reb6A7WXzKA5zw7B-Mgcr4v5cEWo-KYQ?key=Yg5R1-eSiNKi7hLLV0G3iNSN" alt="">
Create a profile and upload photos:
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfRav3IxrfZao3fv10JiltB_evUSWWcmRXpJYb31K4NuO8hqPFdv9Co6O3xj_jF9fxTxSwUdF8F9WEgkI0jXADPefcAEAvx2r8olQBrjL0H147JjUKReLOJWdWD4KZIt-PskjeZYQ?key=Yg5R1-eSiNKi7hLLV0G3iNSN" alt="">
Plan Selection: Users choose between the free and premium subscription:
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXewJYTSWr-udiPD0zINmAM9DAjuly6_C50NvP2mnMlIP5WEY0kCaBU0Mc-ybbVxeEKuHoD8Nb4OAkOq_2zEzpLaPj1QuPnY0yN2a7WfhuwoaPzEDscQZngaPWz9C6wp-CSwwzSgXw?key=Yg5R1-eSiNKi7hLLV0G3iNSN" alt="">
Role Assignment: Based on subscription choice, users are assigned either a “FreeUser” or “PremiumUser” role in <a href="http://permit.io" target="_blank" rel="noopener nofollow">Permit.io</a>.
Free users:
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdnOJ_8F6eiwjoe1IteximS4abkSelH7oUuHIFpb_XBOKSRuDFumGdRCZd3zPlxqCLG-HzhHrTPTFjm0bv7ygNdoaNpfqymHfamOdL4BUt27cn10xEiWlz-ghgjtdtiHvXhLPgQeA?key=Yg5R1-eSiNKi7hLLV0G3iNSN" alt="">
Premium User:
<img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdWc4-zUmH1GX-V7AXC48r8kjfRT8EDGIO20ocmSFXmpbLU0nXw7H8p1NqUijsUxvpPWhk74_qtV4HQ30rthhX5VAS4qY2hPeFCPimULxs95qTjLWhY8uo2vPzXVga3C1kOMjbYmg?key=Yg5R1-eSiNKi7hLLV0G3iNSN" alt="">
Feature Access: As users navigate the app, permission checks determine which features they can access. When viewing profiles, free users see only the first photo with a lock icon indicating premium content. When reaching daily swipe limits, free users see an upgrade prompt. When visiting the “Likes” page, free users see a premium feature gate instead of actual likes.
<h2>Prerequisites and Getting Started</h2>
Below is a detailed list of all the tech stack needed to get the article up and running:
Frontend
<ul>
<li>Next.js 15+ for the React framework with server components</li>
<li>React 19 for building user interfaces</li>
<li>Tailwind CSS 4 for styling components</li>
<li>Lucide React for icon components</li>
</ul>
Backend &amp; Data
<ul>
<li>Supabase for:
<ul>
<li>Authentication</li>
<li>PostgreSQL database</li>
<li>Storage (for profile photos)</li>
</ul>
</li>
<li>Next.js API Routes for backend logic and API endpoints</li>
</ul>
Authorization
<ul>
<li><a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a> for implementing permission layers and role-based access control</li>
</ul>
Developer Tools
<ul>
<li>TypeScript for type safety</li>
<li>Node.js 18+ for the JavaScript runtime</li>
<li>npm or yarn for package management</li>
</ul>
Knowledge Prerequisites
<ul>
<li>Basic understanding of React and hooks</li>
<li>Familiarity with Next.js App Router</li>
<li>Understanding of authorization concepts (RBAC)</li>
<li>Basic knowledge of PostgreSQL and SQL queries</li>
</ul>
Environment Setup
<ul>
<li>Supabase account and project</li>
<li><a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a> account and configured environment</li>
<li>Local development environment with Node.js installed</li>
<li>Environment variables for API keys and service connections</li>
</ul>
All code examples will work with the listed versions, though newer versions should be compatible as well.
To get started
You will need to clone this repo:
<pre><code>Git clone https://github.com/marvelken/tinder-clone-Flamer.git
</code></pre>
Input your <a href="http://permit.io" target="_blank" rel="noopener nofollow">permit.io</a> API key, same with your Supabase API keys, and you should be good to go.
<h2>Database Schema for the Dating App</h2>
This dating app uses a PostgreSQL database with two main tables that store essential data for user profiles and matchmaking. Let’s explore the core tables and their relationships:
Profiles Table
The profiles table stores user information and preferences:
<pre><code>create table public.profiles (
 id uuid not null,
 name text not null,
 age integer not null,
 gender text not null,
 looking_for text not null,
 about text null,
 location text not null,
 max_distance integer not null default 25,
 photos text[] null default '{}'::text[],
 created_at timestamp with time zone not null default now(),
 updated_at timestamp with time zone not null default now(),
 constraint profiles_pkey primary key (id),
 constraint profiles_id_fkey foreign KEY (id) references auth.users (id) on delete CASCADE,
 constraint profiles_age_check check ((age &gt;= 18))
)
</code></pre>
Key features:
<ul>
<li>Primary key (id) linked directly to Supabase authentication users</li>
<li>Core user attributes like name, age, and gender</li>
<li>Dating preferences (looking_for, max_distance)</li>
<li>Array of photo URLs (photos)</li>
<li>Age verification check constraint (minimum 18 years)</li>
<li>Timestamps for creation and updates</li>
<li>Automatic timestamp update via trigger set_timestamp_profiles</li>
</ul>
Likes Table
The likes table tracks the potential matches:
<pre><code>create table public.likes (
 id uuid not null default extensions.uuid_generate_v4(),
 liker_id uuid not null,
 liked_user_id uuid not null,
 created_at timestamp with time zone not null default now(),
 is_match boolean null default false,
 constraint likes_pkey primary key (id),
 constraint likes_liker_id_liked_user_id_key unique (liker_id, liked_user_id),
 constraint likes_liked_user_id_fkey foreign KEY (liked_user_id) references auth.users (id) on delete CASCADE,
 constraint likes_liker_id_fkey foreign KEY (liker_id) references auth.users (id) on delete CASCADE
)
</code></pre>
Key features:
<ul>
<li>Unique constraint to prevent duplicate likes from the same users</li>
<li>Foreign keys to the auth users table for both the liker and the liked user</li>
<li>is_match boolean flag that gets updated when both users like each other</li>
<li>Cascade deletion to maintain referential integrity</li>
<li>Automatic UUID generation for the primary key</li>
</ul>
This database structure provides a solid foundation for implementing our permission-based features, where access to certain data depends on the user’s subscription tier.
<h2>Implementation Guide</h2>
In this section, I will walk you through implementing permission layers in our dating app. We’ll systematically approach authorization following a “plan, build, implement” workflow.
Planning Step
Before writing any code as a developer, we need to understand our authorization model. This is the foundation of our permission system.
Resources We’re Controlling Access To
<ul>
<li>Profile: User profiles with photos and demographic information</li>
<li>Likes: Records of who has liked a user</li>
</ul>
User Roles
<ul>
<li>FreeUser: Base level access with limitations</li>
<li>PremiumUser: Paid subscription with full feature access</li>
</ul>
Actions
For each resource, we’ll control these actions:
<ul>
<li>view: Basic viewing permission</li>
<li>viewfull: Complete access to all details</li>
<li>viewlimited: Restricted access to partial information</li>
</ul>
Authorization Policies in Plain English
<ul>
<li>Free users can only view the first photo of each profile</li>
<li>Premium users can view all photos of each profile</li>
<li>Free users are limited to 10 swipes per day</li>
<li>Premium users have unlimited swipes</li>
<li>Free users cannot see who liked them</li>
<li>Premium users can see who liked them and match instantly</li>
<li>Premium users appear with higher priority in the discovery queue</li>
</ul>
Schema
Setting Up <a href="http://Permit.io" target="_blank" rel="noopener nofollow">Permit.io</a> Resources and Actions
First, we’ll define our resources and actions in <a href="http://permit.io" target="_blank" rel="noopener nofollow">Permit.io</a>:
<table>
<thead>
<tr>
<th>Resources</th>
<th>Action</th>
<th>FreeUser</th>
<th>PremiumUser</th>
</tr>
</thead>
<tbody>
<tr>
<td>Likes</td>
<td>view</td>
<td>❌</td>
<td>✅</td>
</tr>
<tr>
<td>profile</td>
<td>viewFull</td>
<td>❌</td>
<td>✅</td>
</tr>
<tr>
<td>profile</td>
<td>ViewLimited</td>
<td>✅</td>
<td>✅</td>
</tr>
</tbody>
</table>
To finish this article, you can do that <a href="https://medium.com/@marvelken2000/from-swipes-to-subscriptions-building-permission-layers-in-a-dating-app-5f2c7ac13866" target="_blank" rel="noopener nofollow">here</a>. Thanks for sticking this far, your comments will be appreciated.

marvelken's public Squad

A comprehensive tutorial on building permission layers in a dating app using Next.js, Supabase, and Permit.io. The guide demonstrates implementing a subscription-based access control system where free users have limited daily swipes and can only view first photos, while premium users get unlimited swipes and full profile access. Covers database schema design, role-based access control setup, and feature gating strategies for modern web applications.

From Swipes to Subscriptions: Building Permission Layers in a Dating App