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!

Zero to MVP (in 84 days)

When I started working on Box CI, the first goal was to build and ship an MVP of the product within a 10 week time frame.

I wanted to do this whilst following the Y Combinator Startup School program, which lasted for 10 weeks. The idea was to document the process of turning the idea into an MVP, starting from zero, and applying the lessons from the program (which is focused on building early stage startups) along the way.

In the end it actually took 12 weeks to ship the MVP - below are the updates I posted.

July 22

Today I've been working a bit on the build runner - I have it running a sh script on my laptop and it streams the logs to another service which right now just prints them in another terminal.

I also checked out the Startup School software, and submitted my first 'update' - thought it might be a bit pointless doing one on the first day, but actually it was pretty useful for focusing on what matters. My answers to the questions were as follows:

Weeks to launch


How many users/prospective users have you talked to this week?


What are your top 1-3 goals for the next week?

Get a landing page up.
Get a prototype working that I can run builds on from my laptop that saves logs, run time etc to a database also on my laptop.

What have you learned from users?

Nothing yet, haven't talked to any

Biggest obstacle?

Right now, have nothing working at all, don't know if I have a target market really (I just know I'm solving my own problem)

On a scale of 1-10, what is your morale?

10 – Couldn't be more excited and optimistic!


So, I went for 3 weeks for the launch. This number was basically plucked out of the air, but I think it's useful to set a goal and be a little bit over optimistic about the timing of it. Is 3 weeks over optimistic? Well, I'd say it's over optimistic within the realms of possibility, if that makes sense. I know how long it takes to get a new product shipped, and believe me I've never approached anything like as short as 3 weeks before, by about a factor of 10 probably. So yeah, I'd say it's over-optimistic (I also just remebered I've been invited to talk at the Edinburgh React Meetup next Monday, and I'm going to make a short 3-day holiday out of it with my wife, so perhaps even more so), but if I strip the scale of everything right back and just do the absolute simplest thing possible, I think it's doable.

Also answered truthfully that I've spoken to no potential customers. I guess this is a bit mitigated by the fact that I'm a potential customer of the product (don't worry, I'm not going to count myself using it as having succeeded in getting paying customers :-)

But seriously - the not talking to customers part is probably the first thing I need to work on. Come to think of it, I'm adding that to the goals for the week. See, writing this blog is helping me already!

Oh yeah, I also signed up for a 'Group Session' video chat - not much info but I guess a group discussion about our startups with other people in the program - on Thursday at 8pm. I again just plucked that time out of the air. Hope it turns out I'm not actually busy then!

Ah yes, also finished setting up the twitter account for this experiment (@zero_startup) adding a photo I made in about 10 seconds just with a screenshot, a short bio and a link to this blog. Probably pointless and will remain at zero followers, but why not try it.

July 23

Today, I talked to people!

I posted this blog to Hacker News and also on the Startup School forums, got an absolutely amazing response with the HN post hovering on the second page most of the day (really didn't expect this, the absolute best one of my previous products' Show HN posts has done has been 4 stars - check out my submission history :-), some really helpful ideas in the comments and a bunch of people following the @zero_startup twitter account.

A massive thanks to everyone who upvoted the posts, commented, followed the twitter account and showed interest, it's really going to make this experiment a lot more fun having you guys be part of it, giving me great ideas and feedback and joining in the conversation :-)

So one of the first things that jumped out and a few people suggested was that, yes, I really really should begin by talking to people, based on the fact that as per yesterday's progress report, I'd talked to zero potential customers about the idea.

