Technical debt isn't always immediately obvious from a far, but easily recognizable when you touch it: it feels bad. Its a broken abstraction – a manual work-around. Its a burden. Its embarrassing. You scratch your head wondering how you got here and how to never get here again. It is often so woven into your particular workflow that off-the-shelf or external solutions don't seem to apply – its isolating.
Setting up emails is still a silly, annoyingly technical task. Often, my clients don't anticipate just how many email systems are needed, even for a tiny saas business.
I'll walk through the four necessary categories of emails below and how they differ in setup.
These are the @example.com email addresses. You'll need them, your team will need them, and you'll want to be able to create aliases and groups. Your domain registrar will say they offer this. Don't use it.
Tasks: - Setup a G-Suite account with your domain - Connect your domain to it via MX records
These are the emails that get sent as receipts or in conjunction with core user activity on your app. These shouldn't be conflated with your marketing emails. Send them separately through Postmark or Sendgrid. You want these to be delivered and the reputation to be separate from your marketing campaigns.
Tasks: - Setup a new domain name - Attach it to a transactional email service - Follow their onboarding rules and hoops, and give yourself time (sometimes weeks) to make it through their verification processes
This inbox will be where your customer support happens, so do yourself a favor and create a shared inbox. This can be a group or alias that goes to a shared G-Suite inbox, or a dedicated service like Intercom or HelpScout.
These emails require visibility so try to have multiple eyes on them !
Tasks:
- Create a "group" in G-Suite that receives emails address to [email protected]
- Add support team members to the group
You'll use one or more services for marketing emails and these domains have the highest risk attached. I recommend separating them from your transactional email domain and company email domain to better insure than any reputation issues that affect them don't impact the other channels.
Starting out, you'll also want to be smart about the "reply-to" address used in these emails. For onboarding drip campaigns: reply-to founders – this is product research. For others, make sure your reply-to lands in someone's real inbox. Customer's rarely reply to email blasts, but if they do – you want to know.
Tasks:
- Sign up for MailChimp, ActiveCampaign, Customer.io, etc
- Register a subdomain, email.example.com
- Follow their onboarding process for verification (note: it may take days, or even weeks before you can begin sending en masse)
- Begin sending slowly, an early misstep in sender reputation can be costly
- Setup email security domain records: spf, dkim
A client of mine forwarded an interesting e-mail:
Technical Debt
n. Inefficiency introduced to satisfy a requirement, because the resources (time, knowledge, solutions, funding) are not available.
I'm not sure where I saw this definition, but I loved it. It includes the motivations behind why we choose technical debt as humans.
You want a car, but you don't have $50,000 today. So, you take on debt and get the car today. Now you have the car, and you carry the debt. The debt doesn't actually hurt you. The debt only comes into play when you're making decisions.
Technical debt only hurts in a system that needs to make changes and respond to new priorities.
You need to get from point A to B.
You can build a bridge, or you can pay a toll.
You don't have time to build a bridge, or the right bridge-builder, or the steel at hand to build a bridge.
So you take the toll road – you’ve created technical debt.
That’s the debt, the cost of taking that toll now every time you need to get from point A to B.
Web developers spend an ungodly amount of time compressing, converting and manipulating images.
But like a cake out of the oven, once it's been baked – there's only so much you can do. (Editor's note: I recommend eating it)
Creating a "Review App" pattern allows every developer to have a "QA environment" for their branch. But setting this up is not as straightforward as it sounds. The secret to the Review App pattern is to maintain two pipelines: code-based and state-based.
Code pushes up, State pulls down.
"Brush your teeth, twice a day"
"Wash your hands before you eat"
"Shower every morning"
Human hygiene is ritualized from a young age – and for good reason. Hygiene rituals protect communities from plague, and individuals from easily preventable serious issues.
But do you see the trick? These rituals work because they have triggers attached to them.
Before you A, make sure you B. These triggers create habits in people, and turn us into well-oiled machines.
API Hygiene is the (often overlooked) set of practices and policies that you apply to incoming and outgoing data. Just like proper human hygiene protects health and reduces issues, API Hygiene insures that what comes into and goes out of your app keeps your system in running order.