---
title: Technical Breakdown Resources
---

:::caution[Programme Sunset]
The open Mentorship Programme has been sunset and is no longer accepting new participants. These pages remain available as reference material.

I'm now running a private, personalised professional development programme on an invite-only basis - hand-selecting a small number of participants so the shape of each journey can be built around them. There is no application process; participation is by direct invitation only.

Being active in my [Discord community](https://chat.nhcarrigan.com/) increases your chances of being invited.
:::

**TECHNICAL BREAKDOWN TEMPLATE AND EXAMPLES**

## Technical Breakdown Template

Copy this template into each user story issue:

```markdown
## 🎯 Acceptance Criteria
- [ ] Criteria 1 (clear, testable condition)
- [ ] Criteria 2
- [ ] Criteria 3

---

## ⚙️ Technical Details
- Proposed implementation approach:
  - [ ] e.g., API endpoint, UI component, database schema changes
- Data considerations:
  - [ ] Models, validation, storage needs
- Security/permissions:
  - [ ] Any auth or role checks?

---

## 🔗 Dependencies
- [ ] Related tickets or features
- [ ] External services or APIs
- [ ] Libraries or frameworks required

---

## 🧪 Testing Notes
- [ ] Unit tests to cover…
- [ ] Integration tests to cover…
- [ ] Manual QA steps…

---

## 📂 Additional Context
- Links to designs, diagrams, or docs
- Any constraints or assumptions
- Open questions / things to clarify
```

## Technical Breakdown Example

### Example User Story

**User Story:** As an authenticated user, I should be able to add a game to my library.

### Completed Technical Breakdown

```markdown
## 🎯 Acceptance Criteria
- [ ] User can add game to library via API endpoint
- [ ] User can view games in their library
- [ ] User can remove game from library
- [ ] User cannot add duplicate games to library
- [ ] Only authenticated users can modify their library

---

## ⚙️ Technical Details
- Proposed implementation approach:
  - [ ] POST /api/library endpoint to add game
  - [ ] GET /api/library endpoint to retrieve user's library
  - [ ] DELETE /api/library/:gameId endpoint to remove game
  - [ ] Front-end component to display library
  - [ ] Front-end component with add/remove buttons
- Data considerations:
  - [ ] User model must have library property (array of game IDs)
  - [ ] Each game ID references a Game model record
  - [ ] Validate game ID exists before adding
  - [ ] Prevent duplicate entries in library array
  - [ ] Consider pagination for large libraries
- Security/permissions:
  - [ ] Validate JWT token on all endpoints
  - [ ] Ensure authenticated user can only modify their own library
  - [ ] Validate game ID to prevent invalid references
  - [ ] Rate limiting to prevent abuse

---

## 🔗 Dependencies
- [ ] #2 - User authentication must be implemented first
- [ ] #5 - Game model must exist
- [ ] #8 - Profile UI necessary to access library view
- [ ] JWT authentication library
  - [ ] Express middleware for JWT validation

---

## 🧪 Testing Notes
- [ ] Unit tests:
  - [ ] POST endpoint adds game to library
  - [ ] POST endpoint prevents duplicates
  - [ ] GET endpoint returns user's library
  - [ ] DELETE endpoint removes game from library
  - [ ] Endpoints reject unauthenticated requests
  - [ ] Endpoints prevent users from modifying other users' libraries
- [ ] Integration tests:
  - [ ] Full flow: add game, view library, remove game
  - [ ] Authentication flow with library operations
- [ ] Manual QA steps:
  - [ ] Test adding game via UI
  - [ ] Test viewing library
  - [ ] Test removing game
  - [ ] Test error handling (invalid game ID, duplicate, etc.)
  - [ ] Test with multiple users to ensure isolation

---

## 📂 Additional Context
- Relational data model means using MongoDB might not be the best choice. Should we re-evaluate database choice?
- Consider adding a GET /api/library/:userId endpoint for viewing other users' libraries (future feature)
- May want to add library statistics (total games, recently added, etc.)
- Consider caching library data for performance
```

## Technical Breakdown Guide

### Acceptance Criteria

**Purpose:** Define clear, testable conditions for story completion.

**Tips:**
- Make criteria specific and measurable
- Focus on behavior, not implementation
- Ensure criteria are testable
- Cover both happy path and edge cases

**Examples:**
- ✅ "User can add game to library"
- ✅ "User cannot add duplicate games"
- ❌ "Implement library feature" (too vague)
- ❌ "Use MongoDB" (implementation detail)

### Technical Details

**Implementation Approach:**
- What components/modules will be created?
- What API endpoints are needed?
- What UI components are required?
- What database changes are needed?

**Data Considerations:**
- What data models are involved?
- What validation is needed?
- What relationships exist?
- What storage requirements are there?

**Security/Permissions:**
- What authentication is required?
- What authorization checks are needed?
- What data should be protected?
- What rate limiting is appropriate?

### Dependencies

**Types of Dependencies:**
- **Feature Dependencies:** Other user stories that must be completed first
- **Technical Dependencies:** Libraries, frameworks, or services needed
- **External Dependencies:** Third-party APIs or services

**Identifying Dependencies:**
- What must exist before this can be built?
- What external services are needed?
- What libraries or frameworks are required?
- What infrastructure is needed?

### Testing Notes

**Unit Tests:**
- Test individual functions/methods
- Test edge cases and error handling
- Test validation logic
- Test business rules

**Integration Tests:**
- Test component interactions
- Test API endpoints
- Test database operations
- Test authentication/authorization flows

**Manual QA:**
- Test user workflows
- Test UI interactions
- Test error scenarios
- Test across different browsers/devices

### Additional Context

**Include:**
- Design mockups or wireframes
- Architecture diagrams
- Related documentation
- Constraints or limitations
- Open questions or concerns
- Future considerations

## Common Technical Patterns

### API Endpoint Pattern

```markdown
## ⚙️ Technical Details
- Proposed implementation approach:
  - [ ] POST /api/resource endpoint
  - [ ] Request validation middleware
  - [ ] Database operation
  - [ ] Response formatting
- Data considerations:
  - [ ] Resource model schema
  - [ ] Required fields validation
  - [ ] Data relationships
- Security/permissions:
  - [ ] JWT authentication required
  - [ ] Role-based authorization
```

### UI Component Pattern

```markdown
## ⚙️ Technical Details
- Proposed implementation approach:
  - [ ] Component structure (e.g., React component)
  - [ ] State management
  - [ ] API integration
  - [ ] Error handling UI
- Data considerations:
  - [ ] Component props/state
  - [ ] Data fetching strategy
  - [ ] Loading states
- Security/permissions:
  - [ ] Conditional rendering based on user role
  - [ ] Protected routes
```

---

*Technical breakdowns help you plan implementation before coding. Take time to think through all aspects of the feature.*

