Our Development Workflow Goals

The last few months we have been focusing on streamlining our development workflow. When a new engineering hire comes on board we want him/her to be able to submit their first pull request within 10 minutes of walking into our office. While most engineers won’t actually commit code within 10 minutes, we favor this approach for 2 reasons:

1. We want to have fast local environment setup time
2. We want to enable our engineers to ship code faster

Streamlining Our Development Workflow

To accomplish the first goal. We needed to minimize the number of steps in the setup process and ensure instructions for the remaining steps were clear and concise. We also wanted to abstract all the manual work by incorporating as much of the setup process as we could into our code base.

The second goal was much harder to accomplish. Our biggest fear about bringing new people on board was that they would commit code that would somehow impact the codebase unintentionally.

We needed to implement a process that would prevent unintentional errors from reaching production, increase the understanding of the current code, and give our engineers 100% confidence that the new code is error free.

Here is what it takes to get Lob Dev Environment up and running on a Mac:

That’s it….we are ready to commit!

Now for the harder part. Here is our dev workflow:

Using Gulp.js we are able to force syntax checking during the development workflow. Every time a developer saves, the codebase is linted (using jshint) to ensure syntactic consistency across the organization. If there are errors, we prevent the developer from starting the development server. This forces them to fix the error right away as they cannot continue developing without re-starting the server.

Once the developer has code that they think is production ready, they can run “gulp test” locally. Our Gulp test uses Mocha and Istanbul to ensure 100% of the tests pass and that we have 100% code coverage.

Given that the tests pass locally and there is 100% code coverage, developers can now commit their code to Github. On commit, we immediately trigger a build on Circle CI. We hooked up our CI results to our main Engineering Hipchat Room, so not only will they get a green or red light once the test completes, it will have their name right next to it. This enforces people to double check their code locally before they commit, as no one wants to be the person that has a bunch of “FAILED BUILDS” next to their name.

We are building out processes such as these to further boost our engineering productivity, ship code faster, and continue developing new product features in an agile fashion. If you have any comments on our process or ways to improve it, let us know!

Lob is an API company. That means that not only are our external product offerings all APIs, but that all of the internal tools we build are also APIs. We believe that an API-first approach to development improves the quality of our code and empowers our developers to be more productive.

What is API-First Development?

API-first development is the idea that whenever you are developing a piece of shared functionality for your organization it should be exposed as a RESTful HTTP API to all of your other developers. Rather than creating a library or module that needs to be added to all code bases requiring the functionality, developers can consume all the necessary functionality through the API. Having developers consume all functionality through an API enforces separation of concerns and hides internal complexity.

Enforcing Separation of Concerns

One of the most basic examples of using API-first development to enforce separation of concerns is to decouple the front and back ends of a web application. In this case an API is created to house the business logic and data access (the back end) which is only responsible for communicating through a RESTful interface with the front end. This makes it much easier for developers to create a front-end website, native mobile apps, and consumer facing APIs using the same back end.

At Lob, we believe taking this separation even further makes it easier for our developers to quickly create high quality applications. The example below demonstrates how the internal functionality for billing, accounts, and shipping have been moved to independent APIs that can be accessed over a RESTful interface.

This means whenever our team needs to add a new product offering which involves billing, shipping, or accounts there is a well documented interface with which to work.

Hiding Complexity

Providing internal functionality through a RESTful API allows developers to abstract the complexity of that functionality away from the developers consuming the API. Consuming developers only need to know about endpoints, responses, and errors which can all easily be handled with quality documentation.

If I am the developer in charge of the billing functionality, here is just a sampling of the features I need to worry about:

• Multiple payment platforms (Stripe, Balanced, BrainTree, BitCoin, etc.)
• Payment Cycles (recurring subscriptions, one time charges, etc.)
• Issuing refunds and tracking credits
• Following up on unpaid bills and expired credit cards

However, if I am the developer in charge of a new product endpoint I am only concerned about things such as charge customer A $50 on June 12 or bill customer B $200 at the beginning of each month for the next year. I'm not concerned about which payment provider is used to charge the customer, whether the customer has credits on file, or following up with a customer to obtain a valid credit card. Internal functionality through RESTful APIs allows developers to focus their energy on the complexities of their product rather than everyone else's.

Going Forward

