shreya-headshot

Shreya Gupta

[Hacking the Engineering Process](https://www.meetup.com/hacking-the-engineering-process/) is a San Francisco-based meetup, which opens discussion for software engineers and tech enthusiasts to share their thoughts on leading topics, pose thought-provoking questions for each other, and learn more about how various engineering teams measure developer productivity amongst themselves.

In March, the guest speaker was the VP of Engineering at Apartment List, Sue Nallapeta. Nallapeta is a leader in tech and is passionate about building highly performant and vastly scalable engineering systems. One of the questions that many engineering leaders often contemplate is whether or when to build or buy software in the process of building a product. Companies invest a lot of time and resources into building software, while buying software can also be expensive in other ways. In her talk, Nallapeta described the “7 C’s” she considers when making this decision between build vs buy and shared her experience in implementing this process while developing Apartment List.

<iframe width="560" height="315" src="https://www.youtube.com/embed/dTSFDkWM1oM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

## Capability
The first C is Capability, which is determined by the problem that you are solving for, including any features you need or want to build. This is a product and a business’s core, and often what makes it stand out amongst others. These capabilities are what you want to go to market with and what your customers will use. The question then becomes whether these capabilities already exist. If so, developers need to decide whether it is worth building them from scratch or using the tools that are already available, which is a decision that depends on how quickly the product needs to go to market and which path would help achieve the goal most effectively and efficiently.

## Cost
There are two common dimensions to cost that most people will look at when building. The first is resources, including how many engineers a team may need to develop the product. The second being time, on how long it will take for those engineers to build the product given the resources they have available. Most teams will consider the two and choose the cheaper option. There are, however, other pertinent costs that can and possibly should impact your decision: build time, maintenance costs (to monitor the product, support it, build test cases, etc.), infrastructure costs, and hosting costs (which are hidden but can add up to a lot).

There are other costs if you choose to buy. Transferring a solution you already have or integrating a new tool can be time consuming and have major migration costs. Buying software also involves onboarding costs (how long it takes for engineers to learn the new system and become comfortable with it) with offboarding costs (typically there is an overlap between old and new systems) and maintenance costs for successful long-term integration. It is crucial for teams to think beyond these two dimensions before making a decision based on cost.

## Complexity
In order to build systems that are easy to understand and explain to others including the sales team, growth team, and all business stakeholders. Teams often build products that are very complex, and complexity also grows as the product scales. For example, Netflix’s scale was so large that they needed to invest in their own Content Distribution Network (CDN) and built Open Connect, which they can ship to all ISPs to cache videos on the client side to deliver content quickly.

## Competence
A product’s build speed heavily depends on the team’s competence. Do we have the right engineers on the team who understand what needs to be built? Do they have the experience and domain knowledge to understand what we are solving from the business and customer perspective? Do they work well together? If not, how long will it take to hire and build this team? Building a competent team can take upwards of 3-6 months just to hire.
At a previous company, Nallapeta’s team acquired over 10 companies, each acquisition immediately adding value in the span of a couple of months. If they built, it would have taken several months or more to add those capabilities.

## Cohesion
Cohesion, or connectedness, is tricky in the case of buying - whether the feature you are buying integrates with the other systems that you already have. For example, Apartment List uses Salesforce for Customer Relationship Management (CRM), and any other software they build that ingests data should support sending data to Salesforce. You can create value through an ecosystem of softwares, where systems coexist with each other and are dependent on each other.

## Competitive Advantage
Any product needs to be able to compete once it enters the market. Competitive advantage is a key factor decided by whether the product or its features are core to its functionality and to the business. The product’s capability determines if it can be competitive and can ship features faster to win the industry.

## Continuity
Continuity goes hand-in-hand with maintenance. It determines how you ensure scalability of the product as your user base grows and as new feature requests rise. This is important to track so you can guarantee that your system is sustainable and you don’t need to replace the system every few years, which can be a major setback.

## Apartment List’s Experience
### Build: A/B testing
In building a product that satisfied all of the capability needs, Out of the Box (OOTB) solutions were insufficient for the business need at the time. Apartment List is a subscription based business. The team had to quickly ship many experiments, and try various subscription based models and paywalls, each with changes in prices and features, which would not have been possible without fast iteration.

They also wanted to maintain control over customization to build a great user experience. The product was highly customized for various customers and customers sub-groups. It also provided a great competitive advantage with insights and quicker feature launches with a lower experimentation and test setup, leading to an increase in customers globally.

### Build: Billing System
In a high risk industry, the chargeback rates are extremely high. With a subscription based business model, Apartment List needed to maintain fall back use cases such that if a payment does not go through for a customer, the system automatically redirects to a different payment processor, a feature unavailable in other billing system tools. This allowed them to also lower the renewal rates and offer more discounts to their customers. Most importantly, Apartment List’s margin was low, meaning using a tool like Stripe would lead to them cutting into their margins.

### Buy: Email Software
Apartment List had initially built their own email software, which was relevant for the stage of the business. At the startup stage, it made more sense to build the software and have access to customized complex features. However, engineering teams did not have the bandwidth or documentation to support the system and over time, as the team who built the software left the company, there was not enough in-house knowledge about the software to maintain it. Eventually using the in-house software also meant that something as simple as a brand update with new logos and colors would require weeks or months of engineering effort.

Apartment List chose Courier to support transactional emails and another provider for marketing emails. This also helped the company achieve cohesion, with the new systems integrating well with the existing system and each other.

### Buy: Testing Software
Every company requires some form of Quality Assurance (QA), which, as the product scales, can become an expensive and tedious process that forces engineers to divide their attention away from the product. Using an external tool offers better control and ease of use of the testing software and increases the efficiency of the testing process.

### Build & Buy: Analytics
Data is the backbone of any company, requiring high data accuracy and coverage. Every decision made needs to be built on a strong foundation. With evolving business needs, ApartmentList chose to both buy analytics software and build on top of it to close the gaps.

## Learn More & Join
If you would like to learn more about Sue Nallapeta’s decision making process and experience with Build vs Buy, check out the talk recording on YouTube: [https://youtu.be/dTSFDkWM1oM](https://youtu.be/dTSFDkWM1oM)

Hacking the Engineering Process hosts monthly meetups.

* Become a member: https://www.meetup.com/hacking-the-engineering-process/
* Submit a CFP: https://jkfr7wbzytt.typeform.com/submit-cfp


A swan pulls a ready-made nest out of a Courier box while a duck has to build one from scratch across the pond.

build-vs-buy-header

This post gets into the “7 C’s” that should be considered when deciding to build vs buy. Learn about how Apartment List implemented this process.

build-vs-buy-thumbnail

Build vs Buy: The “to be or not to be” of Tech

nick-headshot

Nick Gottlieb

As modern applications have become increasingly feature-rich and performant, user expectations are at an all-time high. Failure to communicate key information or displaying out-of-date information frustrates users and causes a loss of trust. Think about the last time you ordered something online: if you didn’t receive your order confirmation within seconds, you probably began to worry that something went wrong. Users require product transparency for consistent use.

Luckily for developers, a proliferation of new APIs have been developed to help provide features such as real-time order update emails, push notifications based on in-app activity, or live chat with sales and support. Communications APIs are becoming increasingly specialized, with each type being more or less suited to certain tasks.

If you’re an engineer who’s been tasked with planning out your application’s communication strategy, this post will help you map out the landscape. You’ll come away understanding the three core types of user communication APIs and in which circumstances you should use them to create the best possible end-user experience. We’ll also show you how using the right APIs in the right places will streamline your own day-to-day work.

Let’s get into it! 

## Planning Your Communications API Strategy

The best outcome any engineer can hope for is that your communications strategy is so smooth, it isn’t even noticed. For the end user, it just works exactly when it’s supposed to work, the way it’s supposed to work. For your own internal teams, everyone has the ability to craft the messaging they need and send it when they need, without unnecessary bottlenecks that can often impact your own engineering time.

In a marketplace application, for instance, users need to get an automated push notification or email every time someone comments on an item they’re selling. The marketing department also wants to send email campaigns to everyone who has purchased an item in the past six months to let them know there’s a sale coming up. When a buyer’s checkout fails, they might need to message your sales or support team to get help and complete the transaction. 

All of these are very different examples that will need to use a different type of communications API to get the job done.

## Exploring The Three Types

Communications APIs are segmented not only by the functionality they provide and how immediately they need to respond to user actions but also often by which teams at the company will need to use them to send messaging. 

App-to-user APIs are highly customizable, instant communications sent by engineering as integral parts of the application experience, such as push notifications about likes or comments. Brand-to-user APIs collect data and give the company, particularly marketing and product teams, the ability to send users targeted messages individually or en masse. User-to-user APIs facilitate live chat either among app users or with someone at your company, such as sales or support.

Let’s discuss the strengths and weaknesses of the three types of APIs, and see some commonly-used third-party providers for each.

## App-to-user APIs

App-to-user APIs are transactional messages that are embedded into the application code. These APIs are often the most mission-critical of the three, as they form a core part of the application experience. For instance: your rideshare has arrived, your order was received, you have just been added to this chat room, here is your one-time password for login. These types of communications tend to be time-sensitive and are designed to send immediately when the trigger events occur.

A robust App-to-user API will provide multi-channel communication (email, SMS, and push notification), complex routing, and easy opt-in and opt-out for users. Most can be heavily automated as well. For instance, when a new user is created via Auth0, a welcome push notification can be automatically sent.

App-to-user APIs are typically instrumented and used by engineering teams. Companies who have the resources may choose to build their own App-to-user API infrastructure, which we have [a guide on how to do here](https://www.courier.com/blog/the-developers-guide-user-requirements). Courier also provides a ready-to-use App-to-user API infrastructure. 

## Brand-to-user APIs

Brand-to-user communication happens any time your company has a message for a specific group of users. Maybe the product team noticed that a user got partway through the sign-up flow but didn’t hit the “complete” button. Maybe marketing wants to tell everyone in New York about an upcoming in-person event.

Braze and Customer.io are two examples of out-of-the-box Brand-to-user APIs. Engineering implements API calls in the application code that log information about user behavior, which then gets sent to a separate dashboard other teams at the company can access. Anyone on those teams can then use that data to craft and send messages to specific subsets of users. For instance, users who didn’t complete the sign-up flow, or who live in New York. Brand-to-user APIs save engineering time because, once the initial API calls are instrumented, any team who needs to send campaigns or needs to access that data can do so easily and independently.

While Brand-to-user APIs make it easy for anyone at the company to send messaging to users, they typically aren’t configurable enough to power core parts of the application experience. Messages can go out minutes to hours after user criteria for the message have been met. There can also be implementation delays any time you want to send messages based on a different set of criteria than you were using before—new API calls in the app mean the data needs time to populate before they can be used. 

While this trade-off is often worthwhile for marketing and product communications, App-to-user APIs (discussed above) are a much better fit when you need fine control over messaging content or timing within engineering.

## User-to-user APIs

User-to-user communication APIs facilitate active conversations among two or more individuals—either between a user and someone on your own internal staff or from one app user to another. 

Support tickets, for instance, are a type of User-to-user API, as are live chat boxes that let customers have direct conversations with your support or sales teams. Likewise, two users in a marketplace might need to message each other to offer bids or send along shipping information. While these are possible services to build out in-house, most companies opt to save time by going with a ready-to-use SaaS solution, such as Intercom, Zendesk, or Sendgrid.

## Conclusion

Most applications will use more than one type of user communications API for different parts of the user experience. Your application may very well use all three! 

App-to-user APIs provide part of the application’s core functionality. These APIs are highly customizable and provide instant user communication that is tightly coupled with your application code. Marketing and product teams will often want a Brand-to-user API implementation that makes it easier to see user data and send updates to users. User-to-user APIs give customers access to back-and-forth communication either among each other, or with company support or sales teams.

When you’re thoughtful about your communications strategy, you can create a seamless experience for users while also enabling everyone on your team to save time and do their best work. 

Read on for more information on building user communication API infrastructure:

* [The Developer's Guide to Building Notification Systems: User Requirements](https://www.courier.com/blog/the-developers-guide-user-requirements)

* [How to Set Up Multi-Channel Notifications in Your AWS Stack](https://www.courier.com/blog/multi-channel-notifications-aws)

*Illustration by [Rebekka Dunlap](https://rrebekkaa.com/)*


Three different people using a computer, tablet, and smartphone look up as magic surrounds them indicating the ease of communication through apis.

user-communication-apis-header

This post describes three core types of user communication APIs and in which circumstances you should use them to create the best possible end-user experience.

user-communication-apis-thumbnail

3 Types of User Communication APIs and When to Use Them

*We recently had the opportunity to speak to a student audience at Serverless Days and came up with some insights that we felt were worth sharing with a wider audience. Please take a look and let us know your thoughts [@trycourier](https://twitter.com/trycourier).* 

Serverless architecture is relatively new, yet many startup developers prefer building their foundation on a Serverless framework. But what's with the hype? What makes developers trust Serverless to the point that companies are willing to spend their resources to rewire their entire backend infrastructure to host their products on platforms like AWS, GCP, or Azure?

At AWS re:Invent 2016, Neil Hunt, acting CPO at Vibrant Planet and previously at Netflix, spoke about how the rapidly growing global company relied on AWS to deploy servers and storage efficiently. Big name companies such as Netflix, Coca Cola, and Nordstrom as well as smaller startups like Courier are using Serverless to cut down costs and build scalable tech.

There are major advantages to Serverless that cause companies of any size to become dependent upon it. This dependency ultimately allows developers to save time, preserve resources, and lessen performance issues.

## Why Students Should Get Comfortable with Serverless
Often, cloud computing companies will visit schools and host workshops to introduce students to their software. However, there aren't many institutions that teach students specifically about Serverless architecture. Even after using these services for hackathons or class projects, few students have an in-depth understanding of how Serverless works and what it can be used for.

Many students working at startups after graduation will likely encounter one of the big three: AWS, Azure, or GCP. Serverless is increasingly becoming a technology that startup software developers and product managers will need to be proficient in, to help grow their products quickly, cheaply, and reliably.

### Time
Using Serverless frameworks allows developers to build and deploy their applications from zero to production speed. Any time a product needs to be released or updated, developers no longer need to worry about managing their backend and uploading code to the server. They can simply upload or update pieces of code to the Serverless computing provider in a fraction of the time.

### Resources
In addition to time, teams can save expenses on people and products by running their code from the cloud. They can save money on getting and running servers by purchasing cloud space from Serverless companies at a fraction of the cost.

### Reliability
By allowing Serverless computing companies to manage the servers, startup developers can avoid a large amount of risk. These Serverless companies are able to store massive amounts of servers that allow their users to scale projects in seconds. Developers no longer need to worry about their applications crashing since their servers have to take excessive loads. If an application does require more servers than anticipated, the cloud will automatically increase the number of servers provided to them. Depending on Serverless architecture massively decreases the chances of a product running into any software, hardware or human faults related to servers.

Bit Project is a student organization that tackles the deficit of shared information in tech by building and hosting free coding bootcamps to help students build key skills required to succeed in tech. One of these is the Serverless Camp, in which students spend four weeks learning about the services that Azure provides and how they can use them to build various applications. For the next four weeks, students work with professional mentors from the tech industry to find and resolve a world issue using Serverless technology.

## Example Projects to Build
Several students around the world built projects using Azure Functions for the Serverless Days: Student Edition Conference hosted by Bit Project in 2021. Each student had worked extensively with mentors in the tech industry, software developers, project managers, and developer advocates, to learn about the services that Azure provides and how to integrate databases and APIs to build bots and applications using those services to solve real world problems.

### Creating a Smart Teaching Assistant on Github with Serverless - Ganning Xu

High School student, Ganning Xu, was the first to complete the Camp course and took his head start as an opportunity to find and resolve issues in the program. The Camp curriculum itself was hosted on a in-house GitHub bot. For his final project, Ganning decided to improve the overall experience of the bot for both students and mentors by adding more features, bug fixes, and transferring the code to host the bot as a Serverless function.

### Building a Knowledge Base for Online Classes - David Tetreau

Another student, David Tetreau, was a military veteran and had shown a special interest in improving the online learning experience for new programmers. By using the Slack Bolt framework, Node.js, JavaScript, and Serverless web app hosting, David built a solution to save time and increase productivity.

His project, a Serverless Slack Bot, helps alleviate the stress of virtual team communication, and helps boost productivity. The bot maintains and updates a single knowledge base, monitors channels for keywords, and responds to inquiries with those words in threaded conversations with users.

### Go Eat! Meal Reminders with Serverless - Beatrix Cendana

Beatrix Cendana, originally a writer, wanted to build more technical skills and become a technical writer. While balancing a hectic schedule, Beatrix discovered a need for a product that can help generate random recipes for daily cooking and timely reminders for regular meals. She decided to create an SMS feature with the Twilio API that can remind people to eat based on a proper schedule and add the feature to help them get the random recipes.

Watch the full [Serverless Days: Student Edition 2021 Conference](https://youtu.be/l_1BhV-dtMk), where five of the students from the Serverless Camp present lightning talks including the inspirations behind their application ideas, journey to building it, and demo of the working application. Students also talk about their experience working with external APIs, databases, and their mentors.

These students are an example of how quickly programmers can pick up Serverless architecture, get started building their own applications, and become experts in the field. These skills can be valuable in various roles across tech that require extensive knowledge of cloud computing and deploying applications on providers like AWS, GCP, Azure, etc.


serverless-hype-header

Companies' dependency on Serverless allows developers to save time, preserve resources, and lessen performance issues during the engineering process.

The Hype Around Serverless and Why Student Engineers Should Buy In

serverless-hype-thumbnail

Why Student Engineers Should Buy Into the Hype Around Serverless

Aydrian Avatar

Aydrian Howard

Package Person Header Image

Let's dive into how Matt got the idea for the Package person game, how he built it with Unity, Courier, etc. in his toolbox, and his reflections on the project.

Engineering student builds game using Unity game engine, Courier, Twilio, etc.

Package Person Thumbnail

How to Use Notifications to Build a Game in 36 Hours

chris-profile

Chris Gradwohl

serverless-header

serverless-thumbnail

From MVP to Production Ready With Serverless

a row of developers sitting and hacking at a hackathon

hackabull-2021-review-header

a row of developers hacking away at a hackathon

hackabull-2021-review-thumbnail

Best of Courier at Hackabull 2021: Speed Friender

Kevin Krige Profile Picture

Kevin Krige

What Makes Transactional Emails Effective With Examples Header

What Makes Transactional Emails Effective With Examples Thumbnail

Courier [Notifications Landscape]

Build vs Buy: The “to be or not to be” of Tech

3 Types of User Communication APIs and When to Use Them

Why Student Engineers Should Buy Into the Hype Around Serverless

How to Use Notifications to Build a Game in 36 Hours

From MVP to Production Ready With Serverless

Best of Courier at Hackabull 2021: Speed Friender

Transactional Email Templates: What Makes Them Effective Plus Six Examples to Learn From

Build your first notification in minutes

Build your first notification in minutes

Product

Developers

Resources

Company