So I opened up a thread on twitter (still very much open by the way, if you'd like to chip in!), just asking what people thought of the idea and if it would be useful for them. I also whatsapped some friends with a particular penchant for devops and product development, whose opinions I really value. Got some interesting tips and suggestions from both of these and the HN comments:

Existing products that might have some overlap with what I'm doing

Appveyor (thanks @paul1664) and Jetbrains Team City - I've used Travis, CircleCI, Gitlab and Codeship before so I still have quite a few more products in the CI space I need to get familiar with.

What exactly am I proposing to build -- why will it be better or easier than what's out there now

This one points to the fact that I need to do a better job explaining what this product is, and in particular emphasising the main points of it upfront and super clearly (@DanielJamesPost 's question really helped me here, thanks!). This actually fits in pretty well with the week 1 goal I set for Startup School of getting a landing page up for the product, as I guess I'll need to do exactly this. What I thought was super interesting though, reading between the lines a bit, is that nobody I spoke to actually disagreed that problem with configuiring the current services, was actually a problem. That seemed to be taken as given in the discussions I had. Which I think is a good thing, but I probably need to drill in on this a bit more in future discussions.

What's the business model? Will it be open source? How will it work?

Also good questions and again, realised I'd not explained this at all. So I see two distinct parts to this product, really:

  • The cli tool, which will be a wrapper for your build script and which you'll install with a package manager on your build machine(s) and use to run the builds. This will be the thing that does stuff, on the machines you control, and will be completely open source.
  • The service, which the cli tool will talk to, which will be the thing that manages builds, displays live logs, saves build history including logs, manages accounts and teams etc so everyone can see the builds, etc. This part will be the closed source, paid, product. Now, this part is important - the cli tool will work according to a protocol that I'll document so that if you want to build and host your own 'service' part, you can. The paid part will be having this service provided for you, without you having to do any of that work. That's the business model here - customers paying for this service on a monthly subscription, if they want it. Again, the cli tool that sits on your machines and does the builds will be 100% free and open-source, and available via package manager(s) for super easy installation.

Why not do a livestream some of the coding?

Great idea here from sansnomme in the HN comments. Should be an awesome way to 'just do stuff' without getting drawn into perfectionism and down rabbit holes when building the product, and generally a pretty fun experience since I've never done this before. Will also make a great complement to this blog, I think. So I'm going to do it. Probably when writing the open-source cli, because that just makes sense. I'll follow up with plans for this when I've figured out how to set it up.


So today I did what I set out to achieve - the less easy thing than bashing out more code on the prototype - talking to people about the idea, figuring out how to best explain it, and getting some great tips and ideas in the process. Good day I'd say, and not a single line of code written. Makes me slightly worried when I think of that 3 week launch goal, but makes me feel good to realise I already crossed off 1 of the week's goals I set for Startup School.

July 24

Today was a mix of continuing talking to people and doing the Startup School orientation stuff. Didn't get opportunity to work on the prototype any more today.

Had more CI products that do similar things pointed out to me - in particular one called Buildkite (thanks @spikelindsey for pointing this one out on twitter) that actually looks like it works on a similar mechanic with an open-source agent you can install on your own build machines. As I pointed out in a reply this didn't come up at all in my googling for this type of product - anyway it's good that I'm getting a better picture of the current set of products out there that do overlapping things. Should help me focus on my particular usecase etc, assuming it's not optimised for by any given product out there right now.

Another thing that came up today in a conversation with a friend was how reproducible builds are going to work with my product. This was actually a really good point - it's not something I'd thought about that much because my way of making builds these days is using docker containers to make the build machine etc, so they're reproducible just because of that. But if you didn't do this, and instead just wrote a build script that assumed certain dependencies (tools etc) on your build machine, and didn't script the installation of these or even write them down, it could be a bit of an issue.

My first thought on this was 'with great power comes great responsibility' - like sure, owning the build machines and being able to do anything you like, however you like, in the build process means that you also have to follow good practices to make your whole setup reproducible. On the existing providers, you typically get reproducibility 'for free' as a by product of being forced to define the entire build in a config file, but you also have all the limitations etc I've already discussed as a result of that.

Perhaps a solution here might be tutorials and examples that show how to define builds in terms of docker images etc, or other tactics like having dependency installer scripts or just writing dependencies down even. Not sure. This needs more thought...

Startup School-wise, I thought today the first lecture was going to be released, but it doesn't appear to have been yet. I think it might be released on California time, so middle of the night here. Perhaps I'll watch tomorrow morning. Anyway, I watched the course orientation video which obviously won't be too entertaining to talk about, the most interesting thing I think was that it set up expectations for the group discussions which are going to take place tomorrow.

Basically I'll be placed with 8 other founders and will have to give a super quick summary of me, my idea and my progress and goals this week, then at the end we'll all anonymously give feedback on each other. Sounds like it might be kind of fun and interesting. Pitching is something I've only done a little bit of and all I know is, you think it's going to be easy to fit what you want to say in like 30 seconds or whatever but it's actually extremely difficult! And usually you don't really get the message out quite the way you want. Will be good to get a bit of a trial by fire on that with feedback. Should be really useful. Looking forward to reporting on that in tomorrow's update!

July 25

Today I didn't speak to any users ;-) But I did speak to other founders in the Startup School program, in the first group discussion. One of these will take place every week, and each week I'll be paired with a group of between 5 and 8 random founders who are also following the program.

This week, I had a group of 4 other founders, but only 2 came online for the discussion. We had to do the elevator pitch for our idea, and then discuss our goals and plans for the week ahead. It was interesting to do, and one thing I immediately realised was that my elevator pitch for the product needs to be understandable for non technical people who don't know what CI is.

This is kind of funny, because I honestly hadn't thought about this at all until the moment I had to explain it realising that not every founder in my group was technical. I think my explanation of CI came out something like "erm, it's what you do to build and deploy, erm... code" and so I wasn't surprised to get feedback at the end (yeah, you get written feedback from everyone after the session, which is very useful) that they hadn't understood what my product will do.

It's not something I'd considered mostly because for this product, my customer base in terms of direct users is by definition going to be technical. Obviously I'm going to have to optimise the 'main' pitch for the technical userbase, but one takeaway is I definitely need a non-technical pitch to explain what this will do, perhaps not in terms of how it does it but in terms of the effects it will have. Faster deployment. Cheaper infrastructure costs. Less distraction for engineers. Those sorts of general advantages. It's important because as well as explaining and selling the product to direct users, i.e. engineers, I'll also at times probably need to sell it to non technical people, maybe because they're approving the purchasing decision, are just generally interested or want to know, etc. This is a b2b product after all. So that 'secondary' pitch is on my homework list and I'll try to get it so I have everyone ticking the 'understood the idea' box in the feedback form next week.

In terms of goals for the week, the main one was getting the shell of the service, i.e. the webapp, up on the internet. Ah, which reminds me - today I started working on that and, of course, in the true hacker tradition, my very first action before writing a single line of code was to think of a name and buy the domain ;-)

So I decided to call the product Box CI, and I've got The idea started from the idea of running your CI on your own box, so that's where it comes from. Also it's short, and I think boxci works pretty well as a cli tool name.

July 26

Short update today as I had a lot of stuff on, so didn't get to spend that much time on Box CI. In the morning I did a little bit more setup stuff on the web app, cloud accounts etc. Glad I got to push it forward a bit and aiming to get the week 1 goal of shipping the landing page done tomorrow.

Had an interesting exchange on Twitter with @HarveyMultani who threw a few great ideas at me. One was to actually send the blog out as an email newsletter. I'd thought of putting a form on the landing page to let anyone interested in the product give me their email, basically just to let them know when it launches, and this would be a great thing to combine with that. Another idea he suggested was to do video updates of the progress of the product here, after it's shipped. I thought this was a great idea and something I'll definitely do.

Final cool thing to note today was positive feedback on twitter from @andrew_n_carr on the Box CI name - great to hear!

July 27

Another short update today, actually the first day since the start of the experiement where I really didn't have time to do anything on Box CI. Spent a lot of the day apartment hunting, as we've just moved from London to Manchester and need to find a new place.

Frustrating that I didn't get the landing page out today, but I am absolutely determined that week 1 goal is getting hit, and I still have tomorrow. It's going to happen!

July 28

Today, I shipped the landing page!

So as you'll see, it definitely adheres to the "if you're not embarrassed by it, you shipped too late" school of thought :-) The goal here was to get something, anything, up at that just does the following:

  • Give a short description of what Box CI will do, really just the '1 liner' as they're calling it in the Startup School program
  • Give anyone interested a way to get notified when it launches

and completely discard any instincts towards perfectionism or even 'doing it right' Vs 'doing it fast'

It took a lot of effort and fighting against my nature to do this. I simply copy pasted the 'about' description text from what I'd already drafted for my 1-liner pitch in the Startup School in the 5 mins before the group discussion this week. Done in 30 seconds, no proof reading by anyone, no edits, no poring over the wording. The layout and styling is almost as simple as it could possibly be, without getting ridiculous, just plain text in a single font over colored backgrounds. The colors I picked were literally the first colors that came to mind at random as I was writing the CSS. I used out of the box form components (from the excellent Material UI = ). There are no pretty pictures with SVG icons of laptops or Rasberry Pis with arrows pointing to the cloud, even though I'd really enjoy making that. There's not even a favicon, even though it would take me about 10 minutes to set one up and deploy it.

So why not? Why so minimal? Because none of the things I just mentioned add anything but an incremental improvement over the two points I listed. They add value, but that's only meaningful if there's something there to add value to. If there's nothing shipped, they are adding value to nothing. Waiting and waiting until all the small details are right I think has been my single biggest failing when trying to ship products in the past, and I'm absolutely resolute I am not doing that again. I don't care if it's a bit crap, I shipped, and my bullet points above are ticked off :-)


