DEV Community: Yogesh Raj Kabilan

Building a Local-First Task Manager with Next.js and React — Lessons from Planow

Yogesh Raj Kabilan — Wed, 29 Apr 2026 17:05:48 +0000

An honest engineering breakdown of building Planow — the decisions, tradeoffs, and lessons that mattered.

Syed and I had been circling around the idea of building Planow for roughly four years. Not continuously — it surfaced the way most side projects do: in moments of frustration, when existing tools felt unnecessarily complex or slow.

We didn’t want another bloated productivity tool.

We wanted something that answers one question instantly:

“What should I do right now?”

That naturally led us to the Eisenhower Matrix.

The idea was simple:

Categorize tasks by urgency and importance
Make prioritization visual and immediate

But building something that feels instant and intuitive turned out to be the real challenge.

Planow is built on a simple idea: your tasks should be fast, private, and available the moment you think of them — not after a network request.

The Stack — Choosing the Future (With Tradeoffs)

I made a deliberate decision early: Build on where the ecosystem is going, not where it is.

Next.js 16 (Canary) + React 19
TypeScript
Tailwind CSS v4
Zustand
Supabase
@hello-pangea/dnd

Next.js 16 (Canary) + React 19: Both pre-stable when I started. I made this call deliberately. My reasoning: we were building something we intended to use long-term, and building on the current stable release meant I’d be doing a framework migration in six months regardless. React 19’s improvements to concurrent rendering and transitions were directly relevant to the drag-and-drop experience I had in mind. I accepted the tradeoff — occasional canary instability, fewer Stack Overflow answers — in exchange for building on where the ecosystem was actually heading.

TypeScript throughout: Not a stylistic preference. The core Task interface flows through the UI layer, the Zustand store, the Supabase integration, and the drag-and-drop logic. Without TypeScript keeping the shape of that data honest across all four, you’re just hoping nothing breaks at runtime.

Tailwind CSS v4 — also pre-stable. The removal of the tailwind.config.js requirement and improved CSS variable integration in v4 were what pushed me toward it. I use Tailwind for layout utilities, spacing, and responsive breakpoints only. All color and typography tokens live in theme.css as CSS custom properties. That architecture decision mattered more than the Tailwind version.

Zustand for state. Redux felt excessive for the scope. Context didn’t scale cleanly. Zustand hit the right balance. Zustand was minimal and powerful. Zustand worked because of its simple API, centralized state, easy async handling and built-in persistence support. It became the backbone for state, persistence, and optimistic updates.

Supabase for backend, auth, and real-time. PostgreSQL, row-level security, Google OAuth, and WebSocket subscriptions in one managed service. I’m not in the business of running database infrastructure. Supabase let me stay focused on the product.

@hello-pangea/dnd for drag-and-drop. The community-maintained fork of react-beautiful-dnd, updated for React 18+ compatibility. react-beautiful-dnd is no longer actively maintained by Atlassian — using the fork was the safer long-term call.

The Data Architecture — Getting Flat Right

Early in the build I had to make a foundational decision about the data shape. The obvious approach for a Kanban-style board is a map keyed by column name:

// The tempting approach
mainData: {
  Do: Task[],
  Schedule: Task[],
  Delegate: Task[],
  Limit: Task[],
  Later: Task[]
}

This makes rendering easy. It makes drag-and-drop operations locally easy. It makes syncing to a relational database a nightmare. Every operation that touches the database requires you to reconstruct which array a task lives in, and your data shape in the client diverges from your data shape in the DB.

I went with a flat array instead, with each task carrying its own boardName (and later board_id). The rendering layer groups by quadrant. Every database operation is a straightforward row operation.

// Flat array - what I actually used
mainData: Task[] // each task has boardName: 'Do' | 'Schedule' | etc.

This decision paid off when I connected to Supabase. No transformation layer needed. Fetch from DB, set in store, render.

The Drag-and-Drop Reorder Problem

This is where most Kanban implementations quietly take shortcuts.

The naive approach is to sort by createdAt timestamp and treat position as implicit. This works until someone drags a card, at which point your timestamp is semantically wrong. You need an explicit position integer column.

My drag handler:

