#startup

Randomness is a perspective

Diederik • @jdvhouten • • Part of Day 40

For many founders the whole process of building a product and bringing it to market is stressful and anxiety-inducing. Founders want confirmation that they’re on the right track. But is this a reasonable thing to want? And does it matter?

Startups are an unusual environment where you’ll succeed if you focus on the things that truly matter at the expense of everything else. Not many things in life are like that. In college, for instance, you can “cheat” by picking easy courses or by studying for the test instead of for comprehension. College is artificial and all the metrics can easily be gamed.

It’s not just college that’s artificial. Consider these occupations that never leave the make-believe world:

  • Tax advisors game metrics for a living. Government makes the tax laws and the tax industry figures out ways to skirt them. It’s an endless game of cat-and-mouse that provides no particular value to society. It’s basically a boring competitive video game where you get points according to some byzantine rule system and also the points are money.
  • Many, but not all, charities fall into this artificial category. They raise funds for causes that deserve our attention, but then what happens? Being good at fundraising and being good at making the world better are two entirely different skillsets. It shouldn’t surprise anybody that when charities optimize for their ability to tug on our heartstrings they get good at that, and only that. Charities don’t need to be good at improving outcomes in order to be considered successful, they just need to look like charities and play the part.
  • An employee in IT that works hard to keep everything running smoothly might get no credit because all the value provided is invisible. Another employee that works weekends to put out fires of his own creation gets lauded for his work ethic. You’d think that businesses, because they want to make money, actually get really good at making something people want to pay for. But you’d be wrong because a businesses isn’t a person and it doesn’t have a singular will. It’s an organization first and foremost, made up from individuals who have personal goals often at odds with the goals of the business. An established business can survive on momentum for decades, churning out low quality products with poor customer service.

Disconnects like these are the default everywhere, not the exception. I’m not making a point here about misaligned incentives. The point is that these artificial environments provide simple benchmarks for success for the people in them. At work and at school your boss/teacher will tell you what to do and whether you’re doing a good job. You might still be working on pointless projects (see Graeber’s bullshit jobs), but it doesn’t really matter, because you don’t get judged on efficacy.

From this perspective it makes total sense that people feel scared and anxious when they start a startup. They need to transition from an artificial environment to one where they have to sink or swim. The complete freedom and apparent randomness of startup life feels scary and unstructured. Nobody tells you what to do or if you’re doing a good job, and the outside feedback you get feels totally random.

Some weeks you’ll get many thank you messages. Other weeks people say mean things about you or your startup on twitter. You’ll never know what triggered the positive and negative reactions, but you can easily lose your mind trying to figure it out. We assume these fluctuations are just noise, unless we see clear contrary evidence. You want to focus on the things that matter at the expense of everything else, which means you can’t let outside forces hijack your day.

If you work every day to make your app better and if you work every day to get the word out there, what do you have to be anxious about? Traffic goes up, traffic goes down. Customers come, customers go. Competitors come and competitors go. Much of this is completely beyond your control. The process is what matters and the process is extremely simple:

Work on the product in chunks until you believe it’s good. First make the most basic solution that works. Then refine it until it’s good enough to ship. Start with the hard parts and work your way back to the easy stuff (registration, login, documentation, etc.). Work on marketing with an “all of the above strategy”. Finetuning is for later, after you have established your startup is viable.

What is under your control is the work you do, and there is nothing random about it. Luck still plays a major factor of course. You can’t know in advance how many people want the thing you’re making. Sometimes you swing and you miss. And if we keep swinging we’ll hit a homerun sooner or later. But hopefully sooner :).

PS: It’s day 40. We’re half way through! And we have 20% of an app! Oh boy.

Thinking different about technical debt

Diederik • @jdvhouten • • Part of Day 26

Technical debt is typically understood as the consequence of shortcuts programmers take to meet a deadline. At some point in the future this debt is repaid by cleaning up the code, or so the basic finance analogy goes.

Technical debt, much like debt in the real world, is not all created equal. Some types of technical debt come with a high interest rate and put serious constraints on what you can do in the future. Debt like this can easily ruin your startup. Other types of technical debt just exist, harmlessly, like a 30 year mortgage bearing a 1% interest rate.

