Azirgo KanbanAn agency's boards, tasks, alerts and weekly podcast schedule in a single dashboard

Web & applications developer: I designed and built the whole application - interface, data model and RLS policies, emails, scheduled jobs and the programmes module - as the repository's sole author, at Azirgo SAS.

An agency that builds software and produces podcasts every week has teams that barely overlap, yet they all start the day with the same question: what is due today, who owns each task and what changed since yesterday. On top of that sits the production of the shows: every episode has to be edited, given a thumbnail, cut into clips and scheduled before its publishing time, week after week, and a generic task such as “episode of 25 August” tells nobody what actually needs doing.

• Projects (workspaces) with members and boards: each user sees only the projects they belong to, admins see all of them, and a board can be narrowed to specific members within its project.
• Kanban board with drag and drop of tasks between columns and column reordering; moving a task into the done column marks it complete, and moving it out reopens it.
• Three views per board - Kanban, List and Calendar - and tasks with priority (High, Medium, Low), due date, several assignees, description, attachments and comments.
• Home dashboard with the urgent things first: tasks due today, pending, overdue and completed this week; for admins, also active boards, workload per member, delegated tasks and recent activity.
• In-app notifications - task assigned, edited, moved, commented on or due today - with an unread counter and a panel that separates what is due today or tomorrow.
• Emails with Resend and React Email: task assigned, task completed, a daily reminder per person with their overdue and pending tasks, and a team summary for admins.
• Programmes module for the podcast schedule: today's show with a countdown to its scheduling deadline, the full week with times and platforms, and weekly tasks that create themselves on each show's board.
• Activity log with 22 action types, per board and global, with filters by entity type, search and pagination.
• User management for admins: account creation, roles, blocking and deletion, with each person's pending, overdue and completed tasks and last activity.

A single Next.js application on Supabase: the dashboard queries the database directly with the user's session, and anything that needs privileges or external services goes through server-side API routes.

The Programmes module connects the podcasts' publishing calendar with the board where the team does the work.

The application alerts people through two channels, inside the dashboard and by email, so nobody has to check every board to know what is on their plate.

Each module covers one part of the day-to-day operation, without leaving the panel.

• Home

  What is due today, pending, overdue and completed; for admins, active boards, members, workload per person, delegated tasks and recent activity.

• Projects and boards

  Projects with their members and boards with a description; boards can be duplicated with just their columns or with their tasks as well.

• Tasks

  Priority, due date, several assignees, description, attachments and comments; tasks completed more than 8 days ago are archived from the view.

• Programmes

  The weekly podcast schedule with a countdown, platforms and a team per show, and weekly tasks that create themselves on its board.

• Notifications

  Alerts for assignments, edits, moves, comments and due dates, with an unread counter and what is due today or tomorrow at the top.

• Emails and reminders

  Task assigned, task completed, a daily reminder per person and a team summary for admins, built with Resend and React Email.

• Activity log

  22 action types, per board and global, filterable by tasks, columns, boards, projects, users and comments.

• Users

  Account creation, admin or user role, blocking and deletion, with each person's task metrics and last activity.

• Access and security

  RLS policies per project and per board, a session refreshed in the middleware, blocked accounts that cannot sign in, and cron endpoints with their own secret.

• Security lives in the database: RLS policies with helper functions such as is_admin, is_workspace_member and can_access_board decide which boards, columns and tasks each user sees, and editing a task is restricted to its assignees or an admin.
• Board members narrow access within the project instead of replacing it: a board with no explicit members stays visible to the whole project, so the boards that already existed kept working as before.
• Reminders run inside the Next.js process itself with node-cron, registered from instrumentation.ts, with no extra infrastructure. Since several instances would each send the same emails, a variable switches them off so they can be triggered from an external scheduler.
• The cron endpoints sit outside the session middleware and authenticate with a shared secret in a header, compared in constant time; if the secret is not configured, they reject every request.
• The schedule - each show's day, publishing time, lead time and platforms - lives in code because it is stable; the database only stores which board and column the tasks go to, who receives them and each week's templates.
• A template's attachments are uploaded once and every generated task points to the same file instead of duplicating it each week; uploads go to DigitalOcean Spaces and only accept images and PDFs of up to 10 MB.

• Moving from one generic task per episode, which did not say what had to be done, to a list of tasks per show - edit, thumbnail, clips, publish - each with its own assignees, day and time, instantiated every week with that episode's date.
• Making generation idempotent and punctual: a unique record per template and episode stops tasks from being duplicated even if the job runs several times, and a pass every 5 minutes keeps a task set for 11:45 from taking up to an hour to appear.
• Fixing the board-members schema in production: the table already existed with an old schema, so its creation was a no-op and inserts failed; a follow-up migration added the generated id, the NOT NULL and UNIQUE constraints and cascading foreign keys, safe both on the old table and on a clean database.
• Reconciling soft deletes with RLS: marking a column as deleted made PostgREST's implicit RETURNING clash with the read policy, which was solved with a separate read policy for admins.

Azirgo Kanban is in production as Azirgo's internal tool for organising its work by project and board. Email reminders and due-today alerts go out on their own, every change is logged, and each show's weekly tasks appear on its board at the configured time with their assignees already set.