One is my office account with the Pro plan. Another is a shared account I use with my colleagues on the Max plan.

At first, I assumed this would be simple.

Log out. Log in. Maybe switch profiles. Done.

But that is not how Claude Code works.

Every time I switched accounts, I either lost my project history, lost my custom commands, or had to keep setting everything up again.

And the worst part?

The only thing that actually needed to be different between accounts was the authentication.

Everything else — my project history, my commands, my MCP setup, my CLAUDE.md instructions, my settings — should have stayed the same.

Instead, Claude Code treats everything as one giant config folder.

So if you want multiple accounts, you end up duplicating everything.

That quickly becomes painful.

The Actual Problem

Claude Code stores almost everything inside a single config directory.

That includes:

• Authentication

• Settings

• Project history

• Custom commands

• MCP configuration

• CLAUDE.md instructions

The issue is that authentication is account-specific.

But the rest is not.

I do not want separate project histories for every account. I do not want to recreate the same custom commands three times. I definitely do not want to copy-paste the same CLAUDE.md file every time I make a change.

After a few switches, my setup looked like this:

• One account had the latest commands

• Another had the right MCP config

• A third one had the actual project history I wanted

Everything was fragmented.

And every time I switched accounts, something would silently stop working.

The Setup That Actually Works

The fix was separating authentication from everything else.

Instead of giving every account its own full Claude config, I created:

• One shared folder for everything common

• One small folder per account containing only auth

My setup now looks like this:

The fix was separating authentication from everything else.

Instead of giving every account its own full Claude config, I created:

• One shared folder for everything common

• One small folder per account containing only auth

My setup now looks like this:

~/.claude-shared/
  settings.json
  CLAUDE.md
  projects/
  commands/
  mcp.json

~/.claude-office-pro/
  auth.json
  settings.json -> ~/.claude-shared/settings.json
  CLAUDE.md -> ~/.claude-shared/CLAUDE.md
  projects -> ~/.claude-shared/projects
  commands -> ~/.claude-shared/commands
  mcp.json -> ~/.claude-shared/mcp.json

~/.claude-shared-max/
  auth.json
  settings.json -> ~/.claude-shared/settings.json
  CLAUDE.md -> ~/.claude-shared/CLAUDE.md
  projects -> ~/.claude-shared/projects
  commands -> ~/.claude-shared/commands
  mcp.json -> ~/.claude-shared/mcp.json

The only real file that is different between accounts is auth.json.

Everything else is shared using symlinks.

Which means:

• I log into each account once

• All accounts use the same project history

• All accounts use the same commands

• All accounts use the same CLAUDE.md instructions

• Changing something in one place updates it everywhere

This was the first setup that actually felt usable.

Setting It Up

First, create the shared folder and separate account folders.

mkdir -p ~/.claude-shared
mkdir -p ~/.claude-office-pro
mkdir -p ~/.claude-shared-max

Then move all the common files into the shared folder.

mv ~/.claude/settings.json ~/.claude-shared/
mv ~/.claude/CLAUDE.md ~/.claude-shared/
mv ~/.claude/projects ~/.claude-shared/
mv ~/.claude/commands ~/.claude-shared/
mv ~/.claude/mcp.json ~/.claude-shared/

Now create symlinks inside each account folder.

ln -s ~/.claude-shared/settings.json ~/.claude-office-pro/settings.json
ln -s ~/.claude-shared/CLAUDE.md ~/.claude-office-pro/CLAUDE.md
ln -s ~/.claude-shared/projects ~/.claude-office-pro/projects
ln -s ~/.claude-shared/commands ~/.claude-office-pro/commands
ln -s ~/.claude-shared/mcp.json ~/.claude-office-pro/mcp.json

ln -s ~/.claude-shared/settings.json ~/.claude-shared-max/settings.json
ln -s ~/.claude-shared/CLAUDE.md ~/.claude-shared-max/CLAUDE.md
ln -s ~/.claude-shared/projects ~/.claude-shared-max/projects
ln -s ~/.claude-shared/commands ~/.claude-shared-max/commands
ln -s ~/.claude-shared/mcp.json ~/.claude-shared-max/mcp.json

Then create aliases so switching accounts becomes one command.

alias claude-office='CLAUDE_CONFIG_DIR=~/.claude-office-pro claude'
alias claude-shared='CLAUDE_CONFIG_DIR=~/.claude-shared-max claude'