You want to distinguish between the different kind of shortcuts you can take and the ways in which the debt can bite you. In this post I expand the use of ‘technical debt’ so all design choices that create future obligations are considered debt. You can accumulate debt to the point where you spend all day every day dealing with these obligations. You have to work longer and longer hours just to avoid drowning. Any additional setbacks and you’re going under. The financial analogy here is that you don’t want to get to the point where the majority of your income is eaten by interest payments. You won’t have a good time digging yourself out of that hole.

I categorize tech debt roughly like this:

Sloppy code debt. This can be anything from gratuitous copy-pasting to a hairball of dependencies between different parts of your stack. This is what most people think of in the context of Technical Debt. Harmless technical debt in this category is inside self-contained in edges of your architecture. Self-contained parts are easy to understand and easy to rewrite if you need to. The worst kind of debt in this category is at the core of your app. If the code you have to deal with all the time is a mess that’s going to slow you down and result in bugs.

Creative user debt. Your users will use your app in ways you don’t anticipate. Suppose you introduce a ‘tags’ feature then some users will inevitably try to add 100 or 1000 tags in places where you expected people to use at most a handful. If you’re in a hurry and don’t at least assert()[1] to put a cap on the number of tags that can be associated with a thing you’ll wake up one day to an email from a user about the app being slow. After some minutes of confusion and looking at some SQL logs you figure out what’s going on. Goodbye road map, hello long days of frantic repair work.

Not making a nice error message when a user adds to many tags? Harmless tech debt. Having the UI glitch when there are a silly amount of tags? That’s fine, too. Having servers melt down because you didn’t spend 10 seconds to enforce limits? Not worth it.

Package dependency debt. Software you write today will stop working sooner or later, and often much sooner than you’d think. Sometimes people call this bit-rot, as if software suffers from biological degradation. It doesn’t, of course, but the environments we write software for change and that amounts to the same thing. Server-side packages get patched for security updates, as does the OS itself. On the client browsers change and break your code.

When your app is large and has many dependencies this kind of debt isn’t just a chore to deal with. It can actually become a real problem, especially when you’re forced into version upgrades in order to get those security patches. It gets even worse when you compile your own packages or deviate from the packages that come with your OS. Have your app depend on 250 packages? That’s easy. Monitoring 250 packages for security vulnerabilities? Practically impossible.

To mitigate this we think it’s best to roll your own solution instead of adding dependencies to your app, whenever possible. It’s more work up front, but your code will solve exactly the right problem and once it’s done it will continue to work with minimal maintenance.

3rd party integrations. All integrations with 3rd party services create debt and debt of this kind is always bad. Every integration you make with a 3rd party is going to break, and probably at the most inconvenient time. There is a time for caveats, but this isn’t one of those times. Any 3rd party you depend on is either (slowly) going out of business or they’re growing so quickly that they have growing pains and need to make breaking changes to cope. In the past we’ve built integrations with Slack, Twitter, Google Maps, Google Analytics, Google Workspace né Google Suite né Google Apps, MS Active Directory and more. They have all completely broken down, at some point or another. The ongoing cost of integration maintenance is real and not to be underestimated.

Overengineering debt. When you overengineer you make something stronger than it needs to be. When you under-engineer you make something that you expect will collapse sooner rather than later. This might sound bad, but it isn’t. You can’t predict where the bottlenecks in your architecture will be in advance, especially in the face of exponentially growing traffic. Exceptions notwithstanding, the simplest pieces of architecture are the easiest to diagnose and improve.

dis GIF

If we have to choose between having extra package dependencies (debt of itself) and a brittle 100 line Python script we’ll go with the Python script every time. Sometimes the hacky solution keeps working for years with zero issues. Using your SQL database as a message queue? It’s not pretty and it requires polling, but it’ll work and your customers won’t know the difference. Do you want to wake up a script? Polling a file’s atime or sending a SIGUSR signal is no crime. Customizations for customers? You can hardcode them. It’s fine.

Feature debt. Sometimes features turn out bad and confusing. If at all possible, you want to get rid of those features right away. When you’ve just launched you can still delete a feature without notice. Once you have paying customers removing features from your product becomes a far more delicate matter. Sometimes two features are fundamentally incompatible, and by introducing one feature you can’t introduce another. For instance, if you promise end-to-end encryption you can’t also offer server-side search functionality (the inverse is also true). Once you realize your mistake you have to fork your code and you’ll end up with customers on both forks.

