This process ensures all features are developed in alignment with our Practices documents, following the "simplicity first" and "startup agility" principles.
The feature development process follows these phases:
- Discovery - Understand the problem
- Definition - Write user story and acceptance criteria
- Design - Simple design before code
- Development - Incremental implementation
- Review - Practices-aligned code review
- Deployment - Ship and learn
Goal: Understand the user problem before proposing solutions.
- Identify the user problem
- Validate the problem is real and worth solving
- Consider the simplest solution first
- Ask: "What's the minimum viable feature?"
- Problem is clearly defined
- Problem is validated (user feedback, data, etc.)
- Simplest solution is considered first
- MVP scope is identified
Goal: Define clear, testable requirements using the user story template.
- Write user story using User Story Template
- Define expected behavior
- Write acceptance criteria (Given-When-Then format)
- Identify success metrics
- Link to relevant practices
- User story follows template format
- Expected behavior is clear and testable
- Acceptance criteria cover happy path
- Critical error cases are identified
- Success metrics are defined
- Related practices are linked
- Out of scope items are documented
Goal: Design the user experience and technical approach before coding.
- Design user experience (wireframes, flows)
- Consider edge cases but don't over-engineer
- Design data model (if needed)
- Design API endpoints (if needed - only for external APIs)
- Design Inertia pages and components (for Laravel monolith)
- Get feedback on design before implementation
- Product Practices - Product Development
- Feature Development Practices - Design Before Code
- Architecture Practices - Design Principles
- User experience is designed
- Data model is simple and normalized
- API design follows RESTful conventions (if external API needed)
- Inertia pages/components designed (for Laravel monolith)
- Edge cases are considered but not over-engineered
- Design feedback is gathered
- Design aligns with simplicity principles
Goal: Build incrementally, test as you go, ship fast.
- Build smallest working version first
- Add functionality incrementally
- Write tests as you develop
- Follow existing patterns and conventions
- Use Practices Checklist during development
- Follows existing code patterns
- Code is readable and self-documenting
- Tests written for happy path (see Testing Practices)
- Critical error cases are tested
- Security considerations addressed
- Database queries use parameterized queries
- Input validation implemented
- Error handling is clear
- No premature optimization
- Unit tests for business logic (Laravel services, models)
- Integration tests for API endpoints (if external API)
- Feature tests for Inertia pages (Laravel)
Use Practices Checklist during review:
- Code follows simplicity principles
- Security practices are followed
- Database practices are followed
- Code quality practices are followed
- Architecture practices are followed
Goal: Ensure code aligns with practices and meets acceptance criteria.
- Self-review before requesting review
- Run tests and linters locally
- Request review from team
- Address review feedback
- Verify acceptance criteria are met
- All tests pass
- Linter passes
- Code follows team conventions
- Acceptance criteria are met
- Practices checklist is verified
- Documentation is updated
- No obvious performance issues
Goal: Ship fast, learn from users, iterate.
- Deploy to staging/test environment
- Verify feature works in staging
- Deploy to production
- Monitor for errors
- Gather user feedback
- Plan iterations based on feedback
- Feature tested in staging
- Monitoring and alerts configured
- Rollback plan prepared (if needed)
- Documentation updated
- User feedback collection plan in place
- Monitor feature usage and errors
- Gather user feedback
- Measure against success metrics
- Plan iterations based on data
- Remove features that don't add value
- Product Practices - Product Maintenance
- Product Practices - Product Iteration
- Feature Development Practices - Feature Iteration
Follow the practices guidance on optimization:
- Product Practices: Optimize only when metrics show users struggling
- Code Quality Practices: Optimize only after profiling shows bottlenecks
- Database Practices: Optimize queries only after profiling shows slowness
- Architecture Practices: Optimize only when you have real scale/bottlenecks
Don't optimize:
- Before measuring
- For hypothetical future needs
- Code that isn't a bottleneck
- Features users aren't complaining about
- Building features "just in case"
- Over-engineering the first version
- Skipping tests to move faster
- Optimizing before measuring
- Waiting for perfection before shipping
- Adding features to fix feature problems
Before considering a feature complete, verify:
- User story acceptance criteria are met
- Feature solves the user problem simply
- Code follows all practices
- Tests are written and passing
- Documentation is updated
- No obvious performance issues
- Ready for production
- Can ship and learn from users