At Lob, we believe that APIs are the future for how businesses will communicate with one another. Enforcing this type of communication between our internal teams allows us to develop more efficiently and to learn what works and what doesn't when developing APIs. This has been a great learning experience for the team thus far. We have learned what tools allow us to be the most efficient and which ones hinder efficiency (we have since dropped CoffeeScript). The biggest challenges we have faced so far have been identifying how to efficiently and comprehensively test API endpoints and how to version breaking changes in an API.

If you have any thoughts on the use of RESTful APIs for internal functionality, the biggest challenges when developing APIs, or tools/techniques that you rely on for API development, we would love to hear about them!

Application programming interfaces (APIs) are becoming more and more prolific in today’s technology driven world. Millions of developers use APIs on a daily basis to integrate existing technologies into their applications. At Lob we don’t really like to think of our API as a product to “sell”, but as a way for us to partner with other great companies to deliver new-found value. As we partnered with the first 2000 developers that signed up with Lob, we learned many important things about how to talk about and share our API with them. Here are four key steps that we’ve found helpful as we partnered with our first to go through with any customer that is interested in using our API:

1.) Customer - identifying the pain point

The first thing we do at Lob is take the time to understand our customers needs. It’s easy to simply jump into discussing features and why a company should use an API, but it is more important to identify a problem and challenge your customer is facing. When we chat with customers, we look to understand their potential use cases, existing workflow and processes, technology requirements and any concerns that they may have with our API.

2.) Education - how does the API solve the pain points

After understanding the customer’s needs better, the next step is educating the customer about our API and how it can help them. The key here is focusing on the areas that are most important to the customer. If we’re talking to a large enterprise customer, we’ll address concerns around data security & privacy and tackle SLA questions up front. On the other hand, with smaller companies, like startups, we discuss details such as packaging, fulfillment time, and pricing questions.

One other strategy that we use at Lob is using case studies to showcase how current customers are using our technologies and API to solve real problems. Often times pointing to a concrete example of benefits that other companies have achieved by using our API helps potential customers understand how the API is deployed in a real-world context.

3.) Pilot and Proof of Concept - show me it works

Whenever you’re working with an API, it is important to realize that there is always an integration time required on the customer side. There are development costs and it takes engineering resources to get the API up and running. As such, one of the factors we look at closely is time-to-integration. Lob provides wrappers in almost every major language to help speed up development time for our customers.

As a next step with larger customers, they often want to see a proof of concept (POC) or run a small pilot. This serves as an opportunity to prove the API works and demonstrate functionality on a smaller scale. Offering to run a small pilot or work to create a POC is a great way to get your foot in the door and show the benefits of your API. At Lob, this gives us a chance to ensure our customers are happy with fulfillment times, ease of use, and have a chance to play with the actual product as well.

4.) Launch and Support - continued excellence w/ customer service

Once all the boxes have been checked and the customer is happy with the API, we go into production. At this point any integration pain points have been worked out and the customer is happy with product fulfillment. We find out the launch date and make a note to watch carefully for any issues with live orders for the first few days. All customer service requests are promptly responded to.

Furthermore, we set up regular times with customers to connect to collect feedback and make sure no further issues are occurring. Having a regular time to connect is important to correct and plan for any changes coming down the line.

As hackathons become more and more popular, organizing a hackathon has become close to a full time job. We would like to draw on our own experiences both sponsoring and participating in hackathons to offer some helpful tips for hackathon organizers. Below are a few tips to help you organize your next hackathon and make it successful for all parties involved.

Before the Event

1. Choose the right venue

When choosing a hackathon venue, the most important thing is to find a place that is appropriate for the size of your event. For very large events, scout locations that have huge empty spaces such as convention centers, warehouses, and stadiums. For smaller events, co-working spaces are a great choice because they are already wired up and ready to go. Wi-Fi is always a challenge, so make sure to gather as much information as possible about the internet speed, number of routes, ethernet availability, etc. At the very least, strive to provide wired connections to as many people as possible and rate limit so that everyone gets a solid connection and nobody is left out. Make sure there is space for demos, sponsor booths, and presentations.

hackTECH 2014

2. Develop a mobile app

Communication at hackathons is tough, especially if you're dealing with hundreds or thousands of hackers, sponsors, and judges. A mobile app helps you centralize information while also allowing you push notifications to attendees, contact sponsors straight from the app, and answer questions in a live chat.