Now when I want to use my office Pro account, I run:

claude-office

And when I want to switch to the shared Max account that I use with my colleagues:

claude-shared

That is it.

No logging in again. No copying files. No broken commands.

The Bigger Lesson

This looked like a Claude Code problem.

But it is actually a common problem with developer tools.

Most tools bundle:

• Identity

• Configuration

• User data

Into one folder.

That works fine until you need multiple accounts.

Then suddenly the thing you actually want to isolate — authentication — is tied to a bunch of things that should have been shared.

The best setups separate those concerns.

Authentication should be isolated. Everything else should be reusable.

Once I changed my Claude setup to follow that idea, switching accounts stopped feeling like context switching.

It finally felt like the same workspace, just with a different login.

And honestly, that is probably how it should have worked in the first place.

Strong suggestion: don’t copy my workflow — read through the failures, mistakes, and learnings, and use them to craft a workflow that works for you.

If you want to jump straight to my current workflow, go here →
👉 Iteration 7: My Current Workflow (What Finally Worked)

I’ve been thinking about writing this for a while.

I’m still learning, but over the past year, I’ve been coding with AI almost every day — both in personal projects and in production systems at work. I’m not claiming this is the best way to use AI, but this is the workflow that helped me compress what usually takes three weeks into two days.

This blog isn’t about a single “aha” moment.
It’s about iterations — where things worked, where they broke, and what each failure taught me.

Iteration 1: AI Felt Like Magic

When I first started coding with AI, I was honestly impressed.

Things that used to take real mental effort were getting done effortlessly:

• Solving a LeetCode problem

• Creating Simple UI with React and Stylings

• Writing a simple API to CRUD a model

AI handled all of this extremely well.

At this stage, I was mostly using Cursor for personal projects. These projects were small, the codebase was tiny, and the AI had very little context to reason about.

Naturally, I assumed:

“If this works so well for personal projects, it should work even better for office projects.”

That assumption didn’t last long.

Iteration 2: Production Codebases Change Everything

Around 6–8 months ago, my company gave me a paid Cursor license.
I started using it on our actual product codebase.

The difference was immediate.

Same prompts.
Same workflow.
Completely different results.

In personal projects, the AI was dealing with hundreds or a few thousand lines of code.
In production, it had to reason about tens of thousands of lines, multiple modules, and years of architectural decisions.

That’s when things started breaking.

Iteration 3: Ask → Plan → Build (Worked… Until It Didn’t)

To regain control, I introduced structure.

Before implementing any feature, I started doing this:

1. Switch Cursor to Ask mode

2. Ask it to understand specific folders or modules

3. Explain the feature I wanted to build

4. Ask it to give me a plan

5. Switch to Agent mode and ask it to implement the plan

This was before Cursor even had a dedicated Plan mode.

And honestly — it worked really well.

I completed multiple backend-heavy features using this approach, and I was genuinely surprised by how well the AI understood the code and executed changes.

Until I hit a full-stack feature.

Iteration 4: Full-Stack Complexity Broke the Workflow

The next feature involved everything:

• Frontend

• Backend

• Queues and background jobs

• Socket events

• Real-time UI updates

• State management

The number of moving parts exploded.

I followed the same workflow.

The output was bad.

• TypeScript types replaced with any and unknown

• Method signature mismatches

• Code written just to “make it work”

• Hidden bugs everywhere

That’s when I realized something important:

The workflow didn’t change.
The task complexity did.

Iteration 5: Treating AI Like a Fresh Developer

I asked myself a simple question:

“If I were giving this task to a fresh developer, how would I do it?”

I wouldn’t explain everything at once.

So I split the feature into independent chunks:

1. Backend

2. Frontend

The backend agent didn’t know about the frontend.
The frontend agent only knew the API contract.

For the backend, I gave very clear instructions:

• Queue behaviour

• API design

• Event flow

Then I handed the API contract to the frontend.

This worked beautifully.

Until I tried spinning up a new microservice.

Iteration 6: Plan Mode Enters (And Still Fails at Scale)

Around this time, Cursor launched Plan mode, and naturally, I started using it heavily.

On paper, this felt like the missing piece.

The idea was simple:

• Create a detailed plan in markdown

• Let the agent refer to it instead of holding everything in memory

