Phase 4 step-by-step
Deliver one senior-level feature end to end.
Outcome: a feature design, module plan, code boundary, accessibility review, performance evidence, security pass, and rollout plan.
Design
Build
Measure
Roll out
Choose the feature
Use a feature with real cross-cutting concerns. Example: reminder notifications for saved businesses.
Checkpoint: you can state the user problem in one sentence and define one non-goal.
Write the feature design doc
Feature: Saved business reminders Problem: Users save providers but forget to contact them. User flow: Detail screen -> Save -> Set reminder -> Reminder list. Non-goals: No server notifications. No calendar sync. Risks: notification permission, OEM alarm behavior, duplicate reminders. Success: users can create, view, cancel reminders reliably.
A reviewer can understand scope before reading code.
Draw module boundaries
Start with ownership and dependency direction.
:app
:core:model
:core:notifications
:feature:catalogue
:feature:reminders
Allowed: :feature:reminders -> :core:model :feature:reminders -> :core:notifications Not allowed: :core:notifications -> :feature:reminders
Define the feature API
Expose the smallest contract other modules need.
interface ReminderScheduler {
fun schedule(reminder: BusinessReminder): Result<Unit>
fun cancel(reminderId: String): Result<Unit>
}
data class BusinessReminder(
val id: String,
val businessId: Int,
val title: String,
val triggerAtMillis: Long
)Checkpoint: feature code can be tested with a fake ReminderScheduler.
Add accessibility requirements before implementation
- Reminder time picker has clear labels.
- Save/cancel buttons are reachable by screen reader.
- Dynamic font does not clip date/time labels.
- Error message says how to fix invalid reminder time.
Add performance checks
Senior engineers measure the risk they introduce.
| Startup | No reminder database read before first screen unless required. |
|---|---|
| List | Reminder list uses stable ids and avoids formatting in tight loops. |
| Battery | Scheduling does not poll; use platform scheduling APIs. |
Add security and privacy checks
- No phone numbers or addresses in logs.
- Reminder notification text avoids sensitive private data.
- Permission prompt appears only when the user asks for reminders.
- Failure path works if notification permission is denied.
Prepare rollout evidence
Rollout checklist: - Unit tests for reminder validation - Manual test on Android 13+ notification permission - Accessibility pass with large font - Feature flag default off - Rollback: disable reminder entry point - Metrics: reminder created, reminder fired, reminder cancelled
The feature can launch gradually and be disabled without breaking saved businesses.
Senior-level risks
Feature starts with codeWrite design and rollout constraints before implementation.
Module boundary follows UI tabsBoundary should follow ownership and dependency direction, not screen labels.
Accessibility checked lateLate accessibility fixes often cause layout rewrites.
No rollbackA senior feature needs a safe stop path before launch.
Completion gate
- Design doc reviewed before code.
- Module graph is explicit.
- Public API is small and testable.
- Accessibility, performance, security, and rollout evidence exist.