function handleOnDragEnd(result: any) {
  const { source, destination } = result;
  if (!destination) return;
  const sourceItems = mainData
    .filter((task) => task.boardName === source.droppableId)
    .sort((a, b) => a.position - b.position);
  const destItems = mainData
    .filter((task) => task.boardName === destination.droppableId)
    .sort((a, b) => a.position - b.position);
  if (source.droppableId === destination.droppableId) {
    const reordered = [...sourceItems];
    const [removed] = reordered.splice(source.index, 1);
    reordered.splice(destination.index, 0, removed);
    const updated = reordered.map((task, i) => ({ ...task, position: i }));
    updateData(updated);
    return;
  }
  const newSource = [...sourceItems];
  const [removed] = newSource.splice(source.index, 1);
  const newDest = [...destItems];
  newDest.splice(destination.index, 0, removed);
  const updatedSource = newSource.map((task, i) => ({ ...task, position: i }));
  const updatedDest = newDest.map((task, i) => ({
    ...task,
    boardName: destination.droppableId,
    position: i,
  }));
  const untouched = mainData.filter(
    (t) =>
      t.boardName !== source.droppableId &&
      t.boardName !== destination.droppableId,
  );
  updateData([...untouched, ...updatedSource, ...updatedDest]);
}

On the database side, I needed atomic bulk updates for position changes. A single UPDATE per task would mean N round trips per drag operation. I wrote a Supabase RPC function instead:

create 
or replace function reorder_tasks(payload jsonb) returns setof tasks as $$ begin perform pg_advisory_xact_lock(123456);
return query 
with 
  rows as (
    select 
      (elem ->> 'id'):: uuid as id, 
      (elem ->> 'position'):: int as position, 
      nullif(elem ->> 'board_id', ''):: int as board_id, 
      (elem ->> 'updated_at'):: timestamptz as updated_at 
    from 
      jsonb_array_elements(payload) elem
  ) 
update 
  tasks t 
set 
  position = r.position, 
  board_id = coalesce(r.board_id, t.board_id), 
  updated_at = r.updated_at 
from 
  rows r 
where 
  t.id = r.id 
returning 
  t.*;
end;
$$ language plpgsql;

The pg_advisory_xact_lock is important. Without serializing reorder operations at the transaction level, two concurrent drags from two devices produce a race condition where both writes succeed but the resulting order is wrong. The advisory lock is session-scoped and cheap — it doesn’t block reads, only concurrent writes to the same logical lock ID.

The Local-First Architecture

This is the part I’m most satisfied with, and also the part that took the most iteration to get right.

Planow is designed as a local-first system — tasks are stored locally and work instantly. Cloud sync is optional and enabled only when users choose to log in.

If a user signs in, their locally-created tasks sync to the cloud. If they’re already a cloud user, we fetch from the DB on login. Conflict resolution happens automatically.

The Zustand pattern I landed on:

addTask: async (task) => {
  const previousData = get().mainData;
  const userData = get().userData;
  // Optimistic update - UI responds immediately
  const tempTask = {
    ...task,
    id: crypto.randomUUID(),
    completed: false,
    source: userData ? "remote" : "local",
    updated_at: new Date().toISOString(),
  };
  set((state) => ({ mainData: [...state.mainData, tempTask] }));
  if (userData) {
    const { data, error } = await supabase
      .from("tasks")
      .insert(task)
      .select()
      .single();
    if (error || !data) {
      // Rollback on failure
      set({
        mainData: previousData,
        snackbar: { show: true, content: error?.message, type: "error" },
      });
      return;
    }
    // Replace temp record with real DB record (correct ID)
    set((state) => ({
      mainData: state.mainData.map((t) => (t.id === tempTask.id ? data : t)),
    }));
  }
  // If no userData: stays in local state with source: 'local'
};

The source: ‘local’ marker is how the sync layer knows what to push on login. We only sync tasks carrying that marker — not everything. This prevents unnecessary writes and handles the common case of a user editing tasks while logged out and then logging back in.

The sync RPC handles conflict resolution via updated_at comparison:

create 
or replace function sync_tasks(payload jsonb) returns setof tasks as $$ begin return query insert into tasks (
  id, board_id, completed, position, 
  title, updated_at
) 
select 
  (t ->> 'id'):: uuid, 
  (t ->> 'board_id'):: int, 
  (t ->> 'completed'):: boolean, 
  (t ->> 'position'):: int, 
  t ->> 'title', 
  (t ->> 'updated_at'):: timestamptz 
from 
  jsonb_array_elements(payload) t on conflict (id) do 
update 
set 
  board_id = excluded.board_id, 
  completed = excluded.completed, 
  position = excluded.position, 
  title = excluded.title, 
  updated_at = excluded.updated_at 
where 
  excluded.updated_at > tasks.updated_at 
returning 
  *;
end;
$$ language plpgsql;

Last-write-wins by timestamp. Simple, predictable, and correct for a single-user task manager.

The Privacy Philosophy — Your Data Stays Yours

One principle guided many of our decisions:

