Sending the survey is easy. The reply is the product.

A text message gets opened. An email survey sits unread in a promotions tab; a text is read within minutes, by almost everyone, almost always. That gap is a genuine reason to reach for SMS, and it's the honest pitch of an SMS-first survey tool: ask one question in a channel people actually look at, and you'll hear back from the people email never reached. The send is the part that demos. Wire up Twilio, blast a thousand "How was your visit? Reply 1–5," watch the replies trickle in, and it looks like a business in an afternoon.

It isn't, yet — and the reason is the channel cuts both ways. Sending a thousand texts is trivial. The product begins the instant a human texts back something you didn't anticipate.

The product is the inbox, not the outbox

Picture the replies actually landing. One says STOP. One is a three-paragraph complaint about the parking. One is a thumbs-up emoji and nothing else. One says "who is this?" One is a "4" with no context, replying to a survey you sent last month. One is a phone number that's been reassigned to someone who never visited you at all. The outbound message was uniform and you controlled every character of it. The inbound is a crowd of humans, each answering in their own way, and every one of those replies is now your problem to make sense of.

That's the reframe. The survey going out is the easy twenty percent — one templated message, one provider call, done. The product is the eighty percent that begins on the way back in: reading intent out of freeform text, honoring an opt-out the instant it arrives, and threading a stray "4" back to the right question and the right person so it means something. Sending is broadcast. Replying is a conversation, and a conversation is a much harder thing to own well.

The capability chain

Strip it to what has to happen, end to end:

You pick an audience and a question → you send the text → the recipient reads it → they reply, in whatever words they choose → you parse that reply into something structured → you record it against the right person and question → you show the organizer what came back. Seven steps, and exactly one of them — the send — is the part the Twilio quickstart covers. The other six are audience, delivery, interpretation, attribution, and reporting, and the heaviest of them is the one in the middle: turning a free-text reply into an answer you can count.

Notice where the difficulty sits. The send is identical for everyone and trivial for all of them. The parse is different every time, because people don't reply the way your form imagines they will.

What it rides on

Named as the modules a real version needs:

• Background jobs — sending to an audience, retrying the texts that didn't go, and processing replies as they arrive are all scheduled work that shouldn't block a web request. This is the same kind of batch runner that already polls and processes on a cadence under CompanyGraph in production.
• Accounts and auth — a survey, its audience, and its replies belong to an organizer, and only they should see who said what.
• A log — a local record of every message sent and every reply received: to whom, which survey, when, and what came back. When a recipient says "I asked you to stop texting me three weeks ago," that has to be a row you can read, not a guess. CompanyGraph runs exactly this kind of logger in production, with every message leaving a trace.
• An admin — somewhere the organizer, and you, can watch a campaign go out, see which replies are still unparsed, and answer "did this person opt out?" without opening the database. CompanyGraph has run on an operator admin like this since before it had its first user.

That list is the point of this whole site. Background jobs, a logger, accounts, an admin — those aren't features you'd invent for a survey tool; they're the boring, load-bearing parts that already run in production underneath CompanyGraph and send for Smallbox Labs from the same place. An SMS survey doesn't need any of them built. It needs one genuinely new capability — two-way SMS through Twilio — wired into a foundation that already carries the rest, plus a little analytics on the replies and email for the digest the organizer reads on Monday. That's the difference between a quarter of work and a week of it.

What you own, and what you leave with the provider

A useful habit for any idea like this: decide early what's yours and what stays at the provider.

Twilio stays external, and that's right. The carrier relationships, the number provisioning, the actual delivery of bytes to a handset across a dozen mobile networks — that's a hard, well-solved job worth renting, and rebuilding it would be a different company. What must be yours is everything about meaning and consent: the questions, the parsed answers, the attribution that ties a reply to a person and a survey, and — the load-bearing one — the consent record that says who agreed to be texted and who asked you to stop. If the only record of an opt-out lives in the provider's logs, you don't really have a product; you have a thin coat of paint over someone else's API, and a compliance problem with no home. Keep the answers and the consent state in your own database, and Twilio becomes a part you could swap for a cheaper carrier without losing what the product knows.

The foundation under that consent record — owning the opt-out instead of borrowing it — is its own subject. Owning consent and the opt-out list rather than renting them is the capability note beside this one, and an SMS survey rides every word of it.

The hard part

Two honest risks, and neither is the send.

Reply parsing. People do not answer the way your form imagines. You'll ask for a number 1–5 and get "great thanks!", "meh", a single emoji, a paragraph, or a reply to last week's question instead of today's. Pulling a usable answer out of that — and knowing when you can't, so a human can look — is genuine work, and it's most of the product. The fix isn't one clever regex; it's a parsing layer with a fallback to manual review and an attribution model that always knows which question a stray "4" belongs to. This is solvable, but it's the part you're actually building, and it's invisible in a demo where you reply to yourself, correctly, once.

Opt-out and consent — and this is the one that bites. SMS tends to be regulated more tightly than email's softer norms. A STOP has to be honored immediately and permanently, recorded as a fact you can prove, and never crossed again — and the same goes for the consent that let you text someone in the first place. Reach is the whole pitch of this product, and reach is exactly what turns deliverability and consent into the risk: the more people you can text, the more it matters that every one of them agreed to it and that every opt-out is instant and durable. Get this wrong and the failure isn't a bad review — it's carrier filtering that quietly kills your delivery, or a regulatory complaint with your name on it. The compliance shape is not optional and not a footnote; it's a first-class part of the build, and pretending otherwise is how an SMS product gets itself shut off.

The verdict

This is a real niche product with a real angle: SMS reaches people where email is ignored, and for the right audience — a clinic chasing visit feedback, an event wanting a one-tap rating, a service whose customers won't open a survey link but will glance at a text — that reach is worth paying for. But it's thin if it's only "send a survey," because the send is the commodity everyone can do in an afternoon. The depth is on the reply side: the parsing that turns freeform text into countable answers, the consent record that keeps you deliverable and compliant, the threading that makes a stray "4" mean something. Build the reply side well and you have a product. Build only the send and you have a Twilio demo with a logo on it.

Which is the kind of thing a foundation makes cheap to find out about. The honest question was never "can I send a thousand texts" — you can, today. It's "can I make the reply side good enough, and stay deliverable and compliant, before the parsing edge cases and the opt-out rules decide it for me." When the background jobs, the logging, the accounts, and the admin are already in place, only the two-way SMS and the reply handling are new — so a pointed version can reach real recipients fast, not because the work is trivial, but because nearly all of it is already built, and your attention goes straight to the part that was always going to be hard.

That's also the cleanest way to see where the line falls between a feature and a product over a channel like this. The honest line between a feature and a standalone product is its own build idea, and an SMS survey lands on the product side of it only when the reply, not the send, is what you've actually built.

---

Two-way SMS wired this way rides on the foundation — the background jobs, logging, accounts, and admin that turn a Twilio send into something a stranger pays for. If you've got a pointed version of an idea like this, the next sensible step is to put one workflow through the foundation and watch real people reply.