DEV Community: Ayoola Solomon

Your resume can be faked in an afternoon. Your work can't.

Ayoola Solomon — Fri, 25 Sep 2026 10:19:45 +0000

Anyone can now ask an AI to write a polished, backdated account of their career in an afternoon. A glowing summary of projects you led, skills you mastered, impact you drove: generated in minutes, nearly indistinguishable from the real thing, and almost impossible to verify after the fact.

That should worry anyone who relies on resumes, LinkedIn profiles, or portfolios to signal what they've actually done. Every one of them is a self-reported claim. They always have been. We just used to treat the effort of writing them as a weak proxy for truth. AI removed that proxy.

Polishing the claim doesn't fix the problem

Most advice for standing out right now is about being more visible: post more, network more, build a personal brand. That isn't bad advice. It just solves discoverability, not credibility. It makes claims louder, not truer.

In a world where anyone can generate a convincing story about their past, louder claims just mean better-produced fiction competes with honest work on equal footing.

What if your work wrote itself down as it happened?

I've been designing, and am now building (for myself first) a different answer: a work journal that doesn't rely on you remembering to write anything down, and can't be quietly rewritten later.

The core idea is simple. Instead of a document you write once and polish forever, it's a log that captures itself passively from things you're already doing: commits, calendar events, the real trail of a working life. Periodically, weekly or monthly, you review what it captured, approve it, and it becomes part of a permanent, dated record.

The part that matters most: once an entry is approved, it's immutable. Not "hard to edit." Actually append-only, enforced at the core of how the tool works, with optional cryptographic timestamping so the record's integrity can be verified by anyone, even years later, even if I disappear as the person maintaining it. That's what turns it from another journal into something closer to proof of existence at a point in time.

The shape of it

A few design decisions I think matter:

Local-first. Your data lives on your machine by default. Nothing is required to leave it.
Passive, not another app to open. It runs quietly in the background and nudges you, rather than waiting for you to remember it exists.
Open source. The whole point is trust, so there's nothing about how it works that isn't inspectable.
Immutable by design. Entries can be corrected by appending, never edited or deleted.
Optional, not mandatory sharing. The log is yours. What you choose to show a future employer, or no one at all, is up to you.

Where this stands

I'm building a personal version first, pulling from my own GitHub and calendar into a monthly rollup, and I'm going to actually live with it for six months before deciding whether it's worth being more than that. No grand claims yet. I just think the underlying problem is real and getting worse, and I'd rather find out if this is a genuine answer to it than assume it is.

If this resonates, or if you think it's solving the wrong problem, I'd like to hear it.

Resumes are becoming obsolete. Here's what I think replaces them

Ayoola Solomon — Fri, 18 Sep 2026 09:49:14 +0000

I've been in tech for over 10 years, across five companies: fintech, SaaS, and my own startups. Every time I update my resume, promo case, or LinkedIn, I hit the same wall: I genuinely can't remember what I did.

Not because it wasn't meaningful. Because nobody wrote it down as it happened. Ask me what I shipped in Q2 last year and I've got nothing, until I sit with it and slowly reconstruct. That's career amnesia, not a personal failing.

And even when I do remember, the resume format kills the part that mattered. "Managed cross-functional team to deploy new architecture" tells you nothing about the problem, the constraints, what broke, or what I learned fixing it. A resume doesn't just compress your career. It strips the context, and the context was the point.

Now add AI: a polished, keyword-optimized resume takes 30 seconds, whether you did the work or not. The format that already threw away the substance is now trivially fakeable too.

So what's left? Not what you say you did, but a dated, ongoing record of what you actually did, with the context intact.

What's already out there

A few tools circle this problem. Each solves a slice:

Dayflow: open-source, local on your Mac, turns screen activity into a daily timeline and standup summary. Great for "what did I do today?" Days and weeks, not a career.
bragdoc.ai and similar: pull GitHub commits and PRs into an AI brag doc for review season. Developer-only, and built for one moment a year.
ActivityWatch: long-running open-source activity tracker. Strong on raw data, no narrative.
Trajecta: closest in spirit, a permanent record of professional impact. Still manual entry. You're the one writing it.

