Development Standards
Project Tasks

Project Tasks

Each project is a complete mini-application scoped to ~8 hours. Every project is designed to exercise every relevant standard and checklist for its tech stack. Complete the project, run every linked checklist, and tick every item in "Done When" before marking it done.

Read This First

Start from this overview before opening any individual project.

These rules are shared across all project briefs. Employees should read this page first, understand the common role model and workspace rules, and then open the selected project detail page.

Order to follow Read shared rules here, pick your stack, open one project brief, then build only after understanding the flow, permissions, screens, and acceptance checklist.

How to Use

  1. Read the common rules on this page before picking any project
  2. Pick the project matching your tech stack
  3. Read the full project brief before writing any code
  4. Plan your approach — identify which checklists apply before starting
  5. Build each feature, running the relevant checklist as you complete it
  6. A project is not done until every "Done When" item is checked
Common Rules

What stays the same across all projects

The project brief changes, but the product model, permission thinking, data shape, and delivery expectations stay consistent across all stacks.

Important Do not assume project-specific tools like Notion, third-party dashboards, or external workflows unless the project brief explicitly asks for them.
Common Product Model

Most projects are multi-workspace SaaS-style builds.

Even a small project should be designed with ownership, workspace isolation, permissions, and scalable data structure in mind.

Core Roles

Owner, Workspace Admin, and Member exist across the project tracks.

  • Owner: creates and manages multiple workspaces, sees all related users and activity, and controls workspace-level settings.
  • Workspace Admin: manages only assigned workspaces, can manage project records there, and cannot access unrelated workspaces.
  • Member: works inside assigned workspaces, creates or updates own records where allowed, and cannot access admin-only views or approve own requests.
Permission Rule

Every important record should be scoped by workspace.

A user can access a record only if they are the Owner of that workspace, an Admin of that workspace, or a Member of the same workspace with the correct permission.

This applies to directories, tasks, contacts, leave requests, announcements, expenses, invites, documents, and knowledge base records.

Common Data Model

Most projects should include the same backbone entities.

  • users for authenticated user profiles
  • workspaces for team or company units
  • workspace_members for user-to-workspace role mapping
  • a role field or role table for owner, admin, and member
  • audit_logs where important actions must be tracked
  • the project-specific table(s) that store the actual feature records
Common User Flow

Most project journeys follow the same base pattern.

1Owner creates a workspace.
2Owner adds an admin to that workspace.
3Admin logs in, opens assigned workspace, and adds members.
4Member logs in, opens assigned workspace, and creates or views project records.
5Admin manages, reviews, or approves records where the workflow requires it.
6Owner can review all workspace activity and cross-workspace visibility where allowed.

Security Standards

  • Never trust frontend-only permissions.
  • Enforce access control on backend or database level.
  • Every workspace record must be scoped by workspace_id.
  • Validate input on both frontend and backend.
  • Use private storage for sensitive files.
  • Do not leak data through search, filters, or dropdown options.

UI / UX Standards

  • Every list page must include loading, empty, and error states.
  • Add search and filters where relevant.
  • Show clear action buttons and permission-aware UI.
  • Every form must include validation, labels, error messages, success feedback, and disabled submit during save.
  • Destructive actions must use confirmation.

Backend and Testing Standards

  • Include proper data model, server-side permissions, validation, and business-rule handling.
  • Use service-layer thinking and clean API responses.
  • Support pagination for list endpoints where needed.
  • Test Owner, Admin, Member, non-member blocked access, create/edit/delete, invalid input, and cross-workspace blocking.

Projects by Stack

StackProject 1Project 2
Next.js + SupabaseClient Feedback PortalMeeting Room Booking
WeWeb + SupabaseTeam Member DirectoryTask Board
WeWeb + XanoContact BookLeave Request System
React + DjangoAnnouncement BoardExpense Tracker
React + SupabaseWorkspace Invite SystemDocument Library
Django + TemplatesLeave Request SystemInternal Knowledge Base

What Each Project Covers

  • Designing and creating the database schema
  • Writing all required backend logic (RLS / endpoints / services)
  • Building all frontend pages with loading, empty, and error states
  • Handling forms with proper validation and Add/Edit consistency
  • Showing all async feedback: loading states, toasts, error banners
  • Applying role-based permissions at every level
  • Running the full checklist for every feature before calling it done