• Execute step by step

For medium-sized features, this worked really well.

But then I hit a much bigger task.

This feature involved:

• Creating a new microservice

• Linking it with existing services

• Implementing cutting edge tools

• Adopting modern Node.js and TypeScript patterns

• Handling cross-service communication

I brainstormed deeply with the AI and created a pixel-perfect plan.

The plan itself was solid.

The execution wasn’t.

• any everywhere

• Interface mismatches

• Build failures

• Runtime issues

That’s when I finally understood the real problem:

Even with Plan mode, a single massive plan is still too much context.

Plan mode helped — but it didn’t remove the need to break the problem down further.

Why This Fails (Even for Humans)

Imagine your CTO hands you:

• An 800–900 page tech requirement document, includes

• Multiple microservices

• Multiple protocols like Kafka or gRPC

• Multiple external dependencies

…and asks you to implement everything in a single go.

You wouldn’t be productive.

That’s why we have:

• Epics

• User stories

• Tasks

But when it comes to AI, we forget this and treat it like a supernatural entity.

It’s not.

It has limits.

Iteration 7: My Current Workflow (What Finally Worked)

This is the workflow that actually stuck.

Step 1: Start With High-Level Architecture

No function signatures.
No deep implementation details.

Just:

• Models

• Responsibilities

• Clear system boundaries

Step 2: Let AI Propose Mid-Level Phases

I ask the AI to break the feature into phases.

Usually, I get something like:

• 8 phases

• Each phase with 4–5 bullet points

Now the big feature is split into manageable chunks.

Step 3: Create a Separate Plan for Each Phase

Each phase gets its own plan:

• Separate document

• Less than ~500 lines

• Focused and crisp

A 5,000-line plan is no better than no plan.

Step 4: Manual Review Is Mandatory

Before building anything, I review each plan:

• Fix naming

• Correct modeling flaws

• Adjust structure

You cannot blindly trust AI.
You still own the architecture.

Step 5: Build Phase by Phase

Slow.
Deliberate.
Controlled.

Phase 1 → Build
Phase 2 → Build
…
Phase 8 → Build

This is where everything finally clicked.

The Result

The entire feature was completed in 2–3 days.

Without this workflow, it would have easily taken weeks.

The code was:

• Clean

• Strongly typed

• No unnecessary any

• Easy to reason about and maintain

Final Thoughts

AI productivity gains are real — but only if you respect its limits.

Think of AI as:

A very fast fresh developer who needs clear, scoped, precise instructions

This is my 7th iteration of this workflow, and it’ll iterate as the complexity increases.

If you think I missed something, tell me.
If you’ve found a better approach, share it.

Let’s learn from each other and write better code with AI, not just more code.

Cheers!

People are obsessed with TypeScript, and I don't say it's wrong.

But when it's used incorrectly (without proper clean code principles), even it'll cause a disaster instead of saving us.

Let me give you an example:

The Problem

const getLogs = (
  userId: string,
  from?: Date,
  to?: Date,
  sort?: Map<string, number>,
  limit?: number,
  lastLogId?: string
) => {};

This function might look fine at first glance, but it's not.

Now think about the consumer:

How will they know the order of all those optional parameters?

Having this many parameters in a function not only makes it harder to maintain but also makes it prone to errors.

The Solution

Here's a cleaner approach:

interface LogsOptions {
  interval?: {
    from?: Date;
    to?: Date;
  };
  pagination?: {
    limit?: number;
    lastLogId?: string;
  };
  sort?: Map<string, number>;
}

const getLogs = (userId: string, options?: LogsOptions) => {};

This approach is:
✅ Cleaner
✅ Easier to maintain
✅ Less prone to errors

Consumers can immediately understand what parameters are available without guessing.

Moral of the story

TypeScript alone won't save your product. Regardless of the language or framework you use, clean code principles play a vital role in your product's longevity.

Frameworks and languages come and go, but the fundamentals stay the same.

💬 What practices do you follow to keep your product alive? Share your thoughts in the comments!

Cheers,
Navayuvan Subramanian

I used to believe that small PRs were the cleanest and best way to develop.

But in recent times, I've realized this approach doesn't always work.

This might be effective for companies moving at a slower pace.

However, for startups pushing out at least one release a week, this can slow things down significantly. 🐢

In most startups, developers own large chunks of features.