Each nails a piece: local-first privacy, developer activity, raw tracking, long-term framing. None puts it together: passive where possible, guided where it can't be, non-technical roles included, built for years instead of days.

What I'm building

That's the gap I'm building into with EchoWork.

Where it can, it pulls from where the work already lives: commits, tickets, calendar. Where it can't (enterprise, IP-locked environments), it doesn't scrape or spy. It notices you had a three-hour block on "system migration" Friday and asks what you decided and shipped. Either way, it becomes a real monthly rollup: not a bullet point, but the actual story, dated and preserved.

It runs local-first, with your choice of LLM, so none of it has to leave your machine.

It's not built to replace LinkedIn or hand your data to recruiters. It's for you first, so when review season, a promo case, or a job search comes around, you're not starting from zero. Sharing a slice with an application is optional, not the point.

I'm building the first version for myself right now, testing whether I'd actually use it daily before deciding what it becomes. I think the resume's days are numbered. What replaces it is proof, with the context still attached.

Material vs locked: the rule that lets 2048 and Sudoku share a board

Ayoola Solomon — Sun, 13 Sep 2026 13:31:16 +0000

I've always loved Sudoku and 2048. They're the puzzles I open instead of scrolling. For a long time I wanted a mashup that felt like both, not a gimmick with two logos stuck on one grid.

Play Number Merge Sudoku (Daily or Endless). What follows is the design decision that made it playable.

Why mashups usually fail

Sudoku says: every digit appears once per row, column, and box.

2048 says: equal neighbors merge into the next value, and duplicates are the whole point of the economy.

If every tile on the board counts as a Sudoku digit the moment it appears, merges die. You can't keep two 2s in the same row long enough to make a 4. If you ignore uniqueness until the end, you don't have Sudoku; you have a merge game with a checkbox at the finish line.

The interesting problem isn't "can I render a grid in React." It's: when does a number start counting?

The contract: material vs locked

Every occupied cell holds a tile in one of two states:

Material: may share its value with other material tiles in the same row, column, or box. Material tiles can merge. They do not count toward Sudoku uniqueness.
Locked: counts as a Sudoku digit. Locked tiles cannot merge. A value may appear at most once as locked in each row, column, and box.

You only ever spawn 1s, and they always spawn as material. Merge two equal material neighbors and you get the next value, still material, on the survivor cell. No auto-chains. No Sudoku check on merge.

Seal is the verb that turns material into locked, in place. Seal is illegal if that value is already locked in the same row, column, or box. Until you seal, the board is allowed to look "illegal" by Sudoku standards. That's intentional. Duplicates are fuel.

Win condition: every cell is occupied by a locked tile, and every row, column, and box contains each digit of the board's alphabet exactly once. Easy is 4×4 (digits 1–4). Medium and Hard are 6×6 (digits 1–6).

One sentence version: Sudoku uniqueness applies only to locked digits.

That single sentence is the whole product.

Three moves, three jobs

The run is empty at the start. No seeded givens. You build the puzzle by playing it.

Spawn: put a material 1 on any empty cell. Always legal. No uniqueness check.
Merge: two orthogonally adjacent material tiles of equal value become one material tile of the next value on the survivor; the other cell clears. Max digit is terminal (4 on Easy, 6 on Medium/Hard). Locked tiles never merge.
Seal: convert one material tile to locked, if uniqueness still holds for locked digits.

UI-wise it's two-tap merge and tap-empty to spawn. The mental model is what matters: merge builds value; seal commits it to the Sudoku layer.

Color follows the same contract. Each digit has a fixed hue. Material uses a softer treatment; locked uses a denser one. Color never encodes "legal move" or hints. Digits stay readable. Hue is state, not advice.

Soft-locks aren't bugs

You can fill yourself into a corner where no spawn, merge, or seal remains, even with empty cells left. That's a Loss: a soft-lock.

I almost treated that as a failure of the ruleset. It isn't. It's the tax of a merge economy living under a uniqueness ceiling. If soft-locks couldn't happen, the puzzle would be too forgiving to feel like either parent game.