Make this mistake 5 times and you’ll struggle to keep the different versions of your product apart. This will slow your development efforts down to a crawl. Every feature has a recurring cost to it, in maintenance and in the space it takes up in the user interface, so you can’t afford to add features haphazardly.

Customer support debt: when you build a feature in a rush and don’t spend enough time making the interface intuitive you’ll also pay a price in customer support. This debt isn’t so bad because the cost of the fix doesn’t increase over time. However, if you find yourself repeatedly answering the same questions that’s a problem. Either make the feature good and self-explanatory or only enable it for a handful of users. If you allow poorly conceived features to accumulate you’re not just creating a lot of support work for yourself, you also alienate your users. A backlog of support tickets can also be considered a type of debt.

Every startup accumulates some technical debt. This is inevitable, and it’s not even a bad thing. When you start out you don’t know exactly what you’re making. By writing and rewriting your app your figure out what works. No point in creating beautiful code if you’re likely to rip it out in a week or two anyway.

Besides, before you have any users technical debt isn’t real. Anything can be fixed with the delete key at this early stage. The more users (or worse, customers!) you have the harder it gets to keep debt at a manageable level. Database migrations must now be planned carefully. Removing features becomes difficult or near impossible. 3rd party integrations break and will hijack your development schedule. Security updates and other maintenance work will slowly eat up a larger and larger percentage of your week. You can’t let these factors spiral out of control.

If at all possible, make the core of your app rock solid before you start charging people money. That way you can continue building on a solid foundation with little tech debt. If this means building a much smaller app, so be it. Smaller is better. You want few dependencies and few moving parts. Knowing exactly which corners to cut and which parts to rewrite until they’re just right is very, very hard. We still get it wrong all the time.

[1] Asserts abort a program when a condition isn’t met. The user gets a “server error” message and the programmer gets an automated email that a specific edge case has been hit. By adding many asserts throughout your code that check whether your data and inputs look correct you’ll save yourself days and weeks of debugging time.

It’s not 0 or 1

Wim • @wcools • • Part of Day 18

It seems binary thinking is not prevalent in just tech founders but when starting a business in general. Often people seem to think something needs to be done perfectly, or it isn’t possible. If that’s reason not to pursue your dream of building a product/business, that’s a shame because you can slowly work your way from 0 to 1.

All at once

At every stage in the business, you’ll deal with other issues and challenges. It’s okay to learn while doing and deal with them as they occur, otherwise it would become impossible to start. Thinking you have to do everything all at once means you can’t really start with anything.

In the beginning you don’t know yet whether anything you’re about to do will really matter. That’s when it’s best to worry about “bad problems”. That’s not a pleonasm, because there are “good problems” too. A bad problem would be not having any customers yet. Focus on that. A good problem is having so many customers that you can’t handle support anymore.

Spending time on fixing good problems you don’t have yet is a waste because it might never have been needed in the first place. Plus you won’t really understand yet what the best way to handle it is until later.

All in

Starting a business doesn’t mean you need to drop everything else. We started building our first software business when we were students. We did freelancing and work for university on the side. Admittedly it was a very busy time, and we promised ourselves to switch to full-time as soon as we financially could, but we managed to grow to our first product in this way and become ramen profitable. 

Going all-in when it’s an option is great, but sometimes the timing isn’t right and starting up on the side is totally possible. See if you can get a first customer, then scale it up. 

Doing less

Some things which need attention can also be fixed with a duct tape solution, and then revisit them later when it becomes really painful. For our first app we didn’t even have a password reset option. People had to email us and then we’d reset it for them, manually. We just didn’t have the time, and if we would end up with 0 customers it would have been a waste of time to invest in. 

Technical founders also like to set up their perfect environment and tech stack. Kubernetes, CI/CD, Docker, Microservices, the list goes on and on. It’s all a waste of time if you don’t have a product with customers yet, and you just won’t need it. Duct-tape it together with whatever means necessary for now (that actually sounds worse than it is, I like to think of it as just going for a simple and elegant solution). Worst case it takes off and you get to improve it while being paid for it.

Copying the big league 

Because big businesses are more visible, their approach sometimes seems like the only way to do anything. But just like when they were small, many of the challenges they have are not relevant to you.

Just because Netflix has servers all over the world doesn’t mean you can’t run your entire business from a single computer under your desk. Focus on getting some customers first. You don’t need to worry about a few minutes downtime yet (if you have any people noticing at all then that’s a Good Problem).

