How I Automated My Job Application Process. (Part 3)

Welcome to the final part of this series. In Part 1, I showed you the proof of concept. In Part 2, we dove into the actual application. Now it's time for the good stuff - all the ways everything went wrong before it went right.

Remember when I said the email system deserved its own article? Well, here it is. It's a story of hubris, AWS rejections, and what happens when you try to run your own email server. (Spoiler: Nothing good.)

The Email System Saga

I wanted something simple: a system that could send and receive emails programmatically and provide a decent ui to view sent emails and reply to incoming emails. Here's how that "simple" requirement turned into a two-week adventure.

Round 1: The Simple Solution

First thought: "I'll just use Gmail's SMTP server!"

Problems:

• Their API documentation is a nightmare

• You need to use OAuth 2.0 to authenticate and make API requests.

• They're really not fond of automated emails

• Even their business accounts have strict limits

The real kicker? This used to be dead simple. Back in the day, you just had to enable the "less secure apps" option in your account settings, and boom - you could fire off emails using your username and password with nodemailer. No OAuth dance, no security theater, just simple SMTP auth. But Google killed that flow, and now we're left with a more complex setup that takes way more time to get running.

Next thought: "Fine, I'll use ProtonMail - they're privacy focused!"

• Requires a business account

• Need to submit a request form

• Have to get approved for SMTP access

• Spoiler: They don't approve automation use cases

Round 2: AWS SES (Simple Email Service)

AWS seemed perfect:

• Built for programmatic email sending

• Great documentation

• Reasonable pricing

• Even handles incoming mail via S3 buckets

I built a whole system around it:

• Outgoing emails through SES

• Incoming emails saved to S3

• Lambda function to process responses

• MongoDB to track everything

It worked beautifully in testing. Then I applied for production access...

Dear Developer,

Thank you for your request for production access to Amazon SES.
We have reviewed your use case and determined that it does not align with our service terms...

Turns out "I want to send automated job applications" isn't what they want to hear. Who knew?

Round 3: The Self-Hosted Dream

"Fine," I thought, "I'll run my own email server. How hard can it be?"

(Those words should be engraved on every developer's tombstone.)

I found this great tool called Mailcow that handles everything:

• SMTP server

• IMAP support

• Web interface

• Spam filtering

• The works

The setup process was actually smooth:

1. Spin up an server (I used an ec2 instance here)

2. Configure DNS records

3. Set up Mailcow

4. Open the required ports...

Oh wait. AWS blocks SMTP ports by default. You have to request access. And guess what their response was?

Back to the drawing board.

Round 4: VPS Adventures

Okay, no AWS. I'll use a regular VPS where I have full port access!

Got Mailcow running on a cheap VPS I grabbed during Black Friday sales. Everything looked good:

• Server up and running

• All ports open

• DNS configured

• TLS certificates in place

I could receive emails! Victory!

...but I couldn't send any. And honestly? I never figured out why. The server was configured, the ports were open, everything looked right on paper - but no emails would go through. After countless attempts and configuration tweaks, I did what any sane developer would do: I shelved the entire project.

At this point, I had sunk two weeks into this email adventure with nothing to show for it. It was time to step back and rethink everything.

The Final Solution

Then one day, while taking a break from this project, I came across this video by Joe Barnard (the BPS.space guy):

A rant on personal engineering projects

In it, he makes this brilliant point about the difference between company projects and personal projects. In a company, you optimize for things like cost, scalability, and perfect systems integration. But with personal projects? Your biggest challenge isn't making it cheap or efficient - it's actually finishing the damn thing.

He talks about how in a company, if one approach fails, you can buy another solution, hire consultants, or modify the requirements. But in a personal project, you're the only one responsible for everything. Your biggest risk isn't going over budget - it's the project never getting done at all.

So I did what I should have done from the start:

1. Used Mailgun for sending emails

2. Set up their inbound routing to forward replies to my regular email

3. Added my email as BCC on all applications

4. Called it a day

Was it the most elegant solution? No. Was it the cheapest? No. Did it work? Yes. Did it get me over the finish line? Also yes.

The Results

In the end, I sent out about 250 job applications in 20 minutes. Total cost? About $5 in API fees.

The irony? I got a job offer before I even finished the project. Not from the automated applications - turns out networking still works better. But here's the real plot twist: talking about this project during my technical interview actually helped land me the job.

When they asked about challenging projects I'd worked on, I walked them through everything - the script execution system, the data pipeline, the email server saga. Nothing demonstrates your technical chops quite like explaining why you spent two weeks trying to run your own SMTP server before admitting defeat. Sometimes the projects that don't quite work out teach us the most valuable lessons - and make for the best interview stories.

Lessons Learned

1. Start with the boring solution

   • If something's been solved, use that solution

   • Your clever idea probably isn't worth the trouble

   • Every "I'll just build it myself" decision needs serious justification

2. Define "good enough"

   • Perfect email deliverability isn't needed for a personal project

   • You can forward emails instead of building an inbox

   • Sometimes BCC'ing yourself is the right solution

3. Know when to quit

   • Two weeks on email infrastructure was too long

   • "I've already spent X time on this" is a trap

4. The best solution is the one that ships

   • A working project beats a perfect plan

   • You can always improve it later

   • Sometimes "later" means "never," and that's okay

What's Next?

Could this project be better? Absolutely:

• The email generation could be batched to reduce API costs

• The UI could be prettier

• LinkedIn integration would be nice

• Job board scraping could be automated

Will I do any of that? Probably not. I have a job now, and more importantly, I learned what I needed to learn.

The code lives at jaas.fun if you want to check it out. Feel free to fork it, improve it, or use it as a cautionary tale about overengineering.

And if you're applying for jobs right now and want to use this tool, message me on LinkedIn or email me at dd@daviddodda.com. If enough people need it, I might even turn it into a proper product.

What's Coming Next

Even though I landed a job (starting in a few days!), I'm not done building things. Nights, weekends, and that sweet spot between coffee and sleep? That's building time.

My next project tackles another part of the job hunt puzzle: "Pimp My Resume" - a tool for enhancing and auto-customizing your resume for specific job listings. Because if you thought automating job applications was fun, wait until you see what happens when we let AI loose on resume optimization.

Stay tuned. This one's going to be interesting.

---

Thanks for following this series! If you want to talk about job automation, overengineering, or making personal projects that actually ship, find me on Twitter or LinkedIn.