Splitting these into smaller tasks and raising separate PRs not only wastes time but also makes reviewers lose context about the feature as a whole. 😵‍💫

But then, reviewing a PR with 100+ file changes is no walk in the park either. So, what's the solution?

Here's what works for me:

Provide a clear description of the changes.

You don't need to be overly detailed, but a high-level summary of the changes goes a long way.

Avoid unnecessary changes

Skip alignment changes or edits unrelated to the feature you're working on.

Annotate unrelated changes

If some unrelated changes are unavoidable, add comments explaining why they're included. This helps reviewers stay on track.

Streamline priority reviews.

Let's be real---no one jumps to review a massive PR immediately. If it's a priority, set up a quick call with the reviewers to explain the changes. It makes the review process faster and more efficient.

Respect the reviewer's time

Ask your reviewers when they can reasonably review the PR and follow up after the deadline. Respecting their time is key.

Follow up without annoying

Reviewers have their own priorities, and forgetting your PR is natural. Gently remind them without being pushy to get it reviewed.

This is how I approach or request PR reviews at my workplace.

How do you handle your PR reviews? Let me know in the comments! 💬

And don't forget to follow Navayuvan Subramanian for more tech insights! 🚀

Let me make it clear with an example: Todoist.

It's a simple to-do app with a monthly subscription of $5.

Now, we might think, "I can develop that app myself." But, hear me out!

The payment we provide them includes:
👉 The research they've done to make a feature usable.
👉 The efforts they've put in to integrate with other applications. (Slack, G-Cal, etc.)
👉 Client app support across multiple platforms (browser extensions, desktop, web apps, etc.).
👉 Constant improvement of existing features or the development of new ones.
👉 And many more.

Now, can we do all of this consistently just to save $5? Absolutely not! 🙅‍♂️

The efforts involved in doing these are enormous, and there's an entire company dedicated to it. So, instead of building it ourselves, paying for the subscription seems like a smarter choice. 💡

Does that mean we should never build an app for ourselves? Not at all. 🙌

Here's when it makes sense to build the app ourselves:
- When there are no apps on the market suitable for our needs.
- When the amount we'd pay for an app is less than or equal to the value of the time we save by not developing it ourselves.
- When the existing apps in the market have major pain points, solving them could even lead to a new startup or business idea.

If any of these criteria are met, then building it ourselves might be the way to go! 🚀

In the end, it's all about balancing time and effort. ⚖️

So, the next time you think about building an app yourself, take a moment to reflect on whether it's really worth the time and effort you're about to invest. Then, decide wisely! ✅

And, don't forget to follow me. I'll be dropping some interesting stuffs soon 😉

Your fellow developer,
Navayuvan Subramanian

Let’s explore building a robust HTTP Client in React TypeScript, integrating caching with Tanstack Query (formerly React Query), and creating custom hooks that streamline your API calls.

🌐 Understanding HTTP APIs

HTTP (HyperText Transfer Protocol) is the universal language systems use to communicate. Whether it’s fetching data, updating a resource, or deleting something from the server, HTTP has got us covered. Here’s a quick refresher on the HTTP methods:

• GET: Grabs the data you need from the server.

• POST: Sends data to create something new on the server.

• PUT: Updates an existing resource entirely.

• PATCH: Updates a part of an existing resource.

• DELETE: Removes something from the server.

Each method is like a tool in your toolbox—pick the right one for the job, and your APIs will be a joy to work with.

💡 Why Axios?

So, why are we using Axios for our HTTP Client? Imagine having a personal assistant who handles all the boring tasks like adding headers, dealing with JSON, and managing timeouts—Axios does just that! It’s a library that simplifies HTTP requests, making our code cleaner and easier to maintain.

🛠️ Creating the HTTP Client

Step 1: Installing Axios

Before we dive into the fun stuff, let’s install Axios:

npm install axios

Step 2: Setting Up the HTTP Client

Now, let’s set up our HTTP Client to make API calls a breeze.

import axios, { AxiosInstance, AxiosRequestConfig, AxiosResponse } from "axios";

class HttpClient {
  private instance: AxiosInstance;

  constructor(baseURL: string) {
    this.instance = axios.create({
      baseURL,
      withCredentials: true,
    });

    this.instance.interceptors.request.use(this.handleRequest);
    this.instance.interceptors.response.use(this.handleResponse);
  }

