# eFounders Bi-monthly stories about code, tech and shared experiences. For developers. UT is brought to your by eFounders.co -- startup studio building great SaaS startups. - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Wit.ai's startup journey and the lessons from its founders' previous venture DevFeed: [Wit.ai's startup journey and the lessons from its founders' previous venture]() Original publisher: [Read original article]() Author: Rachel Vanier Published: 2015-11-06T14:59:50Z Content type: opinion Language: en Sources: [eFounders]() Topics: [AI Platform](), [AI Development](), [Users]() Tags: [ai](), [ai-platform](), [developers](), [entrepreneurship](), [facebook](), [startup]() ### AI overview This article profiles Wit.ai co-founder Alexandre Lebrun and describes Wit.ai's early launch, traction, Y Combinator participation, funding, and acquisition by Facebook. It contrasts that rapid progress with the mistakes and challenges Lebrun encountered while building his earlier company, VirtuOz. ### Source excerpt You don't often get to meet a co-founder of a startup that follows, by all means, the "perfect successful startup" path. And by "perfect startup", I mean the kind of startup that goes by the book. And by "the book", I mostly mean Paul Graham's essays. I met Alexandre Lebrun, co-founder of Wit.ai, an AI platform that makes it easy for developers to create apps that users can talk to. He holds a degree from a top engineering school. He started his startup while he was living in Palo Alto. He had previous experience in the field. He built the app and launched it early on Hacker News. The app got traction. The team got into Y Combinator. They raised $3M after the Demo Day, with one of the most prestigious VCs (Andreessen Horowitz). 9 months later, they got acquired by Facebook. Here you go. Perfect startup story. What is even more surprising is that when I asked Alexandre: "Your startup seems to be super successful from day 1, is that so?" his answer was: "Well... yes". Don't worry, there is a "but" I was more looking for a "don't be desperate, there are downsides behind all this, success never comes without struggle" kind of testimony. In reality, Wit.ai does indeed follow the success path from day 1, but it's only because Wit.ai is Alexandre's second startup. The story of his first venture, VirtuOz, involves many more mistakes that he learned from. Founders Alex Lebrun, Laurent Landowski and Willy BlandinDoing things right the second time around The story of Alex as an entrepreneur started in 2002, when he decided to launch VirtuOz in Paris. As an engineer passionate with voice recognition and artificial intelligence, his dream had always been to make robots understand human language. Inspired by chatterbots' pioneers like Joseph Weizenbaum -- who created ELIZA in 1966 -- he imagined a solution much similar to Siri. Back in 2002, building Siri was impossible, both from the technological and business perspective. Right after the Internet bubble burst, he decided he would f ## Mention's CTO journey to 400,000 users DevFeed: [Mention's CTO journey to 400,000 users]() Original publisher: [Read original article]() Author: Hexa Published: 2015-10-22T12:17:15Z Content type: article Language: en Sources: [eFounders]() Topics: [App](), [Monitoring](), [Crawler](), [Concurrency](), [race-condition](), [Go Language](), [MySQL](), [API](), [Kafka](), [Redis](), [Percona](), [backups]() Tags: [api](), [backups](), [developer](), [development](), [dns](), [go](), [kafka](), [monitoring](), [mysql](), [percona](), [programming](), [race-condition](), [redis](), [startup](), [tech](), [users]() ### AI overview Mention's co-founder and CTO describes the technical challenges involved in growing the real-time monitoring application to 400,000 users. The article covers high-concurrency web crawling, a libc DNS resolver race condition, and the use of Go as a workaround. It also explains Mention's storage architecture using Percona MySQL, Redis for caching, Kafka for messaging, and incremental backups. ### Source excerpt Mention is a real-time monitoring application used to track and analyze trends and e-reputation in a very complete and intuitive way. Co-founded in 2010, it now counts 400,000 users across the world. This impressive growth rate not only implies great marketing talent but also impressive technical achievements. Arnaud le Blanc, Mention's co-founder and CTO, tells us about how he got Mention there. You gotta love technical challenges "When we developed Mention, our main competitor was Google Alerts, which feels a little like being David versus Goliath at first. But then it became one of the reasons I like my job: it is very challenging. Getting to this point of a product development involves a true entrepreneurial mindset. Before being Mention's CTO, I was a developer and then the lead developer working on the media monitoring feature at Pressking. eFounders offered me to become Mention's co-founder. I might not have thought of myself as an entrepreneur before, although today, I really feel like Mention is my product: I've built it together with my co-founders. Building an application like Mention is full of technical challenges. We handle a large amount of data, crawl thousands of web page per second, built an open API for our own apps, and use lots of third-party APIs." FOCUS: a challenge overcome when developing Mention's web crawler Since Mention crawls a large amount of web pages in parallel, there is a point when the crawler reaches a high concurrency level and stresses the OS: that is when we got to the limit of our system. In our case, these limits entailed the appearance of a race condition in the libc's DNS resolver. libc was sending over DNS queries on random unrelated file descriptors, which was leading to weird behaviors. The bug was reported and fixed a few months later, but in the meantime, we had to use the plain-Go DNS resolve, which happened to work really well. "At Mention, several millions of Mentions are inserted in user feeds per day (see infogra ## How Martin Destagnol Built Folders and Sold It to Box in Seven Months DevFeed: [How Martin Destagnol Built Folders and Sold It to Box in Seven Months]() Original publisher: [Read original article]() Author: Hexa Published: 2015-10-15T17:49:43Z Content type: opinion Language: en Sources: [eFounders]() Topics: [iOS](), [Mobile](), [Cloud](), [App](), [User Experience](), [dropbox](), [Google]() Tags: [acquisition](), [apple](), [cloud](), [dropbox](), [engineering](), [entrepreneurship](), [ios](), [product](), [startup](), [user-experience]() ### AI overview This article recounts how Martin Destagnol built Folders, an iOS client for accessing cloud-stored files on mobile, and sold it to Box seven months later. It describes the product's origins in his own frustration, his focused development effort, and his meetings with Box, Dropbox, and Google Drive. ### Source excerpt Martin Destagnol, him-self...And then became Director of Mobile Remember back in 2013, when reading files on "mobile" was new and everyone was wondering how the h*ck to do it? That's when Martin Destagnol, entrepreneur and engineer, built Folders. And seven months laters, Folders got acquired by Aaron Levie's Box. Destagnol is now Director of Mobile and of Box Notes -- the French "serial" "startuper" went from building a product in his apartment (we don't get many garages in Paris) to managing a whole engineering team inside one of the fastest-growing startups in the Silicon Valley. How does one do that? Here's the story. Startup genesis and crazy-fast acquisition As you might hear often times when wondering why an entrepreneur built a startup, Folders came from Martin's own frustration: accessing cloud-stored files on mobile was just a pain. So he decided to build an iOS client providing the very best User Experience possible. But Destagnol also brought a strong business rationale to the idea: as Folders was his 3rd startup, he knew what kind of risk he was willing to take and what outcome to expect. His previous company, Plyce, was a social network based on coupons, which had a great potential but also high risks. When coming up with Folders, his ambition was to build a product much more targeted, with higher chances of a "smaller scale" success. The bet was that one of the existing cloud providers could need a product like Folders; worst case scenario, he would still sell enough to make up for the money invested. Then he shut down everything else but work, and built Folder in 7 months. Full time. Like, 24/7. As in 100% of the time. Once the app was approved by the Apple store, Destagnol decided to come to San Francisco to show it to Box, Dropbox and Google Drive. The product wasn't launched, but he figured the sooner he would show it to the big players to get their feedback, the better -- for those of you who are reading from elsewhere than San Francisco, yes, that's ## How we scaled Wisembly's infrastructure : moving from our Elephant to RabbitMQ DevFeed: [How we scaled Wisembly's infrastructure : moving from our Elephant to RabbitMQ]() Original publisher: [Read original article]() Author: Guillaume POTIER Published: 2015-07-02T13:31:56Z Content type: article Language: en Sources: [eFounders]() Topics: [RabbitMQ](), [Socket.IO](), [WebSocket](), [real-time](), [MySQL](), [Node.js](), [PHP](), [Redis](), [Software as a service]() Tags: [backend](), [growth](), [mysql](), [node-js](), [php](), [rabbitmq](), [real-time](), [redis](), [saas](), [startup](), [tech](), [websockets]() ### AI overview This article describes how Wisembly evolved its infrastructure as usage grew. It focuses on using RabbitMQ on the backend to communicate between application components and servers, after earlier use of Node.js, Socket.IO, PHP, MySQL, Redis, and WebSockets. ### Source excerpt Hi, I'm Guillaume, I am the CTO and co-founder of Wisembly, a SaaS solution facilitating interactions during your big meetings and events. We recently launched a beta of our new product: Solid to help you make your every-day-meetings more productive and actionable. This is the story of how we improved our performance by changing and adding elements to our stack over the time. I'll particularly focus on how using RabbitMQ on the backend to communicate between different stack and servers improved our life. Where we once were Here are the building blocks for our tech team's philosophy: start small, DRY (Don't Repeat Yourself) and YAGNI (You Ain't Gonna Need It). Back in 2012, when we implemented real-time websockets communications with Node.js and Socket.io, we had a pretty small stack: everything fullstack on Symfony2 with MySQL as single storage and some tiny parts of Backbone.js here and there to power up our application. One year later I presented these slides at the Symfony2 Live Paris 2013 explaining how we implemented Elephant in raw PHP to communicate from our Symfony2 backend with our distant socket.io push server. https://medium.com/media/dfdfc12635e346b3ceb1b2838fda5808/href As I said, our stack was pretty minimal at the time. We didn't feel the need to complexify it for the sake of the socket.io push server. So we looked at websockets and found a pretty way to implement them, connect and emit events with our Open Source library. It did the job, we open-sourced something cool (more than 500 stargazers now and still active!), on our way to live happily ever after :)... Or did we? Where we are now Quite recently, as the business was growing, more and more push events were sent every minute on the various customer meetings we handle daily. For example, we have a specific feature for very interactive seminars where more than 500 users can answer a live poll. Oftentimes, all the attendees submit their answers during the same 10-to-20-second time window, right after ## 5 things I've learned being a CTO in startups DevFeed: [5 things I've learned being a CTO in startups]() Original publisher: [Read original article]() Author: Jean-Baptiste Escoyez Published: 2015-06-25T13:58:10Z Content type: article Language: en Sources: [eFounders]() Topics: [Development](), [business logic](), [Code](), [optimize](), [App](), [Users]() Tags: [business-logic](), [code](), [cto](), [dev](), [optimize](), [productivity](), [startups](), [users]() ### AI overview A startup CTO shares two rules for making technical decisions: align engineering work with business and customer outcomes, and organize code into small reusable modules to support speed and flexibility while limiting technical debt. ### Source excerpt In the past 5 years, I have been Chief Technical Officer of two startups -- one, GoCar has been acquired and one, Solved, has been discontinued -- and helped many others as a technical advisor. What characterizes startups is that they have to ship a lot of results with limited resources. As CTO, your daily job is to lead the technical team, set the goals and take the right technical decisions. You are in a constant tradeoff of immediate speed VS long-term productivity. In this article, I want to share 5 rules I follow in order to make my choices. So far, they enabled me to keep shipping while avoiding to pile up "technical debt". 1. Dedicate yourself to the business The goal of any startup is to build a solution which will bring value to its customers. There are chances that your business co-founder will spend most of his/her time talking to them and understanding their needs. On this basis, your co-founder will set the priorities and report what customers' problems are. Your role will be to find out and build an outstanding product that provides a solution to them. As a technical person, it is easy to get excited by a new technological challenge or a new service that looks promising. When it occurs to me, I ask myself this simple question: "What is the business outcome of what I am doing". This way, I always know if I am working on the right priority or not. At Solved, we even dedicated a weekly meeting with my business co-founder, Thomas, where we were reviewing the features to ensure they match the business priorities. At any moment, I and any member of my dev team could say why we were working on any feature. In order to ensure I did a good job, I was asking myself: how will it delight our users? how will it help our startup to make money? or help our operations team? If you can also answer these questions for your own project, there are chances you are on the right track. 2. Optimize for speed and flexibility In its early days, your startup's main challenge is to ## 3 Takeaways from Point Nine's CTO Event on Scaling Up Tech and Tech Teams DevFeed: [3 Takeaways from Point Nine's CTO Event on Scaling Up Tech and Tech Teams]() Original publisher: [Read original article]() Author: Moritz Dausinger Published: 2015-05-13T15:05:17Z Content type: opinion Language: en Sources: [eFounders]() Topics: [Development](), [Architecture & Design](), [Database](), [Microservice](), [ci]() Tags: [challenges](), [engineering](), [hiring](), [organizational](), [pipeline](), [scaling](), [tech-talent]() ### AI overview The article presents takeaways from Point Nine Capital's CTO event on scaling technology and engineering teams. It argues that organizational and managerial challenges often outweigh technical problems, and recommends maintaining a pipeline of technical talent. ### Source excerpt illustration by Adrien Griveau Last week, Point Nine Capital invited the CTOs and VPs of Engineering of their portfolio companies. The event took place in Google's offices in Berlin. I was flattered to get invited and had the opportunity of spending the day next to great people from famous startups such as Morten Primdahl, Co-founder and CTO at Zendesk, Spyros Magiatis, Founder and CTO at Workable, or Johannes Ziemke, Platform Engineer at Docker. Nicolas Wittenborn on Twitter Lots of brainpower in the room at the #p9techcircle thx to @GoogleDE for the great location! pic.twitter.com/yGTZJsxgL2 The agenda was quite packed with interesting topics around scaling tech and teams. You can find the complete agenda on this post written by Rodrigo Martinez, who did a fantastic job organising the event. Next to great tech-centric talks (e.g. Continuous Integration Best Practices by Florian Motlick, CTO at Codeship, Microservices by Andy Smith, CTO at Werker etc.), an important subject was hiring and scaling teams. In other words: a mix of the most important topics you need to know once you have traction. And as the CTO of one of eFounders' under-development startups, this really struck a chord. So here are my key takeaways from this meetup. Takeaway #1: The hardest problems when scaling up are most of the time non-tech problems The panel was called 'Best Practices on Scaling Tech', but after a couple of minutes of discussion, it became very clear that the bottleneck is mostly due to organizational challenges. Indeed, answers to well known technical problems such as how to scale a MySQL database are available most of the time. Despite all your preparation, be ready for your 3am emergency alert, stay focus, and you'll resolve the problem. No, your true challenges will come from human and managerial situations. Your job as a CTO is to have a working team in place which can perform, produce and scale with the success of the startup. Hiring tech talent is increasingly difficult an ## How to organize your files on your Meteor projects DevFeed: [How to organize your files on your Meteor projects]() Original publisher: [Read original article]() Author: Vianney Lecroart Published: 2015-05-07T15:13:56Z Content type: tutorial Language: en Sources: [eFounders]() Topics: [Meteor](), [Framework](), [Ruby on Rails]() Tags: [developer](), [files](), [how-to](), [meteor](), [meteorjs](), [structure]() ### AI overview The article discusses how to organize files in Meteor projects. It explains Meteor's file-loading priorities and alphabetical ordering, then shares the author's experience and reasons for preferring task-oriented file grouping over a Ruby on Rails-style structure. ### Source excerpt illustration by Adrien Griveau I have been working on Meteor projects for more than 2 years now. I already shared the reasons of this choice in a previous post. Today I want to address the question of file structure. Unlike frameworks such as Ruby on Rails, which has clear instructions on how files should be organized, Meteor lets you decide how you want to structure them. It only sets a handful of rules on files priorities. For instance, files inside a directory called lib are always added above all other files. Also, Meteor sorts all files in alphabetic order. But this autonomy leaves first-time users with a lot of questions, as you can see on StackOverflow or on Meteor's forum. Obviously, the topic is hot. Abigail Watson, a well-known developer in the Meteor family, wrote an article about it. In her awesome Meteor cookbook, she dedicated a section to describe the different file structures, depending on your project. As you can see, there's more than one solution. So, how do you set up the right structure for your project? Here are my thoughts and return on experience based on the different projects I run at eFounders. Why I decided not to follow the Ruby on Rails file structure Meteor evangelist Josh Owens (if you don't know him, he's the guy behind Meteor news site crater.io, The Meteor podcast, and The Meteor club) reuses part of the directory structure used in Ruby on Rails. But as he explained in this article, his main reason for doing so being "having spent 9+ years working with that framework", it didn't convince me (no offense Josh). Going a step further, here are my reasons not to use the Ruby on Rails file structures. First, it generates too many small files and directories. You end up with tenths of open tabs, and switching between tabs can very quickly become annoying. Second, I almost always work on a specific task on a specific part of the app (let say the comment system of a blog). Therefore, I like to have all files related to this task close to ea ## The art of the startup pivot from a founder-CTO point of view DevFeed: [The art of the startup pivot from a founder-CTO point of view]() Original publisher: [Read original article]() Author: Yann Lechelle Published: 2015-04-30T13:15:07Z Content type: opinion Language: en Sources: [eFounders]() Topics: [risk-management](), [Business Security]() Tags: [efounders](), [management](), [risk-management](), [startup](), [startups](), [tech]() ### AI overview An opinion piece examines startup pivots from a founder-CTO perspective, covering why strategic changes occur, their effects on founders, investors, revenue, and company structure, and how repeated pivot experience may inform risk management. ### Source excerpt A risk management perspectiveYann Lechelle (LinkedIn, Twitter) is a Paris-based entrepreneur with a number of pivots under his belt. He was founder and CEO at Etheryl (acquired by private investors), co-founder at KickYourApp.com (acquired by Change), co-founder and COO/CTO at Appsfire.com (acquired by MNG), co-founder at Sonetin.com and currently COO at Snips.ai using AI to make technology disappear. Yann occasionally invests in and advises other startups, on pivots among other things!~ TL;DR: this post discusses the generic notion of a startup pivot. Technically minded readers might prefer to focus on the product & tech sections, or anything else in bold. Pivots are a fact of life in the startup world. Yet, very few founders, especially first-time founders, will provision for it. The founder mindset is typically focused on a single go-to-market strategy. The investors are sold on the potential based on that initial strategy, signing off a budget calibrated accordingly. Everyone sings the same tune until the shareholders realize, hopefully before it's too late, that the strategy is going nowhere, and that a radical change is required. This scenario occurs more often than not, over 65% of the time according to Fred Wilson. While this iterative process appears natural, and with the benefit of hindsight, accepted and even praised as part of the startup folklore, it remains a traumatic event from the inside, and possibly a direct cause for failure. Reversely, if done right, a pivot is almost inevitably cause for success. Structurally, there can only be a handful of pivots within the lifetime of a company. Repeat entrepreneurs may have experienced it multiple times and therefore developed their art of the pivot... hence becoming pivot artists, a trait that VCs should consider as key risk management expertise! Here are a few awesome pivot artists: Multi-pivot repeat entrepreneur Stewart Butterfield: from video game to Flickr and from video game to Slack; product & vision p ## How your API could benefit from Hypermedia DevFeed: [How your API could benefit from Hypermedia]() Original publisher: [Read original article]() Author: Olivier Hervieu Published: 2015-04-23T13:15:46Z Content type: tutorial Language: en Sources: [eFounders]() Topics: [API](), [hypermedia](), [HTTP](), [Website](), [client]() Tags: [api](), [client](), [computer-science](), [http](), [hypermedia](), [links](), [rest](), [stateless](), [tech](), [web]() ### AI overview The article explains how hypermedia supports the REST uniform interface constraint in APIs. It describes resource representations, self-descriptive messages, and server-provided hyperlinks that expose transitions and actions, using the web as an analogy and beginning a Twitter API example. ### Source excerpt illustration by adrien griveau Roy Fielding's dissertation thesis on "Architectural Styles and the Design of Network-based Software Architectures" albeit published in 2000, is still a goldmine in 2015. For those who are not familiar with Fielding's work, he is one of the authors of the Apache web server, he has worked on the first specification of HTTP, and he is the father of the REST acronym. A REST architecture is an architecture that MUST (as in RFC 2119) respect the following architectural constraints: client-server stateless cacheable layered-system uniform interface code-on-demand (optionally) HTTP and the 2000's World Wide Web, fit perfectly in this description of a REST architecture (in fact, REST constraints seem to be chosen so that systems that would respect these constraints will look like the web ☺) 15 years later, everybody builds RESTful APIs. These APIs take full benefit from HTTP (and thus, from its REST-base architecture) but most APIs do not fully respect the "uniform interface" constraint. In the Fielding sense, an API is really RESTful if it respects the uniform interface constraints: resources are unambiguously requested via URIs, representations of resources are manipulated (you're always playing with a "view" of a resource, not the resource itself), messages are self-descriptive and self-contained, transitions and actions should be clearly exposed to the client by the server, via hyperlinks and hypertext. This point is often referred as HATEOS: Hypermedia as the engine of application state. A classical website, like the one from which you're reading this article, uses hypermedia as the engine of application state. You're viewing representations of resources and, on each of them, a set of actions (going back to home, viewing a related article) is actionable via hypertext links. Clicking on one of these links will (hopefully) give you another view of another resource, modifying the application state. Those links are materialized and explained ## Making your website multi-regional using top-level domains DevFeed: [Making your website multi-regional using top-level domains]() Original publisher: [Read original article]() Author: Nicolas Mondollot Published: 2015-04-15T12:19:08Z Content type: article Language: en Sources: [eFounders]() Topics: [Website](), [Search engine optimization (SEO)](), [Rails](), [domain](), [Development]() Tags: [article](), [development](), [dns](), [domain](), [rails](), [search-engine-optimization](), [seo](), [startup](), [tech](), [website]() ### AI overview This article explains how to localize a website for multiple languages and regions, compare URL strategies for international SEO, and use country-specific top-level domains with Rails. It describes Drivy's choice of ccTLDs and notes limitations in a simple domain-based locale implementation. ### Source excerpt illustration: Adrien Griveau Hi there. My name is Nicolas Mondollot, I am the CTO of Drivy -- an awesome peer-to-peer car rental service. We launched our german website in early 2015. Here are some things we learned along the way. When you start a website you usually start small: one website, hosted on one domain, targeting one country and one language. Simple, right? Then, one day you decide to go international (exciting!). One problem, though: people don't all speak/read the same language everywhere. You must localize you content in multiple languages. The standardized way to do so is to use a locale for each language and geographical region you are targeting. For instance if you want to make your website available in the US, France and Canada you'll need 4 locales: en : English (US) fr : French (France) fr-CA : French (Canada) en-CA : English (Canada) side note: this is a 'pragmatic' approach to locale naming, where we drop the regional part when it is not needed (more information here). Great. Now, how do you make your website available in all these locales? Locales and URLs The first rule of Search Engine Optimization when you go international is: the locale must appear in the URL. Google suggests choosing among several options: URL parameters: example.com?locale=fr Subdirectories with a generic top-level domain (gTLD): example.com/fr/ Subdomains with a generic top-level domain (gTLD): fr.example.com Country-specific top-level domains (ccTLD): example.fr There is no one-size-fits-all approach. The best solution really depends on your specific requirements (this article from Moz may give you some pointers). At Drivy we decided to use ccTLDs because it was the best solution SEO-wise to target different countries. Plus it's prettier. First implementation In Rails this is pretty straightforward. You just need to point your new domain DNS to your application server and drop this code in your ApplicationController (inspired by the official Rails guide): class Applicat