So, it's the end of the first week of the experiment. Time to review what goals I set and which ones I hit:

  • Talk to potential users
  • Get a landing page up.
  • Get a prototype working that I can run builds on from my laptop that saves logs, run time etc to a database also on my laptop.

So, I hit 2/3 - I think I pretty much maxed out the time I could have spent on the experiment this week, so I'll take that on the chin. But at the same time, I don't think that hitting that last goal was impossible. I could have done it. I still could do it, but instead I'm going to celebrate shipping the landing page by relaxing tonight :-) Have plans to go out for dinner with my family, so I'm going to go do that and not think about work.

So the prototype naturally now becomes the focus for next week, and gets promoted to goal number 1 for week 2. Now that the landing page is up, the race is on to get the product launched behind it. Keeping with the same philosophy of just doing the most minimal possible thing to ship something valuable, I'm going to start with the tooling. The web app will need some let's call it 'generic' work such as sign in, sign up, user account management screens, etc, but it's much much more important to have a prototype of the core product working before I even get to that, I think. If I do the web app stuff first, I'm falling into the trap of building a pretty shell around nothing of value - I'm far more interested in having a valuable tool ready for people to use, then building the simplest possible way for them to access it via the webapp.

Good first week, and nice to end it with shipping something :-) If you've been following along, hope you've enjoyed it so far! It's really keeping me motivated and focused thinking about writing my daily updates: can I reveal something exciting, can I report real progress - it's really helping me to avoid wasting time on things that don't matter.

