How to deploy side projects as web services for free

In 2020, the web is still the most accessible permission-less platform. For the past few months, I have been playing and building side-projects to simplify my life. I started with a Calendar Bot for scheduling events, DeckSaver for downloading decks from Docsend, AutoSnoozer for email management, and StayInTouch for maintaining follow-ups.

When I started on this journey, I had the following in my mind.

  1. Cost of domain ~ 12$ a year or 1$ a month
  2. Cost of a VM ~ 10$ a month

Read More

Docker 101: A basic web-server displaying hello world

A basic webserver

Docker containers are small OS images in themselves which one can deploy and run without worrying about dependencies or interoperability. All the dependencies are packed in the same container file. And the docker runtime takes care of the interoperability. You are not tied to using a single language or framework. You can write code in Python, Go, Java, Node.js, or any of your favorite languages and pack it in a container.

Consider a simple example of a Go-based webserver

Read More

Keep your dotfiles bug-free with Continuous Integration

Update: As of April 2020, I have switched over to GitHub Actions. Travis CI has become buggy and flaky over time and I got tired of trying to keep the builds green. My GitHub action scripts can be seen here.

Just like many software engineers, I maintain my config files for GNU/Linux and Mac OS in a git repository. Given that, I wrote a fair bit of them in interpreted code, notably, Bash, it is a bit hard to ensure that it is bug-free. The other problem I face is that packages on homebrew, the Mac OS package manager becomes obsolete and gets deleted from time to time.

I added CI testing on Travis CI to prevent these breakages and to ensure that my dotfiles are always in good shape for installation. The great thing about Travis CI is that it is entirely free for open-source repositories even for testing on Mac OS containers.

Read More

A short guide for MBAs looking for a job in the tech world

Why Tech

In the past decade, interest among MBA grads towards tech companies has drastically gone up. If you are one of those, take a pause and ask yourself “why”. Of course, there are upsides; the tech sector is growing faster, pays well, has a much better work-life balance than finance, private equity, or consulting. But at the same time, do remember that you spend almost 50% of your waking hours at your workplace, so you must as well enjoy it. If you enjoy flashy presentations, regular travel, or an opportunity to think about big M&A deals, then these things come much earlier in your career on the east coast than that on the west.

Why Product Manager

Product Manager is the dominant choice for an MBA grad. That does not mean this is the only possible role. Anecdotally speaking, getting into a PM role at Google is harder than a Software Engineering role. And if you are an international student looking for visa sponsorships, then some tech companies are not willing to do that for the PM role. Lastly, if you are not from the Computer Science/Electrical Engineering background, it is harder to get shortlisted and clear interviews. My goal is not to discourage you from applying but make your expectations realistic.

Beyond Product Manager

Facebook, Google, Apple/Amazon, Netflix (FANG), and Microsoft are big businesses. They deal with a wide range of functions such as real estate to supply chain to short-term/long-term cash management. There are all sorts of finance-world equivalent roles beyond the PM role. I won’t be surprised if Google pays more in real-estate rents than say, WeWork. All big companies engage in regular M&A as well and have a full-time team staffed for that. Cisco, Apple, and Google, in particular, are known for M&A. Also, many companies have roles like Product Strategy and Product Marketing Manager. These roles are similar to Product Manager but attract much less attention since these titles do not look as coveted as the Product Manager. You can use these roles to get in and then can transition to a Product Manager role later.

Beyond tech companies, many venture firms, both domestic and foreign (like Rauketen and Softbank), invest in US tech startups. And for that, they hire analysts, principal, and associates. The job responsibilities range from scouting to deciding on the deals.

Does company size matter?

I like quantifying companies in three stages – stage 1 (pre-product market fit), stage 2 (post-product market fit, growth stage), and stage 3 (mature companies like FANGs). Do note that in a big company like one of the FANGs, you will find products that are in stage 1, stage 2, or stage 3.

If you need visa sponsorships and have loans to pay, then stay away from stage 1 companies. The risk-reward ratio is more skewed towards risk here. If this succeeds, even a small acquisition can net you a million-dollar or two easily.

In a stage 2 company, the likelihood of broad responsibility is higher. You could be doing inside sales one day and scouting for a new office lease the other. If you are willing to take the risk, then the long-term financial rewards are much higher here. If you need visa sponsorship, then you should join a stage 2 company with a non-US office as well. So, in case you don’t get H1-B before your OPT expires, the company can move you to one of the international offices. Confirm this after getting the offer letter and before signing it. Some companies like GitLab have a strong remote culture; this can be extra beneficial to someone concerned about the visa sponsorship issues.

