Recently, an email developer started a lively debate with his Responsive Email Without Media Queries? blog post that expressed frustration and a screw you, Gmail attitude¹. I can understand his frustration and that attitude. But I disagree.

I used to feel that way. But then I learned how how to reconcile Gmail support with a client’s budget.

Hello Stakeholder and Android user

My first clients were smaller companies, startups and iphone users. Then came larger projects. My developer liaisons were iPhone users. But the managers and stakeholders who needed to sign off the project were sometimes Android users. The first such project caught me off guard.

It doesn’t matter if the statistics show that most mobile opens are on iOS devices. If the emails does not work on the stakeholder’s phone, the project is not considered complete, which means I cannot be paid yet.

Bill for effort, not just results

Up until then, I charged email projects like web design: at fixed prices, e.g. $5000. Clients prefer having a maximum cap on a budget. Then I switched to day dates only. I am sure I lost some potential clients. But this is important because email testing can be really intensive and difficult to predict.

But here is how I make it work for both me and the client.

1. What is the client’s budget?

Potential clients always give a project description, but rarely reveal their budget. I wait until after a client presents what the project. Then I ask for their budget. Some push back. That’s ok, I say. You can email or call me later.

I continue anyway and explain the project planning, budget and process.

2. Split project into blocks

Divide the project into milestones and tasks, each with time budgets, e.g. a half, or 2-3 days. In the initial meeting, I usually just offer milestone estimates. For example:

Block	Budget
Shared Header and Footer	0.5 days
Marketing Email	1-2 days
User Purchase Series (3 Emails)	2-3 days
Total	3.5 - 5.5 days

Woah, that range max is 150%+ higher than the minimum. Yes it is. But that includes a buffer for extra testing and Android support.

3. Translate estimates into client support

This is when I give the client a list of supported email clients. Most on the list are tested with Litmus, which is fast and allows for fast iterations. But I explain that Litmus has poor Android support, which means I have to do manual testing:

• Send email to a test account.
• Wait for it to appear in the inboxes (usually instant, but sometimes takes a few minutes).
• Open email on Android Phone.
• Scan through email, note imperfections and take screenshots.
• Repeat 3-5 times per Android device and app.
• Adjust code. Rebuild email.
• Repeat process again.
• …
• Working? Ok! Re-test in Litmus to make sure changes didn’t break other clients.
• …

In my experience, the client realizes how much work is involved when they see the full list. Those with limited budgets will eliminate Android support at the project start. They reveal their budget and we find a project scope and email client support that fits their budget. If we do not reach the max, we can consider mobile or Android support.

4. Adjust project design?

Sometimes we can cut development time drastically (esp. if the client wants Android support) simply by slightly changing the email design. For example, vertically centered elements are always tricky, and bottom aligned ones more so. If we can live with top alignment, we can save X dollars.

Time is Money

In the web sector, money is not a scarce resource (see venture capital). But developers and developer time is. Many clients appreciate that I am fast. My rates are high, but I get the job done faster and free up in-house development time for other projects.

In a recent project, the client estimated project development time at two weeks. The stakeholders were not excited about my rates until I said I could complete the same project in 4 days, which I did.

I have optimized my workflow with the Antwort Ruby gem, which speeds up development by automating repetitive tasks. This software is also generally offered to clients so they can adjust emails on their own in the future - saving them even more time.

In conclusion

I agree, developing for Android support is a pain. But viewing the challenge from a developer’s point of view is myopic thinking. Globally Android users outnumber iPhone users. And ultimately we build not for ourselves and, not for clients, but for their users.

So let’s make the extra effort. I think it’s worth it to the users. We just have to convince the clients by translating that effort into money, not just as income for us but also as time and sales for them. And now you know how. So get out there and do awesome work.

---