A heads up, tomorrow I'm travelling to speak at React Edinburgh about my open source library react-frontload, and me and my wife are staying there for a couple of days afterwards for a mini break to see the city. So work on Box CI will continue on Thursday!

July 29

Today I travelled to Edinburgh to speak at the React Edinburgh meetup, so no progress made on Box CI. Beautiful city by the way, if you get the opportunity I recommend visiting :-)

July 30

Quick one today - Haven't done anything since I'm on holiday in Edinburgh (until Thursday), but I had to do my weekly update for Startup School

Set my week 2 goals:

  • Get prototype working locally
  • Speak to more potential users

So yeah, the main one I think is the prototype for this week. I set the goal as 'working locally' because I really don't think it's realistic this week to plan to ship it. That's mostly because of all the web app stuff I'll have to build around it to make it shippable, which won't get done by Sunday. However I am hoping to get the prototype working locally, but to a shippable standard, if that makes sense.

August 1

Back to it today, and got straight into my goal of building the prototype of the open source agent. Taking the train from Edinburgh back to Manchester I had 3 hours to focus on this.

On a side note, I really like writing code on trains. I get enough reliable internet via my phone to view documentation or download dependencies if I really need to, but not enough that it's effortless, so I spend most of the time off the internet and in the editor. Really great for focus and getting a lot of code written out, which is especially helpful building something new because there's a lot of setup to be done. It's less about solving specific problems and more about just building out a platform of code to build the product on top of.

So in that time I got the open source agent from really just a proof of concept, to almost done. What it does is takes a command, runs it and streams the logs to an API which will at some point be provided by the service (but for now is just mocked with a test API). It's working solidly - including against tests that mock random latency for the network requests. It's not done yet though - it still needs to handle request failure, retries etc, and the cli tool's API and options need some thought and additions (most stuff that should be configurable is just hard coded for the initial tests). But I am pretty happy with today's progress. I'm going to target tomorrow for shipping the open source agent in a beta version.


The other thing I did today, in the evening, was the second Startup School group discussion video chat. I actually got put again with the same (Manchester area based) founders that I had in the discussion last week, which was an unexpected pleasant surprise since Startup School told us that the selection would be random each week. Not sure if they changed that decision, if it was just chance, or a bug in the random selection algorithm or something :-) but it was great to talk to the same people as last week again, plus one new founder we hadn't talked to before

