The QuickNews Odyssey: Lessons from Building a Startup

Building a startup has the reputation of being one of the toughest challenges a person can undertake in their lifetime. And indeed, despite the abundance of resources it actually is rather hard to figure out how to approach all the problems encountered on a daily basis: building the product, managing a team, hiring, fundraising and all that jazz.

I frequently resort to studying the history of great companies: my list of favorite business books contains very good ones on Microsoft and Google, full of facts and short on hero-worship. Yet even with the great ones in this genre (Steven Levy’s books come to mind), it is often difficult to draw lessons applicable in the daily grind: two students build search engine, get to a million users, then to a billion, and so forth with Hegelian inevitability.

Wishing that I had a more concrete and down-to-earth resource available to help me as I was starting my startup journey, I’ve undertaken to put into writing our experiences in developing QuickNews, the smartest AI-powered news aggregator in the world, covering the idea, vision, implementation (expect a future post with more technical detail), obstacles, and decisions good and bad, which I’m hoping will be useful for founders just starting out.

Keep in mind that my grandiose goals are far from accomplished. QuickNews launched in January, and has accumulated over three and a half thousand downloads. Not bad, but way more to go!

Myself

More on the story’s antihero: originally from Croatia, I got into programming and math in high school, participated in competitions with some success, and decided to parlay my early passion into a career in the tech industry. I was inspired by the example of my father, a software entrepreneur, as well as good old Silicon Valley hagiography, from the Traitorous Eight/Fairchild/Intel, to Jobs & Woz, all the way to Larry & Sergey.

My most prominent job so far has been as a software engineer at Amazon in Vancouver, Canada. I worked on AWS, S3 to be specific, and was on the team responsible for scaling a large part of it (well, keeping it afloat at the very least). Afterwards I joined the Alexa team in the midst of the email project, and built a big chunk of the “Alexa, tell me when I get an email from X” feature. Most important achievement at Amazon: I made Alexa read Trump’s tweets in his own voice.¹

In mid-2019, after almost three highly productive years, I decided to do something on my own. At twenty-seven, I believed it was a good time to incur risk and that the cost of failure was not ruinous. Add to this my passion for the problem, excitement with the technology, impatience with bureaucracy, and a certain desire to make an impact. Armed with reasonable savings from my time at Amazon and an affordable, college student lifestyle, I was good to go.

Idea

How does one even pick a startup idea to work on? This is an underexplored question, and one susceptible to retrospective mythologizing. I’ll give my best attempt to reconstruct how I settled on doing QuickNews. The main things, quite far apart in time, are:

• Croatians, myself included, are notorious news fiends, and there are endless jokes about having “twenty tabs” open, with all the Croatian portals, Ctrl+tabbing through them with gusto whilst making sure the boss does not catch one in flagrante. Jokes aside, my countrymen truly are passionate news consumers, so working on problems in this space has a certain visceral appeal.
• The demise of Google Reader way back in 2013. I was an enthusiastic user and had it set up just right. After it got buried by Google, I wanted a replacement, but smarter (I hated setting up the RSS feeds). Feedly didn’t seem great.
• Recent advances in machine learning, particularly for text. I’d been doing a lot of self-study on the topic of deep learning, doing courses, reading papers and attending meetups. One of the standout concepts was word and document embeddings. You essentially map text onto vectors, with the property that semantically similar documents are close in space. I was convinced that this could be the core of an awesome recommender system, giving us a multitude of easy wins, like clustering, deduping, and similarity.
• Playing to my strengths. Having coding skills myself, at least for the back-end, it seemed possible to pull off without a large budget. It was clear that I’d need somebody else to do the landing page and app, but a substantial part of the coding could be done by me. In addition, my hunch was that it wouldn’t be expensive to host, as we’re talking about textual data, and ephemeral at that (nobody really cares about news articles from a week ago, so they’re safe to expire).
• The enormous success of Toutiao in China. This AI-powered news app, owned by ByteDance, claims 200M monthly active users, with the average user spending over seventy minutes per day on it. Though the company is more famous today for owning TikTok, the news app was actually the cash cow that enabled their acquisitive appetites.

