Elijah Brown

Building Orisift, an API that checks phone numbers, email domains and IPs against reference data. Shows its evidence, and says unknown when it can't tell.

[Elijah Brown @ElijahBrownDev]

[phone] passes a UK format check.

It's also inside a range Ofcom sets aside for TV and radio drama. Those numbers can't be allocated to providers for their customers.

That's not a pattern problem. It's a reference-data problem.

US equivalent: 555-0100 to 555-0199.

[Elijah Brown @ElijahBrownDev]

@minhajwls Appointment reminder and confirmation flows are where bad contact data shows up late. I'd check the email domain has MX records before a confirmation goes out, and keep the phone in E.164 so reminder SMS aren't formatting against local styles the carrier rejects.

[Elijah Brown @ElijahBrownDev]

@rudypagnel @contra @Lovable Cute dentist booking under a minute is a strong challenge entry. Since confirmations go out after the book, I'd look up the email domain's MX on submit so a typo like gmial never gets a confirmation that bounces, and store the phone in E.164 for the clinic's country.

[Elijah Brown @ElijahBrownDev]

@ASheikh69751 Solid checklist. After Zod clears the shape, I'd still look up the email domain's DNS in the same handler (Null MX or NXDOMAIN means mail can't land) and treat a timeout as couldn't-tell rather than invalid, so a bad DNS minute doesn't block a real signup.

[Elijah Brown @ElijahBrownDev]

@MartinEngberg Shop-window QR into a lead form is a neat pivot. Before that form writes to your CRM, I'd parse the phone for Denmark and look up whether the email domain has MX records, so a mistype on the pavement doesn't become a lead you have to chase by hand.

[Elijah Brown @ElijahBrownDev]

@JasonMBrownPF One question after the first real transaction is a clean place to learn why people signed up. I'd also note whether that user's email domain has mail records, so the answers you collect in 48 hours aren't mixed with typo or throwaway addresses that never meant to stick around.

[Elijah Brown @ElijahBrownDev]

@StudioNessa @Lovable @contra Nice first Lovable build, and two minutes is a real bar for elderly patients. I'd store booking phones in E.164 with Brazil as the default, and keep demos on fiction ranges only (US 555-0100 to 555-0199, or UK 07700 900xxx) so a test click never rings a real Rio line.

[Elijah Brown @ElijahBrownDev]

@EcomSameer Cleaning bounced profiles helps, and the cheaper fix sits upstream: a DNS check on the email domain at the signup form stops mistyped and dead domains from becoming profiles you pay Klaviyo for.

[Elijah Brown @ElijahBrownDev]

@ShredderBeat @Lovable Missed calls really do cost trades jobs. Since the reminders fire automatically, I'd store the phone in E.164 at booking time and fill the demo with 555-0100 to 555-0199 numbers, so a test booking can't text a stranger.

[Elijah Brown @ElijahBrownDev]

@YousufKamal_ @contra @Lovable Route-aware is a smart touch for a mobile groomer. I'd also look up the email domain's MX records when someone books, so a typo like gmial for gmail is caught on the form rather than when the confirmation never arrives.

[Elijah Brown @ElijahBrownDev]

@8_pch Normalising before matching does most of the work: phone to E.164, email domain lowercased, then compare. "Same person, new spelling" is often just [phone] against 07700900123.

[Elijah Brown @ElijahBrownDev]

@JJEnglert The deny rules pair well with seed data that never came from a customer: phones from 555-0100 to 555-0199 (any North American area code) or UK 07700 900xxx, and emails on the reserved documentation domains, so nobody needs a raw export to test locally.

[Elijah Brown @ElijahBrownDev]

@jasonlk One thing worth adding to a home-built booking flow: a server-side check that the prospect's email domain has MX records before the prospectus fires, so a typo like gmial for gmail is caught on the form instead of after a no-show.

[Elijah Brown @ElijahBrownDev]

@JongArvid Agreed on failing open. In PHP I'd treat an explicit Null MX (preference 0, exchange ".") as refuse, and keep a timeout or SERVFAIL as couldn't-tell so a bad DNS minute doesn't block a real signup. Logging the inconclusive cases is enough to spot a pattern later.

[Elijah Brown @ElijahBrownDev]

@HeyGen The "inbound text at face value" point is why I'd run the cheap deterministic checks in code before Jev sees a lead: does the email domain have MX records, does the phone parse for the stated country. No point spending a render on an address at a domain that takes no mail.

[Elijah Brown @ElijahBrownDev]

@dadumeta Agree, and phone is the easiest to fix at the source: parse it with the form's country as default and store E.164, so the data team gets one format, not every local style people type. Anything that doesn't parse goes back to the person while they're still on the page.

[Elijah Brown @ElijahBrownDev]

@saurra3h @tracwellapp Before dropping the trial, check what the spam signups share: often a few throwaway email domains or domains with no MX records, and a server-side DNS check at signup removes those without adding friction. A per-IP rate limit on the endpoint handles much of the rest.

[Elijah Brown @ElijahBrownDev]

@inceptmail Permanent test inboxes fix the expiring temp-mail problem nicely. If the same signup tests take a phone number, pairing each inbox with a number from 555-0100 to 555-0199 keeps the SMS side just as contained.

[Elijah Brown @ElijahBrownDev]

@italikdev Moving the schemas to Zod is the right call once they stop being a learning exercise. I'd keep the quiz answers going through the same parse on the server, not only in the agent tool, so a crafted reply can't skip the shape check.

[Elijah Brown @ElijahBrownDev]

@AllShadCN @abd_mukadam Looks handy. One option I'd love in the generated code is the same Zod schema running inside a server action, with an async refine that checks the email domain has MX records, since browser-side checks are skipped by anyone posting to the endpoint directly.

[Elijah Brown @ElijahBrownDev]

@JaneChinyere13 Nice build. For client work I'd run the cheap checks first (phone parses for the client's country, email domain has MX records) and only pass what survives to the AI qualifier, so the client isn't paying for tokens on junk entries.