We were also working on the fringe website. We integrated the website with the brand spanking new ticketing system - which cost nearly £900k.

We were also hosting websites for Boots, Kellogg’s Food Service and dozens of other clients.

All of this was held together by three or four developers, two systems administrators and me.

On the 13 June (incidentally, I got married on the same date years later), as I was just getting ready for a wild night on the town, a call comes through - which John answers.

I still remember them laughing and then doing a double take “oh, you’re serious? let me get Shri”

It was the fringe. We’d already known that they were having trouble with their ticketing system. I’d even pitched in, made suggestions - looked at their code to try and help, but none of that was enough. I expected an update.

They wanted to know if we could put together an interim booking system for them over the weekend. I wasn’t sure. I told them I’d speak to my team and get back to them.

I wasn’t involved with the work on the fringe up until this point. I knew very little about it. I was focused on megabus.com. The US version of the site had a big marketing campaign happening in a few days and that was what I was meant to be focused on.

By the time I put the phone down, Chris, who had been the lead on the fringe already had a answer. “We can do it!”

“But how - it’s got to take more than a weekend - right?”

The fringe website was already built well and had a clean layer interfacing with the new ticketing system. In fact, that was the bulk of the work that year.

So.. Chris told me - all we would have to do is to implement the functionality within that thin layer, fattening it up.

He believed we could do it. I believed him.

I hopped in a cab, headed over to the fringe to talk it through. I didn’t promise them we’d be able to get something ready by Monday, but I promised we’d do our best.

We were in the office on the weekend, writing code. I remember working on the basket, sending diffs over email and generally having a good time.

I even had some megabus US fun to keep me entertained in the form of issues with loading sheets - I was already in the office, so it was one step easier to fix.

One of the bits of functionality which took a surprising amount of time was the seat allocation. None of us had to worry about that before - it was just capacity management on megabus. For the fringe though, we had to allocate actual seats with seat numbers and everything.

With the fringe we had multiple tables which all joined together (thanks hibernate) to encode a tremendous amount of detail about the seating plans - including their physical location on a map.

It was too much detail for us, so we had to simplify it all down to get it working in the timeframe. We kept most of the rest of the structures intact to keep the data migration easier once the ticketing system was fixed.

By Monday, we had each managed at the most 6 hours of sleep each of the previous three nights. I still have vivid memories of a suit of armour that we put together using packing material while we were waiting for bits of data or details of logic.

I broke the MySQL replication at 01:24, fixed by 01:32

I remember the delirium setting in. Email sent to the client with “fun fun fun fun fun fun fun” as the subject

There were random emails to my brother “I’m still here!”

I also remember making makeshift beds with bubblewrap to get a wee nap here and there. We were all so exhausted - pumped up on coffee and nicotine.

Finally at 03:35 on the Tue email to client: “DONE DONE DONE DONE DONE NODE NODE NODE NODE”

Then at 05:33, requesting a PostgreSQL server rebuild for megabus US for their marketing campaign.

At 10am on Tuesday, the fringe is finally able to sell tickets. The website promptly fell over from the load, but we nurse it back and it sells 65k+ tickets in the first week.

It would be at least two more weeks before the ticketing system is fixed and brought back in.

For the work we did for them that year, and the previous one, we effectively only charged about 30% - because that’s all they could afford. This year, we asked if they could put our name on the website.

Over the next two weeks(while megabus US was on their marketing campaign), we fought many battles. There were 750 duplicate bookings. Numerous customer complaints (thanks to our name being on the website) - almost all of them blaming us for the failure of the ticketing system. People did not understand that we put in the interim one, not the one that failed.

Press releases went out from the fringe - only two credited us. Both misspelt the company name. Both called us a web design company — which, we were not, had never been, and had no interest in becoming.

In truth, I wanted to be a hero - I think we all did. What we really wanted was an acknowledgement of what we had done - which was nowhere to be found. We got paid though - at least for a part of our effort.

For many years after that, I would tell people with pride - “did you know - I saved the fringe, back in 2008,” which was inevitably met with something like “oh, did they have a problem that year?”

It started off small, and little by little, I carried more and more. I became we, and we carried more and more. Before we realised, we were carrying a great deal. Ultimately, though, if something went seriously wrong, it would be on my shoulders.

The chart does not capture the scaling of the organisation, or other departments like tech support or hosting, which had dozens of clients.