MHacks Mobile Application

3. Get Sponsors

Your goal at the hackathon is to provide useful tools for your attendees. Find sponsors that can arm hackers with tools (such as APIs, devices, etc.) and send technical evangelists to help participants. Participants are most successful when they have a plethora of tools at their disposal and companies benefit from the valuable feedback on their products. Don't be picky with sponsors, if they can help and have good tools, it is in your hackathon's best interest to find a way for them to get involved.

4. Give sponsors instructions

One of the biggest complaints we hear from sponsors at hackathons is that things seem disorganized and they don't know what they are supposed to be doing. Sponsors are used to organized events and expect instructions. Before the event, send sponsors tentative schedules and tips on how to engage with hackers. Suggest hotels, give parking directions, and be clear on what you expect from them.You can really bring the sponsor experience to the next level by simply giving them the information they need beforehand.

5. Plan office hours

A lot of your sponsors are awesome and have amazing products. Give them the opportunity to talk to hackers and teach them how to use your product. It's a great way to support the community and also gets hackers really excited about your company. Getting to sit down and talk to them about your app, their job, or even just life. Facilitate these types of interactions by organizing open office hours for your sponsors.

6. Arrange speakers and panels

Reach out to interesting and notable members in the tech community and beyond. You will be surprised to find that many of them love to come out to hackathons to give a talk, fireside chat, Q&A, etc. From our personal experience, industry leaders often give very insightful talks that both motivate and raise morale at hackathons. Also, these guests are always impressed by the many different hacks which helps raise awareness for your participants.

YC Panel at MHacks

7. Don't let sponsors take over

Many talented hackers will stay away from events with large prizes because there's no way to win unless you use the most APIs/products that the main sponsor(s) have provided. When this happens, demo day/final presentations turn into infomercials sponsored by the biggest companies with the deepest pockets. You should encourage teams to build technically sound and creative projects rather than ones that are the most branded.

During the Event

8. Engagement

Your sole job during the event is to promote engagement amongst attendees and sponsors. No one knows the hackers at the hackathon better than you do. Many of them are constantly running into issues and need help and many of your sponsors happen to be experts in one or more languages and can help hackers tackle obstacles along the way. As an organizer, you need to facilitate these introductions and help people engage.

After the event

9. Solicit feedback

After the weekend is over, make sure to personally reach out to participants, sponsors, and partners and ask for feedback on the event. What went well, what could have been better, and what new ideas could be incorporated next time around. If there are unhappy sponsors, it is important to recognize their grievances and work with them to see how you can improve the experience, especially if you want to work with them again. At the end of the day, the hackers are the voices you should consider the most. Do everything in your power to get their feedback and share it within the organizer community.

10. Track progress of projects

For the most part, most people do not continue maintaining or working on their projects after the weekend is over. Reach out to attendees to encourage them to continue on their hacks. They may have the next killer app (GroupMe).

--

A big thanks to everyone who contributed to this post. As always, let us know what you think about this list. What did we leave out and what do you like?

If you are organizing an event and would like Lob to be involved, reach out to support@lob.com!

The last few months at Lob, our engineers have started to create Lob’s new scalable API infrastructure. As we begin transitioning to this new infrastructure stack, we want to share and discuss the technologies we have decided to use.

Infrastructure

At the infrastructure layer, we are hardcore AWS fans. Our entire infrastructure at Lob is built on AWS and we view the platform as a major driver of productivity, especially for a company of our size. Below is a diagram of our system architecture and the AWS services we use.

Application Stack

The two driving factors behind our API design have been language independence and modularity. We want to give ourselves the flexibility of using any language or framework to write a given endpoint of the API. For example, on our address verification endpoint (which is pinged several times every second) Node.js is a logical choice because of its ability to handle a large number of concurrent requests. However, on our more computation-heavy endpoint for parsing and validating objects we may want to take advantage of the large number of libraries and tools available in a language like Ruby or Python.

By building our API in a modular way where each endpoint is its own internal API, we can pick and choose which language we want to use for current or future endpoints. That said, we don’t want to internally support too many languages so we usually try to stick to 1 or 2 preferred languages. Right now we predominately use Node.js and want to talk about some of the tools we have been using to build our custom MVC and APIs.

