This is the first article in our "Building under constraints" category. We will look at the pros and cons of building software products and businesses under constraints. In some cases, we'll show that constraints lead to a more focused and sustainable product.
For those of you who are building a business under constraints, we strongly recommend a book called "Company of one" by Paul Jarvis ( https://ofone.co/ launch ).
As a small team of three software engineers working remotely, we inherently build software under all sorts of constraints. We cannot and do not want to throw people at each new problem that we face. Here are just a few examples of work that we regularly do under constraints:
Here is the list of some of the topics I will discuss in this and upcoming articles in the "Building under constraints" category:
The main point of this article is funding constraint. I will describe our decision making around funding constraint.
Whenever anyone starts a new business, there is a question of funding. Few people have enough personal savings to self-fund a business, and this lack of funds is a constraint. Nowadays, the majority of founders prefer not to embrace a funding constraint. Instead, they seek external sources of funding, typically investors. A few founders do succeed in getting funding from investors, and media typically glorifies these events. As a rule, funding is portrayed as a business success.
In our company of three, we decided to embrace our funding constraint. In the past, we avoided this constraint by raising funds for our now shutdown company: Drizzle (pay-per-view paywall software for websites). Although we had a dozen paying customers, we spread ourselves too thin. Fundraising took a lot of our time and focus from the product. As a result, the product suffered. Our lack of time and focus caused us to bloat the product with features and to create overwhelming technical debt. Sustaining sucha product was impossible in the long run. Thus, we shut it down. Fundraising is a full-time job, and if you a small team, it will easily sidetrack your engineering efforts.
We feel extremely lucky that we decided to self fund our current company: Async Labs. First, we took time to build and improve our SaaS boilerplate ( https://github.com/async-labs/saas launch ). This boilerplate enabled us to cut engineering time and launch Async on a low budget in just a few weeks. We now use this boilerplate whenever we need to launch a new product quickly to test out a market. I bet that other teams who work together for a long time on multiple projects use a similar internal boilerplate. We made our boilerplate public. Second, the revenue from the sales of our books ( https://builderbook.org/ launch ) lets us self fund comfortably. Using startup language: we have unlimited runway for Async or any other potential software products.
Since none of us is fundraising and our books require little support, all of are coding and thinking is geared towards our product. We can do deep work ( http://www.calnewport.com/books/deep-work/ launch ) while building and improving Async. None of us is distracted, and we take time to discuss new ideas or rethink about old ideas. There is no pressure to rush a feature or to take on technical debt. We test things in-depth and create a focused, easily manageable and extendable bloat-free product.
All of us enjoy working on Async. I personally feel that I can enjoy gradually improving Async in a meaningful way my entire life and never get burned out. In my experience, a funding constraint could is healthy for a small team, especially if you plan to run your company for a long time without an exit strategy.
In the next article, I will describe our decision making around pricing in the context of constraint.
If you have any questions, feel free to send an email to email@example.com launch