The last point sealed the decision. I always find it soothing to see precedents of this sort, since they show you’re not crazy. However, it was important to be cognizant of the differences between the Chinese and Western markets (China not having a Facebook equivalent, for instance; the presence of super apps; or their jump from cash straight to mobile, bypassing credit cards).

Thus, while being one of the first copycats of a Chinese product in the West gave me a certain impish delight, it was clear from the onset that the approach would need to be significantly different.

Key tenets

My old boss’s boss’s … boss’s boss, Jeff Bezos, frequently orates on the importance of “working backwards from the customer”. In the case of my news app, this was a double edged sword: on the positive side, it had a target user from day one: myself; on the negative side, it had a pretty damn stubborn and opinionated user from day one: myself.

Aware that I was at risk of being overly prescriptive, I nevertheless started with a couple of tenets, but would be careful to validate them as soon as possible.

• Real time: Well, starting with a controversial one right away. I’ve never been a fan of the way that most currently extant news apps give you articles from hours ago. This is silly in today’s world of social media, where communication is real time. Hence, the initial design decision was to catch articles as close as possible to the time when they’re first published at the source.
• Zero tolerance for fake news: Squint a bit, and you’ll see that there’s quite a bit of tension between this and the preceding point. Social media, which is real-time, has the problem that anyone can publish and get amplified with no consideration given to their reputation, leading to fake news galore. On the other hand, waiting for multiple reputable sources to confirm a story leads to a time delay. It’s important to balance these two, though when there’s even a shadow of a doubt, give preference to trust.
• Bootstrappable with no other users: A key point — it is critical to provide a good experience out of the box, before we have millions of users and can do collaborative filtering. In addition, the setup should be kept to a bare minimum.
• Awesome personalization: There are billions of people of different ages, locations, mother tongues, and interests. In order for an app to be successful, it can’t have a limited offering, but needs to cater to a variety of tastes, and even more importantly, be able to adjust to the user and learn from their actions.
• Notifications as a critical feature, not a bastard child: Notifications are frequently treated as a kind of dark pattern to trick users into coming back to the app. With a news app, on the other hand, they are crucial and ignoring this part makes the app a failure. I remember the wise words of a Facebook engineer friend when we were talking about this: if the user needs to open a search engine to find information about a current event, your notification system is a failure. The penalty of getting it wrong, though, is steep: you’ll annoy the user, and get them to uninstall the app!

A crowded market? Perhaps. As were search engines in ’97. That about sums up my initial opinions on the matter. Now how to make money off of this?

Business model

Several possible business models sprang up:

• Advertising: In a business model not seen or heard since about 2012, the idea is that you run ads inside the feed and target them to specific users, getting money per impression. Good side: easy to implement, can be seamlessly inserted into the feed. Bad side: requires a massive user base, Facebook/Google duopoly. See also: this article, “Early monetization and alignment with product” section. This really does seem like the only way to monetize a free tier.
• Premium tier: Something along the lines of the user leaving a credit card and then getting charged for paywalled articles by the click, whereupon we do revenue sharing with publishers. User benefit: the user can read articles from different publishers (NY Times, Washington Post, Wall Street Journal), even if they don’t want to pay a subscription to each publisher individually. Publisher benefit: closely related — get some money from users that are not willing to pay for a full subscription.
• Sell the backend to someone with a lot of eyeballs? Do something akin to Google powering AOL’s search. Package, say, the personalization algorithms into an API, and take Apple News or even an end publisher like the New York Time or the BBC as customers.

Getting on with it

With contours of the idea formed in my head, I quit Amazon. Knowing myself, it was clear that I needed to be in this one hundred percent, lest I end up procrastinating and not accomplishing anything. The abyss of not having a paycheck affects tranquility somewhat, but is at the same time good for focus and efficiency. It went better than anticipated.