Node.js

Node.js has been a great boost to productivity for the Lob team. The asynchronous nature of the language and its ability to handle a large number of concurrent connections fits well into the architectural needs of our company. The Node.js community and strong support for npm means there are usually several open source libraries for performing nearly any task. There are also a large number of productivity tools available to help developers write high quality code more quickly. Below you will find information on some the Node.js tools that help us build at Lob.

Hapi

Hapi is a newer framework and is a “simple to use configuration-centric framework”. It has built in support for input validation, authentication, and other essential facilities that make it perfect for building an API . Aside from being a great API focused framework, it has built in support for view engines and makes working with Handlebars (our preferred engine) seamless. Hapi is also a very readable framework so the learning curve isn’t as steep as other fraweworks.

Bookshelf.js

Our current API offerings are backed by relational database storage rather than a NoSQL storage system which you will see in a large number of Node.js web apps. In order to interface with the relational database in Node.js we started using a great ORM called Bookshelf.js. Bookshelf.js is built on top of the Knex query engine and “extends the Model & Collection foundations of Backbone.js”. Bookshelf.js provides great support for defining models, inheritance, eager/lazy loading, and multiple database engines (MySQL, PostgreSQL, and SQLite3).

Mocha

We currently use Mocha for testing our Node code. There are a large number of great testing libraries in Node, but below are a few reasons why we enjoy using Mocha.

• Concise, readable syntax for creating sections and tests
• Support for both synchronous and asynchronous tests
• Flexibility in choice of assertion library (should.js, chai, expect.js, better-assert)
• Variety of test reporters including HTML, JSON, Markdown and Nyan

Gulp.js

We have been using Gulp.js in order to speed up the development process by automating common tasks. Below is an outline the workflow we are currently using with Gulp.

1. Compile CoffeeScript in to JavaScript
2. Compile LESS in to CSS
3. Lint the compiled JavaScript code
4. Run unit and integration tests
5. Generate JSDoc documentation

What We Do

Our goal with Lob has always been to provide businesses and companies with a means to automate processes and workflows around physical real-world infrastructure. We firmly believe that APIs are the answer and a focus on technology and engineering will help us achieve that vision. This is why we put the developer first, aiming to arm them with the tools necessary to streamline their businesses and applications.

Our most successful product to date has been our Print & Mail API, which allows developers to access commercial print infrastructure on-demand in a programmatic fashion. Our customers have taken advantage of this and we have seen a huge variety of use-cases ranging from enterprise applications to creative consumer applications. Our API has helped developers offer printed collateral from within their apps as a means to monetize and to bring creative assets to life.

By giving developers such a platform, we are able to aggregate and queue up demand, and in turn give our customers on-demand pricing. This is a powerful concept and has been extremely successful for us. As our volumes scale over time, we are able to pool more demand and push our costs down even further. When that happens, we pass those savings back to our customers. This is a virtuous cycle and we are always evaluating our business model to find ways to save our customers money.

Lowering Prices Across The Board

Today, we are proud to announce our first round of price cuts. We took a very close look at all our products and the processes we have in place with printing and fulfillment at our facilities. Across the board, we have lowered pricing 7.3% on average, with some products being lowered in excess of 20%.

We’d like to celebrate our success by showing appreciation to our current customers and making it that much easier for developers everywhere to continue building amazing applications on our API.

Take a look at our products and pricing here. We are always exploring and beta testing new and exciting products to offer through our API, so stay tuned for new product releases!

Check out our documentation and get set up at Lob for free.

It's no secret that hackathons are quickly growing in prevalence and size around the world. If you are unfamilar with what a hackathon is, check out this great piece by Dave Fontenot. At Lob, our goal is to give developers access to physical world infrastructure through an API, so that they can build cool features directly into their applications. Hackathons have been a very valuable medium for us as a company to evangelize our APIs, build our brand, and meet developers. We have seen many creative uses of the Lob APIs as hackers have built applications on top of Lob and as cool extensions of their existing applications.

