Skip to content
main
Straddle 101 - Internal
  • Pages
    • main
      straddle
      • TL;DR
      • Embed
        • main
          Regulatory Structure
        • Weave (KYB Decisioning)
      • Strategy
      • Press Release
    • Big ideas '25
      • Manifesto
      • Communication
        • Open doors
      • Engineering @ Straddle
        • Engineering Values
        • Building @ Straddle
          • Discovery->Delivery
          • Linear Guide
            • Projects
            • Issues
            • Workflows
          • Templates
            • Project Template
            • Short PRD
            • Concise Issue
            • icon picker
              Detailed Issue
      • main
        Company Memo
      • 2025 Strategy
      • Ideal Customer Profile
      • Personas
      • Compound Startup
    • Straddle Public Library
      • Payments vs Transfers
      • APIs as ladders
      • How to avoid breaking APIs
        • Breaking changes in JSON APIs
      • How to: Friction Logs
      • Enterprise sales meets product development
    • Payment Systems
      • ACH
        • ACH Basics
        • Flow of Funds
        • ACH Primer
          • Why do businesses choose ACH?
          • ACH vs wire transfers: what’s the difference?
          • What is Nacha and is your business compliant?
          • What is an ACH debit?
          • What is direct debit?
          • What is ACH credit and how does it work?
          • How does an ACH deposit work? A behind the scenes look
          • How an ACH transfer works: a complex process explained
        • Nacha Quick Reference Guide
          • ACH Returns Quick Reference
main
Straddle 101 - Internal
/
/
Detailed Issue
Share
Explore

Detailed Issue

Format

Issue Title

Short and Direct
team should be able to understand purpose of issue at a glance

Overview

Task/Problem Description
Keep it to a few sentences
Link to PRD in Coda [will also be linked in the project links section in Linear]

Outcome/Deliverable

Defined Result or Goal of the Task

Acceptance Criteria

List of Specific, Measurable Conditions for Completion

Technical Specifications

Specific Technical Requirements or Guidelines

Notes (Optional)

Additional Thoughts

Additional Context/Links (optional)

Internal or external links
Best practices
Research material
Industry standards
ALWAYS SEARCH THE INTERNET FOR REFERENCE MATERIALS, NEVER LINK TO THE CHAT INSTANCE

info
Remember to configure the issue settings in linear
Status
Priority
Assignee
Estimate
Labels (if appropriate)

Recommendations

This section is for you, the agent to provide recommendations [only when appropriate] such as splitting the issue into sub-tasks [with details] or other potential improvements

Example

Customer Endpoint v1

Overview

This issue involves the creation of Straddle API endpoints for the customer resource management.
The API will facilitate actions such as creating, looking up, deciding on, unmasking, updating, listing, and deleting customer records.
It will enable individual and business customer types to be created and prepare for future integration with verification and risk management tools. The development should align with the specifications and objectives detailed in the product requirements documentation

Outcome/Deliverable

The outcome is the successful development of the following API endpoints, including appropriate responses:
Function
URL
Method
Notes
​
​
​
Create a customer
/v1/customers
Endpoint for creating new individual or business customer records.
Lookup a customer
/v1/customers/:id
Endpoint to retrieve details of a customer by ID.
Decision a customer
/customers/:id/decide
Endpoint to accept or reject a customer with pending status.
Unmask a customer’
/customers/:id/unmask
Endpoint to retrieve sensitive data for a customer.
Update a customer
/customers/:id
Endpoint to update existing customer information.
List all customers
/v1/customers
Endpoint to list all customers with pagination support.
Delete a customer
/v1/customers/:id/delete
Endpoint to soft-delete a customer record
There are no rows in this table
⁠

Acceptance Criteria

Each endpoint is tested and returns the correct status codes and JSON responses as per the API contract.
API endpoints handle errors gracefully, providing meaningful error messages.
All endpoints perform necessary validations and enforce data integrity.

Technical Specifications

API endpoints will follow RESTful design principles and support JSON request and response bodies.
Security measures such as authentication, encryption, and rate-limiting are implemented from the start.
Data schema validation is in place to ensure the consistency and integrity of customer data.
Logging and monitoring are set up to track usage patterns and potential issues.

Notes (Optional)

Architecture should be scalable and maintainable, with considerations for future enhancements such as risk scoring integration.

Additional Context/Links (optional)


Format
Issue Title
Overview
Outcome/Deliverable
Acceptance Criteria
Technical Specifications
Notes (Optional)
Additional Context/Links (optional)
Recommendations
Example
Customer Endpoint v1
Overview
Outcome/Deliverable
Acceptance Criteria
Technical Specifications
Notes (Optional)
Additional Context/Links (optional)
Gallery
 
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.