My manager on the Alexa team, with whom I had an excellent relationship, was supportive of my startup aspirations, as were all my friends and coworkers at Amazon. I guess that in the tech sector going off and doing a startup is considered a legitimate career choice, and I have a hunch that a lot of people secretly want it at some point. In any case, goodbyes were said, beers consumed, an evening at the bowling alley pleasantly passed.

Our Director’s parting thought was that he was looking forward to me boomeranging back. Comforting, but he’ll ideally be proven wrong. In any case it was time to get to work. Almost… my last few months at Amazon were extremely busy, as we were shipping all the time. In addition, knowing that I was leaving, I was anxious to finish everything I started and put in plenty of extra effort to my project across the finish line (burning the midnight oil). So a bit of rest first.

Back-end

Now came the fun part for any technical founder: building the thing itself! First the scope: as every good startup founder, I had read The Lean Startup and consider it one of my favorite books. It’s replete with Wizard of Oz examples, and with startups adhering to Y Combinator’s “Do Things That Don’t Scale” dictum. And yet I broke those rules. Why?

My initial idea was that I’d start by manually selecting the news articles that I’d present to users. The thing is, that stops scaling immediately. Furthermore, developing the infrastructure for that would not take me significantly less than developing the real deal. So a heavyish MVP… This was important to keep in mind. We would offset the complexity of the infrastructure by starting with a very limited feature set, and would put that in front of users ASAP.

Onwards to coding. Language of choice: Python (speed of development, availability of libraries). Cloud provider: AWS (intimate familiarity). Some machines on Digital Ocean (a vague desire to give money to an alternative provider). The main components to develop:

• A simple crawler (or scraper, I never know): On every run it takes a manifest with all the sites to crawl, does a pass through them and gets all the new articles. It has memoization, so it knows not to download articles multiple times. It stores batches of articles on S3.² Deployed on a cloud instance, runs as a cron job, taking approximately fifteen minutes.
• Machine learning models: We covered before that a key thing was to run the article’s text through a Doc2Vec model, and getting a vector. The other part of the model is mapping the vector to one of the clusters (this was trained with K-means).
• The main worker: This component is somewhat large and monolithic. But the gist of it is that it takes the articles caught by the crawler, does deduplication and elimination of junk and maps the articles to vectors and clusters. It then stores the relevant data for each article (metadata + vectors and clusters) into a database (DynamoDB, possible regret).
• The API server: Has methods for generating the feed based on the user’s interest profile, as well as methods to register users’ clicks and update their interests. Keep in mind that QuickNews uses the click information to adjust interests but does not keep the clicks logged, so as not to be intrusive to the user’s privacy.

Altogether, a bit of a time investment. Still, better to have a working solution with some generality. Another point: the components were awkward and hacked together rapidly, but at least they were reasonably well separated. So if need be, they could be nuked and replaced one by one. The main problem now: no front-end.

CEOing

Now things got interesting. Logistical matters first — I decided to take a two-month working vacation in Croatia. Business and pleasure indeed. I’d spend most of my time there on the island of Vis, where part of my family is from, and is known as one of the best tourist destination in that part of the Mediterranean.

That being said:

• Hanging out with my family was good for business actually. Both my father and my uncle are experienced entrepreneurs, and my mother a former executive at the Croatian national television (hence good contacts, great for getting feedback from pros).
• Hiring. The fact of the matter is that I couldn’t have afforded hiring engineers or designers in either Canada or the US. Croatia was excellent in that regard, and had amazing engineering talent. In addition, since I had gone to both high school and university there, my network was pretty strong.

Strong but imperfect, and not helped by my time as an émigré. Nevertheless, I reached out to a friend who had experience launching startups, and specifically mobile apps, to recommend people that he had worked with. After a bit of back-and-forth, I settled on a design agency to do the initial design. They had great experience and were enthusiastic about working with startups. A word of advice: when evaluating designers and front-end people, Behance is your friend.