As a hacker, these events are the best way to come together with others to build amazing products, solve interesting and challenging problems, and meet new people all within the span of 24-48 hours. When companies sponsor hackathons, they are presented with a great opportunity to meet talented individuals of all ages and backgrounds. With numerous software and hardware hacks, the insight into the most popular tools, APIs, languages, and development approaches taken can be invaluable for companies as they look to hire and develop their own products. If the organizers of these events are able to bring together all these parties in a well-planned fashion, then it is truly a one-of-a-kind experience for everyone involved.

Demo Day at MHacks 2014

In part one of our Hackathon Playbook Series, we wanted to lay out 10 things that sponsors need when they are considering sponsorship of hackathons. Sponsoring these events often requires a great deal of commitment for companies of all stages and it is important to make the most of your experience. We based this list off of our own observations and learnings sponsoring and attending various hackathons of all different sizes. No matter what event you choose to sponsor, the common theme of a successful sponsorship is a strong presence.

1. Engage Engage Engage

We cannot stress the importance of this as it relates to sponsors. Even though you probably have a nice spot in the venue with a table set up dedicated for your company, you should be spending a good chunk of your time during the hackathon walking around and meeting hackers. Ask about what they are working on, offer your help and constructive feedback, and tell them about your company. The large majority of hackers at these events won’t even know you are there if you stay at your table all weekend.

2. Bring Swag

Bring as many stickers, t-shirts, stationery, and other fun things as you can get your hands on. Hackers love swag (who doesn’t?) and bringing fun stuff accomplishes two things: 1) builds your brand and 2) attracts attention. Things like stickers have a viral effect and subtly markets your brand during and long after the weekend is over. When you have swag at your table, people will immediately gravitate towards you and more often than not, listen to a quick pitch about your product. If you don’t bring anything, you’re going to miss out on these opportunities.

3. Send Technical Evangelists

This one is absolutely crucial, especially for companies that are trying to evangelize technical integrations such as APIs. It is very important to have someone on the ground for the duration of the weekend that knows your product inside and out and can help to debug and answer any questions hackers have at these events.

Peter Nagel, Software Engineer and Dev Evangelist at Lob

4. Cleary Communicate Your Product How-Tos

Have clear documentation/instructions on your website that is immediately accessible. Explore other avenues as well. For example, the folks at MongoDB hand out small, aesthetically pleasing journals that are ripe with FAQs and helpful tips on how to integrate with their product. They hand this out as part of their swag pack and it’s awesome. You have to remember that hackers have to build out a functional product in as little as 24 hours so if your product is confusing to use, they will more than likely give up and use something else.

5. Bring Big Signage

Make sure to bring banners, table throws, and whatever signage you can get your hands on. Hackathons are usually held at big venues, so unless you have a visual presence that commands attention, it is difficult to stand out. Buy some stand-up banners and put it on top of your sponsor table so that everyone can see it from anywhere in the venue.

6. Provide Real-Time Customer Support

All companies should always make sure to beef up their customer support efforts, but this is especially true when it comes to hackathons. There has to be a way to interact with company reps in real-time. So if you can’t send people to be physically there, make sure to let everyone know that they can get answers from you in real-time via a support phone line, email, olark, twitter, and other mediums.

7. Offer Creative Prizes

For those companies that have an API, offer up a prize to the team with the best integration. Make sure you approach every single person that uses your API that weekend, thank them, and ask for feedback. For companies that are recruiting, offer up a prize to best overall hack or some other general category. This will allow you to personally communicate with teams that impress you. Prizes don’t necessarily have to be expensive. iPads and gadgets are always a hit, but often times what’s more valuable may be some sort of unique trophy, or perhaps even a private dinner with your team. The opportunity for hackers to pick your brain can be way more valuable than gadgets you can buy any time. Just keep in mind that simply offering up a prize is not enough, you have to do a good job of evangelizing it as well.

8. Provide Snacks and Fuel

When midnight rolls around, hackers start getting tired and burnt out. Even though the event organizers generally do a great job of making sure there is always enough food, you can never have enough frappuccinos, red bulls, chips, and candy. If nothing else, people will love you for bringing treats, but more often than not, they will also give you their attention and learn about who you are and what you do. We have personally had quite a few hackers find out about our product and actually use it because we offered up some drinks.

9. Bring Business Cards

Many people will say that business cards are becoming obsolete, but it is still the easiest way to hand out your contact info. We have found that hackathon participants ask for your personal business cards because it is always nice for them to be able to follow up with you after meeting at the event. You will meet lots of interesting and talented people at hackathons, so be sure that they have a way to contact you afterwards.

