Welcome to the Box CI blog. Box CI is a very early stage company that started from zero only a few months ago. Here I'm documenting the process of launching this product and company from scratch.
I'll be posting the blog updates to twitter under @zero_startup and also having any conversation around the whole thing there. Please follow that account if you're interested in following along!
I'm doing this as a learning experience, and to because I think it'll be useful for me and hopefully other people bootstrapping companies. I've built quite a few products as side projects before, and even launched a couple of them, but never with success. I know the reasons for this - the usual traps around perfectionism - spending far too long on product development without shipping and getting feedback, focusing on the wrong things, not doing the 'right' but boring things, etc.
With Box CI, I want to try to learn from these previous mistakes and do things in a completely different way. I want to attempt to throw away all that BS, and just do exactly what needs to be done and no more to get to paying customers.
A CI service that does everything for you, except for running the builds - it gives you complete control of that part. So you can run the build from anywhere you like, and however you like. Whatever works best for your usecase.
Could be your laptop. Could be a beefy machine you're renting from a cloud provider. Or one you've bought for builds and have under your desk. Or that Rasberry Pi that's sitting in the drawer, begging for a good use. Or even your phone! Whatever works for you.
I love everything about CI, as a workflow, but I don't love a few things about using the various managed services that exist:
So my idea is to launch a CI service that gives you all the really useful stuff you want - managing builds across multiple worker machines, showing live logs from a build in progress, allowing you to do rebuilds, keeping a history of builds and logs, managing team access to all these things - while letting you run and control the workers.
I envisage it as a centralised web app for the admin stuff, and a cli tool you'll install on workers that will act as a wrapper around your build script, providing all communication with the service for run management and streaming of logs. So setup of a worker should only involve installing this cli tool, and of course whatever else you need to run your builds.