Most portfolio projects stop after implementing authentication and CRUD operations.
Production software doesn't.
Engineering teams need systems capable of handling operational failures under pressure. During an incident, dozens of engineers may collaborate simultaneously, permissions must be enforced correctly, every action must be recorded, and changes must propagate instantly across every connected client.
SignalHQ was built to explore those engineering challenges.
Instead of another task manager, the project focuses on modeling how modern organizations manage production incidents from detection to postmortem.
Modeling the Incident Lifecycle
One of the first architectural decisions was to treat an incident as a state machine rather than a collection of arbitrary status values.
Instead of allowing any transition, every change must follow predefined business rules:
Open
↓
Investigating
↓
Identified
↓
Monitoring
↓
Resolved
↓
Postmortem
Centralizing these rules inside a dedicated state machine eliminates duplicated logic, simplifies testing, and prevents invalid transitions from occurring anywhere in the application.
Authorization Beyond User Roles
Many applications stop at role-based permissions.
SignalHQ goes one step further.
Changing an incident's severity requires the appropriate role, while resolving an incident additionally requires ownership of that specific incident.
This combination of:
- Authentication
- Role-based authorization
- Resource ownership creates layered security that closely resembles production systems.
Separating Operational History from Security History
SignalHQ intentionally maintains two independent historical records.
Incident Timeline
Records operational activity:
- Comments
- Status changes
- Severity changes
- File uploads
Audit Log
Records security-sensitive actions:
- Login attempts
- Permission changes
- Escalations
- Administrative actions
Separating these concerns keeps operational history useful for responders while providing administrators with an immutable security trail.
Real-Time Collaboration
Engineering incidents evolve rapidly.
Refreshing the browser every few seconds isn't acceptable.
SignalHQ uses authenticated Socket.IO connections to broadcast updates after database transactions complete successfully.
Every connected engineer immediately receives:
- Status changes
- Timeline updates
- New comments
- Attachments
- Severity changes
The server remains the single source of truth - WebSockets never modify application state directly.
Search That Scales
Searching production incidents becomes increasingly expensive as data grows.
Instead of relying on:
ILIKE '%database%'
SignalHQ leverages PostgreSQL's native full-text search capabilities:
- tsvector
- GIN indexessq
- Database triggers
The result is significantly faster searching while keeping indexing responsibilities inside the database rather than application code.
Building for Maintainability
Throughout development, the primary objective wasn't adding features - it was reducing future complexity.
The backend is organized into isolated modules with dependency injection, DTO validation, migrations, and reusable guards.
This makes individual components independently testable while allowing the application to evolve without accumulating tightly coupled code.
Lessons Learned
Building SignalHQ reinforced several software engineering principles:
- Architecture matters more than frameworks.
- Authorization is more nuanced than checking user roles.
- State machines simplify complex workflows.
- Real-time systems should remain server-authoritative.
- Search should leverage database capabilities instead of application code.
- Auditability is a first-class feature in production software.
SignalHQ demonstrates that production-ready applications aren't defined by the number of features they contain, but by the quality of the engineering decisions behind those features.
Top comments (0)