10. Meet and Build Relationships With Other Sponsors

When it comes to sponsorships, there is an innate sense of competition. Sponsors are competing for talent, technical integrations, and attention. Although this is true, you should be building relationships with other sponsors. If you go to enough of these, you start running into the same people. The two most recent hackathons we have been to were MHacks and hackTECH. At both events, we saw several cool apps that used a combination of sponsor APIs such as Pinterest + Lob, Sendgrid + Lob, and others. Some ideas are so impressive that they could inspire real product integrations.

For those of you who have sponsored hackathons or are thinking about sponsoring hackathons, we'd love to know what you think in the comments below. Stay tuned and check back for Part 2: Playbook for Hackathon Organizers.

1. More APIs From More Companies

We have discussed on several occasions how we believe APIs are the future. They will overtake software and become the backbone of business operations. 2013 saw the continued success of API companies such as Twilio and Stripe. 2014 will bring about the emergence of more startups built upon an API foundation.

Competition from industry incumbents is on its way. As the non-API industry giants see market share being eaten away by disruptive API companies, they will recognize the need to invest more in developers to build their own APIs to stay competitive going forward.

Companies such as Amazon will continue to monitor the API landscape to see what is gaining traction so they can either enter the market, making it all the more difficult for new startups to succeed or make strategic acquisitions. No matter what happens, 2014 will be a huge year for disruption and innovation in the form of APIs.

2. Hackathons Becoming Mainstream

The term “hackathon” will continue to proliferate through communities both technical and non-technical. Soon every university, high school, and tech company will be hosting their own white-labeled hackathons.

This phenomenon will be important to watch as the hackathon model evolves. Hackathons or code-a-thons were started with the goal of bringing together motivated and talented minds together to build awesome and useful things.

As hackathons become larger and more common, it will be interesting to see if the essence of these meetups can be preserved. With bigger sponsors, bigger prizes, and a bigger push to identifying talent, the hackathon model is shifting from a focus on innovation to a focus on money, business, and recruiting. In short, it is scary to see how hackathons are becoming more corporate. We hope that hackathon organizers stay true to being developer focused and making sure that have as many resources to work with.

Nevertheless, we remain convinced that hackathons will be an important staple of the developer community. It is the duty of all tech companies and startups to empower developers with the tools necessary to build and innovate. Corporates, startups, incubators, and co-working spaces alike will have to all contribute in their own ways to make sure hackers have an awesome venue to work in, cool prizes to work for, and a plethora of tools to work with. In 2014, we will see at least one startup whale emerge out of a weekend hack.

3. Open-Source Everything

2013 proved to be a huge year for the open-source community and we fully expect the momentum to continue into the new year and beyond. With the recent release of SteamOS in beta, Valve has embarked on the lofty goal of creating a Linux-based world starting from the living room. Like all open-source projects, their success will be dependant on the developer community’s patience and willingness to debug, provide feedback, and put in work.

Github just announced that their number of hosted repositories has skyrocketed from 5 million in the beginning of the year to a whopping 10 million by the end of the year. The most amazing part of this growth is the trajectory. According to Brian Doll (VP Marketing - Github), the first million repositories took ~4 years and the last million happened in 48 hours. This just shows that Github is poised to experience some truly explosive growth in 2014.

Open-source will become even more prevalent in 2014 as developers band together to work on important projects related to government, healthcare, privacy, and other issues that will be spotlighted.

Implications

As API’s become more mainstream it will be tougher to stay competitive. At Lob, we recognize that we will have to continue to make our product more accessible and easier to use. With more and more options emerging at a rapid pace, companies need to make sure they stay innovative.

Hackathons are getting more corporate and its going to get tougher and more expensive to vie for developer attention. From a developer perspective, although there will be more opportunities available, every single event will be that much more competitive. It will be difficult to stand out amongst the masses.

With more code to be open-sourced, ideas and software will become much easier to create making proprietary knowledge more scarce. While the community in large will benefit, it will be harder to create novel ideas as the probability of replication increases. Companies will have to find new ways to differentiate from each-other in addition to differentiating on the product. Startups are going to have to focus on customer support and user experience or else they will be left in the dust.