So Difficulty isn't "how many givens." There are no givens. Difficulty chooses board size, alphabet, undo budget, and hint budget:

Difficulty	Board	Digits	Undos	Hints
Easy	4×4	1–4	5	3
Medium	6×6	1–6	3	2
Hard	6×6	1–6	1	1

Undo reverts the last successful spawn, merge, or seal. It stays available through a soft-lock so you can dig out. After a Win, the run auto-finalizes; undo and hint close.

Hint is a legality nudge, not a solver. It reveals one currently legal move and leaves you to play it. Prefer merges that don't crowd the survivor's house with the result digit, then spawns that set up merges, then seals of unique material values. It does not claim a path to win. Spending a hint locks Difficulty for the run the same way the first real move does.

Daily as the habit loop

Daily: one run per UTC day. Leave mid-board and it resumes. Pick Difficulty until the first successful spawn, merge, seal, or hint; then it's fixed for that day. Elapsed time starts on the first real move (not on staring at an empty board, not on hint alone), pauses when the tab is hidden, and freezes on win.

Endless: same rules, as many runs as you want. No Daily share.

On Daily win, you get a board snapshot (digit hues intact) plus a caption: game name, UTC date, difficulty, win, undos used, hints used, elapsed time, and a clean link back to the play page. Share is opt-in after finalize. Losses aren't share artifacts. Soft-locks are for learning, not for the timeline.

I built the thing I'd open with coffee. The Daily is how that intention shows up in the product.

What I deliberately didn't do

No seeded puzzle of the day. The day is a label and a lock, not an RNG board. You and I start from the same empty grid; the run diverges with play.
No solver-as-hint. Hint answers "what is legal right now," not "what would a SAT solver do."
No React tutorial. The shell is Remix, TypeScript, and a small domain core with tests. The novel work was the state machine for material vs locked, not the component tree.
No "place any digit" mode. If you can drop a 6 wherever you like, you're back to Sudoku with extra steps. The merge ladder is the constraint that makes the board feel like 2048.

Try it

If you have a few minutes:

Open Number Merge Sudoku.
Start on Easy if you want the rule to click fast; Medium if you want the real Daily shape.
Spawn 1s, merge equals, seal only when uniqueness allows.
Soft-lock once on purpose. Undo. Notice what you learned.

When you win a Daily, share the board if you want. I'd rather see your soft-lock stories in the comments than a stack screenshot.

The mashup only works because uniqueness waits. Everything else is choreography around that one contract.

Play: ayoolasolomon.com/play/number-merge-sudoku

Project notes: ayoolasolomon.com/projects/number-merge-sudoku

If this was useful, the follow-ups worth writing are soft-locks as a feature, and a hint engine that reveals without playing. Tell me which one you want next.

Try our evaluation playground — no API key, no signup

Ayoola Solomon — Fri, 05 Jun 2026 19:06:57 +0000

We shipped a public playground for echostack — paste business signal text, get a structured decision back.

Try it: https://getechostack.com/playground

No account required.

What it does

Most tools give you a score. This returns an operational decision:

Status — e.g. QUALIFIED, PARTIAL, ESCALATE.
Extracted fields — budget, authority, severity, timeline, etc.
Recommended next action — e.g. BOOK_MEETING, ESCALATE_NOW, GATHER_INFO

Scenarios built in

Sales call — inbound qualification (BANT-style)
Web form — demo request / inbound lead
Support ticket — P0 outage triage
Trial usage — PLG expansion signals

Each scenario loads sample text you can edit, or paste your own (up to 1,000 chars).

Why we built it

We kept hearing: "I don't want another lead score — I want to know what to do with this inbound signal."

The playground runs the same evaluation path as our production API. Sign up only if you want API keys and to wire it into your stack.

What I'd love feedback on

Is the output format actually useful for your workflow?
What scenario should we add next? (support triage, fraud, compliance, etc.)
Would you use this via API, webhook, or no-code?

Drop a comment — especially if something breaks or the result feels wrong for your input.

Stop writing prompts to classify text: make evaluation declarative

Ayoola Solomon — Tue, 02 Jun 2026 20:02:27 +0000