The section at the top is the number of active committers for that quarter. You can see my on my todd at the start and the rise and the fall of the dev team.

The very peak of it was in 2008. We built a booking system over the weekend for the Edinburgh festival fringe because their brand new £800k+ system could only handle one person at a time.

There were a handful of us building it while I was simultaneously prepping and managing the megabus US systems for a sales campaign. At the same time we were operating megabus across the UK, USA, and Canada, Oxford Tube, Coach USA, the Fringe website itself and numerous other smaller hosting clients like Boots, Kelloggs Food Service, and so on.

We were a total of ~4 developers and two systems administrators holding all of these together.

I was recently reminded of a story a friend of mine told me. Before he was my friend, he worked with me, and one of the things we did together was one the big megabus deployments when we migrated to a Java EE ticketing system.

One part of the migration was the data. I had developed a tool to migrate the data and on the evening - everything was prepared, we were off peak, and we had taken the site offline. He ran the script, which went on for a wee while and it failed. It was not meant to do that.

The way he tells the story, he told me about the failure. I come over, look at the errors, say “hmmm, that’s interesting,” and head off to have a cigarette. A few minutes later I go over to my desk type away furiously, then asked him to run it again.

It worked, and completed.

I remember that night. I don’t remember what the problem was or how I fixed it, but I do remember that moment when I went over to see how it had failed. In the short walk from my desk to his, I reiterated in my mind, all the possible backup plans - with the worst case scenario being to call off the migration on that day. We would do it another day. It would cost money, but it would be do-able. I was ok with that.

I was curious as to where my limits were, so I kept pushing, until I would meet with a wall.

There were no rails and there were no railings - just a cliff edge, unmarked… I didn’t know that - I expected a brick wall.

The worst of it would be only a few years later, in 2011. We built a new Java EE ticketing system for a fraction of what it should have cost in about 30% of the time it needed.

I personally responded to over 250 out of hours emergency tickets over an 18 month period. That was hard!

I had run off a cliff edge, and like the roadrunner in the cartoons, it took a while before I realised there was no ground beneath me.

A few years after I ran off the cliff, the company shut down. A few years later, I would start my active recovery journey through therapy. A few years later still, when I felt ready for a leadership role, I was asked to lead a problematic team - a role they struggled to fill for a while.

The team worked hard and delivered but struggled with the perception of poor delivery. Trust was thin, stress was high and morale was low. The situation was so bad that the week before I was supposed to start, the scrum master who was supposed to be my guide through it all quit.

I was warned by multiple people that this job was loaded with problems. I took on the job anyway, without a real guide, straight into multiple serious issues.

I loved it and managed to turn the whole thing around in my first week. Delivered key items, laid the foundations of trust and improved morale. It took a bit longer to bed everything down. Within weeks, I was asked if I would take on leading the entire digital team.

It was here, many years later, I got a sense of how unusual it was for such a tiny team to do so much.

It was here, many years later, I got a sense of how it is to have guardrails, to have support, peers to lean on.

It was here, for the first time I realised that the job didn’t have to be a lonely one.

I was 22 years old.

When I built the original prototype for megabus.com, I built it using PHP + PostgreSQL. I put together a document detailing my reasoning for these choices. I quoted 33 days for it, built it over six weeks and charged £13,200.

The support contract was £350/month - for one day a month. On the first day, megabus.com sold 200 orders.

When megabus had its first expansion, I was up overnight bringing new servers online and scaling it live. I loved it - my code was finally being tested.

Over a week, I’d probably burned through many days of effort. I remember the project manager specifically asking me to invoice for the extra work I put into it. I even said that I would - except I didn’t.

I’ve had a long time to think about this - why did I not send that invoice? I even had approval.

The answer, as with most things of this nature is complicated. I loved the work and I didn’t want it to end. I didn’t want a potential conflict trying to figure out what a reasonable amount was to charge. I felt that I should have done a better job in the first place - I felt responsible that I had not told them that scaling of this nature would not have worked without prep work.

I had not scaled anything before.

I was 22 years old.

I was super grateful that someone believed in me. I naively assumed that they saw all the extra effort I was putting in and that they would reward me for it - that they would have my back.

I remember adding a bunch of different bits of functionality because I wanted it there. I didn’t want to go through the process of quoting for it, and it getting potentially rejected, not to mention the waiting for decisions. One key bit of functionality I remember is adding in a percentage load column for the loading sheets. I built it, showed it - they loved it! It went live. I did not charge for it.

