16,652 email verifications. 689 emails sent. 4 users. One month of use.
Those are the numbers behind Iznely, an outreach tool I built because the ones I tried either didn’t work or cost too much. I’ve been a webmaster for more than ten years, mostly on WordPress, Joomla, and hosting. I know how sites, servers, and domains behave, but I had never built a full application from scratch. Here’s how AI helped me close that gap, and what I built along the way.
The gap I ran into
A year ago, I discovered a business I’d never heard of: selling domain names online. I jumped in. My method was to find potential buyers and reach out to them by email.
That method depends on two things. First, emails that actually exist, because sending to dead addresses damages your sender reputation. Second, a way to send campaigns without doing it by hand.
I tried the tools on the market. Some didn’t work as advertised. The ones that did were expensive, and their free plans capped verifications and sends almost immediately. I’d spent years around hosting, DNS, and mail servers, so I knew roughly what these tools were doing. Paying a monthly fee for it felt wrong.
Deciding to build it
Then I came across a YouTube video about vibe coding: describing what you want and letting AI write the software. My world had been CMSs, plugins, and server configuration, not custom applications. This looked like a way to turn a feature list into a real product without becoming a full-time developer first.
I wrote down every feature my domain business needed and started building in Google AI Studio.
Why it’s called Iznely
Before going further, a word on the name. I wanted something original, easy to pronounce, and easy to remember. English words and other languages gave me nothing that felt right.
Then I thought of Amazigh. I looked for a word close to the idea of sending and found “izen,” which means “to send.” From there, Iznely was born.
The constraint that shaped everything
One fact drove most of my design decisions: Iznely runs on shared hosting. Anyone who has managed hosting knows what that means. You have limits on how many connections you can open and how many emails you can send, and if you ignore them, you get blocked.
So instead of building a tool that goes as fast as possible, I built one that goes as fast as the server allows, with every limit adjustable from a settings page. You’ll see that idea come back in each step below.
How Iznely works: the journey of a campaign
The easiest way to understand the tool is to follow a campaign from raw list to results.
Step 1: Clean the list
I collect contacts and import them as lists, which I can create, edit, and delete, then reuse in later campaigns. Before sending anything, each address goes through three checks:
- Syntax check. Does the address follow the standard structural rules?
- Domain and DNS lookup. Does the domain exist, and does it have active MX (Mail Exchange) records pointing to a mail server?
- SMTP handshake. The tool connects directly to the recipient’s mail server and opens the delivery conversation, then stops before sending any content. Along the way, it asks the server whether that specific mailbox actually exists.
Because of the hosting constraint, I can cap verifications per minute or per hour from the settings. When a list finishes, the system emails me through its own SMTP account, so I don’t have to watch it run.
Step 2: Send without getting blocked
Sending is where shared hosting bites hardest, so this part has the most safeguards:
- Throttling. I set the delay in seconds between emails, the number of emails per minute, and a daily limit for the whole system.
- Multiple sending accounts. I can connect several accounts and choose which one a campaign uses. Connecting is automatic through SMTP, with no manual setup, and Google OAuth handles both signing up and linking accounts.
- Multiple signatures. Users can save several email signatures and pick one per campaign.
Step 3: Follow up automatically
Most replies don’t come from the first email, so follow-ups matter. For each campaign, I choose how many follow-ups go out and on what schedule. If a contact replies, the system stops the follow-ups for that contact, so nobody who answered keeps getting chased.
Step 4: Schedule and measure
Each campaign can launch at an exact date and hour, so I can send when people are likely to read. Afterwards, reporting shows how many recipients opened each campaign’s emails.
Under the hood: the tech stack
The stack follows the same logic as the rest of the project: modern where users see it, practical where the server has to cope.
- The interface. A React 19 single-page application in TypeScript, bundled with Vite and styled with Tailwind CSS.
- The engine. A modular PHP REST API with a MySQL database through PDO. PHP and MySQL run on nearly any shared host, which is why I chose them.
- The mail layer. PHPMailer rotates between the SMTP accounts I connect. For verification, there’s no third-party API: Iznely opens raw socket connections to mail servers, using port 25 for the handshake described above. IMAP connections detect replies automatically, which is what triggers the stop on follow-ups.
- The background workers. CLI-based PHP cron workers process a queue asynchronously. They pick up verification and sending jobs, respect the throttling limits, and keep running after I close the browser.
The results, honestly
- 4 total users
- 16,652 total verifications
- 689 total emails sent
I only used Iznely for about a month before I stopped selling domain names, so these numbers come from a short window, not a long run.
What I took away from it
AI didn’t replace my experience. It closed the gap. Years of hosting and CMS work taught me what shared servers can handle, how DNS and mail behave, and what a sensible verification flow looks like. That let me describe exactly what I wanted and notice when something was off. The AI supplied what I lacked: the application code itself.
The domain business is behind me, but the lesson stays. If you understand your problem well enough, you can build the tool yourself, even if you’re not a developer by trade.
