When I refer to “icebergs,” I’m talking about all the things that may seem benign on the surface but are actually rather cumbersome. You might overlook them because they’re not a core part of your application. And they aren’t always challenging or tricky, but it can be easy to underestimate the effort to complete them. Set aside time for these tasks so they don’t ruin your schedule.
Transactional Email
While you might not think of transactional emails as a complex part of your application’s interface, they are. It’s incredibly easy to identify companies that take care in crafting their emails, and equally easy to identify those that don’t.
With transactional email, you’re going to need templates for all of your emails, and those templates all need to be tested in a wide array of email clients. At some point in the near future, you’ll also need to integrate seamless bounce handling in your application. Since you’re likely to use a third-party, make sure you’re firing off those emails using a background service. That way, if the connection with your email service fails, the email won’t be lost, and you can try again. This also ensures that the third-party HTTP request doesn’t slow down the main request for your user. As you can see, email quickly becomes bigger than just plugging in SMTP credentials. You can get away with that in a prototype, but your support requests will skyrocket if you aren’t careful with email.
I suggest starting out with plain text (rather than HTML) emails and focusing on the copywriting and content. Don’t just throw words into an email. Put some deep thought into it. Have a copyeditor look over them–you might be surprised at how much that can help. Exhaustive testing of HTML emails isn’t something you need to make time for at this point. Whatever you do, treat every email notification as if it were a page in the application. Set aside time to do it right. Alternatively, you could use something like Postmark’s open-source templates to help you get a quick start. They’re robust and well-tested against modern email clients. Just add your logo and go.
We’ll talk more about bounce handling in the chapter dedicated to email, but it’s very likely you’re underestimating the complexity of email if you’ve never managed transactional email for a web application.
Beta and Invite System
You’ll probably want to release a beta version of your app to a select group of people. So you’ll need either to manually set up accounts for these people–which is fine at smaller numbers–or set up a more automated system to send out invitations that allow participants to create accounts on their own. Either approach requires time and attention, and you’ll need to plan accordingly. It’s not incredibly complex, but it can be a distraction to have to write code that will only be used for a short time. This won’t kill your launch date by itself, but it’s one more thing that can chip away at it.
Administrative Tools
You can probably get by without administrative tools at first, but you’ll find fairly quickly that some support requests require you to update data–these tasks can soon become tedious if you don’t have administrative tools. For instance, we readily extended customers’ trial periods for Sifter. (This was always our number one support request.) Perhaps a customer created an account but didn’t get a chance to use it, or they decided they liked Sifter but needed to pull a few more people into the trial period. Extending someone’s trial period is still a somewhat manual process, but I don’t like making people wait, so I built some tools that let me take care of this from my phone with a couple of clicks. In hindsight, I could have taken that even further with self-service trial extensions under the right conditions.
Another great candidate for administrative tools is your background processing. How many jobs are queued up? Are there any failed jobs? Sifter has an interface that lets the team access this information so they can quickly intervene and fix any problems–or manually rerun failed jobs–if necessary. When things go wrong with your background processing, you’ll need a way to dive in to see what happened and make sure things are running smoothly once you get to the bottom of things.
I’m not saying you should build all this right away, but I hope I’ve offered some insight into the types of tools you’ll need. Start small so you don’t invest too much time in the wrong things, but you’ll eventually need to build some administrative tools. I’d even suggest setting aside a separate dedicated application and server for these tools if you can. Assuming you’re comfortable hacking this in a terminal, I wouldn’t build them for launch day, but I’d set aside some time for them shortly after that. Remember that the terminal is error-prone, and the longer you wait to build proper administrative tools, the more likely you are to botch a command and make an expensive mistake.
Pre-Launch Landing Page
You need to start collecting email addresses for your launch announcement. There are quite a few services that make this fairly easy, but the key is to set it up as soon as you have a domain and start actively promoting the service.
An empty text box asking for an email address isn’t all that compelling. Put some effort into explaining what your application does and why someone would want to sign up. I’ve seen many landing pages gloss over this, but I don’t want you to make that same mistake: your landing page needs to call out the pain points that your application alleviates. Then explain why they should care and why they should trust you–keep it brief, but don’t skip this.
Privacy Policy, Terms of Service, and Other Legal Stuff
The legal stuff is never fun, and it always takes time. It’s easy to procrastinate here, and the potential back-and-forth between your company and your lawyers doesn’t make things any easier. Don’t forget you’ll need a clear explanation of how you use cookies or other technologies with privacy implications. The sooner you get started, the better. And you can’t just ask a lawyer for an off-the-shelf privacy policy–they’re going to have questions, and you won’t be able to answer all of them right away. This process takes time, so you’ll need to plan ahead.
Your Company Blog
Building your blog can be a huge time sink. Steer clear of just tossing up a template site on a blogging service (although I suppose that would be better than nothing). Until your site goes live, your blog design and your content are the face of your business. It might even be the only communication you’ll have with your early customers. Don’t cut corners; make sure your company’s blog lives up to your standards. These days, you can get pretty far just by setting up a blog on Medium, but you’re also placing a lot of trust in them to make the right decisions.
Finding time to write can quickly become tedious when you’re juggling dozens of other tasks, but it’s also one of the best ways to get your message out and to refine that message. My early blogging for Sifter was a great boon for our marketing, but more than anything, it forced me to think through my ideas. It’s sometimes easy to believe something is a good idea until the moment you have to explain it to someone else. Without my early blogging, Sifter wouldn’t be what it is today–it might not even exist at all.
There are plenty of other icebergs out there, and your business will have several of its own unique icebergs. You can’t uncover them all, but you can keep your eyes peeled so you can minimize the impact on your timeline.