Then a mobile developer. My friend had worked with a student from my alma mater, also named Marin³. Now I broke one of the more fundamental rules of hiring: I didn’t do a coding interview, a transgression I would have ridiculed other founders for. But for once, I was lucky, for Marin turned out exceptional: a great expert in mobile and, unusually, equally good at iOS and Android, as well as having startup projects under his belt. And in Amazon parlance, excellent “Ownership” and “Bias for action”. We ended up making a killer team.

An important point for the aspiring founder: both the designers and Marin would be working part-time. This, if not properly taken into account would lead to long development times. We “solved” this by reducing the scope — only the login, main feed, and a very basic search function.⁴

Front-end

Now a brief comment on our decision-making about the front-end. The first, easier, question was whether to go with a mobile app or a regular page? On this I had a strong opinion: mobile rather than desktop would be the main platform for our users, and everything should be optimized to give mobile users the best possible experience. Besides, at least on Android, we could iterate fast. Mobile it was.⁵

The second question gave me nightmares: iOS/Android or Flutter/React Native. I have yet to meet a single experienced mobile developer who would go on the record saying that they feel even a modicum of affinity towards Flutter/React Native, and I’d almost always hear comments along the lines of “Now your app is going to look ugly on both platforms”. But on the other hand we had the downside of duplicating work if we took the other route. We’d be deeply in “heavy MVP” territory.

We decided to go with native Android/iOS. We had considered skipping iOS, but decided against that since North America was our initial market, and there Apple’s market share hovers around 50%. We did, however, make a shrewd decision: we’d start with Android (trivial to ship, unlike iOS), get it in front of users, iterate on the feature set, and then follow up with iOS. Since then we’ve stuck to this strategy, and we iterate on Android first and observe the results. We follow up with iOS once we’re out of other feature ideas.⁶

Launch and user acquisition

Now back in Canada, I experienced something peculiar that would make Gary Vee spasm: I had no idea what to do. Marin was working on the Android app, which meant that we still had nothing to show users. At the same time, the back-end was done for the time being, and despite pending tweaks there was nothing major.

I tried to make the most of it. A clever scheme congealed: just on the corner by my old Amazon office was a café where many of my former brethren went, people I’d known from the office. I figured that I’d go work from the café, and whenever I encountered one of my old colleagues I’d say hi and give an elevator pitch. Then once we had a product, I’d start signing them up in the same way and get their feedback.

And then, with characteristic effectiveness, Marin finished the app. The first steps seemed clear enough: sign up family and friends. In addition, I persevered with the previously outlined café strategy and recruited plenty of old coworkers. The most prominent person to succumb: a VP/Distinguished Engineer on AWS and industry demigod. He graciously agreed to serve as a beta tester. I also recruited users in the meetups I attended.

The initial feedback was lackluster, to put it mildly. We tried to be clever and infer users’ preferences from their social media accounts. This produced underwhelming effects since there usually isn’t enough data to infer anything. In addition, dealing with social media accounts in today’s world is a disaster waiting to happen. So we nuked this logic and added a simple topic selection screen. The app would still learn as you go, but at least the initial profile would not be useless.

In the meantime, our design agency finished the design and the copy, for our landing page (quicknews.ai, virtually unchanged since the first iteration) and we found a developer on Upwork to do the slicing. He produced the HTML and CSS, which we summarily hosted on AWS (S3 + Cloudfront + Route53).

Retention and notifications

Most people are familiar with Dave McClure’s famous AARRR metrics: acquisition, activation, retention, referral, revenue. And for the most part, all of them are treated with similar reverence. We put a slight twist on it, for which I was to a great degree inspired by one of my skip-level managers at Amazon, a startup veteran — that retention is the critical one, especially for consumer apps, and should therefore take precedence over the others.