At this point, the vast majority of my time was spent on megabus - very little of it actually paid for.

At a glance, based on the emails sent, I probably spent a minimum of 10 days each month supporting megabus when I was charging for one day.

In Jan 2004 - I proposed doubling the contract to two days for £4,800/year. It probably kicked in in Feb 2004. By March 2004, the site exceeded that revenue each day.

In the following months, I probably spent, on average a minimum of at least double the time I was paid for. I should have charged for it.

I grew the team, and the support contract based on the minimum I needed to maintain the product - not based on the amount of time I was spending.

For my 28th birthday, my girlfriend at the time organised a cake which was a image representing kraya - which was basically megabus. I felt bad that she thought that kraya was the most important thing in my life - she was right - but it still felt bad. kraya had other clients at the time, but my time wasn’t monopolised by other clients, or indeed by kraya - my heart still belonged to megabus.

And it would all have been fine too, except for a grave miscalculation I made.

In 2010, after trying to rebuild the ticketing system for £500k, and making some mistakes with people I trusted, kraya ended up in £150k in the hole. We needed some money urgently.

I was desperate and naively, I reached out to stagecoach for help. I thought they were my friend - that they would have my back.

They understandably lost a great deal of trust in my ability to manage and lead my company. I trusted the wrong person - but that was still my mistake. They were right.

I thought that I’d built up enough goodwill that they would help me through this. I’d felt I would have way more than that “in the bank” in terms of goodwill. I learned that professional relationships do not work that way that dark afternoon, standing outside my office on the phone, in the rain.

They didn’t make my life easier. Instead, I’d ended up rattling the cage - they were now panicked - realising their over-reliance on an organisation that could disappear at any point.

Instead of support, I had further actions, renegotiating the contract and what felt like punitive, and definitely invasive reporting obligations.

I was hurt and angry. I had poured my heart, my soul - hey, my very life into this product that I loved.

Suffice it to say - I got no help - no loan, no offer of investment - though they did suggest buying us outright - which I rejected.

I signed a contract under circumstances I would not wish on anyone.

The best I got from them was a challenge - if we were really spending more time than we were charging for - prove it. I did! We documented every minute we were spending - I wasted my time on spreadsheets, pointless meetings and work to try and rebuild the broken trust.

We went from £300k in the hole to £200k profit within a year. We charged for a whole year in support around 20% of what the system made in a day.

I was 28 years old.

Around the same time, I was also dealing with the operational aftermath of trying to build a java EE ticketing system over six months for £500k. I thought it would take a year and cost £1m. In hindsight, it needed two years and probably three million pounds.

Over 18 months, I personally answered over 150 out of hours emergency calls. We had a rota and others on call too - but I took the vast majority of these calls. I felt bad putting others through what I knew was gruelling.

All of this led me down a narrower and narrower path to a serious breakdown - though I didn’t know enough to name it until many years later. All I knew - all I felt was that something broke in me.

We managed to resolve all of the issues, but the deployment of that version kept getting pushed.

Stagecoach cancelled the contract in 2012. They had started building a ticketing system in-house two years prior - the cost of my grave mistake. I wasn’t able to make the meeting - I was in India, and at the same time as the meeting, I was meeting for the first time the one who is now my wife.

I was 28 years old. I spent the next 15 years putting myself back together.

How much did it cost them to build it inhouse? If I had charged for my time from the start, would we all have been better off?

I still feel something deep inside me every time I see a megabus - a sense of pride mixed in with a deep sense of sadness - not for what I lost - but for what could have been.

I am 44 years old, and I am starting again.

The team had already written a lot of stuff in Spring - but I really did not like it. There was all this XML all over the place which was annoying, but what I really didn’t like was that the code and configuration for each component was spread out all over the place. It meant that to understand how something worked, I had to go hunting. Eventually, I got sick of it, and ported it to EJB myself.

Later in the same interview, he said: “I know people like you - you come in, shake things up and get things done - but that’s not what I’m looking for.”

He was right. I understand that. But I’ve been thinking about what he was actually describing.

When megabus.com was still a PHP site, search was the problem. It returned quickly when the database was healthy and crawled - and slowed down when the database was struggling. The load came in spikes. Even within a minute, there were peaks and troughs.

My fix was simple. Before the search query ran, I added a small SQL check: how many queries are currently active on the database server? If too many, wait a second and try again. A few retries, then send it anyway.