The start of the discussion was just a report of which goals we hit last week and which goals we set this week (this is mandated by Startup School, everyone has to go around and report this) so basically just what I wrote in the Day 9 update.

But then in the chat we had afterwards something interesting came up - one of the founders in the group gave me feedback that the cost model of Box CI was probably the thing that stood out the most - he described the other big CI platforms as having a price model that 'punished success' which I thought was a brilliant observation and way to put it - that is, it's free or cheap to get going with them but then, because they charge relatively quite a lot for relatively modest amounts of compute, it gets really expensive really quickly when you need to scale the number of builds up, and this is a concern especially for scaling startups and indie hackers if that's my target market (which it is).

Obviously it's clear form the start that Box CI wouldn't have this issue, because the service will be charged for at a flat rate that won't grow with the number or complexity or duration of builds, because you control the hardware that runs those and commodity hardware is very cheap or free to provision for yourself.

It's an interesting observation because I think he was spot on - that is a very big very real problem, and I think it's perhaps the most important advantage of Box CI. Perhaps more than speed of builds. Perhaps more than security concerns with exposing code and secrets to a third party.

I know this because I've literally faced that exact problem, at one of the startups I worked at. We were using one of the big CI platforms, and both our number and the lengths of builds grew very quickly as we wrote more features, with more tests, and hired more engineers. We found builds were waiting in queues for a single build 'instance' on the platform, basically we had a log jam, but we the engineers weren't in control of the purchasing decision to buy more 'instances' and frankly the founders were reluctant (rightfully) to increase the spending because the per-instance prices were not a trivial amount of money per month, and remember that especially in the early days, going from 1 to 2 parallel instances is doubling the cost. Not something that's that easy to justify, or do. Waiting a bit for builds is managable right?

Imagine how much better it would have been if we could have just spun up a cheap cloud VM or just used one of the spare laptops sitting around. Or even our own laptops. Almost no costs, nobody to sign off a purchasing order, no time wasted. We could have just solved our own problem. That's why I'm building this. Cost is often the main bottleneck for startups and hackers building side projects. I'm building this for them. I think I should be pushing low cost and scale-friendliness as one of, if not the, main thing that Box CI will bring.

August 2

Today I was head down coding the open source cli tool for Box CI. So, my goal yesterday of having something shipped today was wildly over-optimistic :-) That said, a lot of progress made today, with the API of the cli tool figured out and also the protocol (via an http API) over which it speaks to the service.

It means it's working locally now, and I'm ready to start working on a prototype of the service itself, i.e. the webapp. Thinking about it a bit more today, I actually think to be honest I will hang back on shipping the first beta of the cli until I've built a prototype service, because it can't do anything without the service anyway and so there is really no point, and also I want to be a bit more confident that the protocol and APIs I've defined aren't missing anything. Usually, these things seem simple to design but I've found there are always details that you don't think about or don't become apparent until you actually integrate things and use them in practice.

So, a short update today, but a lot of progress made towards the week 2 goal of having a prototype full product built and working locally. I think while that goal was always a bit ridiculous, if I keep things very simple and just drive for 'working' then I might actually have a chance of hitting it.

August 3

Very short and simple update today - just continuing work on the cli tool!

August 4

OK, it's the end of week 2. Wow, this week went quickly! That's probably because I spent the first half of it on holiday in Edinburgh :-) But still, since Thursday I've been putting in some solid hours and it still feels like it's flown. Time to review this week's goals, where I am, and set the goals for week 3.

My week 2 goals were as follows

  • Get prototype working locally
  • Speak to more potential users

So, in short, I have utterly failed on both goals this week. I didn't talk to any potential users at all as my focus has been 100% on building the prototype, but I didn't get anywhere near done on that either.

Let's get the excuses out of the way. First of all, on a positive note, today I've got the prototype of the cli tool done. The UX is polished and I'm happy with it, all the configurability is done - nothing hardcoded or mocked - and it also has a suite of tests that test both that it works and handles errors gracefully under adverse conditions like the network being really slow, or the service dropping requests at random due to being overloaded.

I'm very happy with all this, and the cli tool is exactly how I want it, but I'm far more disappointed with myself that I've allowed myself to lose focus on the week's goals and go down the perfectionism rabbit hole. For the past 4 days since Thursday, I've laser focused on getting this cli tool done and done right. And I've done that. But I've done it at the expense of hitting my real goals - talking to users and getting a full prototype of the cli and the service working together so that I can ship it ASAP and get people to try it ASAP.

