BlueChilli

How a small team shipped 160 startups in 6.5 years

BlueChilli was a startup accelerator and incubator based in Sydney. The promise to founders was end-to-end: take your idea from a napkin sketch, validate the problem, build the product, and get it into the hands of paying customers. We ran quarterly cohorts of four to twelve startups, each following the same rhythm — six weeks of product discovery and design, then six weeks of build.

That cadence meant the engineering team was always building something new. Not iterating on a single product over months, the way most engineering teams operate, but starting fresh every quarter with a new set of founders and a new set of problems. Over 6.5 years, the team shipped more than 160 MVPs.

I joined in 2014 and left as Head of Engineering in late 2019. The story of my time there is really two stories: how the engineering team changed the way it worked, and how that changed what we were able to deliver.

Getting in the door

I was BlueChilli's first remote hire. I was also, technically, fired on my first day. The previous CTO had brought me on, but the CEO at the time was firmly against remote work. When he found out, the arrangement was off.

I flew to Sydney to make the case in person. Not because I had a plan, but because I was genuinely excited about the company and figured I had nothing to lose by showing up. We hit it off. He took the risk. That early trust ended up being the foundation for everything that followed — I eventually ran his entire engineering organisation.

Changing how the team worked

When I started, BlueChilli's engineering process was sequential. Designers finished mockups. Front-end developers sliced them into HTML, CSS, and JavaScript. Back-end developers implemented them. Each handoff added days.

The first change I pushed for was decoupling the front-end and back-end into separate codebases connected by APIs. I'd seen this work at We Are Hunted before Twitter acquired the company, and I believed it would work here. There was some resistance, which is natural when you're asking people to change how they build things. Rather than making a theoretical argument, I partnered with a teammate to prove it on a real project. We built a proof of concept that showed the value quickly. Once people could see the result, the resistance faded. My general approach to change is the same now as it was then: get in, ship something, show value. People understand what they can see working.

The shift let front-end and back-end engineers work in parallel. It also moved us from .NET MVC Razor and jQuery to React single-page applications, which opened up mobile development for the first time.

The bigger cultural change was getting engineers involved in product discovery. BlueChilli's broader agile transformation was a multi-year effort across the whole company. My focus was on the engineering side: moving developers out of a "build what's specified" mindset and into the room where product decisions were being made. We prototyped before committing to complex builds. We structured knowledge sharing so that lessons from one startup improved the next.

I was lucky to be in a flexible role that touched both halves of each quarterly cycle. During discovery, I worked with founders as a product and engineering advisor — helping them sharpen their problem statement and figure out what was actually buildable in six weeks. During the build, I was hands-on with the engineering team. That switch between product thinking and engineering execution, every six weeks, is something that shaped how I approach every project now.

The migration nobody wanted to start

The .NET Core migration landed during my time as Head of Engineering. Microsoft had marked the existing framework as end-of-life. We needed to move before the deprecation deadline or risk building on a crumbling foundation.

The team was apprehensive. Migrations are the kind of work that feels risky and unrewarding — nothing visible changes for the user, but everything can break underneath. The expected timeline was months.

What actually happened was simpler than anyone expected. Once the team started, once they could see the patterns in the first few modules, the fear dissolved and the pace picked up. We delivered in weeks. The lesson there wasn't technical. It was that the biggest blocker to a migration is usually the decision to begin. The early finish freed up engineering capacity that went straight back into startup delivery.

160 startups with a small team

Over 6.5 years, I personally led development on more than 24 startups. The engineering team never grew large, but we kept shipping. My path through the company tracked that evolution: senior front-end engineer, then front-end lead owning delivery and code standards for the team, then Head of Engineering — half managing the team and setting technical direction, half advising startup CEOs on product and technology strategy.

The external side came with the title too. I presented "Engineering at BlueChilli" to accelerator partners like Coca-Cola Amatil and shared our approach with other founders. But the work I'm most interested in talking about is what happened inside the team, because that's where the real leverage was.

Every process improvement translated directly into more startups shipped. Decoupling front and back ends meant parallel work. Engineers in discovery meant fewer wrong turns during the build. Knowledge sharing meant the fifteenth startup benefited from the lessons of the first fourteen.

What I took from it

After 6.5 years and 160 startups, the lesson I keep coming back to is that culture is the thing that makes everything else work. BlueChilli was perpetually underpowered on paper. The team was small, the workload was constant, and the pace never slowed down. What made it work was who we hired. The company selected for empathetic, kind, generous people with a strong bias to action and a natural instinct to lift each other up.

I've seen teams with better tooling and larger headcounts deliver less. The difference at BlueChilli was that nobody waited to be asked for help, and nobody optimised for their own output at the expense of the team's. That's the lens I bring to every team I work with now: the processes and architecture matter, but they only work when the people behind them genuinely want each other to succeed.