Your data belongs to you — not the platform.

Planow is built to work without requiring an account. Tasks are stored locally by default, meaning:

No forced sign-ups
No automatic cloud sync
No hidden data collection

If a user chooses to log in, only then is data synced to the cloud for cross-device access.

This flips the typical model:
Most apps start with the cloud and store data locally as a cache.
Planow starts local — and uses the cloud only when needed.

The Design System — Syed’s Domain, My Implementation

I should be honest here: the design system architecture was a collaborative decision, but Syed drove the visual language. What I implemented was a full CSS custom property token system where every single color in the application is a variable reference. Not one hardcoded hex value in any component.

:root[data-theme="light"] {
 - primary: #5A67FA;
 - background: #F7F7FF;
 - quadrant-do-bg: color-mix(in srgb, #CDFDDD 40%, transparent);
 - quadrant-do-header: #0D834C;
 - quadrant-do-border: #0D834C;
}
:root[data-theme="dark"] {
 - primary: #5A67FA;
 - background: #06060F;
 - quadrant-do-bg: color-mix(in srgb, #0D834C 20%, transparent);
}

The practical consequence: dark mode isn’t a pile of dark: Tailwind overrides. It’s a complete, independently tuned set of token values. Switching themes means flipping the data-theme attribute on . Everything responds. We built out a full opacity ladder for each quadrant color (4%, 8%, 10%, 16%, 32%, 48%, 64%, 80%, 92%) for state layers. Over 400 variables total across both themes. It sounds like overkill for a side project, and maybe it is — but we never had a “this doesn’t look right in dark mode” bug.

What I Got Right

Flat data model → simplified everything
RPC-based bulk updates → performance win
Optimistic UI → better UX
CSS token system → scalable theming
Zustand → minimal and effective

What Was Harder Than Expected

Drag reorder logic

Same column
Cross column
Position recalculation

Database sync consistency

Order remains correct
No race conditions

What Planow Is Today

A fast, visual task manager
Built around the Eisenhower Matrix
Real-time synced (when logged in)
Optimistic and responsive
Clean, minimal UI
Dark/light theme supported

What’s Next

Collaboration features (data model ready)
Reports/analytics UI
Improved sync strategies
Better onboarding & landing experience

Privacy-focused sync alternatives:

Import / Export tasks between devices
Manual data transfer without requiring login
Full user control over where data lives

The goal is simple:
Users should be able to move their data across devices without being forced into an account system.

The Real Lesson

None of this was “hard” individually.

But:

Every small decision compounded
Every edge case mattered
Every shortcut showed up later

The biggest wins came from:

aligning product decisions with technical architecture early

The Honest Part

Four years from “we should build this” to shipped MVP. The idea was simple. The engineering was not hard exactly — but it was full of small decisions that compounded, and getting each one right took longer than the individual decision seemed to warrant.

The local-first sync architecture, the drag-and-drop position management, the conflict resolution — each of these problems is well-understood in the abstract. Actually implementing them in a way that handles real edge cases (concurrent drags, multi-device sync, auth state changes mid-session) requires you to think through every failure mode and decide how to handle it.

Syed handled product and design. I handled engineering. The best decisions came from the gap between those two functions — the conversations about what the right tradeoff was between implementation complexity and correct behavior.

That’s worth saying plainly:

the most important engineering decisions on this project weren’t purely technical. They were answers to product questions that happened to have technical consequences.

Not a developer? Want to understand what Planow is actually for and why the Eisenhower Matrix might change the way you work? Read the story here: I Stopped Drowning in To-Do Lists the Day I Asked Myself Two Questions

Written by Yogesh Raj · Built with Syed Shahab

Try 👉 https://planow.app/ and let me know your honest feedback

From Beginner to Pro: The Ultimate Guide to map(), filter(), reduce(), and forEach()

Yogesh Raj Kabilan — Sat, 29 Mar 2025 18:15:48 +0000

map(), filter(), reduce() and forEach() are the most commonly used Array methods in JavaScript. Let’s dive deeper and learn about these methods.

1. `map()` Method: Transforming Arrays

map() is a higher-order function used to iterate over each element in the array and return a new array of the same length, with each element transformed by the provided callback.

Syntax:

callback is the function to be executed on each element of the array.
- currentValue - The current element being processed in the array.
- index - index of the current element. (optional)
- array - The original array on which map() was called. The index of the current element being processed in the array. (optional)
thisArg is an optional parameter, which allows you to specify the value of this inside the callback function.

Let see a simple example how map() will work with each params

Basic Example: Multiply each element by 2

index: The index of the current element in the array

array: The original array on which map() is called

thisArg: A value to use as this when executing the callback function

2. `filter()` Method: Selecting Elements Based on a Condition

The filter() method allows you to create a new array containing only those elements that pass a certain test. Unlike map(), which transforms each element, filter() filters out elements that don't meet the criteria.

Syntax:

callback- The function to test each element.
- currentValue - The current element being processed in the array.
- index - index of the current element. (optional)
- array - The original array on which map() was called. The index of the current element being processed in the array. (optional)
thisArg is an optional parameter, which allows you to specify the value of this inside the callback function.

Basic Example: Filtering Even Numbers

Using the index and array Parameters

Using thisArg for Contextual Filtering

3. `reduce()` Method: Accumulating Values

The reduce() method allows you to accumulate a single result from all elements of an array by applying a function that you provide. It's typically used for summing values, but you can also use it for other purposes like flattening an array, combining objects, etc.

Syntax:

callback(accumulator, currentValue, index, array): The callback function is executed on each element of the array. It takes four parameters:
- accumulator: The value that keeps track of the result as we go through each item in the array. It gets updated during each iteration based on the operation you want to perform.
- currentValue: The current element being processed in the array.
- index: The index of the current element (optional).
- array: The original array that reduce() was called on (optional).
initialValue: The initial value to start accumulating (optional). If omitted, the first element of the array is used, and the iteration starts from the second element.

Basic Example: Summing Numbers

Basic Example: Flattening an Array

Using the index and array Parameters

4. `forEach()` Method: Iterating Over Arrays

The forEach() method is used to execute a provided function on every element in the array. It’s the most basic way to loop through arrays in JavaScript but differs from map() and filter() in that it doesn’t return a new array. Instead, it simply performs the operation for each item without accumulating or transforming the array.

Syntax:

callback - The function to execute on each element in the array.
- currentValue - The current element being processed in the array.
- index - The index of the current element being processed in the array.
- array - The original array on which forEach() was called.
thisArg - An optional argument that specifies the value of this inside the callback function.

Basic example

Using the index and array Parameters

Using thisArg

Bonus Tip: Using Normal Functions and Calling External Functions

Although we've used arrow functions extensively, you can also use normal functions and call external functions inside methods like map(), filter(), reduce(), and forEach()

Using a Normal Function Inside map()
Calling an External Function Inside map()

These techniques are not limited to map(); they can be applied similarly to filter(), reduce(), and forEach(). Using normal functions and external functions can make your code more modular and easier to read, especially when dealing with complex operations or reusable logic.

Conclusion:

In this article, we've explored four of the most commonly used array methods in JavaScript: map(), filter(), reduce(), and forEach(). These methods allow for clean, functional-style iterations over arrays, making your code more readable and expressive.

map() allows you to transform each element in an array and return a new array with the same length but modified values.
filter() helps you select elements from an array based on a condition, creating a new array of only the matching elements.
reduce() gives you the ability to accumulate values across the array, making it perfect for summing, averaging, or combining data in more complex ways.
forEach() simply iterates over an array and executes a function for each element, with optional access to the index and the entire array.

By understanding and effectively using these methods, you'll be able to handle array manipulations more efficiently and write more declarative and concise code. While these methods are powerful individually, they can also be combined to achieve more sophisticated operations on arrays.

So next time you're faced with an array operation, consider using one of these methods. With practice, you'll find that your JavaScript code becomes cleaner, more readable, and easier to maintain.

This is my first blog, and I appreciate your understanding. Feel free to share any feedback or suggestions—I’m always eager to learn and improve!

DEV Community: Yogesh Raj Kabilan

Building a Local-First Task Manager with Next.js and React — Lessons from Planow

The Stack — Choosing the Future (With Tradeoffs)

The Data Architecture — Getting Flat Right

The Drag-and-Drop Reorder Problem

The Local-First Architecture

The Privacy Philosophy — Your Data Stays Yours

The Design System — Syed’s Domain, My Implementation

What I Got Right

What Was Harder Than Expected

What Planow Is Today

What’s Next

Privacy-focused sync alternatives:

The Real Lesson

The Honest Part

From Beginner to Pro: The Ultimate Guide to map(), filter(), reduce(), and forEach()

1. map() Method: Transforming Arrays

2. filter() Method: Selecting Elements Based on a Condition

3. reduce() Method: Accumulating Values

4. forEach() Method: Iterating Over Arrays

1. `map()` Method: Transforming Arrays

2. `filter()` Method: Selecting Elements Based on a Condition

3. `reduce()` Method: Accumulating Values

4. `forEach()` Method: Iterating Over Arrays