Making feedback
buildable.
I co-founded Napkin and built the backend pipeline that turns customer feedback into structured signals, patterns, priorities, specifications, and task plans.
Plenty of feedback.
Not enough clarity.
A message is not a specification. Before an engineer can act, someone has to connect the repeated problems, retain the original context, and decide what belongs in scope.
My work centres on that middle: collecting feedback, orchestrating the AI stages, and turning the result into useful engineering artifacts.
A pipeline you can follow.
The current orchestrator runs a direct asynchronous flow. Each stage writes its progress and outputs to a Supabase session, so the frontend can follow the analysis.
- 01
Intake
Raw text → structured signals and near-duplicate filtering.
- 02
Synthesis
Signals → patterns, then prioritised opportunities.
- 03
Context
Strategic context plus available business and repository information.
- 04
Build & export
Specification → task plan → exported artifacts.
The interface starts sessions and reads their progress.
Specialised stages extract, synthesise, prioritise, and build specifications.
Feedback and session outputs persist outside the model context.
Sync and automatic analysis use thresholds and cooldowns.
Follow one piece of feedback.
Illustrative input, not a real customer quote or a live run.
“I can’t tell which feedback led to this task.”
Keep the original words.
Intake preserves raw input in the session and extracts structured fields such as the pain, request, and context. Failed extraction can fall back to the raw text.
Look for related signals.
Embedding similarity filters near-duplicates. Synthesis groups the remaining signals into patterns, rather than treating every sentence as a separate feature request.
Decide what the pattern means.
Prioritisation and strategic context narrow the scope. Repository and business context, when available, inform the specification.
Produce a handoff.
The specification feeds a task plan and exports. These artifacts help an engineer investigate and build; they still need human review.
The details matter.
Bound the model work.
Intake uses batches of 50 inputs with at most five batch calls in flight. A semaphore bounds concurrency, and exceptions fall back to raw signals instead of discarding the whole batch.
Trade-off: partial results keep the pipeline moving, but a fallback is lower-confidence evidence.
Deduplicate carefully.
The intake implementation compares embeddings with a 0.92 cosine-similarity threshold. It keeps the earlier signal when two are sufficiently close.
Trade-off: similarity can collapse distinct customer needs. Removing a duplicate is not the same as preserving how often a problem occurred.
Save the intermediate work.
Stage outputs are written into the session as the analysis progresses. That makes the result inspectable without relying on a single final model response.
Persistence is useful, but an in-process background task is not itself a durable job queue.
Next engineering priorities.
A logical next step would be connecting the existing spec-QA module to the main flow; its quality gates are not yet enforced there.
Raw text is retained, but source-record IDs are not carried consistently through every transformation. Stronger provenance, failure recovery, and tests around duplicate handling are areas worth strengthening.