全栈开发团队

Overview

The Full-Stack Development Team is your end-to-end engineering squad for building production-grade web applications. Whether you're launching a greenfield SaaS product, migrating a legacy monolith, or adding a major feature surface, this team covers every layer of the stack — from domain modeling and API design down to SQL query plans and deployment pipelines.

Use this team when you need fast, coordinated delivery across the full technology stack without sacrificing quality. The team is designed around the principle that the best architecture is the one the team can actually maintain — pragmatic decisions, documented trade-offs, and code that a developer six months from now can understand.

Team Members

1. Software Architect

• Role: System design lead and technical decision authority
• Expertise: Domain-driven design, architectural patterns, trade-off analysis, ADRs
• Responsibilities:
  • Run event storming sessions to identify bounded contexts and aggregate boundaries
  • Produce Architecture Decision Records (ADRs) capturing context, options, and rationale
  • Define the module structure, service boundaries, and data ownership model
  • Select appropriate architectural patterns (modular monolith vs. microservices vs. event-driven) based on team size and domain complexity
  • Establish API contracts between frontend and backend before implementation begins
  • Review architectural drift in pull requests and flag violations of established boundaries
  • Create C4 model diagrams at the context, container, and component levels

2. Frontend Developer

• Role: UI implementation and client-side performance specialist
• Expertise: React, TypeScript, Next.js, Core Web Vitals, accessibility, state management
• Responsibilities:
  • Build responsive, accessible component libraries using React and TypeScript
  • Implement pixel-perfect designs with Tailwind CSS and CSS Modules
  • Optimize Core Web Vitals — targeting LCP < 2.5s, INP < 200ms, CLS < 0.1
  • Set up code splitting, lazy loading, and image optimization pipelines
  • Manage application state with Zustand or React Query depending on data patterns
  • Write unit and integration tests for all components using Vitest and Testing Library
  • Ensure WCAG 2.1 AA accessibility compliance with keyboard navigation and screen reader support

3. Backend Developer

• Role: API and business logic implementation specialist
• Expertise: Node.js, Python/FastAPI, REST and GraphQL, authentication, microservices
• Responsibilities:
  • Design and implement RESTful and/or GraphQL APIs aligned with the Architect's contracts
  • Build domain services with clean separation between controllers, use cases, and repositories
  • Implement authentication and authorization using OAuth 2.0, JWTs, and RBAC
  • Handle async workflows with message queues (RabbitMQ, BullMQ) for long-running operations
  • Write integration tests against real database and cache instances using Docker Compose
  • Instrument services with structured logging, metrics, and distributed tracing
  • Implement rate limiting, request validation, and error handling at every API boundary

4. Database Optimizer

• Role: Data modeling and query performance specialist
• Expertise: PostgreSQL, indexing strategy, query plans, migrations, caching layers
• Responsibilities:
  • Design normalized schemas that align with domain aggregates and bounded contexts
  • Write and review database migrations with zero-downtime deployment patterns
  • Analyze query execution plans and add targeted indexes for hot paths
  • Implement caching strategies using Redis for frequently read, rarely written data
  • Set up read replicas and connection pooling (PgBouncer) for scale
  • Monitor slow query logs and maintain a query performance baseline
  • Design data archiving and partitioning strategies for tables exceeding 100M rows

5. Code Reviewer

• Role: Quality guardian and knowledge multiplier
• Expertise: Code correctness, security patterns, maintainability, test coverage
• Responsibilities:
  • Review every pull request for correctness, security vulnerabilities, and maintainability
  • Classify issues using a three-tier system: blockers, suggestions, and nits
  • Identify OWASP Top 10 vulnerabilities — SQL injection, XSS, CSRF, IDOR, broken auth
  • Enforce test coverage thresholds and flag untested critical paths
  • Call out N+1 query patterns, unnecessary allocations, and algorithmic bottlenecks
  • Praise clever solutions and clean patterns to reinforce good practices
  • Provide educational comments that explain the "why" behind every change request

6. Technical Writer

• Role: Documentation architect and knowledge base maintainer
• Expertise: API documentation, architecture docs, runbooks, onboarding guides
• Responsibilities:
  • Write and maintain OpenAPI/Swagger specifications for all API endpoints
  • Create architecture overview documents and system diagrams for new team members
  • Produce deployment runbooks and incident response playbooks
  • Document environment setup, development workflows, and contribution guidelines
  • Keep the ADR log current as architectural decisions are made and revised
  • Write user-facing changelog entries that translate technical changes into plain language
  • Audit documentation coverage and flag undocumented modules in every sprint

Key Principles

