Voice for Technical Specs

Draft technical specifications by talking through your architecture. Capture design decisions, tradeoffs, and implementation plans while they're clear in your mind.

The Problem

Writing technical specs is one of the highest-leverage engineering activities, but also one of the most dreaded. The blank page is intimidating, the scope feels massive, and by the time you sit down to write, you've lost the clarity you had during your initial design thinking.

The Solution

Ummless lets you think out loud through your technical design, capturing architecture decisions, tradeoffs, and plans in real time. The Technical Documentation preset structures your verbal design session into a proper spec with sections, diagrams descriptions, and clear requirements.

Workflow

Think through the design
Spend time understanding the problem space before dictating. Sketch on paper if it helps.
Open Ummless
Select "Technical Documentation" for structured technical output.
Talk through the architecture
Explain the problem, proposed solution, alternatives you considered and rejected, data models, API contracts, and rollout plan.
Refine section by section
You may want to dictate in chunks, one section at a time, for complex specs. Combine the outputs afterward.
Review with stakeholders
Share the drafted spec for feedback. The structured format makes it easy for others to comment on specific sections.
Iterate
Use Ummless again to dictate revisions based on feedback, keeping the spec up to date with minimal effort.

Before & After

Raw Transcript

For the notification system I'm thinking we go with a pub-sub architecture using uh Redis streams. The idea is each service publishes events to a stream and then we have a notification worker that consumes from those streams and decides what to send. We considered using a message queue like RabbitMQ but Redis is already in our stack and streams give us the persistence we need. The main tradeoff is that Redis streams don't have dead letter queues built in so we'd need to build our own retry logic.

Refined Output

## Technical Specification: Notification System ### Architecture Pub-sub architecture using Redis Streams. Each service publishes events to a dedicated stream. A centralized notification worker consumes events and determines delivery (email, push, in-app). ### Decision: Redis Streams over RabbitMQ **Chosen:** Redis Streams - Already part of our infrastructure (no new dependencies) - Provides event persistence and consumer group support **Rejected:** RabbitMQ - Would introduce a new infrastructure dependency - Overkill for our current throughput requirements ### Tradeoffs - Redis Streams lack built-in dead letter queues; custom retry logic with exponential backoff is required - Consumer group rebalancing needs monitoring to prevent event loss during deploys

Suggested Presets

Technical Documentation

Frequently Asked Questions

How do I handle specs that are too long for one session?

Break the spec into logical sections (architecture, data model, API, rollout) and dictate each separately. Combine the outputs into a single document afterward.

Can I include diagrams?

Ummless handles text. Describe your diagrams verbally and the preset will create clear textual representations. Add visual diagrams separately using your preferred diagramming tool.

Ready to try it?

Download Ummless and start using voice for your workflow.