A rate limiter baked into a search algorithm, written live on a production server.

There were edge cases to consider, not to mention the load the rate limiter would add to the database server. I knew though that if it broke, I could fix it - I could just remove it - live, if needed. Not having the rate limiter was at the time, more expensive than having it.

It worked. It got us through more than one hump.

The database was still the ceiling. We were on PostgreSQL 7 - no replication support. Getting a more powerful server was possible but disproportionately expensive. So I built something.

Two database servers. All writes went to both. Reads were distributed randomly between them. Everything funnelled through one section of code.

I didn’t do this live. I tested it. I knew what failure looked like: if the servers diverged badly enough, I’d pick a primary and reset the other. That was the contingency. It wasn’t a safety net someone else would pull - it was mine.

The data integrity held better than I expected. Under very high load there were edge cases - ticket IDs for the same customer could be in a different order across the two servers on a return purchase - but because the IDs were consistent within each server, it never caused a real problem. It held the fort until I could replace it with something better.

I occasionally lie awake at night imagining the databases diverging and figuring out how I would fix it.

I picked PostgreSQL over MySQL when MySQL was the obvious choice. Under heavy load it stays up — it slows to a crawl, but it keeps going. And it had transactions. I was building an ecommerce site; I needed transaction support. MySQL was fast and popular. It also had a habit of giving up under sustained load. I still pick PostgreSQL - but nowadays, so do most other people.

The thing these decisions had in common was that I was the person who’d be fixing them at 3am if they went wrong. When you’re personally accountable for the consequences, the risk calculus changes. You think harder about what failure looks like. You build the contingency before you go live. You know which direction to pull if it goes sideways.

Caution that’s never personally tested isn’t rigour. It’s consequence-avoidance dressed up as responsibility.

“I know people like you - you come in, shake things up and get things done - but that’s not what I’m looking for.”

We had one ADSL connection coming into the office and three of us. I wanted to share the internet. Windows NT didn’t support it cleanly — it had a way, but it was clunky enough that no internet was arguably better. We’d paid hundreds of pounds for it.

I’d heard about Linux. Downloaded Red Hat, installed it, configured it for NAT. It worked — it was like magic. I’m pretty sure I had to recompile the kernel to get some bits working, but there were instructions and they were honest. It did what it said.

Here was software that was completely free — free enough that I could read the source code, make changes, run it however I wanted. It did more than the hundreds of pounds worth of garbage sitting on the desk. And once I set it up, I never had to restart it. Never. Compared to once a week on the NT box.

The difference, in my mind, was simple. Linux was built responsibly. NT was built as a money-making enterprise.

That held for a long time. I moved to Debian, then celebrated when Ubuntu arrived and made things more accessible. I’ve recently been able to abandon Windows altogether — gaming on Linux is finally viable. I came back full time and felt mostly at home.

But there were minor niggles. Things that felt slightly off but that I couldn’t quite name.

Then I started digging into systemd.

I remembered feeling odd about having to run specific commands to read logs. Odd about one tool doing many different things — which ran contrary to the Unix philosophy that had made Linux what it was. When I looked into the history of the opposition to systemd, it was revelatory.

systemd becoming process 1 is, in a word, irresponsible. It makes everything easier and more accessible, which is why it won. But unlike the Linux of old, the tradeoff isn’t visible upfront, and there’s no real choice. The responsible option isn’t the default anymore — it’s the thing you have to go looking for.

I thought I had already done the work. I thought I had found the alternative.

While I was celebrating Linux becoming mainstream, I hadn’t considered what it would cost.

The Linux ecosystem had started optimising for mainstream at the expense of responsibility. It works now, for far more people. But it’s a different thing than it was. When linux was really taking off, there was a joke going around (before memes were called memes) about Microsoft Linux. Turns out the joke was on us!

It is always a tradeoff between security and convenience — something convenient is rarely secure, and vice versa. I think something similar applies to responsibility. The more accessible you make something, the harder it becomes to hold the line on what it was built to do.

There was a time when software going wrong meant losing your work. Now it means losing your money, your reputation, or — in a car, in a hospital — your life.

The context has changed. The attitudes haven’t. And the places that once had better attitudes — the ones built on responsibility, on craft, on caring about the thing itself — are being pulled in the same direction. It gets everywhere.

Do you want your car running Windows? What about systemd?

This isn’t about any of that.