In a stage 3 company, your role is going to be much more structured, narrow, and focused. The company won’t die overnight and would likely have international offices to move you to in case the visa situation does not work out. One caveat for those looking to apply for permanent residence (green card), join a company that did not do layoffs recently and is not planning to do in the next year. If a layoff happens, then the permanent residence applications from that employer are usually rejected by the USCIS.

B2B, B2C, and marketplaces

B2C, Business-to-consumer startups, in their pure form, was thriving in the valley till about 2015. The users have swayed away from installing new apps, and more prominent companies have become good at making the whole startup a feature in their product. So, in 2019, software-only B2C exists, primarily, inside FANG and Snap. Two exciting classes have emerged beyond software-only B2C. One is prosumer (professional consumer) companies like recently-IPOed like Slack and startups like Savvy. The other exciting direction is the D2C, direct-to-consumer, startups like allbirds, and brandless.com. D2C, in my opinion, requires a lot of operations and marketing experience. I notice more B2C startups focused on India, Latin America, and China than the USA these days.

B2B, business-to-business, are all in rage today. From Google cloud/Azure to small companies like Narmi, a lot of companies are capitalizing and building products for other businesses. While B2C is about understanding consumer psychology, B2B is about understanding the needs of another business.

Two-sided marketplaces are hard to grow. Most of them, in the US, are trying to build pieces of Craigslist, and some are doing well.

How to apply

Don’t apply directly for an off-campus opportunity. Go via a referral. The referral route ensures that you will get a response, even if it is a rejection. Most of the time, direct applicants never get a response. And you don’t need to find someone you know. You need to find someone willing to spend 5 minutes submitting your resume internally. Culturally, it is not frowned upon to provide referrals for acquaintances. And if you get hired, the person referring you will make a referral fee, which is usually a few 1000$.

Where to find stage 1 and stage 2 jobs

  1. Angel List
  2. Breakout list
  3. Y Combinator startups
  4. Hacker News’s who is hiring threads and a bit more readable version

Closeum – closed-source in disguise

Earlier, the Software world was rigidly divided between closed and open-source software. Microsoft Windows is closed-source, GNU/Linux is open-source. Microsoft Office and Lotus Notes are closed-source, LibreOffice is open-source. Turbo C++ is closed-source, and GCC is open-source.

But now, a new class of software products has emerged whose core is open-source, but still, the open-source software is of limited use. One model is to offer some critical and useful functionality in a closed-source layer via a managed service in AWS/GCP/Azure, for example, Redis is open-source, but useful modules on top of it are not. Another model is to use licensing gimmickry, for example, MongoDB is licensed under SSPL which requires that if anyone offers MongoDB as a service, then the source code of the full service must be published under this license. The third approach is to make the core software open-source but make it dependent on closed-source cloud services. For example, the node package manager (npm) is open-source, but a closed source company owns the default npm registry. Android is open-source, but most day-to-day application ranging from Google Maps to Google Music are closed-source. Now onwards, rather than calling such software open-source, we should call them closeum.

Startup founders: How not to write an email

Consider this email,

And now consider this one,

Hi Ashish,

You signed up for the Orchard beta not too long ago, and we’re excited to finally send you an invite!

(Just to jog your memory, Orchard helps you make the most of your relationships, keeping you up to date on where you’re spending your time and who you need to catch up with. It’s somewhere between a personal CRM and a todo list for your connections.) [Emphasis mine]

You should receive an invite from Apple’s Testflight service in the next few minutes. It will contain a code or link you need to install the app. You’ll also need to have the TestFlight app installed on your phone. If you need us to send the invite to a different email address, just reply to this message and let us know.

Once you’ve checked out the app, please send us your feedback — this is a beta and we need your help to improve! Be honest, frank, and opinionated: you won’t hurt our feelings. Bugs, ideas, concerns, etc all fair game. You can reply to me or send to team@orchard.ai.

Thank you!

Brian and the entire Orchard team

brian@orchard.ai

Which one do you think your early adopters have a higher likelihood of understanding and responding to?
Don’t forget while you might live and breathe your startup, your early adopters have probably signed up to try several such services, and unless you remind them what your product is about, they might as well delete the email and move on.

Server vs mobile development: Where the code runs matter

When the code runs on your servers, you have much more control over the “context” in which it runs. On the mobile devices, the device OS and the user control the context. This difference leads to some subtle implications.

