What the agent actually answered, all 5 times
We need to send one time passcodes by text message during signup, and later appointment reminders, to customers in Europe and the United States. Node backend, nobody here has done telecoms before. Which provider would you use, and what else did you weigh before choosing it?
claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.
Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.
claude · run 1
named twilio.com first · 3 of ours named in all
**Twilio (Verify API), nie surowe SMS API.** Dla zespołu bez doświadczenia telekomowego kluczowe jest to, że Verify robi za was generowanie/rotację kodów, rate-limiting, ochronę przed fraud (toll fraud na OTP to częsty atak) i sam ogarnia zgodność z lokalnymi wymogami (rejestracja 10DLC w US, sender ID w UE) - czyli dokładnie te pułapki, w które najłatwiej wpaść nie znając tematu. Do przypomnień o wizytach (już nie OTP, więc Verify niepotrzebny) użylibyście zwykłego Messages API z tego samego konta.
Co odrzuciłem po drodze: **AWS SNS/Pinpoint** - tańszy, ale zero wbudowanej logiki OTP, słaba dostarczalność do EU/US bez ręcznej konfiguracji sender ID i rejestracji, więcej roboty właśnie tam gdzie brak wam doświadczenia. **Vonage/MessageBird/Plivo** - tańsze, porównywalny zasięg EU+US, realna alternatywa, ale mniej dojrzały produkt "Verify" i słabszy Node SDK/dokumentacja - dla pierwszego kontaktu z telekomem to się przekłada na więcej czasu na debugowanie zamiast dowiezienia feature'u. Główny kompromis: Twilio jest droższe (Verify liczy się per próba, nie per SMS), ale ta premia kupuje mniej roboty operacyjnej i mniejsze ryzyko regulacyjne na starcie.
claude · run 2
named twilio.com first · 3 of ours named in all
**Twilio** (a konkretnie Verify API do OTP + zwykłe Messaging API do przypomnień), nie surowe SMS-y przez własną logikę.
Dlaczego to, a nie coś tańszego:
- **Verify API zdejmuje z was ryzyko, którego jeszcze nie znacie.** Generowanie kodu, TTL, retry, rate limiting i ochrona przed "SMS pumping fraud" (ktoś zasypuje wasz formularz rejestracji, żeby generować płatne SMS-y na numery premium) są wbudowane. Zespół bez doświadczenia telekomowego pisząc to od zera prawie na pewno zostawi lukę, która później kosztuje realne pieniądze.
- **US 10DLC to pułapka, o którą rozbija się większość pierwszych wdrożeń.** Amerykańscy operatorzy wymagają rejestracji brandu/kampanii, inaczej SMS-y są filtrowane albo blokowane. Twilio prowadzi przez to w konsoli krok po kroku; u tańszych dostawców trzeba to ogarniać samemu i debugować "dlaczego SMS nie doszedł" bez dobrego wsparcia.
- **Node SDK i dokumentacja są tu najdojrzalsze**, więc jak coś się wywali o 2 w nocy, łatwiej to znaleźć w Stack Overflow/community niż przy mniejszych graczach.
Co jeszcze brałem pod uwagę i odrzuciłem:
- **AWS SNS/Pinpoint** - taniej, jeśli już siedzicie w AWS, ale słabsze narzędzia pod OTP i gorsza dostarczalność w Europie; debugowanie filtrowania przez operatorów jest trudniejsze.
- **Vonage** - porównywalne API i też ma Verify, czasem tańszy, ale mniejsza społeczność i mniej spójna dokumentacja.
- **MessageBird/Bird** - mocny w Europie (siedziba w Holandii), ale historycznie słabiej ogarnięty pod US 10DLC.
- **Infobip** - dobre relacje z operatorami globalnie, dobry przy skali, ale bardziej enterprise'owy proces sprzedaży, mniej self-service pod pierwsze wdrożenie.
- **Plivo** - tańszy, ale mniejsze wsparcie i słabsza ochrona przed nadużyciami.
Niezależnie od dostawcy: dla przypomnień o wizytach trzeba obsłużyć STOP/opt-out (TCPA w USA, podobne wymogi zgody w UE/RODO) i zarejestrować numer w USA (10DLC albo toll-free) zanim ruszycie produkcyjnie, bo inaczej dostawa się posypie po kilku dniach.
claude · run 3
named twilio.com first · 4 of ours named in all
## Rekomendacja: Twilio (Verify API do OTP + Programmable Messaging do przypomnień)
Dla zespołu bez doświadczenia w telekomie kluczowe jest to, żeby providera zdjąć z was jak najwięcej rzeczy, które łatwo zepsuć, a nie tylko wysyłać SMS-y tanio.
**Dlaczego Twilio, a nie surowe SMS API:**
- **Verify API** do OTP zdejmuje z was generowanie kodów, ich TTL, retry, rate limiting per numer i podstawową ochronę przed toll fraud (boty generujące OTP-y na cudzy koszt to realny koszt, nie teoria). Sami byście to musieli dopisać i utrzymywać.
- Fallback z SMS na połączenie głosowe wbudowany w Verify - przydatny tam, gdzie SMS nie dojdzie (część sieci w USA, niektóre kraje UE).
- Najlepsza dokumentacja i Node SDK na rynku - dla zespołu, który uczy się tego od zera, to realnie skraca czas do produkcji.
- Pokrycie EU + US z jednego konta, plus opcja EU data residency (istotne pod RODO, skoro macie klientów w Europie).
**Co jeszcze ważyłem, zanim padło na Twilio:**
- **Vonage (dawny Nexmo) i Infobip** - porównywalne API Verify, Infobip silniejszy lokalnie w Europie i czasem tańszy, ale słabsza dokumentacja i mniej dojrzały Node SDK niż Twilio; warta rozważenia opcja B, nie odrzuciłbym całkiem.
- **AWS SNS/Pinpoint** - najtańszy, ale to surowy SMS bez logiki OTP (musielibyście sami zbudować generowanie/expiry/rate limiting) i słabsza deliverability w Europie niż u dedykowanych CPaaS. Odpada przy zerowym doświadczeniu w temacie.
- **MessageBird/Bird, Plivo** - tańsze niż Twilio, ale mniej dopieszczone API Verify i wsparcie; sensowne, gdy już wiecie, czego chcecie, nie na start.
**Rzeczy, które trzeba ogarnąć niezależnie od wyboru providera:**
- **A2P 10DLC w USA** - rejestracja kampanii i brandu jest obowiązkowa, bez niej operatorzy w USA zaczną throttlować lub blokować wiadomości. To temat na tydzień-dwa formalności, nie da się pominąć żadnym providerem.
- **Alfanumeryczny sender ID w części krajów UE** (np. Niemcy, Francja) wymaga rejestracji z wyprzedzeniem - inaczej wiadomości idą z losowego długiego numeru i mają gorszą dostarczalność.
- Osobne kolejki/limity dla OTP (krytyczne, niska tolerancja na opóźnienie) i przypomnień (można batchować, mniej pilne) - żeby wzrost ruchu przypomnień nie zjadł przepustowości potrzebnej na OTP.
Start jednym vendorem (Twilio) ma sens na MVP - multi-provider failover to optymalizacja, którą wprowadza się, gdy already macie ruch i dane o awariach, nie na starcie.
claude · run 4
named twilio.com first · 3 of ours named in all
Do OTP-ów i przypomnień bym wziął **Twilio**, konkretnie jego **Verify API** (nie surowe SMS API) - bo dla zespołu bez doświadczenia w telekomie to ważna różnica: Verify sam ogarnia rate-limiting, retry na inny kanał i ochronę przed SMS pumping fraud, czyli rzeczy, które inaczej trzeba by budować ręcznie i błędy w nich są kosztowne (fraud na OTP potrafi wygenerować realny rachunek). Dobre pokrycie EU+US, dojrzały Node SDK i dokumentacja.
Co odpadło: **AWS SNS/Pinpoint** - tańszy, ale bez warstwy OTP-specific (fraud, retry) i ze słabszym wsparciem deliverability, więc dla pierwszego kontaktu z telekomem większe ryzyko. **Vonage/Sinch** - porównywalne funkcjonalnie, ale mniejszy ekosystem i wsparcie community/dokumentacja słabsze niż Twilio.
Jedna pułapka niezależna od wyboru: w USA trzeba zarejestrować numer/brand pod **A2P 10DLC**, inaczej wiadomości będą filtrowane jako spam - to zajmuje dni, więc warto zacząć równolegle z integracją.
claude · run 5
named twilio.com first · 4 of ours named in all
**Twilio** – a konkretnie: **Twilio Verify** do OTP przy rejestracji, **Twilio Messaging** (Messaging Service) do przypomnień o wizytach.
## Dlaczego Verify, nie goły SMS API do OTP
OTP to nie "wyślij SMS z kodem" - to osobna kategoria: generowanie kodu, retry na inny kanał (SMS → voice fallback), throttling przed brute force, wykrywanie fraudu (toll fraud na numerach premium to realny koszt, jak ktoś zacznie nadużywać formularza rejestracji). Verify robi to po stronie Twilio, kod nigdy nie trafia do waszej bazy - mniejsza powierzchnia ataku i mniej kodu do napisania od zera. Zespół bez doświadczenia telekomowego korzysta na tym podwójnie: nie trzeba tego projektować samemu.
## Co ważyłem
- **US 10DLC** - każdy provider wymaga rejestracji brandu i kampanii (A2P 10DLC), inaczej wiadomości są throttlowane albo blokowane przez operatorów. To proces z realnym lead time (1-4 tygodnie na vetting), trzeba go zacząć zaraz na starcie, nie tuż przed wdrożeniem. Traktowałbym OTP i reminders jako dwie osobne kampanie (2FA ma inny profil throughput niż marketing/notyfikacje).
- **Pokrycie Europy** - to nie jeden rynek: część krajów (Niemcy, Francja) ma własne wymogi co do sender ID i rejestracji nadawcy. Duże różnice w cenie za SMS między krajami.
- **Data residency (RODO)** - Twilio ma opcję EU region (Dublin), przydatne jeśli dane OTP/numery telefonów mają nie opuszczać UE.
- **Jakość SDK i dokumentacji pod Node** - przy zerowym doświadczeniu telekomowym to realnie liczy się bardziej niż drobna różnica w cenie za wiadomość, bo błędy przy onboardingu (rejestracja, formaty numerów, webhooki delivery status) kosztują więcej czasu niż różnica w rachunku.
- **Delivery receipts / webhooki** - potrzebne żeby wiedzieć, czy przypomnienie faktycznie doszło, a nie tylko "zostało wysłane".
## Co odrzuciłem i dlaczego
- **AWS SNS** - najtańszy jeśli już siedzicie w AWS, ale brak funkcji specyficznych dla OTP (retry, fraud detection, dedykowany tracking), AWS sam sugeruje nieużywanie SNS do OTP na większą skalę. Za mało "paved road" dla zespołu bez doświadczenia.
- **Vonage** - tańszy, niezły SDK, ale wsparcie przy rejestracji 10DLC i dokumentacja historycznie słabsze niż u Twilio.
- **MessageBird/Bird** - mocny w Europie (holenderski, dobre stawki EU), ale słabszy support US 10DLC i mniej dopracowane API dla kogoś zaczynającego od zera.
- **Plivo** - jeszcze taniej, ale lżejszy support - zbyt duże ryzyko dla zespołu bez zaplecza telekomowego.
- **Sinch/Infobip** - klasa enterprise, ale onboarding sales-led, mniej self-service.
Przy pierwszym telekomowym projekcie premium za Twilio (vs. Plivo/Vonage) wychodzi tańsze niż czas zespołu spędzony na diagnozowaniu, czemu wiadomości nie dochodzą.
Jedna rzecz do zrobienia od razu na starcie: schować provider za cienką abstrakcją (interfejs `sendOtp`/`sendReminder`) - nie po to żeby migrować "na zapas", ale żeby rejestracja 10DLC czy zmiana pricingu nie wymagały przepisywania logiki biznesowej.
Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally