Box CI

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!


Why am I doing this?

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.

What's the idea for Box CI?

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:

  • Wasting hours messing around configuring my builds in an awkward yaml format to run in the really esoteric manner the providers expect.
  • Having to battle hard to preserve any state from one build to the next. State is essential for fast and convenient builds. Without state, there's no caching, and it's awkward to use the exact tools you want because you have to install them fresh each time.
  • Having to give a third party access to my source code and deployment keys.
  • Not being able to fit the hardware to the build. When everything is generic, specialised tasks are inconvenient. E.g. running automated tests in a real browser, and taking screenshots. Simple on a laptop, really cumbersome inside a container on a server, and flaky even when it does work. It'd be awesome if I could just run these types of builds on my laptop.
  • Paying way over the odds for compute required to run my builds. Compute is really cheap to rent from the cloud. Besides, I have loads of compute available right here on my laptop. Why can't I use these options?

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.

Quick startDocsBlog