One significant set of differences comes from the lack of control of the platform. For server-side code, one can choose from a wide array of languages. For the mobile code, however, the best choice would almost always be the one dictated by the platform – Java/Kotlin on Android and  Objective-C/Swift on iOS. Further, for the server-side where one can stick to a particular version of the language. In the case of mobile, the platform controls the language version. Same goes regarding the hardware choices – one can choose to use different types of server machines specialized in handling those jobs, eg. GPUs for math-intensive computes. While for the mobile-code, one had to write a good enough fallback to support a wide-enough set the devices. Similarly, the server-side has to rarely worry about the server killing a running process while it is normal for mobile OSes to kill backgrounded processes eventually.

The other set of differences comes from the temporary changes to the platform introduced by the carrier and the user. A network request running on mobile has to be robust enough to deal with intermittent broken connectivity to outright unavailability of a data connection, e.g., due to the user switching to the airplane mode. On mobile, network type matters as well. A network request on cellular would usually cost more than a network request on Wi-Fi to the user and a network request on roaming even more. On mobile, the code has to be aware of not doing unnecessary work when the user is low on battery. Server-side code is rarely subjected to such constraints.

Lastly, it is possible to parallelize and speed up the server-side code by adding more resources like RAM or better CPUs. If a certain number of servers are not enough, you can add more. There isn’t usually a way to offload compute-intensive or memory-intensive work off of the mobile devices without trading it off for network latency and sometimes, user’s privacy as well. While it might be preferable to go with a multi-processing approach in the server code to avoid concurrency issues, on the mobile, however, multi-threading being more straightforward and less resource-intensive is almost always the choice.

Apple vs Google: Naming of flagship Android vs iPhone

iPhone

  1. iPhone
  2. iPhone 3G -> iPhone 3GS
  3. iPhone 4 -> iPhone 4S
  4. iPhone 5 -> iPhone 5S
  5. iPhone 6 -> iPhone 6S (and plus sizes)
  6. iPhone 7 (and plus sizes)

Android

  1. Nexus One
  2. Nexus S
  3. Galaxy Nexus
  4. Nexus 4
  5. Nexus 5
  6. Nexus 6
  7. Nexus 5X & Nexus 6P
  8. Pixel & Pixel XL

While iPhone is recognized as a global name while erstwhile Nexus and now, Pixel has almost no branding outside of the Android fanboys.

Further on Google’s naming snafu:

  1. Nexus 7, Nexus 10, and Nexus 9 are tablets. 7 & 10 were launched with 4 and 9 was launched later.
  2. Pixel brand was originally used for Chromebook Pixel.
  3. Nexus 5X and Nexus 6P were new versions of Nexus 5 and Nexus 6, respectively. It seems like the two teams couldn’t agree on a single suffix letter.

Consumer Internet: why audio can’t be as big as text, photos, and videos

Bandwidth of different senses

The bandwidth of different senses

 

Our brain loves distractions, and multi-tasking gets bored quickly. When we read text or watch a photo, it engages us visually, a video (with audio) engages us even more. The bandwidth of eyes is much larger than the bandwidth of our ears. When we are watching something, it utilizes more bandwidth and hence occupies more of our attention span. Also, given the way our eyes work, we can focus more on the exciting aspect of the visual feed. Compared to that, audio underutilizes our brain’s bandwidth. Further, the unidimensional flow of audio data at a linear speed does not mimic our ability to process it. Contrast forced direct listening with how non-linearly humans read.

How eyes jump forward and backward while reading

How eyes jump forward and backward while reading

And that’s why video games are even more engaging than video. They utilize the bandwidth even further by forcing us to think and act in the game.

Since audio underutilizes our brain’s bandwidth, it leaves spare bandwidth for distractions, including eating food, driving, and exercising. No wonder most audio consumption is passive and happens as a secondary activity as opposed to being a mainstream activity like reading or watching movies.

When aggregation works and when it doesn’t

All consumer internet products are either about consumption, production or both. A blog site is primarily about consumption. A photo transforming app is primarily about production. Social networks are consumption heavy. Good Messaging apps are symmetric. And a grievance collection product like BBB is production heavy.

Building aggregation on top of similar products is a well-known strategy.  The hard realization to note is that it can succeed only in very specific scenarios. Look at all the successful aggregation products, travel booking sites, news aggregators, RSS readers, discount coupon aggregators. As opposed to that, attempts to write an email aggregator, a social media aggregator etc. have not been as successful. And that’s the underlying theme, aggregator works well for consumption only interfaces where the product is sourced from many sources (more the better) and  is standardized in the eyes of the consumer. They have limited success almost everywhere else. And this just doesn’t apply to software products. Microsoft tried and failed to have their own hardware stores since their offerings were similar and a subset of BestBuy whereas Apple succeeded in the same strategy despite the naysayers.

Subscribe For Latest Updates

Signup for our newsletter and get member-only articles