Just because Google is tracking the usage across their apps and A/B tests everything doesn’t mean you even have the numbers to make any of that relevant. Just get feedback on your product first.

As a founder you can (and have to, initially) do everything yourself. You are the sales department, the financial department, the technical department, the support department. Customers are not going to mind if you provide a good service. Besides, from which company you recently dealt with did you get a personal note from the CEO when you had a question. How amazing is that in terms of support?

Lots of founder also seem to worry about all kinds of legal paperwork being so complicated they don’t get started, and overestimate the problems they will get exposed to. You are not going to have the same responsibilities and issues as Amazon. Many exemptions apply to small businesses in the first place, but even the big players don’t have everything perfectly set up. Lots of things you can do yourself. For example, the entire GDPR framework is explained on a website which you can read in a day, problem solved. You don’t need expensive consultants for that. Same for accounting, just go with something simple or do it yourself for now.

Get building and find those first customers!

Everything is Power Law

Wim • @wcools • • Part of Day 16

How and where do you begin? If you’re justing getting started, the very beginning of the entrepreneurial journey seems the hardest. Those who have success have revenue numbers which seem out of reach, a follower count you can only dream of, and they seem to be everywhere.

The way I like to look at this is by acknowledging that Power Law is all around us. Probably 99/100 people reading this already heard it all before, but basically a power law describes a relationship between two quantities y and x such that y(x) = x ^ some power. When you plot a power law distribution it looks like this:

Another example of a power law relationship is the Pareto principle, or 80/20 rule, where 80% of the result is caused by 20% of cases. That’s the head of the graph. All the rest is in the long tail. You could put it even more bluntly and call it “winner takes all”.

It’s everywhere, in nature, life and business. From the distribution of crater sizes, the amount of food animals of a certain size need, the distribution of wealth across a society, pandemics.

Although you might want to call it the 99/1 rule instead. Inflation, a sign of the times.

So back to the beginning. What does this have to do with starting a business? Because so much in business follows this power law, looking at it in terms of power laws makes it simpler to understand why it seems difficult to start, and why success is in fact possible, and why certain routes are harder.

Audience, followers and marketing

For example, when looking at an existing large audience an established company has, it seems impossible to get there. You start out with 0 followers. Then finally you get your first follower or signup for your newsletter. Then finally another one, maybe 4 more. This will take forever! You’re at the end of the tail, and everything looks flat from here.

But. Power law! We see the same relationship in network effects, such as building communities, an audience or a following [1]. The value of a network goes up with the number of participants squared. So next time you send something to your followers, some in the network might notice it. Before you know it, people start sharing your content with some of their followers or friends. Slow at first, but the pace of new followers will pick up.

The important lesson here is to keep going. You shouldn’t look at the slow growth as it not working out, rather you are in the tail. This is the part where you shout in the void, and need to trust that it’s working. The network effect and power law are real. Similarly, you shouldn’t look at some other products following of 100K as unattainable, but rather see it as doubling only 16 times (of course it takes work, but that’s not impossible at all).

Content and thought leadership

The same applies to writing content and sharing ideas.

  • 99% of all content is created by 1% of people
  • 99% of the public debate is determined by 1% of the people (because they publish).

It looks like there is a lot of content out there, but related to the enormous size of the internet, there is almost none. That makes it way easier to have an impact on opinions, debates and establish yourself as a brand in a field you’re interested in.

  • 99% of all traffic will come from 1% of your posts
  • only 1% of all total views for your content will occur at the beginning

Almost nobody reads any of your content at the beginning, and that’s normal and expected. It’s important to keep publishing because you need the numbers to get to that 1% post which will do well (and make the rest of the content work you did compound).

Launches, internet points and product-market fit

Just to name some well-known examples to many startup founders: 1% of launches on ProductHunt will get 99% of votes, only 1% posts of Hacker News will get any traction at all. When a submission to one of those sites gets traction, the long tail of upvotes will just be a handful. You need to get to the 20/80 inflection point of the graph where suddenly it takes off and starts collecting all the other votes.

Having a great post or product is completely necessary to do that, of course. But the difference between 1000 upvotes and 1 upvote is not 1000x. It’s a few votes at the beginning, after which you’ll get the 99% of other votes. Again, good to realize this and not get discouraged and take one launch of a feature or product which failed to get traction as evidence that the entire concept is flawed.