For some time now, we have been hearing about how software is eating up the world but we are seeing a fundamental shift towards APIs eating up software. In the past, customers demanded fully-loaded software applications, but today they are asking for access to the layer underneath: the API.

Garry Tan wrote a great blog post about how more and more APIs will take over various business functions ranging from SMS to printing. APIs will rule the way businesses communicate and interact in the future.

In the past, people would use Paypal for checkout – today, people use Stripe to build their own checkouts. Instead of managing and learning applications like Quickbooks, developers are using Subledger to build accounting right into their applications. The list of APIs replacing software solutions is just beginning and will continue to proliferate in the future.

Here are a few reasons why developers and businesses are choosing to use APIs instead of buying software solutions:

1.) Flexibility and deep integrations

APIs provide developers with the flexibility to incorporate features in the way they see fit. Software is limited to the functionality that the creators built into it and don’t offer the same level of integration that APIs enable. For example – Stripe gives you the tools to create your own payment solutions, but if you use Paypal you would be limited to their module. Twilio gives you access to SMS and voice infrastructure to create your own unique solutions and tight integration instead of buying out of the box software solution for two-factor authentication. Before APIs, developers could purchase software solutions but were limited in how they could integrate it into their existing applications. Now that paradigm is shifting: by having full access to the API layer beneath, developers can build their own custom solutions and ensure tighter integrations with existing software.

2.) Speed up development time

A common mantra we hear is to avoid “reinventing the wheel”. APIs give companies instant access to complex infrastructure that they don’t want to spend time or resources to manage. Software requires users having to download, manage, and configure applications. For example, if you require CDN for your image hosting solution, Cloudflare’s API would be a better fit since it provides instant access to a robust CDN to use as they see fit, whereas legacy software require time to set up, configure, and constantly manage a CDN for your company. Not having to worry about underlying infrastructure or hardware, setup, and maintenance and simply making API calls eliminates development hurdles and reduces the amount of friction needed to build new features into a product.

3.) Access to data

APIs give companies the ability to access underlying data whereas software applications may not. This allows companies to control how much data is shown and also manipulate the data to create dashboards or reports. The Linkedin and Facebook APIs are a great example of how new applications built using APIs can access Facebook or Linkedin’s social data whereas an out of the box software application wouldn’t have the data by itself. Another example is Google Map’s API, which allows customers easily enable mapping functionality and manipulate Google’s mapping data within applications. Previous to these APIs finding an out of box software solution that provides open access to their data would be near impossible.

APIs are quickly becoming the primary customer interface for technology-driven products. At Lob, we are excited to be changing the way that companies think about their printing & mailing needs while introducing technology-enabled consumer-centric business models into incumbent industries.

As the holidays are approaching, we wanted to share some ideas on how you can increase customer engagement using Lob’s API.

For those that don’t have time to set up or build these integrations, we have set aside some time this week to help any company that wants to send out cards. You can email us an Excel list of customers and the PDF and we will send it out on your behalf!

1. Send holiday cards to all/key customers

The holidays are a great time to show customers (specifically high revenue generating customers) that you appreciate their business. Using Lob’s API you can tie this directly into your yearly workflow and create certain customer metrics that if met, the customer would receive a nice card from your company.

We recommend either sending a postcard using the Postcard API or sending a card (setting 201) or letter (setting 101) using the Simple Print Service API

2. Allow people to purchase gift cards

For consumer-oriented companies that are looking to get an extra revenue boost during the holidays, we suggest offering the ability for customers to purchase gift cards for friends or family. Using our Simple Print Service API (Setting ID 201) you can send really nice cards that come in A2 envelopes that can act as gift cards. By generating a unique promo code on each card you can lock in revenue this December.

3. Create a holiday direct mail marketing campaign

The holidays are also a great time to launch a direct mail marketing campaign. Use the holidays as an opportunity to create a campaign to increase user acquisition to boost your end of year numbers. We currently allow people to either use internally generated targeted lists or use our Simple Area Mail API. Simple Area Mail (currently in BETA) gives you the power to blanket ENTIRE zip codes with postcards through a simple API call. It has never been easier to launch a direct mail marketing campaign. For those that want to send out mailers to entire zip codes please reach out to us and we can help you get this done via our new API.

We hope everyone has a great holiday!