I’ve been running ReviewNB as a bootstrapped business since 2018 & have also heard hundreds of stories of other successful bootstrapped products in the past few years. In this post, I’m going to highlight some common themes that seem to work well for bootstrapped companies.
The ideas in this post are mainly applicable for,
- Software products built by technical founders
- Where the goal is to quickly get to $10k+ MRR & then grow over time to several million in ARR
- This is not a good advice if you intend to build a unicorn. That’d require a different playbook.
Okay, let’s dive in.
Build on a platform / ecosystem
If this is your first business & assuming you’ve limited resources then building on an existing platform can be a blessing. These can be more formally defined platforms like Shopify, Salesforce, GitHub, Slack, Heroku, iOS App Store etc. But it can also be a popular platform (say Amazon, Etsy) that does not formally define integration hooks.
Continue reading “How to evaluate bootstrapped business idea” →
People with desk job spend half of their waking life tied to a desk. Yet most are NOT deliberate about their office setup. Today I’m going to talk about one of my favourite topics; how to setup your home office (or office office) so it’s better for your body and productivity. I will cover standing desks, monitors, mounts, docking station, chairs etc. The information is applicable universally but for folks in India, I’ll share my favourite brands/models/vendors and prices as well.
Continue reading “Ergonomic Office Setup” →
Disclaimer: All opinions are personal.
I have been running my bootstrapped venture over a year now & previously been on a startup team that went from angel-seed-series A. Having seen both the sides closely I have some thoughts to share. I’m writing mainly to solidify my own thoughts but you might find it a fun/useful read.
tl;dr – Both sides of the camp over glamorize their approach (yeah bootstrappers too), while in fact they both have pros and cons and really serve different purposes. Good news is, it’s one of the easier decisions in your journey. It ultimately depends on founder’s goal, personality & nature of the problem to some extent.
Continue reading “Bootstrap or VC” →
If you are not familiar with ReviewNB, you might want to check that out first. It’s a tool that lets your team review Jupyter Notebook changes & enables collaborative workflows with it.
Today, I’m excited to announce commenting feature for all the ReviewNB users. Here’s everything you can do with it,
Continue reading “How to review Jupyter Notebook changes?” →
I’m excited to announce ReviewNB, a tool that helps you version control & code review Jupyter Notebooks.
Jupyter is great for data exploration but it’s hard to go beyond that & do any kind of collaborative work with it. Following challenges exist in using Jupyter Notebooks with modern version control system like Git,
- Notebook diffs are hard to read. Hence we can’t do code reviews on GitHub
- Merging in remote changes is hard due to JSON format of Notebook files (.ipynb)
- No easy way to share feedback & have discussion around Notebooks
- It’s not easy to reproduce Notebook results
- It’s not easy to test notebook code cells
Continue reading “Introducing ReviewNB: Visual Diff for Jupyter Notebooks” →
UPDATE: I built a tool to solve some of the challenges mentioned in the post. It’s now live at https://www.reviewnb.com/
A lot of people, including me, love Jupyter Notebooks. It’s a fantastic tool for data science. Today I’m not going to talk about it’s amazing capabilities but rather how it fails at two important things: Version Control and Reproducibility. I will also outline the current state-of-the-art to solve these problems. It’s a useful read if you are a Jupyter user. Let’s jump right in.
Continue reading “Challenges with Jupyter Notebook” →
Companies that care about uptime generally use pager duty & have an on-call rotation. Instructions to handle common incidents are maintained on internal documents called runbooks. These are written in plain English & typically maintained on an internal wiki. First, let’s see some challenges with current form of runbooks:
- You need to manually execute each step, no automation
- It’s quite an effort to get everybody onboard to keep the runbooks up to date
- Unless well written, there can be ambiguity/confusion in following instructions
To tackle some of these problems I am proposing a use of novel data science tool, Jupyter Notebooks. Notebooks are a unique combination of markdown text, executable code, and output all within a single document served in a browser. This combination of features fits the runbook need very well. Let’s see with an actual example. Here’s a before & after picture of simple Gitlab runbook converted into Jupyter Notebook. (kudos to Gitlab for making their runbooks public).
Continue reading “Codify Infra Runbooks with Jupyter Style Notebook” →
Apache Kafka has grown a lot in functionality & reach in last couple of years. It’s used in production by one third of the Fortune 500, including 7 of the top 10 global banks, 8 of the top 10 insurance companies, 9 of the top 10 U.S. telecom companies [source].
This article gives you a quick tour of the core functionality offered by Kafka. I present lot of examples to help you understand common usage patterns. Hopefully you’ll find some correlation with your own workflows & start leveraging the power of Kafka. Let’s start by looking at 2 core functionalities offered by Kafka.
Continue reading “Apache Kafka: Is It Right For You?” →
Earlier last week I was working on a python package that would compress numerical series into strings (and back). The package is now available on Github. It gets you around ~80% compression. It is useful to store or transmit stock prices, monitoring & other time series data in compressed string format.
Continue reading “Releasing NumCompress” →
Estimating software development effort is tricky and can often be a point of contention in the team. I have seen teams spending an entire day planning a 2 week sprint, working out every detail of every task. After a few sprints they have some sense of their team’s “velocity” and could tell how much work their team can deliver in a sprint. And I have seen teams where developers huddle casually, take on major features, gives out rough dates, and miss their deadline by a lot.
I can’t propose a generic process for estimation as it’s highly dependent on the nature of business, team size, culture etc. And frankly I don’t even know what the best process looks like. Instead I am going to share some common pitfalls and best practices that are applicable for any development team. This is a useful read for developers and product owners alike. Let’s dive in!
Continue reading “The Science of Software Estimation” →