The same goes for product-market fit. It’s a lot of long tail small changes which can suddenly bring you to the 80/20 inflection point where things really take off. Once things grow really quickly, you haven’t put in 1000x times the work, but a few doublings in the tail (which are just small numbers) brought you to this moment. From there on, everything goes quickly (feedback, revenue, press, and so on).

Competition

You will only have heard of a few big players (1%) in the market. They seem to be everywhere, but in fact there’s an entire long tail of businesses which have customers! Depending on the market, that long tail can be very lucrative. If you want to build a nice lifestyle business, don’t overlook big markets because there are a few large players. Build in the niches of the long tail.

Looking to become a big player in the field yourself, but see a lot of players? Only 1% of those will become really big, so if you’re willing to go for it, there’s less competition than you think.

Customers, support, reviews and pricing

Let’s end with a few more:

  • 1% of your customers will be your biggest fans and spread the word. That’s why your MVP needs to focus on getting those!
  • 99% of support is going to come from 1% customers. Don’t be afraid to “fire” them if it becomes unreasonable.
  • Likewise, most revenue is going to come from a few customers and few price plans. Make sure your pricing plans follow the power law, and allow customers who see a lot of value to subscribe to a high pricing plan!
  • There will be features which are only used by 1% of customers. Likewise, the vast majority of customers will only use a few core features. The long tail of customers which those extra features bring in will be relevant over time, but no need to launch with those.

[1] Slightly related to the topic of audiences, I like this TED talk by Derek Sivers about starting a movement (https://www.youtube.com/watch?v=V74AxCqOTvg). I just watched it again, and without measuring the exact seconds, I’m pretty sure the number of people dancing along follows a power law.

A paradox of course correction

Diederik • @jdvhouten • • Part of Day 16

The perfectionist needs to be told to ship faster. Because not shipping or having exhausted yourself by the time you launch is fatal. There is a critical difference between polish and wasteful perfectionism. Polished is an app that looks good and works well. Perfectionism is refusing to launch until every single bug is fixed, rewriting and refactoring backend and frontend code just to make it look nicer or cleaner. It’s wasteful work because large parts of your app and infrastructure will get rewritten anyway. Why seek perfection in something you’ll inevitably tear down?

The hustler needs to be told that making a really good product takes time so just sit down and do the work. Because you can’t grow a product startup if you don’t have a good product[1]. The engineer needs to accept that if nobody knows your product exists you won’t have any customers. If nobody knows what you’re building you won’t get any feedback. Having to face zero signups after spending a year on your beta is so demoralizing you’ll likely give up.

The spendthrift needs to stop squandering money. It’s the runway[2] you spend. Everything takes longer than you think and many startups fail simply because they run out of money. The miser should try to be less cheap. Sometimes you have to spend money to push your startup forward[3].

These are just some examples, but I think you get the idea.

In order to survive you want to embrace conventional and boring choices in some areas, because conventional choices aren’t terminal mistakes by definition. That leaves you with unconventional bold choices in those areas where you want your startup to stand out. Founders tend to be unconventional people, but it’s hard to be only moderately and selectively contrarian. That’s a problem because being contrarian and wrong can easily kill your startup.

People who are at one extreme need to shoot for the other extreme in order adjust their behavior enough and end up somewhere in the middle. 10% adjustments don’t cut it when your initial position is completely wrong. Your position is wrong because you are predisposed to believe facts that reaffirm your beliefs. To counteract your blind spots try to overshoot your goal and you’ll end up closer to the middle, where you want to be. This is counter-intuitive!

When you already have a reasonable middle position on any of these issues the advice you read and act on doesn’t affect you much. After all, it’s the big mistakes in startups that kill you. If you can survive until you reach product/market fit (= awesome product and accelerating growth) you’ll be fine even if you get all the small stuff wrong. You just need to avoid the terminal mistakes. Tautological, I know, but still easy to forget.

That’s the paradox of course correction[4]: when you at the one extreme aim for the opposite extreme to end up in a moderate position. If you’re an engineer with an inclination to do zero marketing, try to overdo your marketing and maybe you’ll do barely enough.

[1] You can build a different kind of business, e.g. where you provide some kind of B2B service manually that you’ll automate later, after establishing a market need.

[2] Your runway is the time you have before you run out of money. The sooner you can cover your living expenses the better.

[3] We’re pretty bad at this, admittedly, and have a tendency to reinvent the wheel..

[4] If this is a known concept I don’t what it’s called.

Build one to throw away

Diederik • @jdvhouten • • Part of Day 12

Any time you try something new you don’t know how it will turn out. And your first attempt at anything won’t be very good. You don’t have to feel bad about this. It’s just how it is. If you know in advance that something will turn out great you’re probably working on something too easy.

With the knowledge that it’s counterproductive to pursue quality prematurely, you are now free to focus on something else: discovery. Be curious. Be open minded. Build something wacky. Experiment freely.

If all good design is redesign and all good work is rework then you have already decided you’re going to throw your prototypes out. This means you don’t need to worry about having to scale to a million users. You don’t have to worry about having “the best” architecture. You don’t have to worry about every pixel being in the perfect place. Take shortcuts. Stub out what you can. Copy-paste freely. It doesn’t matter.

You’re free. You’re free to work directly on your core innovation. That thing that makes your app interesting and unique. The less code you have the easier it is to move things around, delete, and rewrite. It’s at this time that you can hone in on what works and learn what doesn’t. It’s this phase of experimentation that will determine whether you’ll have mediocre or exceptional product/market fit down the road.

Spending extra time in this exploratory phase doesn’t guarantee you’ll get a good outcome, but it helps for sure. Knowing it’s futile to pursue perfection in means you can take ugly shortcuts with a clean conscience.

Of course, in the long term you do want quality. Of course you want to make a product you can be proud of. But in order to get there you’ll need to experiment.

That’s where we’re at for the time being. We want to figure out what works. We have a couple of ideas that we want to explore. Does it make sense to use a text editor for everything? Do we want our app to be offline-first and collaborative at the same time? Are we on the right track? I don’t know. Nobody knows.

We build and throw away. Build some more and throw away. With our 80 day deadline inching closer it’s difficult to resist the temptation to rush forward. To start building the app for real. But we can’t. Not yet. First we prototype. Then we build the MVP. Then hopefully we’ll end up with an MVP that sparks joy.

Choosing the hard path

Diederik • @jdvhouten • • Part of Day 8

Often people rush to get their product out the door. From idea to customers in a week. Although that might sound appealing at first glance, there is a big downside: it limits your startup ideas to those that are very easy to build. You can’t do any cool tech in a week, nor in a month. Good software takes 10 years, as the classic essay goes.

Any time you create an MVP there are two outcomes. Either it turns out your idea has some legs and you continue building. Or you discover that your idea was no good. This means your MVP can’t just be a couple of screenshots or a splash page. You might use that to drum up some initial interest, but it can’t tell you whether your product will be any good. For that you need to make the thing and see if people want to use it.

And if you can make the core of your product, at least enough for it to be usable, in a week (or two) then other people can as well. It means there can’t be any real tech beating at the heart of it. The startup has to be about something else. Perhaps it’s some kind of #nocode tool that links together a couple of services. Nothing wrong with concepts like that, but if you can get your startup off the ground without having to build any tech innovation then it’s not going to be a tech startup and you won’t have a corresponding competitive technical advantage. More importantly, we enjoy coding and simply want to have a startup where the technical quality of the product matters.

We’re giving ourselves closer to 4 months (80 days is 16 weeks) to build our MVP, for an idea that is as conceptually simple as it gets. We want to build something in this productivity space that hasn’t been done before. We have some rough ideas, but we can’t know yet if we can turn it into a cohesive whole. That means prototyping, and sketching, and more prototyping until we have something that we think is original, visually distinctive, and shows real promise.

Now that we’re more than a week into our startup it’s becoming evident that even if we scrap everything that’s non-essential there is still a lot left to do. We’re thinking of building our own editor environment from scratch, with real-time multiuser support, and all sorts of synchronization logic. Extensibility? Maybe. In any case, there are many design decisions to make.

We’re doing #buildinpublic because it puts us out of our comfort zone. It’s easy to adopt a “it’s done when it’s done” philosophy, but that isn’t wise. An 80-day deadline forces us to focus and hopefully that will result in us making better product decisions. It’s a tight deadline, but not impossible.

Let’s see if we can build some substantial tech in 80 days. We’re choosing the hard path and we’ll find out soon enough.