But to bring it back to the positive, at least I have realised this after only 4 days, which in the scheme of things is not that much time - and what's made me realise it is that I'm at the end of the week, I had goals set, I have to review them, and I have to write my daily update. I'm starting to appreciate how much following the Startup School program and writing this blog is helping me stay on track.

Following Startup School has helped me realise I've been doing the wrong thing this last few days in another way too - very aptly, today I watched Michael Seibel's week 2 lecture on "How to build an MVP", and it was absolutely on-point and really made me jump up and realise I need to refocus. The video is here on Youtube and I really recommend watching it.

I'd actually say it's one of the best discussions I've ever come across of what the goals and purpose of an MVP should be. There is so much gold in there (the entire thing start to finish is just super dense with condensed experience and wisdom) I can't hope to repeat it all here, so I'll just repeat my favourite nugget: "An MVP should be like a shirt you pick to paint your house in. You probably won't spend a lot of time tailoring that shirt".

It really struck a chord with me because I realised that the reason I've been head down for the last 4 days, writing code I'm proud of, shaping the cli tool's API in a way I'm happy with, writing a comprehensive suite of tests and testing the UX in all sorts of usage conditions and edge cases, working on the UI with its messaging, spinners, timers, indentation, emojis etc - this is all good stuff and stuff that could be valuable eventually, but it's coming from a mindset of treating the MVP like it's special - like it's a tailored shirt. But it's not a tailored shirt - it's a crap one I'm going to paint in and then throw away in a week. Making it nice and tailored is a complete misuse of time at this moment. What I need to be doing is painting the damn house (shipping the MVP -- hopefully I'm not stretching this analogy too thin :-) as quickly as possible.

What I should have done is left the cli as it was after 2 days of work, left the hardcoded options hardcoded, left it failing hard and ugly in unexpected conditions like network dropping, and just spent the other two days building an equally janky prototype of the service webapp, and shipped. Nobody cares about these details - they care most about getting the core piece of value out of the product which is running builds from a machine they control. I could already have something that does that, but instead I have a nice cli that isn't useful yet because no service exists for it to be used with. What's the point in that?

Ok so rant over and lessons learned. I'm a bit frustrated with myself for miserably failing to hit my goals this week and feeling quite far away from my goal of shipping the MVP after 3 weeks, but to take a step back and be philosophical about it, I have learned something really valuable and hopefully within enough time to make it right. Part of staying focused is losing focus, realising it, and correcting yourself. With a week to go before I'm supposed to ship the MVP, I think I can refocus and achieve that.

So, that's it, that's the goal for week 3 - shipping the MVP. I'm not going to shy away from this or make elusory goals like 'having it working locally' or some cop out like that :-) The goal is to get it 'live live' - that's a working service up that people can actually use, in some capacity (again, taking from the lessons of the lecture above - just in some capacity - not perfect, not every usecase, just something small and valuable working).

I'm going to refine and hone exactly what the narrow usecase and narrow bit of value it will deliver are over the week, as I feel like whatever that is might be more of a discovery process than something to just declare in advance. It should, honestly come from users. In fact yeah, I'll set a second week 3 goal to try and get what the MVP does from a potential user. That's going to be quite hard and possibly uncomfortable for me to do. So it's a great goal!

So in summary, my goals for week 3:

  • Ask potential users what one small valuable thing my MVP should do. Then do that.
  • Ship the MVP
August 5

Today straight on the prototype web app - started building out the backend and made decent progress. Short update - work on the prototype will continue tomorrow!

August 6

Another short one today - continued working on the backend!

August 7

So, today I got the backend fully deployed in production. So everything is now there - backend service, frontend service, database.

The basics of account management and auth is done in the backend, and I even got round to starting on the APIs for projects and builds, which is where I'm going to pick up tomorrow. Tomorrow should be fun because now the 'framework' of the system is all in pace and deployed, I'll be able to make hopefully quite rapid progress on the actual fun product stuff. I'm hoping by tomorrow I'll at least have something very simple working with the cli talking to the actual service at

At the midweek point I am pretty happy with progress - I definitely think I have a chance of actually hitting the MVP goal by the end of this week, if I can keep focus and just keep driving at that goal, only doing the simplest possible thing I can to get it shipped!

August 8

Today I built out the APIs in the backend that the cli tool will talk to. Got most of the way there with that.

Also did the week 3 group discussion for Startup School today, and this week the founders were randomised again, so got to speak to a completely new set of people. Very interesting businesses and had some great conversations. This week I was up first with my pitch and did the non-technical version. I got some feedback that it was at least fairly understandable, and I got the idea of what I was building across, so that was much better than week 1 :-)