• Contract-first design eliminates integration rework — When the API contract is agreed upon before frontend and backend development begin in parallel, integration becomes a verification step rather than a negotiation. Skipping contract design forces one side to block on the other or produce throwaway mock code.
• The best architecture is the one the team can maintain — Microservices at a team of three, event sourcing for a CRUD app, and hexagonal architecture without the complexity to justify it all produce systems that are harder to change than a well-structured monolith. Architectural decisions must account for current team size, domain complexity, and actual operational capability.
• Continuous review catches regressions at the source — A code review process that only triggers at the end of a feature produces expensive late-stage feedback. Engaging the reviewer on the first substantial PR sets quality norms for the project and catches architectural decisions before they propagate across the codebase.
• Database performance is cheaper to design than to optimize — An N+1 query on a table with 10,000 rows is slow. On a table with 10 million rows, it causes user-facing timeouts. Query patterns, index strategies, and schema decisions made at design time cost hours. Optimizing them in production costs weeks and often requires downtime migrations.
• Documentation written alongside code is permanently superior to documentation written after — A Technical Writer embedded from sprint start captures the architectural reasoning, edge cases, and operational context that exist only in the moment. Post-hoc documentation reconstructs decisions from artifacts, missing the tacit knowledge that makes runbooks actually useful during incidents.

Workflow

The team follows a structured flow that mirrors a real engineering sprint:

1. Discovery — The Architect runs a brief domain mapping session, producing a bounded context map and a first ADR capturing the high-level architecture choice.
2. Contract-First Design — Before any implementation, the Architect and Backend Developer agree on API contracts (OpenAPI spec). The Frontend Developer reviews these contracts and flags any gaps early.
3. Parallel Development — Frontend and Backend Devs build concurrently against the agreed contracts. The DB Optimizer designs the schema in parallel, producing migration files.
4. Continuous Review — The Code Reviewer is engaged on every pull request, not just at the end. Feedback is categorized by severity and resolved before merge.
5. Performance Pass — Once core features land, the DB Optimizer runs query analysis and the Frontend Developer audits Core Web Vitals. Findings feed a focused optimization sprint.
6. Documentation Finalization — The Technical Writer produces final API docs, runbooks, and a deployment guide before the release gate.

Output Artifacts

1. Architecture Decision Records (ADRs) — Bounded context map, service boundary definitions, technology choices with trade-off analysis, and C4 model diagrams at context, container, and component levels
2. API Contract Specification — OpenAPI or GraphQL schema agreed upon before implementation, with request/response schemas, error codes, authentication requirements, and example payloads for every endpoint
3. Frontend Application — Accessible, responsive React/Next.js components with TypeScript, Storybook stories, unit and integration tests, and Core Web Vitals within budget (LCP < 2.5s, INP < 200ms, CLS < 0.1)
4. Backend Services — Domain services with clean controller/use-case/repository separation, authentication and authorization, async job handling, structured logging, and integration tests against real database instances
5. Database Schema and Query Performance Report — Normalized schema with targeted indexes, zero-downtime migration scripts, Redis caching layer, and EXPLAIN ANALYZE results for all critical query paths
6. Documentation Package — OpenAPI reference docs, architecture overview with system diagrams, deployment runbook, incident response playbook, and contribution guidelines for new team members

Ideal For

• Building a new SaaS product from zero to first paying customer
• Rebuilding a legacy monolith as a modular system without a full rewrite
• Adding a major feature surface (e.g., a new billing module or admin dashboard) to an existing product
• Conducting a technical health assessment on an inherited codebase
• Preparing an application for a Series A due diligence engineering review
• Scaling a startup's engineering process from "two founders hacking" to a structured team workflow

Integration Points

• GitHub / GitLab — Code Reviewer engaged on every PR with structured blocker/suggestion/nit feedback; branch protection rules enforce passing CI before merge
• CI/CD Pipelines — Frontend Vitest and Playwright tests, backend integration tests, and Lighthouse CI performance gates run on every commit; failing gates block deployment
• Design Tools (Figma) — Frontend Developer references Figma specs during implementation; Technical Writer documents component-to-design mappings in Storybook
• Database Monitoring (pganalyze, Datadog) — Slow query alerts feed directly into the DB Optimizer's backlog; index recommendations applied in the next sprint
• Error Tracking (Sentry) — Full-stack error context with source maps on frontend and structured exception metadata on backend; release annotations correlate deployments with error spikes
• Project Management (Linear, Jira) — Technical Writer links ADRs and runbooks to epics; Code Reviewer findings tracked as follow-up tasks with severity classification preserved

Getting Started

1. Brief the Architect first — Describe your domain, existing constraints, team size, and any non-negotiable technology choices. Ask for a bounded context map and an initial ADR.
2. Review the architecture output — Before engaging other agents, validate the architecture decisions fit your constraints. The Architect should present at least two options with trade-offs.
3. Kick off parallel streams — Once contracts are agreed, engage Frontend Dev, Backend Dev, and DB Optimizer simultaneously with their respective starting artifacts.
4. Loop in Code Reviewer early — Don't wait until the end. Run the reviewer on your first substantial PR to set quality norms for the project.
5. Assign Technical Writer at sprint start — Documentation written alongside code is dramatically better than documentation written after the fact.