Software Engineering Standards

Welcome to the Flow Create Solutions engineering standards: opinionated documentation describing how we design, build, secure, and maintain systems.

What these docs are

• Engineering standards: the patterns we expect teams (and AI agents) to follow across projects.
• Documentation-first: treat this site as the source of truth for conventions, structure, and “how we do things”.
• Generic by design: examples are intentionally sanitized and reusable across many apps.

Who this is for

• Engineers building or maintaining Flow Create Solutions systems.
• AI agents assisting on changes, refactors, reviews, and debugging.
• Tech leads aligning teams and reviewing architectural decisions.

How to navigate

Use the left navigation. The main areas are:

• Documentation

  • Project docs structure: required pages, module doc entrypoints, ADRs, and runbooks.

• Backend

  • Overview: expected architecture + stack baseline.
  • Security: authn/authz, rate limiting, XSS prevention, and reporting standards.
  • Database: module structure, conventions, and generic module examples.
  • Development: local setup, error handling, logging.
  • Testing: philosophy, structure, fixtures, and copy/paste-able examples.
  • Integrations: standards for common integrations (AI engine, notifications, workers).
  • Migrations (Operational): operational playbooks/examples (follow migration ownership policy).

• Playbooks

  • Trackers: how to create and maintain tracking documents for multi-session work.

Recommended workflow (devs + agents)

• Start with the relevant section (e.g., Security before touching auth; Database before adding a module).
• Apply the pattern, don’t cargo-cult: match structure + naming + safety posture; adapt details to the project.
• Verify before you claim: when writing docs or standards updates, confirm behavior against a reference implementation and keep it generic.
• Ask when ambiguous: if a decision isn’t covered (or multiple approaches exist), escalate to the project lead instead of inventing a new standard.

What “good” looks like

• Consistent module layout and naming across services.
• Defense-in-depth applied to inputs and security boundaries.
• Tests mirror module boundaries with predictable fixtures.
• Clear docs that teach the next contributor what to do (and why).