I've built the same thing more than once: a step that reads an inbound
message — a lead form, a support ticket, a DM — and decides what to do with
it. Qualify it, escalate it, route it, drop it.

Every time, the implementation had the same shape: hand-write a prompt that
asks an LLM to return JSON, parse the JSON, branch on it. And every time it
rotted the same way:

The prompt was untestable. "Looks right" was the only QA.
It drifted. A model upgrade or a one-word prompt tweak silently changed the output and nobody noticed until something got misrouted.
The JSON lied. The model would confidently return a category that wasn't in my allowed set, or a number outside the range I expected, and my downstream switch would happily act on garbage.
"Confidence" was theater. if confidence > 0.7 is a magic number that means nothing across different inputs.

Eventually I stopped writing prompts. This is what I built instead and what I
learned.

The core idea: declare what to detect, not how to ask

Instead of a prompt, you declare typed detectors. Two kinds:

presence — "is this signal in the text?" → returns found
classification — "put this into exactly one of a fixed set of categories" → returns the category, enum-validated

{
  "name": "Partnership routing",
  "template": "custom",
  "custom_detectors": [
    {
      "name": "competitor_mentioned",
      "type": "presence",
      "examples": ["we're currently using Acme", "switching off a competitor"],
      "non_examples": ["love your product"]
    },
    {
      "name": "partnership_inquiry",
      "type": "classification",
      "categories": ["reseller", "affiliate", "strategic", "none"],
      "examples": [
        "interested in your reseller program",
        "want to co-sell with you",
        "just a support question"
      ]
    }
  ]
}

You never see the prompt — it's compiled from the declaration. That part isn't
the interesting bit; anyone can template a prompt. The interesting bit is
everything that becomes possible because a detector is a typed object instead
of a string.

1. Detectors are tested at create-time, not in prod

Every detector requires at least one positive example. When you create the
evaluation, those examples run as a smoke test: each positive must actually
match, and a classification example must land inside its declared
categories. If it doesn't, creation fails.