August 9

Not a big update today - just continued on with writing the APIs for the cli to talk to. I'm now at the point of running the real cli against the real service, which is really cool. Work will continue tomorrow!

August 11

So, it's the end of week 3. My goal I set on day 1 for shipping the MVP was 3 weeks, and indeed that was the sole goal for this week. So to get right to the point - Did I do it? No. But, I have finished the first, very primitive prototype of the entire product, and it's running on my machine!

That is, I can create an account, sign in, run a build using the cli tool and watch the logs in the webapp. Again, it's very primitive - there's no styling (literally, the logs I'm printing are just plaintext of the json responses coming from the API in <pre> tags :-), I have to create a 'project' manually in the database to set it up as the form to create one isn't there yet, etc etc, but the path from this pre-to-type to the MVP is very clear and it's mostly a matter of building a functional UI (functional is the key word here for the MVP - it just has to work and look reasonable)

So I missed the 3 week MVP goal but I'm really, really happy with that result this week and excited going into week 4, when I am now extremely confident I will ship the MVP. The 3 week goal was always a bit ridiculous and really the point of it was just to focus and get the priorities right in order to attempt it. It's definitely achieved that purpose, and I'm glad I set it even though I missed it. It has 100% led to me shipping sooner. As I say, now I feel very confident I'll ship within week 4, and I think had I originally set week 4 as the goal, I probably would have been writing this same thing just a week later. Or If I'd set it at 2 months, I'd be writing this same thing a month later.

It's so often the case that you can mostly fit whatever needs to be done, perhaps adjusting priorities as neccessary or adding/cutting things, to whatever arbitrary amount of time you give yourself. My biggest lesson learned so far from this experiment is this, I think. In the past, I've spent literally months, sometimes 6 months or more working on the 'MVP' (very emphasised intentional quote marks) of products I've worked on. Whenever I've done that, it's always been very clear afterwards what could have been cut, or done in a simpler way (often just the first way that worked, with no rewrites or refactors) - but at the time it's very hard to stop yourself from just doing 'one more thing' or making this or that one thing 'just a bit better', when you have no goal or deadline to ship for.


On another topic, I observed on the twitter update for day 19 that it was starting to feel a bit like when you're in a standup and are basically just working on something that takes multiple days and just have to say - yeah I'm working on the same thing - which is always a fairly uninteresting update. As the day 20 update was going to be essentially the same, I decided for the first time since beginning the experiment to skip that day's update.

I think the idea with the daily updates was to bring focus to work on and do useful and interesting things each day to push Box CI forwards, but I've realised that it just isn't that interesting to do whilst I'm head down just building the product and there's nothing to actually show at the end of the day because it's still in progress (or now, there's just no MVP to show). So I decided for days like that for the rest of the experiment I'm just going to skip the update with a short message, and won't post to Twitter either. I guess a much shorter summary of this: I'll only publish an update when there's something new and interesting to say or show.

I'll update with week 4 goals tomorrow when I set them.

August 15

So, a quick update today - as you can see I've been very head down building the MVP this week and so, as promised, haven't been posting boring "I'm still working on it" updates :-)

But with the week almost gone, I just want to do a quick update, that the MVP is basically ready to ship. I posted a couple of screenshots on Twitter earlier - so essentially the first feature and workflow of running builds directly from the CLI tool is done. You can sign up, create a project, boxci gives you a project ID and access key which you can then provide to the CLI tool to run the builds, and it streams the logs and shows a history of runs. What isn't done is the watch mode - where the CLI will be sitting there waiting to pick up builds that you start from the UI, or from git pushes etc. That feature will come later - I'll ship first.

So, with that said, when am I going to ship? Well - in planning this week I totally didn't take into account that I have plans this weekend to go visit friends in Cambridge! So yeah, I'm going to do it after the weekend.

To be honest though I see this as a good thing. I've been very head down, in execution mode, and a few days off will be good. And it'll be nice to come back fresh next week and launch! Looking forward to it!

