⚙️How we work at Simple Software?

[RandintN]

🏛️ Our Working Pillars at Simple Software LTDA

At Simple Software LTDA, we operate on a strictly asynchronous (async-first) model. Our focus is to enable deep work by eliminating interruptions, pressure, and the need for time management.

Our culture is built on three essential pillars:

1. Maximum Clarity (Clarity First)
2. Trust and Professionalism
3. Results-Oriented Work

---

1. Asynchronous Communication and Total Clarity

We eliminate live meetings, recurring agendas, and ceremonies like dailies. We believe developer time is too valuable to be spent on synchronizations that can be resolved with text.

• GitHub-Exclusive Communication: All communication, without exception, is handled within GitHub Issues, Pull Requests, and Discussions. We do not use real-time chat tools (like Slack or Teams) for project discussions.
• English-Only Communication: To ensure clarity and accessibility for everyone, all written communication must be in English.
• The Onus of Clarity: All written communication is expected to be crafted with maximum clarity. When creating an issue or reviewing a PR, you must provide all necessary context so any team member can understand the task and its objectives without needing a subsequent conversation.

2. Trust, Professionalism, and No Pressure

We operate based on mutual trust. There is no pressure from arbitrary deadlines or micromanagement.

• We trust that you are a professional capable of managing your own time and delivering work to the expected quality.
• Working "without pressure" does not mean a lack of responsibility; it means the environment is optimized for you to focus on solving the problem, not on appearing busy.

3. Focus on Results, Not Time

We pay for results, not for time.

• We do not track hours, punch-cards, or "seat time." What matters is the final delivery and the quality of the code.
• This model aligns incentives: the company receives functional software, and the professional is rewarded for their efficiency and effectiveness, not for how many hours it took to complete the task.

[RandintN]

Simple Software Development Workflow

This document outlines the standard operating procedure for task management at Simple Software. Our goal is to ensure clarity, minimize context switching, and guarantee quality through evidence-based review and safe deployment strategies.

1. Brain Dump & Backlog

• State: Brain Dump / Backlog
• Purpose: A holding area for raw ideas, feature requests, and technical improvements.
• Process:
  • Items here are considered "unrefined."
  • Maintenance (Garbage Collection): To prevent clutter, items that remain in this column for an extended period without prioritization should be reviewed and deleted.
  • Transition: Once an item is clearly defined, prioritized, and refined, it moves to the To Do column.

2. Selection & Readiness Check

• State: To Do
• Purpose: Tasks ready for assignment.
• Process:
  • Hotfix/Expedite: Critical bugs bypass the Brain Dump and start here, but must strictly follow the subsequent evidence/review rules.
  • The "Pre-Flight" Check (Definition of Ready): Before moving the card, the assignee must verify via the Issue Template Checkboxes:
    1. All necessary information/requirements.
    2. Required tools.
    3. Necessary access permissions.
  • If blocked: Do not move the card. Tag the task Owner requesting clarification or access.
  • Transition: Move to In Progress only when the assignee has everything required to complete the task immediately.

3. Execution & Evidence Collection

• State: In Progress
• Purpose: Active implementation.
• Process:
  • Execute the task.
  • Evidence Gathering: Before requesting a review, evidence of completion is mandatory.
    • UI/UX: Screen recording or screenshots.
    • APIs/Backend: Automated test results (e.g., Api Dog export/screenshot).
  • Transition: Attach evidence to the task/PR comments and move to In Review.

4. Review Process

• State: In Review
• Purpose: Quality assurance, validation, and knowledge sharing.
• Process:
  • Complex Tasks (Live Stream): For logic-heavy features, architectural changes, or complex UI, a synchronous live stream review is mandatory.
    • Documentation: Any key decisions discussed during the stream must be summarized in the task comments.
  • Trivial Tasks (Async): For simple fixes, an asynchronous review based on the provided evidence is permitted.
  • Outcome:
    • Rejected: Move back to In Progress.
    • Approved: Proceed to Done.

5. Completion & Deployment

• State: Done
• Purpose: Code is live in production.
• Deployment Strategy (No Release Events):
  • We adhere to continuous deployment using Feature Flags or Blue/Green environments.
  • Code is merged and runs in production immediately.
• Feature Flag Cleanup:
  • Once a feature is stable and active for 100% of users, a new technical task must be created to remove the flag and clean up the code.
• Definition of Done: The code is merged and successfully running in the production environment.

[RandintN]

No Politics, No Ideology/Religion, No News, No Hype.