INCOMING
01 / CAPTUREA low-friction front door.
A workspace-specific public form collects a useful signal without asking the customer to understand the internal system behind it.
FEEDBACK INTELLIGENCE WORKSPACE
SIGNALDESK
From scattered customer feedback to a decision room product teams can actually operate.
- 01INCOMING
- 02IN FOCUS
- 03ON TRACK
- 04CLOSED LOOP
- ROLE
- SCOPE
- BUILD
- AUDIENCE
- STACK
- Next.js 16Rails 8.1SupabasePostgreSQL
- CONSTRAINT
- CONTEXT / RESULT
- CODE
TECHNICAL READ
Access, integrity and verification at a glance.
Role and scope are stated above. This short map isolates the system shape, its hardest invariant, the decision that protects it and the exact proof.
- ARCHITECTURE
- Next.js → Rails → PostgreSQLSupabase provides the session; Rails owns policies and domain writes.
- HARD PROBLEM
- History cannot drift from stateA mutation without its audit event would make collaboration untraceable.
- KEY DECISION
- Commit the action and audit togetherOne database transaction accepts both records or rejects both.
- PROOF
- Forced audit failureRSpec raises the error and finds 0 persisted comments.
01 THE BRIEF
Feedback was everywhere.
Decisions were nowhere.
Product, support and leadership teams hear useful signals every day, but those signals arrive through forms, calls, messages and informal notes. The evidence gets separated from the decisions it should inform.
I designed and built SignalDesk as a shared operating layer: capture feedback, qualify it with consistent context, discuss it, decide what happens next and preserve the reasoning.
BUILT FOR
- Product teamsprioritize evidence
- Support teamssurface recurring pressure
- Leadersread the workspace pulse
02 THE PRODUCT LOOP
A signal keeps its context from intake to decision.
Four connected views make the workflow legible without turning it into a dashboard maze.
- 01INCOMING
- 02IN FOCUS
- 03ON TRACK
- 04CLOSED LOOP
IN FOCUS
02 / QUALIFYTurn noise into a working queue.
Source, status, priority, tags and customer context make Signals comparable. Searchable, shareable filters let teams return to the same operational view.
ON TRACK
03 / DECIDEMake the why durable.
The detail view keeps qualification, discussion and an immutable activity log together. The outcome is traceable, not trapped in a meeting.
CLOSED LOOP
04 / READ THE ROOMSee pressure, progress and closed loops.
The Control Room summarizes active volume, high-priority pressure and recently resolved Signals without replacing the evidence underneath.
03 ENGINEERING DECISION
The action and its audit commit together.
The activity timeline is a product promise, not a best-effort side effect.
- 01
PROBLEM
A comment or status change could persist even if its activity event failed, leaving the collaboration history incomplete.
- 02
CHOICE
Rails services write the business record and its ActivityEvent inside the same database transaction.
- 03
WHY
The invariant lives on the server: both records commit or both roll back, and a service spec exercises the failure path.
- 04
TRADE-OFF
Audit availability becomes part of write availability: a failed audit insert rejects the action instead of accepting an untraceable change.
TECHNICAL PROOF
Forced audit failure → no partial comment.
- INPUT
- ActivityEvent creation raises ActiveRecord::RecordInvalid
- MECHANISM
- CreateComment wraps the comment and audit write in Comment.transaction
- PROOF
- RSpec expects the error and finds 0 persisted comments
04 ARCHITECTURE
Clear ownership across every boundary.
Next.js owns rendering and interaction. Rails owns domain behavior and authorization. Supabase owns identity and PostgreSQL infrastructure. The browser never queries business tables directly.
01 / Experience
Next.js 16React 19TypeScript
App Router and typed interface states
02 / Identity
Supabase Auth
SSR sessions and ES256 tokens
03 / Domain
Rails 8.1 API
Validation, services and Pundit policies
04 / Data
PostgreSQLSupabase
Relational constraints and tenant-aware persistence
05 / Delivery
VercelRender
Independent deploys from one monorepo
AUTHENTICATED PATH
SSR session to bearer token to Rails policy scope to constrained relational data.
VERIFIED BYRequest specs: 401 without a token · 403 for an insufficient role · 404 outside the current workspacePUBLIC PATH
Origin checks, strict field limits, honeypot and rate limiting before Signal creation.
VERIFIED BYPublic request specs: disabled form → 404 · honeypot → no write · repeated submissions → 429ATOMIC WRITES
Domain services commit each state change with its audit event in one transaction.
VERIFIED BYService spec: failed audit event → raised error · partial comment → 005 CONSTRAINTS & TRADEOFFS
Production-minded, portfolio-sized.
The goal was not to simulate infinite scale. It was to make strong boundaries visible while keeping the service surface proportionate to a real product prototype.
The hardest part was keeping identity, tenant scope and mutation feedback coherent across two runtimes without duplicating domain rules.
- Two runtimesOne monorepo keeps product changes atomic, while Vercel and Render deploy independently.
- No direct browser data accessRails remains the single authority for validation, authorization and transactions.
- No premature infrastructureRedis, background jobs, analytics and billing stay deferred until measured load creates a reason.
- Honest free-tier limitsRender cold starts are acceptable for a portfolio environment, not presented as a production SLA.
06 QUALITY SYSTEM
The proof is in the failure paths.
Three verification levels cover access boundaries, transactional integrity and critical browser journeys.
- RSpec
- Playwright
- Axe
- RuboCop
- Brakeman
- ESLint
- REQUEST SPECSAccess boundaries
Authentication, role permissions, workspace isolation and public intake protections.
- SERVICE SPECSTransactional integrity
Audit events stay aligned with business records; a failed audit write leaves no partial comment.
- BROWSER + SECURITYCritical journeys
Playwright + Axe cover the real local stack; Brakeman and bundler-audit run in CI.
Accessibility checkedNo barrier detected by automated tests across the essential product journeys.
07 OUTCOME & LEARNINGS
A complete product argument, not a collection of screens.
SignalDesk now connects public intake, team qualification, collaboration, decision history and operational visibility in one deployed workflow. Its strongest result is coherence: each screen reinforces the same domain model and trust boundaries.
The build clarified a principle I carry into product work: expressive visual identity can coexist with serious operational software, but only when states, permissions and information architecture are quieter than the brand around them.
See the interface. Read the decision.
Every screen is shown without cropping, with a detailed preview that preserves interface readability.
See pressure, progress and closed loops.
The Control Room summarizes active volume, high-priority pressure and recently resolved Signals without replacing the evidence underneath.
A low-friction front door.
A workspace-specific public form collects a useful signal without asking the customer to understand the internal system behind it.
Turn noise into a working queue.
Source, status, priority, tags and customer context make Signals comparable. Searchable, shareable filters let teams return to the same operational view.
Make the why durable.
The detail view keeps qualification, discussion and an immutable activity log together. The outcome is traceable, not trapped in a meeting.
What I would do next.
Next, I would validate the qualification model with a real product-support team, then measure time to triage and decision consistency before expanding automation.