  private handleRequest = (config: AxiosRequestConfig): AxiosRequestConfig => {
    const token = localStorage.getItem("authToken"); // Replace with your token logic
    if (token) {
      if (!config.headers) {
        config.headers = {
          Authorization: `Bearer ${token}`,
        };
        return config;
      }

      config.headers["Authorization"] = `Bearer ${token}`;
    }
    return config;
  };

  private handleResponse = (response: AxiosResponse): AxiosResponse => {
    return response;
  };

  public get<T>(
    url: string,
    config?: AxiosRequestConfig
  ): Promise<AxiosResponse<T>> {
    return this.instance.get<T>(url, config);
  }

  public post<T>(
    url: string,
    data: any,
    config?: AxiosRequestConfig
  ): Promise<AxiosResponse<T>> {
    return this.instance.post<T>(url, data, config);
  }

  public put<T>(
    url: string,
    data: any,
    config?: AxiosRequestConfig
  ): Promise<AxiosResponse<T>> {
    return this.instance.put<T>(url, data, config);
  }

  public patch<T>(
    url: string,
    data: any,
    config?: AxiosRequestConfig
  ): Promise<AxiosResponse<T>> {
    return this.instance.patch<T>(url, data, config);
  }

  public delete<T>(
    url: string,
    config?: AxiosRequestConfig
  ): Promise<AxiosResponse<T>> {
    return this.instance.delete<T>(url, config);
  }
}

const httpClient = new HttpClient("https://jsonplaceholder.typicode.com");
export default httpClient;

Create a User Model

export interface Address {
  street: string;
  suite: string;
  city: string;
  zipcode: string;
  geo: {
    lat: string;
    lng: string;
  };
}

export interface Company {
  name: string;
  catchPhrase: string;
  bs: string;
}

export interface User {
  id: number;
  name: string;
  username: string;
  email: string;
  address: Address;
  phone: string;
  website: string;
  company: Company;
}

🔄 Handling API Requests

Creating a User

const createUser = async (userData: UserData) => {
  const response = await httpClient.post<User>('/users', userData);
  return response.data;
};

Fetching Users

const fetchUsers = async () => {
  const response = await httpClient.get<User[]>('/users');
  return response.data;
};

Updating a User

const updateUser = async (userId: string, userData: UserData) => {
  const response = await httpClient.put<User>(`/users/${userId}`, userData);
  return response.data;
};

Deleting a User

const deleteUser = async (userId: string) => {
  const response = await httpClient.delete(`/users/${userId}`);
  return response.data;
};

🗄️ The Power of Caching with Tanstack Query

When consuming APIs, one of the biggest challenges is managing the state of the data—especially when it comes to caching. Caching allows us to store responses so that repeated requests for the same data can be served faster, improving the overall performance of our application. This is where Tanstack Query comes in. Tanstack Query is a powerful data-fetching library that makes it simple to manage server-state in your React apps, with built-in caching, synchronization, and more.

Installation

To get started, install Tanstack Query:

npm install @tanstack/react-query

⚙️ Creating Custom Hooks for API Requests

Creating custom hooks makes your API calls reusable and easier to manage. For each type of request (fetch, create, update, delete), we'll create a custom hook using Tanstack Query and the HttpClient we built earlier.

Setting Up Query Keys

First, let's define some constants for our query keys:

// queryKeys.ts
export const QUERY_KEYS = {
  USERS: 'users',
  USER: (userId: string) => ['user', userId],
};

Custom Hooks Examples

Fetching Users

import { useQuery } from '@tanstack/react-query';
import httpClient from '../api/HttpClient';
import { QUERY_KEYS } from '../api/queryKeys';
import { User } from '../api/interfaces';

const useFetchUsers = () => {
  return useQuery<User[]>({
    queryKey: [QUERY_KEYS.USERS],
    queryFn: () => httpClient.get<User[]>("/users").then((res) => res.data),
  });
};

Creating a User

import { useMutation, useQueryClient } from '@tanstack/react-query';
import httpClient from '../api/HttpClient';
import { QUERY_KEYS } from '../api/queryKeys';
import { User } from '../api/interfaces';

const useCreateUser = () => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (newUser: Omit<User, "id">) =>
      httpClient.post<User>("/users", newUser),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: [QUERY_KEYS.USERS] });
    },
  });
};