The view has been espoused in YC as well: a great lecture by partner Gustaf Alströmer, a former growth team lead at Airbnb, mentions retention as the best proxy for the elusive quality of product/market fit.⁷ And indeed, it’s not particularly worth focusing on acquisition before this is nailed down: you’re pouring new users into a leaky bucket. In any case, the best way to visualize retention is through the now well-known “waterfall” graphs, available in vanilla Firebase.

We focused on this with vehemence. Part of it was simply making the feed better and less random, which we achieved through the topic screen. The larger part, however, was in fact one of our core tenets: notifications. I allow myself a certain degree of smugness regarding this hunch. Indeed, notifications are the thing that brings users back to the app. But too often they’re mere annoying reminders. We threw considerable algorithmic firepower at the problem: figuring out which articles are important or breaking (enough to warrant a notification), matching them to users’ interests, figuring out what the right frequency of notifications is, as well as determining the ordering. With this, our retention increased significantly.

Startup School 2020

The next step was enrolling in Startup School, Y Combinator’s online program. This was an excellent proposition: we’d get access to the course materials, participate in group sessions with other founders, and get an opportunity to practice pitching, a good thing for any future application to an accelerator including YC proper (or pitching angels). In addition, you’re required to submit weekly updates, which pushes you to focus more on the key metrics and show progress. It’s also free and you get credits for cloud providers!

Given that our app is universally helpful, this again meant that we could recruit users amongst other founders, as well as through posting in the SUS forum. Two particularly useful resources: a list of places to post about your launch, and a lecture by YC partner Kat Mañalac. We decided to follow this rather closely, and posted to a bunch of startup directories.

We posted in a bunch of other places as well. A surprisingly effective one was a Facebook group for developers in Croatia. We also did a Hacker News launch, which got no traction. And on the same day did a Product Hunt launch which got quite a bit of traction, but we ended up not getting featured, to my surprise. A neat, if somewhat Machiavellian trick: we sent push notifications to QuickNews users inviting them to support us on Product Hunt.

All in all, a good exercise, but I wouldn’t recommend getting expectations too high for these kinds of launches.

Current state of affairs and next steps

With all these measures and a little bit of Google advertising, we were able to get to over three and a half thousand downloads. In the meantime, we’ve significantly improved our notifications for breaking news: as an example, we broke the news of Bill Gates stepping down from the Microsoft and Berkshire Hathaway boards a good ten minutes before competing apps. And we’re improving this constantly.

Apart from this, we’re experimenting with a new design, which you can glimpse above. Our idea is to have better support for topics and give users the ability to find trending articles. We’ve created a simple Mailchimp campaign so we can stay in touch with users and get their feedback. We’ll also explore ways to enable our (hopefully happy) users to evangelize and get their friends to use QuickNews. We have somewhat embarrassingly done no ASO or SEO, so that is also in the cards. In any case, stay tuned, there is much more to come…

[1] Unsupervised hackathon project, not company policy.

[2] If anything whatsoever goes wrong, I can rest assured that my brethren on S3 will get paged and resolve the problem summarily.

[3] Contrary to what you might surmise, it’s only the ~30th most common name in Croatia.

[4] Even the search shouldn’t have been in the MVP, but since I already had the back-end operational on ElasticSearch it wasn’t particularly complicated to do.

[5] For a more detailed exposition of the thinking I subscribe to, read Ben Thompson’s rhapsody from 2015.

[6] We love our iOS users, but shipping for the platform is slow.

[7] A weaker but OK one: asking “How would you feel if you had to stop using X?”. Pioneered by Superhuman.

This article appears in tough times, as the COVID-19 crises rages on. I hope everyone stays safe and follows the recommendations of medical professionals.

Thanks to Christian van der Henst for nudging me to write this post, Startup School colleague Matthew O’Brien for feedback, as well as to my family and Ivan Mandura for reading drafts. And needless to say, to all the people that worked with me on the product, primarily Marin Grbic. Errors and omissions are mine.

I occasionally tweet, so follow me for more updates of this sort. And of course, if you happen to be in need of a real-time, personalized news application with a diversity of political views, do check out QuickNews!