I paused the blog here for about 10 weeks whilst building the MVP
October 11

About 10 weeks ago I went silent and got my head down to work on the MVP. The idea was to pause the daily updates because I could see that it was essentially going to be "I'm still working on it" for a while, which I didn't see as particularly valuable.

Well, I'm back with an update so you can probably guess what that means - I've shipped!

So the first version of Box CI is ready now and the cli tool is available at

I've tried to make it as easy as possible to try it out, or even just have a look around, in a couple of ways:

  1. You can sign up and get a free month of usage, without a credit card.
  2. I'm actually building the boxci cli project with Box CI, and the project is public, so go check it out at no account required to just have a look and see how Box CI looks

Now, what does the MVP do? Because it is indeed an MVP - more features are definitely planned and this MVP basically delivers one - the original reason I wanted this to exist - the ability to run a build on demand from your machine and have the logs stream to the service.

That's what you're looking at when you look at the build for the boxci cli project. What I did there was run this command

boxci "npm run build" --project PT4369Z7 --key secretkey

And what that did was build boxci on my laptop, then create a build on Box CI and stream the logs -- that's exactly what you see when you click into the build. The logs show the tests and then the compilation of the boxci tool from the command above. On an aside, I'm genuinely really excited by how meta that is!! ;-)

So that's it, that's what the MVP does, and you can do the same for free (for a month ;-) by signing up now and building your own project.

Now on that theme, pricing. Pricing is something I thought a lot about for the MVP, because I found it a pretty difficult problem. The question was -- how can I price an MVP where all the following are true

  1. It's very easy and low risk to try out
  2. It's something that's useful enough for people to pay for
  3. It's minimal in terms of features, and certainly you get much less than you eventually will when more features are shipped
  4. It's early software, beta software basically. There will likely be bugs and downtime. It's not tested in practice outside of my usecase.

I guess this can all be boiled down to risk vs reward for early adoptors. What's going to incentivise anyone to try this and pay for it, in its simplest earliest form.

What I came to was my best shot at that - a special plan for early adoptors that charges a nominal amount of $1.99 per month that's not significant but, to meet (2), isn't nothing - but also with the first month free to meet (1).

(3) and (4) are trickier. The question is, how do you incentivise anyone to pay when they're getting a more minimal product than they'd get if they just wait. Part of the answer is making the price lower than it will be in future when those extra features are there, of course, but it's not enough. There has to be some long term reward too.

The idea is then also that early adoptors will stay paying really low rates forever. Because I don't know the sturcture yet of how plans will look I'm deliberately avoiding making specific promises around the costs but ideally I'd like to keep it as close to $1.99 as possible unless there is some very obvious reason that wouldn't make sense. In any case, my promise is that early adoptors will see that reward and will be looked after.

Another idea I've had is to actually help anyone interested in trying out Box CI get set up. I.e. I can help port the build from your current CI service to Box CI, either just going into your codebase and doing it or talking you through it on a call. This will be without obligation to continue using Box CI, of course, it's just to make trying it out easier and less risky.

Ironically one of the main selling points of Box CI is that it should be really easy to set up, but with that said, I don't necessarily expect early adoptors to just trust me one that.

After all, every CI service out there claims to be easy to set up. I've heard that claim before. I've also been the guy who 2-3 days of work & trawling through docs and forums later gives up on switching to that service because I just could not get it working.

That is to say, I more than empathise with an upfront assumption that a CI service port is going to cost a lot of time. Which is what I hope to de-risk by essentially doing it for you.


So now a word on this blog going forwards. Now the MVP is shipped, I have a lot of interesting stuff to do and talk about, including a bunch of things I want to talk about from this past 10 weeks! Most notably, why did it take 10 weeks and not the original estimated 3 to ship ;-)

I'm going to do it as a series of posts instead of one big mega post partly to not have to spend a full half day or something writing said mega post but also to get back into the routine of regularly writing posts.

But here's something I have learned from doing this blog in the initial weeks and then pausing it to focus: doing an update every day is, definitely, too much. It actually steals more focus than it adds I'd argue, and besides, as per the reason I paused the blog, there are often days when there just isn't anything discrete to talk about. I think a better format is shaping the posts around topics, not time period. That is, I plan to blog regularly, but I'll blog when there is something to write about, rather than writing about.. whatever it is I happen to have done on any particular day.

Quick startDocsBlog