Bootstrapping

bootstrapping, transitive verb. to promote or develop by initiative and effort with little or no assistance. Source: Merriam-Webster.com Dictionary

I've been talking over a plan to start a consulting business with my partner, Victoria Pocus. We'd like to specialize in getting our clients from idea to prototype to version 1, and beyond. Since we don't have piles of cash lying around or easy access to external funding, we'll be bootstrapping our business by building up a portfolio of apps we want to use ourselves on nights and weekends to show what we can do and document the process openly as we do it. We'll be openly documenting our process to give potential clients special insight into how we think, how we operate and build products, and how we handle roadblocks and other issues as they arise.

We also love to share this sort of thing as we build since it helps us think through how we're building something and why. As we build actual products for real clients, we'll offer the same sort of written thought process in the form of internal updates, not sharing them publicly but rather privately with the client.

We had a few ideas for the first thing we should build, to showcase our skills. We wanted to first build a mobile app that we would actually use ourselves, not only to showcase our skills but also so that we would actually use it! In this way, we would "dogfood" the app, improving on it naturally as we use it and needs arise. Our ideas so far, in no particular order:

• A shared calendar for the family
• A shared medication scheduling and reminders for cancer treatment, post-surgery, etc.
• A shared to-do list for the house
• A shared notes app
• A location sharing app that's private by default

Vic and I agreed that the most pressing need for us right now is a shared to-do list. This is somewhat convenient as well, because a shared to-do list is a lot easier to build than say, a location sharing app! From a technical perspective, it makes sense to do this first.

This led me to start thinking about how we might build such an app. My first instinct is to go with React Native, most of all so that we can write one codebase that covers both iOS and Android apps (we have both iOS and Android users in our household). It also helps that I already know plain web-based React, and can show Vic the ropes as we go (she has plenty of software development experience, just not with React Native yet). We will naturally use Typescript as part of this, since 1. it's available when we're using React Native and 2. as opposed to its ancestor language, Javascript, Typescript gives us some niceties when it comes to developer experience and tooling, as well as code quality that comes from defining explicit types in our code.

That brings us to the choice of backend. There's more than one way to go here, plenty of potential choices to be made. For the sake of ease of development, and to help us focus on the app frontend and the actual user experience to start, I'm leaning towards Supabase, an open-source alternative to Google's Firebase backend-as-a-service platform. In practice, in a real client app, I would probably advocate for a client-owned Node.js-based backend, with a PostgreSQL database backing the data. This would ultimately give the client more control over their data and how it moves through the system, but here, that's less of a concern for us as we're trying to show what can be built in a rapid prototyping process. This will also help me get Vic up to speed on React Native and Typescript without having to worry about an additional backend layer that, at this point, would add complication more than it would give an advantage in the actual function of the app.

We will be open-sourcing the apps we build as part of this process, and as mentioned before, we will document the development process as we encounter issues, challenges, and choices to be made. In this way, we hope to give insight into our thought process as software engineers, product developers, and designers.

We hope you'll join us in this journey, whether as a potential client, a fellow software developer, or perhaps a curious reader! We think you'll enjoy seeing our process as we write code and make software products, and if nothing else, maybe you can learn with us along the way as we figure things out.

Stay tuned for more updates in the coming weeks and months! Our next post will cover the initial design of the app and what we'll need to start as we write some of the initial boilerplate code for our shared to-do app.