Core rule:

Before you build anything, ask: "Does this already exist, or will it exist again?" If the answer is yes to either — build it once, build it properly, and reuse it everywhere.

Contents

1. The Reusability Check — Before You Start Building

Run this check on every new task before writing a single line:

If any answer is yes — stop. Extract before you build.

2. The Reusability Decision Rule

Three or more similar lines = automatic extraction.

3. Platform-Specific Reusability Guide

React / Next.js

What to Make Reusable

Folder Structure

src/
  components/
    ui/
      Button.tsx
      Input.tsx
      Modal.tsx
      Table.tsx
      Badge.tsx
    forms/
      ProjectForm.tsx       ← Used in Add Project AND Edit Project
      MemberInviteForm.tsx
    modals/
      DeleteConfirmModal.tsx
      ConfirmActionModal.tsx

  hooks/
    useProjects.ts
    useWorkspace.ts
    useAuth.ts

  services/
    projects.service.ts
    members.service.ts
    auth.service.ts

  validations/
    project.schema.ts
    member.schema.ts

  utils/
    api-error-handler.ts
    date-formatter.ts
    string-utils.ts

  constants/
    roles.ts
    status.ts
    routes.ts

  types/
    project.ts
    user.ts
    workspace.ts

Anti-Patterns

× Same Button component defined in 5 different files.
× ProjectForm duplicated in AddProject.tsx and EditProject.tsx with different validation.
× fetch('/api/projects') called directly in 8 different components.
× Same error handling logic copy-pasted across every form submit handler.
× Validation rules written inline in each form component.

WeWeb

What to Make Reusable

WeWeb Reusability Rules

Naming Reusable Elements

Xano

What to Make Reusable

Rule

If you write the same 3+ steps in two different Xano endpoints — extract to a function.

Django

What to Make Reusable

Fat Models, Thin Views Rule

View: Handle the HTTP request and response. Not more.
Model/Service: Handle the business logic.
Form/Serializer: Handle validation.
Template: Handle display only.

Bad — business logic in view:

def create_project(request):
    name = request.POST.get('name')
    slug = name.lower().replace(' ', '-')
    existing = Project.objects.filter(slug=slug, workspace=workspace).first()
    if existing:
        ...
    Project.objects.create(name=name, slug=slug, workspace=workspace, created_by=request.user)
    send_email(...)
    log_audit(...)

Good — logic extracted to service:

# services/project_service.py
class ProjectService:
    @staticmethod
    def create_project(workspace, name, created_by):
        slug = generate_slug(name)
        if Project.objects.filter(slug=slug, workspace=workspace).exists():
            raise ConflictError('Project name already exists.')
        project = Project.objects.create(name=name, slug=slug, workspace=workspace, created_by=created_by)
        send_notification(created_by, 'project_created', project)
        AuditLog.log('project.created', actor=created_by, entity=project)
        return project

# views.py
def create_project(request):
    form = ProjectForm(request.POST)
    if not form.is_valid():
        return error_response(form.errors)
    project = ProjectService.create_project(
        workspace=request.workspace,
        name=form.cleaned_data['name'],
        created_by=request.user
    )
    return success_response(project)

Supabase

What to Make Reusable

Reusable RPC Pattern

If the same business operation happens in multiple places (e.g., "create project + create default task + create activity log"), put it in one RPC function — not in three separate frontend calls.

Bad:

// Frontend makes 3 sequential calls
await supabase.from('projects').insert(...)
await supabase.from('tasks').insert(...)
await supabase.from('activity_logs').insert(...)

Good:

// Frontend makes 1 call, backend handles the rest
await supabase.rpc('create_project_with_defaults', { p_workspace_id, p_name })

4. Reusability Naming Conventions

Names must be clear enough that another team member knows what it does without reading the code.

Functions

verb_noun or getVerb (for getters)

Components (React)

PascalCase, named by what it IS

Hooks (React)

useNoun or useVerbNoun

Services (React/Django)

noun.service.ts / NounService

5. Reusability Anti-Patterns

These are the most common violations. Watch for all of them.

6. When NOT to Over-Abstract

Reusability is good — over-abstraction creates complexity.

Do not make something reusable if:

× It is only used in one place and has no clear future use.
× Making it "generic" requires more complex parameters than just duplicating it.
× The abstraction would make the code harder to read than the original.
× It is a one-time migration script or throwaway utility.

The rule: Three or more identical uses = extract. One use = keep it where it is.

7. Reusability Checklist — Before Marking Done