DEV Community: Aidityas Adhakim

Workspace Shares Made Easy with Permit IO! LeetCall: Master LeetCode with Spaced Repetition

Aidityas Adhakim — Thu, 01 May 2025 08:33:58 +0000

This is a submission for the Permit.io Authorization Challenge: Permissions Redefined

LeetCall is built for DEV Challenge, but is open to the public to try!

📚 Table of Contents

What I Built: LeetCall
Sharing Workspace Securely
Prerequisites
How Does LeetCall Work?
Demo & Project Access
- 5.1 Try the Demo
- 5.2 Project Repository
My Journey Building LeetCall
- 6.1 Designing the Authorization Schema
- 6.2 Challenges with External Authorization
- 6.3 How Can External Authorization Help Building an Entire Application
Using Permit.io for Authorization
- 7.1 Workspace Sharing Model
- 7.2 Setting Up Authorization with Permit CLI
- 7.3 permitio-migration.js Walkthrough
Related Articles

What I Built

The idea is I wanted to start doing leetcode and I find a way to learn it by utilizing the Space Repetition method, basically working on the problem with a space repetition theory. I can manage and schedule the space repetition in spreadsheet manually, but why don’t I create the web app and let other users who wanted to use this method in leet code access this also — currently there’s no similar space repetition app made for programmer.

LeetCall lets you input LeetCode problems, which are then reviewed later using spaced repetition, all the you need to do is add LeetCode problem to be tracked in LeetCall and let LeetCall reminds you with our Spaced Repetition Simplified Algorithm.

Sharing Progress

At LeetCall, we've made sharing your progress effortless. You can share your tracked LeetCode problems and current progress with anyone you choose — whether it's friends, mentors, or study partners. Let others see how far you've come and stay motivated together. Thanks to Permit IO that made ReBAC (Relationship-Based Access Control) easy.

Prerequisites

Permit IO Account.
Deployed PDP if you want to deploy the app locally — either local or a vps. Since we are working with ReBAC, we need to start our own PDP. You can check my article to deploy PDP in heroku under 5 minutes here.
Supabase if you want to deploy the app locally.

How Does LeetCall Works?

LeetCall offers an automated spaced repetition system to support your LeetCode journey, helping you revisit solved problems and strengthen your memory of them.

1. User Add LeetCode Problem to be Tracked

The first step is to add your initial LeetCode problems to be tracked by LeetCall. After that, you can review your progress on the problems you've solved.

2. How Does the Space Repetition Algorithm Works?

LeetCall uses a simplified spaced repetition algorithm — it's a minimal viable formula designed to launch quickly, yet effective enough to support meaningful review sessions. Here’s how we define the formula

LeetCall scoring is range from 0-3 with
- 0: Again(Blackout), complete blackout about the problem’s solution
- 1: Hard, still need to peek for public solution
- 2: Good, correct but with some difficulty
- 3: Easy, perfect response
Simplified Formula(SF)
- SF(n) = round(n * (score / 3) * learningStep);
- With n is repetition
- 3 is maximum score
- Learning Step is [1, 3, 7] in days
If its your first time reviewing the problem — in this case we will use Two Sum Problem. Then any score you pick you will still have to review it tomorrow.
If its your second time reviewing the problem, then it will follow our Simplified Formula with learning step is 3 days.
If its your third or more time reviewing the problem, then it will follow Simplified Formula with learning step 7 days.

Demo

You can sign up to LeetCall and start tracking your leetcode progress, would be happy if you can give some review too! Currently LeetCall is in development, so you don't need to confirm your email on sign up!

I built this app with the help of AI, if you are curious go to my other articles here where I write down the whole journey from creating the PRD and Database Model with the help of AI.

You can use this demo account if you don't want to sign up
email: alice@leetcall.com
password: 2025DEVChallenge

email: bob@leetcall.com
password: 2025DEVChallenge

LeetCall App

Project Repo

Heads up to the repo if you want to deploy it locally or contributing to the project!
LeetCall GitHub Repository

LeetCall Demo Video

My Journey

Designing Authorization Schema

Designing the authorization schema get a little confusing in the beginning since this is my first time designing ReBAC authorization policy. But thanks to Permit IO that provide clear ReBAC documentation and examples.

Problem When Building With External Authorization

We store user information in our database, including their workspace and tracked problems. However, we now also need to sync this data with Permit IO — meaning that whenever a user is created, updated, or deleted, the same action must be reflected in Permit IO. I guess that’s the price that we need to pay for a fine-grained authorization. However, it still very easy to setup since the API and SDK docs is very clear.

How Can External Authorization Help Building an Entire Application?