This is the part I wish I'd had years ago. A prompt can be syntactically fine
and semantically broken, and you find out in production. Here, a broken detector
can't ship — the assertion runs before it's ever live. (non_examples are
presence-only, because a classification detector always lands somewhere, so
there's no "not found" state to assert.)

2. The output is validated deterministically, not trusted

The LLM proposes; deterministic code disposes. The validators are boring on
purpose: present, range:0-100, enum:yes,no. An out-of-set classification
doesn't get to pass — it's coerced to not-found and surfaced in an
invalid_fields list so you can see the model misbehaved instead of silently
acting on it.

This is the line I'd defend hardest: structured outputs / function calling get
you a valid shape. They don't get you a checked value. A schema says "this
is a string from a set"; it doesn't run your range check or tell you the model
went off-menu.

3. Escalation is rules, not a confidence threshold

Escalation is separate from the model's self-reported confidence. You write
triggers on extracted values:

a classification trigger fires when the value is in a declared set
a presence trigger fires when the detector is found
required: true triggers are ANDed; required: false are ORed

So "escalate if it's a strategic partnership AND a competitor is mentioned" is
expressible and deterministic. No magic 0.7.

4. One call, structured decision out

POST /v1/evaluate → { status, extracted_signals, next_action }

status is one of QUALIFIED / PARTIAL / FAILED / ESCALATE. That's the whole
point: the thing my switch branches on is a small closed enum, not free text I
have to parse and pray over. It drops straight into n8n/Zapier/Make. You can
also POST real outcomes back later (converted? deal value? days to close?) so
the rubric can be measured against reality instead of vibes.

What I got wrong / what's still ugly

Being honest, because these are real:

Everything hits the LLM today. Even an obvious keyword goes through a model call. The plan is a pre-LLM pattern extractor so deterministic signals never pay for inference — not built yet. So cost/latency is "one batched LLM call per eval": fine for inbound webhooks, not for high-QPS streams.
It's synchronous. Long transcripts are slow; I prepend a structured header (severity/tier) instead of dumping a 5k-token thread.
Batching detectors into one prompt keeps cost down but lets one detector's phrasing bleed into another's extraction. Isolating them costs N calls. I chose cost; not sure it's right.
Multi-turn is naive. Re-evaluating a growing conversation re-sends the whole thing. Delta prompts are on the list.

The question I actually have

Is "declare + validate + smoke-test" the right altitude? Or do people doing this
seriously want prompt-level control and would find the abstraction a cage the
first time they hit an edge case?

My bet: for the 80% case — lead qual, ticket triage, intent on inbound — nobody
should be hand-maintaining a classification prompt, the same way nobody
hand-writes a query planner. But I've been wrong about abstractions before.
Curious where this breaks for you.

I packaged this up as the evaluation API behind EchoStack
— you can run an evaluation on your own text in the demo
(no signup) or skim the API quickstart.

How I Designed a Modular, Event-Driven Architecture for Real-Time Voice AI

Ayoola Solomon — Wed, 19 Nov 2025 09:49:54 +0000

Most voice AI systems today are built as a fixed chain:

STT → LLM → TTS → Audio Output.

This works for demos, but falls apart the moment you need:

Custom business logic
CRM integrations
Multi-agent routing
Knowledge lookups
Scheduling flows
Post-call actions
Pipeline branching

Swappable providers (Claude vs GPT, Deepgram vs Whisper, etc.)

So for EchoStack, I scrapped the idea of a “voice bot pipeline” entirely and built a voice automation platform powered by an event-driven orchestration layer.

Here’s how the architecture works — and why it has completely changed what’s possible with real-time AI.

LiveKit Only Handles Ingress & Egress

Not STT.
Not LLM.
Not TTS.

Just pure audio transport:

User Mic → LiveKit → EchoStack  
EchoStack → LiveKit → User Speaker

Inside EchoStack, every audio frame becomes an event:

processing.livekit.audio_frame

This makes the audio layer fully modular and independent of AI logic.

Everything Inside EchoStack Is a Connector

A connector can be:

Deepgram STT
WhisperX
AssemblyAI
Claude
GPT-4o
Llama 3
ElevenLabs
Azure Neural TTS
HubSpot
Salesforce
Zendesk
Calendly
A custom HTTP API
A knowledge search
A database entry
Or even another AI agent

{
  "consumes": ["processing.deepgram.text"],
  "produces": ["processing.claude.agent_message"]
}

EchoStack uses this to decide where events flow next.

This creates a real-time version of Zapier or LangGraph.

Pipelines Are Just Manifests

Instead of hardcoded logic, pipelines are defined like this:

{
  "pipeline": [
    "ingress.livekit.audio_frame → deepgram.stt",
    "deepgram.stt → claude.agent",
    "claude.agent → elevenlabs.tts",
    "elevenlabs.tts → egress.livekit.audio_chunk"
  ]
}

No code.
No wiring.
Just declarative routing.

Want to swap Deepgram for Whisper?
Edit one line.

Want to add sentiment analysis between STT and LLM?
Add one rule.

Want multi-agent routing?
Add a router connector.

Multi-Playbook Orchestration (The Real Game-Changer)

Traditional voice agents can only run one flow.

EchoStack can run many — and switch between them in real time:

LeadQualifier.json  
MeetingBooker.json  
FAQBot.json  
SupportAgent.json  
CRMLogger.json

If the user says:

“I want to book a meeting.”

Routing connector switches the playbook:

processing.deepgram.text → intent.router → meeting_booker.playbook

This is impossible in a linear voice bot pipeline, but trivial in an event system.

Real-Time Streaming (STT, LLM, TTS)

Because everything is async events, the system supports:

Streaming STT transcripts
Streaming LLM tokens (Claude / GPT-4o)
Streaming TTS audio chunks
Barge-in and interruption
Live agent escalation
Parallel processing
Multi-agent collaboration

Example LLM output stream event:

processing.claude.agent_message.partial

Example TTS stream:

processing.elevenlabs.audio_chunk.stream

The user hears responses as they are generated — not after the full LLM response.

Full Pipeline Simulation (No LiveKit Needed)

This is my favorite feature.

EchoStack can simulate:

Audio → STT
STT → LLM
LLM → TTS
TTS → Egress
All connector interactions

Without touching real providers.

It utilizes a mock runtime registry to generate realistic, fake outputs.

This allows:

Visual debugging
Step-by-step replay
Education demos
Test-driven development
Predictable QA
“Dry runs” before deployment

This is something even Retell & Vapi don’t have today.

And It Scales Like a Distributed System

Because everything is events:

Each connector is a worker
Workers scale horizontally
Backpressure is manageable
Failures can be contained
Retries & fallbacks are simple
Pipelines can fork or merge
Multi-agent flows work naturally
Audioless connectors (CRM, DB, API) blend seamlessly

It behaves like:

Zapier
AWS EventBridge
LangGraph
Airflow
N8N

…but optimized for real-time audio.

What This Unlocks for Businesses

This is where the architecture stops being “cool tech” and becomes actual value:

Lead qualification
After-hours support
Customer triage
Booking assistants
Helpdesk automation
Sales follow-ups
Knowledge Q&A
Order tracking
Multi-agent escalation
CRM syncing
Custom playbooks per industry
Complex routing between AI tools

You don’t just deploy “a bot.”

You deploy a network of intelligent voice automations.

Closing Thoughts

Voice AI is moving fast, but most of what exists today is still:

rigid
non-composable
difficult to integrate
tied to single vendors
non-debuggable
non-portable

By making the entire system event-driven and connector-based, EchoStack becomes:

A real-time automation platform where voice is the entry point — not the limitation.

If you’re into real-time systems, LiveKit, STT/LLM/TTS pipelines, or voice automation, I’d love to exchange ideas.

Inside the Manifest: How We Make Voice-AI Playbooks Deployable

Ayoola Solomon — Mon, 10 Nov 2025 21:51:59 +0000

Most businesses don’t want another AI “demo.”
They want deployable outcomes — like qualifying a lead, booking a meeting, or handling an after-hours call automatically.

At EchoStack, we wanted to make these outcomes as easy to launch as deploying code — and that’s how the manifest was born.

The Problem

Voice-AI tools today can hold great conversations, but they often stop there.
To actually move data into CRMs, book meetings, or send follow-ups, you need engineers stitching APIs together.

That doesn’t scale for non-technical teams.

Our Solution — The Manifest

Each playbook in EchoStack (e.g., Lead Qualifier, After-Hours Support) is powered by a manifest — a single file that describes:

what the playbook does
which tools it connects to
and what should happen when key events occur.

It’s like Terraform, but for voice-driven business outcomes.

Example Manifest (Simplified)

Here’s a simplified version of what a playbook looks like under the hood:

{
  "id": "lead-qualifier",
  "title": "Voice Lead Qualifier",
  "description": "Qualifies inbound leads via voice and syncs results to CRM.",
  "connectors": ["twilio", "hubspot", "calendly"],
  "events": {
    "call.started": "start_conversation",
    "lead.qualified": "create_contact",
    "meeting.booked": "schedule_event"
  }
}

This isn’t code — it’s a declarative contract between the voice experience and the business stack.
Our platform reads this file, provisions the right connectors, and handles orchestration automatically.

Why It Matters

No-code deployment: Business teams can launch playbooks instantly.
Version control: Every manifest can be tracked, forked, and redeployed.
Extensibility: Developers can author new playbooks using familiar patterns (JSON, events, connectors).

It turns AI workflows into deployable building blocks — reusable, composable, and measurable.

What’s Next

We’re expanding the manifest system to support richer event schemas and multi-step orchestration.
Soon, teams will be able to chain multiple playbooks together — stacking outcomes like Lego blocks.

Closing Thought

If you’ve ever written Terraform for infrastructure or YAML for CI/CD, imagine doing that —
but for voice automation.
That’s what EchoStack’s manifests make possible.

Curious to see a manifest in action?
We’re opening early access for developers building voice-AI workflows — you can join at getechostack.com

Designing Deployable Voice-AI Playbooks

Ayoola Solomon — Tue, 28 Oct 2025 08:54:07 +0000

This is a design/engineering write-up for our EchoStack pivot. We’re packaging Voice-AI playbooks (like After-hours Answering and Lead Qualifier → Auto-Book) into deployable solutions with no-code setup, safe rollouts, and KPI tiles.

Status: Early Access only — we’re validating integrations and rollout safety with a small group before opening signups.

Why playbooks (not tool soup)

Teams don’t buy models; they buy outcomes: fewer missed calls, more booked meetings, lower AHT. The hard parts are barge-in latency and safe deployment, not the LLM itself.

Latency budget we hold ourselves to (p95 targets)

ASR partials: 60–90 ms
LLM first token: 80–120 ms
TTS first audio: 50–80 ms
Network buffers: 40–60 ms → Goal: < 300 ms p95 end-to-end (barge-in friendly).

Rollout safety (what we’re building)

preflight → plan → apply (blue) → smoke test → switch (green) → rollback

Preflight checks scopes, latency probes, and config drift.
Plan shows a human-readable diff.
Apply deploys to an inactive slot (blue).
Switch flips traffic; Rollback is one click.

Integration surface (first adapters)

Telephony: Twilio/Plivo/SIP
Voice agent: Retell (others later)
Calendar: Calendly/Google
CRM: HubSpot/Salesforce (Sheets fallback)
Helpdesk: Zendesk (optional)

What exists today

Data model + manifests for two playbooks
No-code configuration flow (internal)
Preflight → plan → apply skeleton
KPI tiles (self-serve %, AHT, booked meetings) wired to session events

What we’re validating next

Region-aware routing under load
Failure modes during blue/green switches
Adapter ergonomics (CRM/calendar/telephony edge cases)

Looking for feedback

Are these p95 targets realistic for your use case?
What minimum logs/SLAs make you comfortable with rollout?
Which adapter combo should be prioritized?

More context: https://getechostack.com/playbooks

Early Access (no public demo yet): https://getechostack.com/contact?subject=Early%20Access

From building a voice AI widget to mapping the entire Voice AI ecosystem (Introducing echostack)

Ayoola Solomon — Mon, 13 Oct 2025 19:04:15 +0000

Hey everyone,

I’m Solomon — the creator of GetEchoSpace, a voice AI widget that lets any website host real-time audio conversations for support, live shopping, or community.

While building it, I constantly had to combine tools for ASR, text-to-speech, and LLMs — juggling APIs from different vendors and testing pipelines just to get a working flow.

At some point, it hit me:

Everyone building in voice AI is reinventing the same workflows from scratch.

The Problem

There are incredible voice AI tools out there — from OpenAI’s speech APIs to ElevenLabs, Whisper, Speechmatics, and more.
But there’s no central place to discover, compare, and see how they connect in real-world setups.

Builders like me spend hours figuring out:

which ASR integrates best with Twilio,
how to pass data between TTS and LLMs,
and how to deploy these flows in production.

Enter echostack

So I started building echostack — a public directory of voice AI tools and ready-made “stacks.”

Think of it as Zapier templates or Stack Overflow for voice AI workflows.
Each stack shows how to combine tools (e.g., Retell + OpenAI + Twilio + GCP ASR) to achieve real outcomes — like multilingual dubbing, customer triage bots, or AI-powered voice assistants.

The goal:

help developers and AI builders spend less time wiring tools, and more time shipping value.

Tech Behind the MVP

The MVP is built with:

Next.js 15 (App Router)
TypeScript + Tailwind
Supabase (for data)
Zapier & n8n export support planned for v0.2

What’s Live Now

You can explore:

Featured voice AI tools
Early “stacks” (like multilingual dubbing or real-time triage bots)
Newsletter signup for updates as new stacks drop

https://getechostack.com

I’d love your feedback

If you’re building with Voice-AI or integrating ASR/TTS/LLM tools, I’d love to hear:

What workflows or “stacks” you’d want to see next
Which tools are must-haves for you
Whether you prefer no-code or code-level examples

What’s Next?

Expand to more tools and stacks
Add semantic search and tagging
Support Zapier/n8n exports
Launch the curated Voice-AI Stacks Newsletter

If that sounds interesting, you can check it out or share feedback directly on echostack.