It’s about the fact that none of those decisions show up in the metrics that matter to the people making hiring and delivery calls. The cost is immediate and visible. The return is delayed, quiet, and arrives in the form of things that didn’t happen — the investigation that took two hours instead of two days, the API change that didn’t bleed into the domain model, the bug that the structure caught before it shipped.

Sprint velocity captures the extra day. It doesn’t capture what that day bought.

This is not a new problem. Most engineers who’ve been around long enough have felt it from both sides - made the careful call and got measured on the slowness, or inherited the codebase built entirely for speed and paid the tax. The measurement system was already broken. It has been rewarding the appearance of velocity over the thing velocity is supposed to serve.

This was true long before anyone was generating code with AI. The PR process in a lot of teams was already largely theatrical — review comments on naming conventions while the architectural decisions slipped through unquestioned, approvals given because the diff was too large to meaningfully read. The gate was already not doing much. We brushed it under the carpet and moved on.

AI tooling is changing the volume of code moving through that process by an order of magnitude. The pressure to remove the gate entirely — to trust the output, to ship faster - is only growing. The faster-is-better incentive that was already making review ineffective is about to be handed a much larger surface to work on.

Many years ago, I pitched full redevlopment of a ticketing system from a PHP based system to a Java EE system because it was struggling to scale.

It probably needed a couple of years to build. They wanted it in six months. I accepted the challenge.

We built and deployed the system in eight months. We spent the next year fixing it.

The client then rebuilt it in-house.

When AI runs this experiment at scale, who takes it back?

It collected structured metadata about games - tags for features, screenshots, videos, reviews. Users contributed information. We gamified participation and rewarded it with games and gifts.

It started making money through “similar games” lists.

All of our traffic came from Google.

Then we needed more revenue.

So we did what teams do.

We added features.
Integrated Steam, Xbox and PSN.
Pulled in achievements.
Expanded recommendation lists.
Tweaked advertising.
Worked on SEO.

Traffic crept upward.

Still not enough.

Eventually we decided the problem was perception.

The site looked too much like a community project. It needed to feel more premium. More authoritative. More modern.

So we renamed it.
Changed the domain.
Redesigned it from the ground up.

Months of work.

We launched.

Traffic collapsed.

We never recovered.

In hindsight, the failure wasn’t technical.

It wasn’t branding.

It wasn’t SEO.

It was that we never made a hard decision about what the product actually was.

Was it:

• A participatory community?
• A structured data engine?
• A search destination?
• A content property optimised for Google?
• A recommendations platform?

It was all of them.

Weakly.

What Google valued wasn’t polish. It valued volatility.

Our homepage changed many times a day because users were contributing.
Those contributions created fresh internal links, fresh content, fresh signals.

Participation was the engine.

When we redesigned for the information consumer instead of the contributor, we stabilised the surface.

We accidentally killed the engine.

We optimised the visible layer and ignored the system feeding it.

I first heard the phrase “we’ll fix it in post” from my filmmaker brother.

Something wasn’t quite right during filming, but they moved on anyway. It could be corrected later.

In film, that’s sometimes true.

In product development, it’s usually self-deception.

Lean encourages delaying decisions to the last responsible moment.
That’s discipline.

What most teams practice is delaying decisions until they become painful.
That’s avoidance.

An MVP is not the smallest thing you can push out.
It is the smallest thing that is coherent and viable.

Viable means it has a clear shape.
It respects constraints.
It closes more questions than it opens.

If you ship something that only works on the happy path, with undefined edges and postponed trade-offs, you haven’t preserved optionality.

You’ve preserved ambiguity.

Ambiguity spreads.

In code, as defensive layers.
In design, as half-committed patterns.
In product, as multiple possible futures carried at once.

Teams don’t slow down because they’re weak.
They slow down because no one chose.

Every postponed constraint becomes cognitive load.
Every “temporary” rule becomes precedent.

Lean does not say “don’t decide.”

It says: decide at the point where delaying further increases cost.

Most teams drift past that point because deciding feels like loss.

Loss of flexibility.
Loss of imagined futures.
Loss of political safety.

But momentum comes from commitment.

Once something is decided, energy frees up.
The system becomes legible.
Subsequent decisions compound instead of conflict.

We didn’t fail because we built the wrong feature.

We failed because we never chose what we were.

Most startups don’t die from lack of effort.

They die from unmade decisions.

“We’ll fix it later” is not iteration.

It is hope disguised as strategy.