The highest benefit I felt when using external authorization is how simple it is to check user’s authorization. Instead of doing nested left join to many tables, now I just need to simply do

await permit.check('authorization request details here')

I felt like this saved me a ton of time when building apps. Also Permit IO’s UI makes authorization super easy to manage — everything's laid out clearly, and I can handle access just by clicking a few buttons. No need to build extra user management pages or write complex logic for access control.

Using Permit.io for Authorization

In this section we will explore how do I design the authorization schema and how to build a similar schema using Permit CLI.

How Does the Sharing Workspace Designed?

As you have seen before, LeetCall utilize Permit IO ReBAC authorization, which we will have roles, resource and resource instances in this project.

Top Level Roles

On the top level authorization, basically there’s just two roles:

Admin, which the admin that own the app — basically me lol.
User, other users that sign up.

Resource

There is only one resource which is workspace, each user will have their own workspace.

Resource Instances

Every unique workspace is considered as a resource instances, with uuid as the key i.e. (workspace#uuid-here).

Instance Roles

Here’s the roles that exist within the workspace in Permit IO this is called as Instance Roles :

Viewer, which can only view your progress and tracked problems.
Reviewer, can review your tracked problems but cannot add more tracked problems.
Editor, which can edit your entire workspace, add more tracked problems and review it for you.

How to Set Up Your Authorization Schema Using the Permit CLI

In order to complete this section you need to pull the project repository here, so you can get the schema template

For Permit IO Devs, I have tried using permit CLI to deploy the ReBAC authorization, but I just can’t figure out. There is no documentation about:

Create a resource instances, the only resource I can create is a resource, but not with resource instance
Create an instance role, I also check the code and seems like it just doesn’t support it yet.
Assign an instance role to a user

And with that problem, we still need Permit IO Node JS SDK to add a resource instance and assign instance role to a user, lets support the devs to maintain the CLI — I also consider to contribute to their permit CLI, but I don’t have any contributing experience, if you guys have suggestions my dm is open.

Install Permit CLI Check out the installation guides here Permit CLI Docs
Setup Permit CLI First you need to login to the permit cli by doing permit login and it will open up a browser to login to your application.
Run Permit Policy Decision Point (PDP) Since we need ReBAC policy, we need to run our own local PDP, if you want to deploy it in Heroku, I wrote another article for it here Deploy PermitIO PDP to Heroku Under 5 Mins. In this case, we can run it locally by doing permit pdp run and you will get the port where the pdp is running, by default the pdp runs at http://localhost:7766 .
Now lets initiate the schema Make sure you already clone the LeetCall repository, you will find permitio-migration.js which consist of the schema initialization of LeetCall authorization. All you need to do is to run node permitio-migration.js --permit_pdp="the default url or your deployed one" --permit_api_key="your api key"
And if success you will see a couple initial check on the users permissions in the output.

Lets talk about the `permitio-migration.js` file

The first step is to create the resource with its instance roles and what action is available to the resource

await permit.api.createResource({
      key: "workspace",
      name: "workspace",
      actions: {
        create: { name: "create" },
        read: { name: "read" },
        update: { name: "update" },
        delete: { name: "delete" },
        review: { name: "review" },
      },
      roles: {
        owner: {
          name: "owner",
          permissions: ["create", "read", "update", "delete", "review"],
        },
        editor: {
          name: "editor",
          permissions: ["create", "read", "update", "review"],
        },
        reviewer: {
          name: "reviewer",
          permissions: ["read", "update", "review"],
        },
        viewer: {
          name: "viewer",
          permissions: ["read"],
        },
      },
    });

Next lets define the top level roles which is admin and user

await permit.api.createRole({
      key: "admin",
      name: "admin",
      permissions: [
        "workspace:create",
        "workspace:read",
        "workspace:update",
        "workspace:delete",
        "workspace:review",
      ],
    });

    await permit.api.createRole({
      key: "user",
      name: "user",
      permissions: [
        "workspace:create",
        "workspace:read",
        "workspace:update",
        "workspace:delete",
        "workspace:review",
      ],
    });

After that, we can create users and assign the user role to them

await permit.api.syncUser({
      key: "alice@gmail.com",
    });

await permit.api.users.assignRole({
      user: "alice@gmail.com",
      role: "user",
      tenant: "default",
    });

await permit.api.syncUser({
      key: "bob@gmail.com",
    });

await permit.api.users.assignRole({
      user: "bob@gmail.com",
      role: "user",
      tenant: "default",
    });

And then lets each user’s workspace and assign them as the owner of their own workspace

await permit.api.resourceInstances.create({
      key: "alice-workspace",
      resource: "workspace",
      tenant: "default",
    });

await permit.api.users.assignRole({
      user: "alice@gmail.com",
      resource_instance: `workspace:alice-workspace`,
      role: "owner",
    });

await permit.api.resourceInstances.create({
      key: "bob-workspace",
      resource: "workspace",
      tenant: "default",
    });

await permit.api.users.assignRole({
      user: "bob@gmail.com",
      resource_instance: "workspace:bob-workspace",
      role: "owner",
    });

Here I will assign alice -> viewer -> bob-workspace and bob -> editor -> alice-workspace

await permit.api.users.assignRole({
      user: "bob@gmail.com",
      resource_instance: "workspace:alice-workspace",
      role: "editor",
    });

await permit.api.users.assignRole({
      user: "alice@gmail.com",
      resource_instance: "workspace:bob-workspace",
      role: "viewer",
    });

And lets test each other roles on each other workspace

// Check if alice is bob's workspace editor
const aliceRoleOfBobWorkspace = await permit.getUserPermissions(
    "alice@gmail.com",
    [`workspace:bob-workspace`]
  );
const isAliceEditorOfBob =
  aliceRoleOfBobWorkspace[`workspace:bob-workspace`].roles.includes("editor");
const isAliceViewerOfBob =
  aliceRoleOfBobWorkspace[`workspace:bob-workspace`].roles.includes("viewer");
  console.log("Is Alice an editor of Bob's workspace?", isAliceEditorOfBob);
  console.log("Is Alice a viewer of Bob's workspace?", isAliceViewerOfBob);

// Check if bob is alice's workspace editor
const bobRoleOfAliceWorkspace = await permit.getUserPermissions(
    "bob@gmail.com",
    [`workspace:alice-workspace`]
  );
const isBobEditorOfAlice =
    bobRoleOfAliceWorkspace[`workspace:alice-workspace`].roles.includes(
      "editor"
    );
console.log("Is Bob an editor of Alice's workspace?", isBobEditorOfAlice);

And there you go, now we have already set up our authorization schema and you just need to implement it within your application.

Conclusion

Building LeetCall has been a rewarding journey—combining the power of spaced repetition with LeetCode problem-solving to help developers retain what they’ve learned. Through this project, I also explored how Permit.io’s ReBAC authorization can simplify complex access control requirements, especially in collaborative features like sharing workspaces. While there were challenges—particularly around syncing user data and working with Permit IO External Authorization—the experience taught me a lot about designing fine-grained permissions in a real-world application. I'm excited to keep improving LeetCall and invite others to contribute, use the app, or just give feedback. Let’s make studying algorithms smarter, together.

Deploy Permit.IO PDP To Heroku Under 5 Mins! [Video Included]

Aidityas Adhakim — Thu, 01 May 2025 05:59:10 +0000

🚀 Deploying Permit.io PDP to Heroku

Let’s deploy your Permit.io Policy Decision Point (PDP) to Heroku — the easy way. Follow along!

✅ Prerequisites

Before we get started, make sure you have the following:

🧾 A Heroku account — I'm using the free tier via GitHub Student Pack. Thanks GitHub! 🙌. Make sure you create an app that is the target of your deployment.
🛠️ Installed Heroku CLI
🚫 No need for Docker Desktop installed locally
🐶 A Permit.io account
🧑‍💻 Git installed

🛠️ Setup

Create a working directory
Ensure Heroku CLI is installed:
```
heroku -v
```
Login to Heroku:
```
heroku login
```
Authenticate with the Heroku Container Registry:
```
heroku container:login
```
Make sure you’ve created an app on Heroku

Set environment variables:

heroku config:set PDP_API_KEY=<your-permit-api-key> -a your-app-name
heroku config:set PDP_DEBUG=True -a your-app-name

Set your app to use the container stack:
```
heroku stack:set container
```

⚙️ Configuration File

1. Create a Dockerfile

Inside your directory, create a Dockerfile:

# ./created-directory/Dockerfile

FROM permitio/pdp-v2:latest

CMD uvicorn horizon.main:app --host 0.0.0.0 --port $PORT

This ensures Permit PDP uses the correct port that Heroku assigns dynamically.

2. Create a `heroku.yml` File

This tells Heroku how to build and deploy your Docker container:

# ./created-directory/heroku.yml

build:
  docker:
    web: Dockerfile

🚢 Deployment

Initialize a Git repository:

git init
git add .
git commit -m "Initialize Heroku config"

Connect your repo to Heroku:
```
heroku git:remote -a yourapp
```
Push to Heroku to build and deploy:
```
git push heroku master
```
Open your app in the browser:
```
heroku open
```

🎉 Success!

You should see this response:

{"status":"ok","online":true}

Your Permit.io PDP is now live on Heroku! 🔥

Tutorial Video!

Tutorial Video

Building Project With AI Assisted From Scratch: LeetCall

Aidityas Adhakim — Wed, 30 Apr 2025 04:08:55 +0000

In the advanced world of AI, it makes me build things easier, since now AI can cover my skill issue, but how can I build a project from scratch with the help of AI? So I try to build a project from scratch with the help of AI from create Product Requirement Document, Database Modelling and even writing the code! Lets start

Link to the final product: LeetCall

The Idea

The first thing I have is only the idea of what I want to build, the idea is I wanted to start doing leetcode and I find a way to learn it by utilizing the Space Repetition method, basically working on the problem in a repetitive spaced interval.

I can calculate and schedule the task manually in spreadsheet or notion, but why don’t build a web and overengineered it if I can, duh? So here I am try to create a project that can do this for me. I got no name for the project nor the prd or database modelling, basically I’m blind. And here’s how the AI can help

Create A PRD

I wanted to create a PRD, but I don’t even know what to prompt the AI — in this case I use Google AI Studio with Gemini 2.5 Pro model. So I’m just being honest to the AI and tell that I know nothing about PRD and what to prompt and tell the AI to give me initial instruction that I can use to instruct the AI itself. And it works like a charm, here’s the AI response

Key Information Needed:
Product Vision & Goal:
What is the overall product or feature you want to build? (Give me the elevator pitch.)
What specific problem is it solving for users?
What are the primary business goals? (e.g., Increase revenue, improve user engagement, reduce support costs, enter a new market, test a hypothesis?)
Target Audience:
Who are the primary users? (e.g., Small business owners, teenagers, internal employees, specific job roles?)
Are there different types of users (personas) with different needs?
What are their key pain points or needs related to the problem you're solving?
Core Idea / Proposed Solution:
At a high level, how do you envision solving the problem? What will the product do?
Are there any key capabilities or functionalities that are absolutely essential (MVP scope)?
Are there any existing products (competitors or internal tools) that are relevant? What works well/poorly with them?
Context & Constraints:
Is this a brand new product, or an enhancement to an existing one?
Are there any known technical limitations or requirements? (e.g., Must run on mobile, needs to integrate with Salesforce, specific technology stack preference?)
Are there any budget or timeline constraints I should be aware of?
Are there any specific stakeholders whose needs are critical?
Initial Thoughts (Optional but helpful):
Do you have any early ideas about how you might measure success?
Have you identified any obvious risks or dependencies already?

Then, based on the instruction, of course I am too lazy to write that much detail and I don’t even know that much detail of what I’m trying to build 😀 So its just an iterative steps until the final PRD. And I finally know what to name it, I call it LeetCall! — don’t judge my naming skills.

The final PRD

Link to the prompt history This will lead to Gemini AI Studio

Okay, here is the full Product Requirements Document Draft 1.2, incorporating all the refinements discussed:

Product Requirements Document: LeetCode Spaced Repetition & Progress Sharing App (Draft 1.2)

1. Introduction & Overview

Problem: Developers practicing on platforms like LeetCode struggle to retain solutions and problem-solving patterns over time. Manually tracking problems attempted and scheduling future reviews using general tools like spreadsheets or basic note-taking apps is inefficient, error-prone, difficult to maintain consistently, and lacks features tailored for coding problem practice or collaborative learning.

Product Vision: To create a dedicated web application that empowers developers to effectively memorize LeetCode solutions and algorithmic patterns using the proven principles of spaced repetition (specifically SM-2). The application will streamline the tracking process and enable users to privately share their learning journey and progress with selected peers or mentors.

Goal: Build an intuitive and focused tool that automates the spaced repetition scheduling for LeetCode problems based on user self-assessment using the SM-2 algorithm. It aims to provide centralized tracking, improve long-term retention of concepts, and facilitate controlled progress sharing among registered users, fostering accountability and collaborative learning within a trusted circle.

2. Objectives

O1: Automate Review Scheduling: Eliminate manual tracking by automatically calculating and scheduling the next review date for LeetCode problems using the SM-2 algorithm based on user-provided quality ratings and review history.

O2: Centralize Problem Tracking: Provide a single, dedicated platform for users to log the LeetCode problems they are working on, their review history, and their self-assessed performance on each review.

O3: Improve Retention: Help users commit LeetCode solutions, patterns, and underlying concepts to long-term memory through consistent, algorithmically optimized review intervals.

O4: Facilitate Controlled Progress Sharing: Enable users to securely share their tracked problem list and progress (read-only) with specific, invited registered users of the platform.

O5: Achieve User Adoption & Engagement: Gain initial users (starting with the founder), grow the user base within the target audience, and encourage consistent usage for tracking and reviewing problems.

3. Target Audience

Primary: Individuals actively practicing coding problems on platforms like LeetCode, particularly those preparing for technical interviews, learning data structures and algorithms, or finding manual retention methods challenging.

Secondary: More experienced developers seeking a structured review system; coding bootcamp students; Computer Science students using LeetCode for coursework or practice.

Initial User: The project initiator.

4. Key Features (Minimum Viable Product - MVP)

F1: User Authentication: Ability for users to sign up using email/password and log in. Requires email verification to enable sharing features.

F2: Add LeetCode Problem: Functionality for a logged-in user to select a LeetCode problem from a searchable/browsable list fetched via LeetCode's public API (displaying Title, Difficulty, ID). The app should store selected problem details locally (e.g., frontendQuestionId, title, titleSlug, difficulty, topicTags, paidOnly).

F3: Rate Problem Attempt: After reviewing/solving a tracked problem, allow the user to rate the quality of their response using a 0-5 scale, clearly defined in the UI (e.g., 5=perfect, 4=correct after hesitation, 3=correct with difficulty, 2=incorrect but known, 1=incorrect, 0=complete blackout). This rating is the primary input for the SM-2 algorithm.

F4: Spaced Repetition Scheduling (SM-2): Core backend logic implementing the SM-2 algorithm to calculate the next review date.

Uses the 0-5 quality rating (F3).

Maintains an E-Factor (Ease Factor) per tracked problem instance for each user, starting at 2.5, with a minimum value of 1.3.

Calculates the next inter-repetition interval I(n) based on the previous interval I(n-1) and the current E-Factor EF, using I(n) = I(n-1) * EF. Base cases: I(1)=1 day, I(2)=6 days. Intervals are rounded up to the nearest whole day.

Adjusts the E-Factor after each review based on the quality rating q using the formula: EF' = EF + (0.1 - (5 - q) * (0.08 + (5 - q) * 0.02)).

Resets the repetition sequence (interval calculation restarts from I(1)) if the quality rating q is less than 3, without changing the existing E-Factor.

(Decision for MVP: The SM-2 recommendation to repeat items scoring < 4 within the same study session will be deferred to a potential future release to simplify the initial implementation.)

F5: Review Dashboard: A view displaying a list of all problems whose Next Review Date is on or before the current date, indicating they are due for review. Missed reviews should remain on this list until reviewed.

F6: All Problems List: A view allowing users to see all the LeetCode problems they have added to the system, potentially showing details like Title, Difficulty, Next Review Date, Last Reviewed Date, and current E-Factor.

F7: Manage Sharing: Functionality within a user's account settings to invite other registered and verified users (by email) to view their tracked problem list. Users should also be able to see who currently has access and revoke that access.

F8: View Shared Lists: A dedicated section or mechanism for logged-in users to access and view the tracked problem lists that have been explicitly shared with them by other users (read-only view).

5. User Stories (MVP)

US1: As a logged-in user, I want to browse or search a list of available LeetCode problems (displaying Title, Difficulty) fetched from the official API and select one to add it to my personal tracking list, so that I can start applying spaced repetition to it.

US2: As a logged-in user, when I review a problem from my tracking list, I want to be prompted to rate my recall quality on a clear 0-5 scale (with descriptors), so that the system can accurately calculate the next optimal review date for that problem using the SM-2 algorithm.

US3: As a logged-in user, I want to access a dashboard that clearly lists all the problems that are currently due for review (today or earlier), so that I know what I need to study and can easily catch up on any missed reviews.

US4: As a logged-in user, I want to be able to view my complete list of tracked LeetCode problems, along with relevant status information (like the next review date), so I can get an overview of my learning progress and workload.

US5: As a new user, I want to be able to sign up for an account using my email address and a password, and then verify my email address via a confirmation link, so that I can securely save my progress and utilize features like sharing.

US6: As a logged-in user (Owner), I want to navigate to a sharing management section where I can enter the verified email address of another registered user and grant them read-only permission to view my tracked problem list, so I can share my progress privately with friends or mentors.

US7: As a logged-in user (Viewer), I want to have a section in the application where I can see and access the progress lists that other users have specifically shared with me, so I can follow their learning journey.

US8: As a logged-in user (Owner), I want to view a list of all users I have granted access to my progress list and have the ability to revoke access for any individual user, so I maintain control over who can see my data.

6. Technical Requirements

T1: Frontend/Backend: Full-stack Next.JS (using App Router).

T2: Database ORM: Prisma.

T3: Database: PostgreSQL.

T4: Hosting: Platform to be determined (e.g., Vercel, Fly.io, AWS Amplify, Railway).

T5: Spaced Repetition Algorithm (SM-2 Implementation):

Backend service/logic to implement the SM-2 algorithm precisely as defined in F4.

Database schema must support storing per-user, per-problem state: current_interval_days, ease_factor, repetitions_count, next_review_date.

Requires persistent storage of individual review events: user_id, problem_id, review_timestamp, quality_rating_q, calculated_interval_before_review, ef_before_review.

Ensure calculations handle date arithmetic correctly, including rounding up intervals to whole days. Enforce EF minimum of 1.3. Implement the repetition reset logic for q < 3.

(Decision: Defer same-session reviews for q<4 for MVP).

T6: LeetCode Public API Integration:

Implement reliable fetching of the LeetCode problem list via their public GraphQL endpoint (or alternative public API if available/more suitable).

Parse and store required fields locally: frontendQuestionId (as unique problem identifier), title, titleSlug (for generating LC links), difficulty, topicTags (store as JSON or normalized relation), paidOnly.

Implement a caching strategy (e.g., periodic background job, cache-on-read with TTL) for the fetched LeetCode problem data to minimize external API calls and improve performance.

T7: Sharing Mechanism (Email-based Access Control):

Requires user accounts to have a verified email status.

Implement an invitation/permission system: Owner inputs potential Viewer's email. System checks if Viewer is registered and verified. If yes, creates a permission record.

Database schema required for access control (e.g., a ListShares table with ownerUserId, viewerUserId, permissionType (e.g., 'read'), grantedTimestamp).

Backend authorization logic must enforce these permissions when accessing user problem lists.

Frontend UI for Owners to input emails, view current viewers, and trigger revocation.

T8: User Management & Authentication: Standard email/password sign-up, secure password hashing, login functionality, and an email verification flow (sending a unique link/code).

7. Success Metrics

SM1: User Signups: Total number of registered users with verified email addresses.

SM2: Active Users: Daily Active Users (DAU), Weekly Active Users (WAU), Monthly Active Users (MAU) – focusing on users who log in AND perform a core action (add problem, review problem).

SM3: Problem Tracking Engagement:

Average number of problems tracked per active user.

Total number of problems tracked across the platform.

SM4: Review Completion Rate:

Total number of reviews completed (ratings submitted).

Average number of reviews completed per active user per week/month.

SM5: User Retention: Week 1, Week 4, Month 3 retention rates (percentage of new users returning).

SM6: Sharing Feature Usage:

Total number of unique lists shared (owner-viewer pairs).

Percentage of active users who have shared their list.

Percentage of active users who are viewing at least one shared list.

SM7 (Operational/Insight Metric): Distribution of review quality ratings (0-5) submitted – helps understand user difficulty and algorithm effectiveness.

8. Potential Risks & Dependencies

R1: Algorithm Implementation Complexity: Correctly implementing SM-2 state management (EF, intervals, resets) per user/problem requires careful design and testing. Off-by-one errors or incorrect state updates can degrade user experience.

R2: User Motivation & Churn: The app's value is tied to the user's motivation to practice LeetCode. If users stop practicing, they will likely stop using the app.

R3: Sharing Feature Complexity: Implementing secure, email-based sharing (invites, permissions management, revocation, UI) is significantly more complex than public links and adds considerable development effort for MVP.

R4: Scope Creep: High risk of wanting to add more features to sharing (e.g., commenting, different permission levels) or the SRS algorithm (e.g., customizable intervals, different algorithms) before validating the core MVP loop.

R5: LeetCode API Reliability & Changes: The application depends heavily on the availability, stability, and structure of LeetCode's public API. Any changes, rate limiting, or deprecation could break core functionality (adding problems). Requires monitoring and potential adaptation.

R6: Scalability: As user numbers and tracked problems grow, database queries for dashboards, problem lists, and permission checks need to be performant. Efficient fetching/display of the global LeetCode problem list is also crucial.

R7: User Experience of 0-5 Scale: Users must easily understand the meaning of each numerical rating (0-5) for the SRS algorithm to function as intended. Requires clear labels, tooltips, or onboarding guidance.

D1: SRS Algorithm Fine-tuning: While SM-2 is defined, initial parameters (starting EF, base intervals if deviating slightly) and the exact handling of edge cases need final confirmation. Decision to defer same-session repeats needs to be firm for MVP scope.

D2: LeetCode API Exploration: Thoroughly investigate the specific GraphQL endpoint, its schema, rate limits, and any terms of service regarding its use in third-party applications.

D3: Sharing UI/UX Design: Carefully design the user flows for sending invitations, accepting/viewing shared lists, and managing permissions to be intuitive and secure.

This concludes Draft 1.2. Let me know when you're ready to discuss the next steps, like data modeling.

And there we go, now I have a full PRD that I can use for the next step which is database modelling

Database Modelling

The steps for database modelling basically just provide the PRD to the AI and let it generate the Database Modelling, of course there will be some columns that I don’t want or I want to add, and then I just did a VERY SMALL changes, since the AI has covered all the PRD in the database model

Final database model

-- --- User Authentication & Profile ---
-- Links to the master user record in Supabase Auth (or similar)
DROP TABLE IF exists users cascade;
CREATE TABLE users (
    id UUID PRIMARY KEY NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
    email TEXT, -- Optional cache from auth.users
    name TEXT,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create or replace function handle_new_user()
returns trigger as $$
begin
  insert into public.users
  values(new.id, new.email, new.raw_user_meta_data->>'name', new.created_at);

  insert into public.workspaces(owner_user_id)
  values(new.id);

  return new;
end;
$$ language plpgsql security definer;

create or replace trigger on_new_user
after insert on auth.users for each row
execute procedure public.handle_new_user();

-- --- Workspaces ---
-- Represents a container for tracked LeetCode problems.
-- A user might have one or more workspaces (though MVP might focus on one initially).
DROP TABLE IF exists workspaces cascade;
CREATE TABLE workspaces (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- Use built-in UUID generation
    owner_user_id UUID NOT NULL, -- The user who created/owns the workspace
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP, -- Needs trigger for auto-update

    -- Relationship to the owner
    -- Use RESTRICT initially: prevent deleting a user if they still own workspaces.
    CONSTRAINT fk_workspaces_owner FOREIGN KEY (owner_user_id) REFERENCES users(id) ON DELETE RESTRICT
);

-- Index for fetching workspaces owned by a user
CREATE INDEX idx_workspaces_owner_user_id ON workspaces(owner_user_id);

-- --- Canonical LeetCode Problem Data ---
-- (No changes needed here)
DROP TABLE IF exists leet_code_problems cascade;
CREATE TABLE leet_code_problems (
    id TEXT PRIMARY KEY, -- Assuming CUID generated by application
    frontend_question_id TEXT NOT NULL UNIQUE,
    title TEXT NOT NULL,
    title_slug TEXT NOT NULL UNIQUE,
    difficulty VARCHAR(10) NOT NULL,
    paid_only BOOLEAN NOT NULL,
    topic_tags JSONB,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE INDEX idx_leet_code_problems_frontend_question_id ON leet_code_problems(frontend_question_id);
CREATE INDEX idx_leet_code_problems_title_slug ON leet_code_problems(title_slug);

-- --- Tracking a Specific LeetCode Problem within a Workspace ---
DROP TABLE IF exists tracked_problems cascade;
CREATE TABLE tracked_problems (
    id bigint primary key generated always as identity, -- Assuming CUID generated by application
    -- **** CHANGED **** Removed user_id, added workspace_id
    workspace_id UUID NOT NULL,
    problem_id TEXT NOT NULL,

    -- SM-2 State (unchanged)
    ease_factor DOUBLE PRECISION NOT NULL DEFAULT 2.5,
    interval_days INTEGER NOT NULL DEFAULT 0,
    repetitions_count INTEGER NOT NULL DEFAULT 0,
    next_review_date TIMESTAMP WITH TIME ZONE NOT NULL,
    last_reviewed_at TIMESTAMP WITH TIME ZONE,

    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,

    -- **** UPDATED **** Foreign key constraint references workspaces table
    CONSTRAINT fk_tracked_problems_workspace FOREIGN KEY (workspace_id) REFERENCES workspaces(id) ON DELETE CASCADE, -- If workspace deleted, delete its tracked problems
    CONSTRAINT fk_tracked_problems_problem FOREIGN KEY (problem_id) REFERENCES leet_code_problems(id) ON DELETE RESTRICT,

    -- **** UPDATED **** Ensure a problem is tracked only once PER WORKSPACE
    CONSTRAINT uq_tracked_problems_workspace_problem UNIQUE (workspace_id, problem_id)
);

-- **** UPDATED **** Indices reflecting the change
CREATE INDEX idx_tracked_problems_workspace_id ON tracked_problems(workspace_id);
CREATE INDEX idx_tracked_problems_problem_id ON tracked_problems(problem_id);
CREATE INDEX idx_tracked_problems_next_review_date ON tracked_problems(next_review_date); -- Still needed for review dashboard query

-- --- Record of a Single Review Event ---
-- (No direct change needed, still links to tracked_problems)
DROP TABLE IF exists reviews cascade;
CREATE TABLE reviews (
    id bigint primary key generated always as identity, -- Assuming CUID generated by application
    tracked_problem_id bigint NOT NULL,
    quality_rating INTEGER NOT NULL,
    reviewed_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT fk_reviews_tracked_problem FOREIGN KEY (tracked_problem_id) REFERENCES tracked_problems(id) ON DELETE CASCADE
);
CREATE INDEX idx_reviews_tracked_problem_id ON reviews(tracked_problem_id);

-- --- Workspace Sharing Permissions ---
-- **** RENAMED and RESTRUCTURED **** (Replaces list_shares)
DROP TABLE IF exists workspace_shares cascade;
CREATE TYPE user_role AS ENUM ('viewer', 'editor', 'reviewer');
CREATE TABLE workspace_shares (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(), -- Use built-in UUID generation
    -- The workspace being shared
    workspace_id UUID NOT NULL,
    -- The user being granted access
    shared_user_id UUID NOT NULL,

    role user_role NOT NULL,
    -- Optional: Add permission level later (e.g., 'read', 'write') if needed

    granted_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,

    -- Relationships
    CONSTRAINT fk_workspace_shares_workspace FOREIGN KEY (workspace_id) REFERENCES workspaces(id) ON DELETE CASCADE, -- If workspace deleted, remove shares for it
    CONSTRAINT fk_workspace_shares_viewer FOREIGN KEY (shared_user_id) REFERENCES users(id) ON DELETE CASCADE, -- If viewer user deleted, remove shares granted TO them

    -- Ensure a user has only one share entry per workspace
    CONSTRAINT uq_workspace_shares_workspace_viewer UNIQUE (workspace_id, shared_user_id)
);

-- Indices for looking up shares by workspace or viewer
CREATE INDEX idx_workspace_shares_workspace_id ON workspace_shares(workspace_id);
CREATE INDEX idx_workspace_shares_shared_user_id ON workspace_shares(shared_user_id);

Code Writing

For the code writing, I use GitHub Copilot to help me, what I did is I create a GitHub Instructions file and Prompt file — Sources: GitHub Copilot GitHub Instructions. And it helps me so much since the PRD and database model is very clear already.

Conclusion

Honestly, building LeetCall from scratch using AI was quite the experience. From getting the initial idea down into a proper plan (the PRD 📝), sorting out the database structure 📊, to actually speeding up the coding with GitHub Copilot 💻, AI was a huge help. It wasn't just about plugging gaps in what I knew or handling boring tasks; it genuinely made the whole development process faster. If you ever feel stuck or a bit lost starting a project, particularly with stuff outside your main skills, I'd definitely say give AI tools a try. They can really help bring your ideas to life quicker than you might expect. 👍

The conclusion above is written by A.I, here’s my own conclusion “AI covered my skill issue in a superbly good way”

DEV Community: Aidityas Adhakim

Workspace Shares Made Easy with Permit IO! LeetCall: Master LeetCode with Spaced Repetition

📚 Table of Contents

What I Built

Sharing Progress

Prerequisites

How Does LeetCall Works?

1. User Add LeetCode Problem to be Tracked

2. How Does the Space Repetition Algorithm Works?

Demo

Project Repo

LeetCall Demo Video

My Journey

Designing Authorization Schema

Problem When Building With External Authorization

How Can External Authorization Help Building an Entire Application?

Using Permit.io for Authorization

How Does the Sharing Workspace Designed?

How to Set Up Your Authorization Schema Using the Permit CLI

Lets talk about the permitio-migration.js file

Conclusion

Related Articles

Deploy Permit.IO PDP To Heroku Under 5 Mins! [Video Included]

🚀 Deploying Permit.io PDP to Heroku

✅ Prerequisites

🛠️ Setup

⚙️ Configuration File

1. Create a Dockerfile

2. Create a heroku.yml File

🚢 Deployment

🎉 Success!

Tutorial Video!

Building Project With AI Assisted From Scratch: LeetCall

Link to the final product: LeetCall

The Idea

Create A PRD

The final PRD

Database Modelling

Final database model

Code Writing

Conclusion

Lets talk about the `permitio-migration.js` file

2. Create a `heroku.yml` File