How we solve common problems

There is a set of common problems that all software companies face. How do you version your source code? How are your applications deployed? How does your team communicate effectively? How do you write consistent, correct code? These are but a few of the problems our industry shares.

Software developers have been iterating on solutions to these problems since software development existed. How do we take advantage of the progress we’ve collectively made?

Open-mindedness is the key. It is important not to fall victim to the Not Invented Here syndrome, otherwise known as reinventing the wheel. There are a couple of ways to avoid this pitfall.

  1. Take advantage of the community. Use open source software that has been crafted over time by people who depend on it. Open source your own software to be productive members of the community and to get feedback on your own solutions.
  2. Take advantage of paid solutions. There are people out there making a living solving some of your problems better and cheaper than you ever will.

Why do we care so much about not spending time solving problems that are common to the industry? Every moment that we can spend thinking about language learning or ridding the internet of bad ads is an opportunity to iterate on the products we believe we are uniquely positioned to develop. Figuring out how to deploy code or how to log errors is the cost of doing business, but should not define our business.

Here are some examples of how we follow these principles.

Open Source


Many of our Node.js projects make use of the wildly popular Express library. Express is a powerful, unopinionated middleware framework. Its excellent documentation, frequent updates, and abundant tutorials make it a great choice to use as a starting point for structuring our server-side applications. Using it as the default routing tool across all our projects smoothes out expectations between distinct codebases.

The Config Module

Any application will end up having some number of configurations that differ between environments: a database connection, CDN location, port numbers, or logging levels. To solve this problem, we make use of the battle-tested config module for Node.js. It allows simple per-environment configurations and is powerful enough to do complicated things like read secret API keys and database passwords from external sources.


We recently chose Ember.js as the framework for our analytics application within our PubNation product. Ember takes an all-encompassing, on-rails approach to front end development. It recognizes that front end developers have largely been solving the same problems since XMLHttpRequest was a thing. Between routing, rendering, data-binding, testing, deploying, and sharing add-ons, Ember has 98% of your front end concerns covered.

Our Own Solutions

We have open-sourced a number of public repositories on GitHub containing solutions to problems we have faced. A handful of Hubot/Slack integration tools plus a lightweight S3 log file querying tool are a few examples. Check out what else is cooking at

Paid Solutions

GitHub and Travis CI

We use private and public GitHub repositories for all of our source code hosting. GitHub provides excellent tools for exploring code history and reviewing pull requests. Continuous integration testing with Travis CI is then a no-brainer. Per-project configuration is dead simple and integration with GitHub makes it immediately apparent when a build has passed or failed.


We use Amazon Web Services for nearly all of our application hosting needs. Between their virtual cloud machines, routing capabilities, application service infrastructure, and storage solutions, they’ve got you covered six ways from Sunday. We have started using Amazon’s Elastic Beanstalk for fast, simple deploys and hands-off scaling.

Google Apps, Pivotal Tracker, and Slack

There are plenty of in-house solutions for hosting your own email, chat, or tracking software, but then you’re on the hook when you can’t access your tickets during sprint planning. We use Google Apps, Slack, and Pivotal Tracker for team planning and communication. These tools are accessible anywhere in the world and are highly available.


Fluencia stores lesson and user data in MongoDB. We use MongoLab’s hosted MongoDB instances for our staging and production environments. MongoLab is far from cheap, but their availability is high, administrative interface is powerful, and customer support is second to none.


Although we are a Spanish learning company, we don’t want to be a Spanish speech company. We rely on world-class tools from Nuance to provide solutions for text-to-speech and voice recognition. By purchasing their tools, we take advantage of their years of research and development.


Reusing common solutions can have a number of drawbacks. You could experience vendor lock-in. Prices of paid services could go up. Hacker News might tell you that your favorite framework is no longer hip. You are forced to rely on other people who are not as intelligent, forward-thinking, or good-looking as you are. At Curiosity Media, we have weighed these concerns and found a balance that allows us to maximize our effort in building the best Spanish reference and learning tools available.