Updating a User

import { useMutation, useQueryClient } from '@tanstack/react-query';
import httpClient from '../api/HttpClient';
import { QUERY_KEYS } from '../api/queryKeys';
import { User } from '../api/interfaces';

const useUpdateUser = (userId: number) => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: (updatedUser: Partial<Omit<User, "id">>) =>
      httpClient.put<User>(`/users/${userId}`, updatedUser),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: [QUERY_KEYS.USERS] });
      queryClient.invalidateQueries({
        queryKey: [QUERY_KEYS.USER(userId.toString())],
      });
    },
  });
};

Deleting a User

import { useMutation, useQueryClient } from '@tanstack/react-query';
import httpClient from '../api/HttpClient';
import { QUERY_KEYS } from '../api/queryKeys';

const useDeleteUser = (userId: number) => {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: () => httpClient.delete(`/users/${userId}`),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: [QUERY_KEYS.USERS] });
    },
  });
};

Consumption of Hooks!

Here's a sample of how you can consume those hooks. We're using jsonplaceholder for mock APIs. You can see it in HttpClient file.

const App: React.FC = () => {
  const { data: users } = useFetchUsers();
  const createUser = useCreateUser();
  const updateUser = useUpdateUser(1); // Example user ID
  const deleteUser = useDeleteUser(1); // Example user ID

  return (
      <div>
        <h1>Users</h1>
        <button onClick={() => createUser.mutate(newUser)}>Create User</button>
        <button
          onClick={() =>
            updateUser.mutate({
              name: "Updated User",
            })
          }
        >
          Update User
        </button>
        <button onClick={() => deleteUser.mutate()}>Delete User</button>

        <ul>
          {users?.map((user: User) => (
            <li key={user.id}>
              {user.id} - {user.name}
            </li>
          ))}
        </ul>
      </div>
  );
};

📦 Wrapping It Up

Efficiently consuming APIs is crucial for building performant and scalable applications. By setting up a robust HTTP Client with Axios, handling state with Tanstack Query, and creating custom hooks for each API request, you’ll be well on your way to mastering API consumption in React TypeScript.

Remember, the key is to keep your code modular and reusable. As your application grows, these practices will help you maintain a clean and efficient codebase.

Have you ever missed an important task because your reminder got buried in the avalanche of notifications? I used to struggle with this too, until I developed something that completely transformed how I manage tasks.

Like many of you, I relied on standard reminder apps, but they just weren’t cutting it. Sure, they send notifications with a sound, but with the constant barrage of alerts, spotting the right one can feel like finding a needle in a haystack.

I needed something more—a reminder that not only grabs my attention but refuses to be ignored until I act on it. After searching for an app that could do this and coming up empty-handed, I decided to create my own solution.

While building a full-fledged app like Todoist was beyond my immediate scope, I developed a helper application to complement it: NeverForget.

The idea is simple yet powerful: when you add a task to Todoist with a date and time, NeverForget will notify you at the perfect moment.

But here’s the game-changer—the notification is persistent and can’t be cleared until you tap “Done.”

For the past four months, NeverForget has helped me remember and complete tasks I would have otherwise overlooked. 📝

Let me show you how it works.

How to Add Reminders in NeverForget

First things first: You can’t directly add and manage tasks in NeverForget. It’s designed to be a helper application.

If you’re a Todoist user, adding tasks with specific properties will trigger notifications in NeverForget. Here’s how you can set it up.

Connect Todoist with NeverForget

1. Download NeverForget from the Play Store and create an account or log in.

2. If you’re a new user, you’ll be prompted to "Connect to Todoist."

3. Click on that option and proceed to log into your Todoist account.

4. Once your accounts are connected, you’ll land on the Empty Home page.

Add a Reminder from Todoist to NeverForget

1. Open Todoist and create a label named "Reminder" or "Reminders."

2. To add a reminder, ensure your task meets two criteria:

   1. It includes the “Reminder” label we just created.

   2. It has a due date and time to trigger the notification.

And that’s it! Once you’ve set this up, NeverForget will ensure you never miss an important task again.

What’s Next?

We’re excited to announce that more integrations, like Google Calendar, are on the way! Stay tuned as we continue to expand NeverForget’s capabilities, making it even easier to stay on top of your tasks across multiple platforms.