My Startup Journey: Reflections & Lessons Learned

Recently I started thinking about my time as an independent software maker and what effect that experience had on my career and to some extent my life as well.

If you were to compare my life before and after ReadyRoll, a tool I created over a decade ago with the goal of making database change management simpler, from all outward appearances it might appear very much the same.

In 2024, I’m still working in Enterprise IT, still focused on continuous delivery and even continuing to do so within the financial services industry. But for a time – about eight years all up – my career went off on a tangent that was the most satisfying yet arduous thing I’ve ever embarked upon.

Along the way, I got to learn from some extremely generous people who were kind enough to show this startup rookie the ropes, and others who took a chance on a complete unknown and entrusted their databases to an untested piece of software. I also came face to face with own limitations, some of which I overcame and others I did not.

Before ReadyRoll (<2011)

Prior to ReadyRoll, I was working for a point-of-sale finance company that specialised in computer equipment leasing. Faced with the combined pressures of falling equipment prices and the emergence of new fintech players, they decided to pivot to a completely different business model. This resulted in a huge shift in their tech away from monolithic systems towards microservices, which had a huge impact on how we would deliver software going forward.

In my role as build engineer, I found scaling up our database deployments to be the most difficult aspect of adapting to this change, and none of the off-the-shelf products we looked at seem to offer a complete solution to the problem:

• The commercial toolings on offer only seemed to focus on one part of the problem, like getting the database under source control, but didn’t lend themselves to automation at the scale or cadence that we needed to achieve
• On the OSS tooling side, the focus on automation was strong, but usability was sorely lacking

Frustated, I started working nights and weekends on something that I hoped would solve our database deployment problem.

The pitch

I say “something” because at this stage I hadn’t really come up with a way to describe what it was that I was actually building, let alone who I was creating it for. The more I thought about it, the more I found myself doubting the whole endeavour, so it was clear that I needed help with validating my idea. As luck would have it, Jason Cohen , founder of SmartBear and other highly successful self-funded software startups, was going to be hosting a pitching workshop at the Business of Software conference in Boston the following month.

I quickly signed-up and started drafting the pitch for ReadyRoll. I remember feeling a mix of excitement and abject terror at the prospect of presenting a 3 minute talk to a room filled with seasoned entrepreneurs including one that I greatly admired. The day before the workshop, I was able to steal a little time with software startup marketing guru Lisa Wells . She helped point out a glaring issue with what I had in mind so far: my pitch was too focused on what the product did rather than why it even existed. After all, why should anyone even care about improving their database releases?

I spent the entire night digging deep for some sort of narrative that would persuade a prospective customer that they needed ReadyRoll. I recalled a release that once went horribly wrong:

A change that was intended to rename a column in the contract management system actually dropped it instead, along with all of the customer data it contained. A brief but intense scramble followed to find the most recent backup tape (yes, tape!) and in the interim, the system was taken offline and an outage declared, preventing any new business from being written or customer data changes being made for hours thereafter.

We later discovered that the cause: a last-minute addition to the release that had not been properly reviewed. Part of the problem was that our tooling would recalculate the entire release script each time a change was committed, making it almost impossible to see what changed. We were effectively entrusting the safety of the company’s most precious asset to a black box, all in the name of saving a little time in the dev phase. To avoid a data loss event ever happening again, our team needed a way to take the ambiguity of the way we delivered database changes.

I was still refining and rehearsing the pitch in my head as my turn to present came up the following morning, and I remember being so nervous that I tripped over a chair on the way to the stage! Fortunately as I started my pitch my nerves started to calm down, and in spite of it still being quite rough around the edges, it seemed to go down quite well with the panel. Jason highlighted that I’d hit upon a point about safeguarding customer data that could be a great way to position the product from a marketing perspective.

The leap

So inspired was I from my trip to Boston that, immediately upon returning home, I decided to hand in my resignation and go full time with ReadyRoll . This was before I had had a single customer interested in the product, or for that matter used the product in anger myself. In retrospect I realise how impulsive this decision was, but at the time I was still single with some savings stashed aside, so it seemed like as good a time as any to make the leap. I figured that gave me a runway of about a year, maybe more if I cut back on living expenses.

As the clock began ticking, I felt compelled to focus less on “finishing” the product and more on just putting it in front of people. The first ReadyRoll demo I ever did was for Troy Hunt , who was actually writing articles related to database delivery at the time. I had previously responded to a piece he wrote about handling database changes and we stayed in touch after we realised we lived 10 minutes from each other. In spite of how rough the product was at that point, Troy offered some much needed encouragement and very generously helped with getting the word out. Over coffee Troy made the prediction that a certain database tooling vendor would eventually acquire ReadyRoll, something that ended up coming to fruition almost exactly 3 years later.

Entangled with an Octopus

I tried many things to drum up some interest in ReadyRoll, but in the end what really kicked things off was pairing with another startup by the name of Octopus Deploy , which was just out of beta and already beginning to see great success. After trying Octopus for the first time, I was inspired by how easy the smiling cephalopod made releasing applications through to Production, but saw an opportunity to enhance the database deployment side of the story.

I quickly made an integration that would allow customers to start deploying their databases with just a few clicks and messaged its founder, Paul Stovell , to show him what I’d come up with. Within minutes I got an excited reply back. It truly seemed as though Octopus was the missing piece in the ReadyRoll story, and perhaps vice-cersa.

This hastily cobbled together integration and subsequent good will from Paul was the turning point for ReadyRoll, the moment when it stopped just being an idea and became an actual product. Three months after that leg-up from Paul, and 18 months since git init, ReadyRoll finally had its first sale.

Tasting the dogfood

In spite of the wonderful boost from the Octopus integration, sales were still at the tiniest trickle and I was on the verge of completely running out of dough. Consequently, I ended up having to take on contract work to keep the lights on. But at this point product was receiving enough buzz to persuade my clients to let me try implementing it in their teams. What initially felt like a major setback turned out to be a blessing in disguise, as the opportunity to dogfood the product on a customer site would prove invaluable: it showed just how god awful the product was to work with.

Before adding any more product features, I decided to stop all work and focus on what I could take out of the product first:

The biggest UX issue seemed to be with ReadyRoll’s scripting tool, which supported both an offline and an online workflow. If one followed the happy path and always completed an offline workflow before starting an online one, everything would work fine. However, it would often be necessary for the user to stop mid-flow and back out the most recent changes, which resulted in them getting totally stuck (akin to what happens in Git if you rebase --interactive but neglect to --continue or --abort). Clearly I had overcomplicated the product by including two contrasting workflows and so a decision of which one to keep and which to chuck was needed.

Fortunately, I’d been able to witness first-hand which workflow my client valued the most and consequently decided to cut the offline workflow completely; a decision that made a night-and-day improvement to the tool’s usability.

This whole exercise taught me that sometimes paring the product back, as difficult as it might be to remove a favourite feature, is a necessary part of creating a product that people love to use. The uptick in sales certainly suggested that this was the right move.

Good times start to roll

The period that followed was without an absolute doubt the most enjoyable part of the whole ReadyRoll story. Getting to know some of my customers and witnessing first hand the impact ReadyRoll was having on the way they worked was an absolute joy.

One of my favourite memories is dropping into the offices of Spotlight, an iconic talent agency near Leicester square in London, and seeing how the team, headed then by Dylan Beattie , were using ReadyRoll as part of their database release process. After swapping notes we headed out to a freehouse where I tried a proper British ale for the first time, which, temperature wise is still something I’m getting used to!

I also took a trip up to Ipswich to visit the team at Ludologic. Richard , Roger and his team started off with just a couple of licenses but seemed like every month they would need one or two more seats to accommodate their growing needs. Eventually Ludo ended up being one ReadyRoll’s biggest customers, and with all the experience they gained through all their releasing, they became a huge influence on how the product subsequently evolved.

Most of the interactions with customers I had other than that were primarily via email support, and in time I got into a good rhythm with managing the support queue, developing new features and blogging about new releases. The ability to turn around a feature request in a day and completely take a customer by surprise was a pleasure beyond compare.

Hitting a wall

However in spite of all the progress ReadyRoll had made, sustaining and building on that success would proved elusive. Business from month to month was bit of a roller-coaster: one month sales would be strong enough to make me consider giving up contracting work, the next month they would tank.

Looking back, it seems I had fallen into a common trap that a lot of engineers-cum-entrepreneurs fall into: not charging enough. I realise now that probably needed to try a different approaches to pricing than the perpetual licensing model the product offered. At the time I was worried about charging differently to my competitors, but this overlooked the fact that ReadyRoll offered a more complete solution for its target audience than any one product at the time, meaning there was probably untapped value to be had there.

There are also product design reasons that likely affected ReadyRoll’s success:

• Being too closely tied to one IDE (Visual Studio)
• Not having an easy-to-use command line interface (not counting its rather clunky MSBuild integration)
• Only having support for one database platform (SQL Server)

Aside from these limitations, the learning curve involved in adopting ReadyRoll (especially when onboarding complex databases) meant that only the most dedicated individuals got past its initial quirks and got to see the real value that the product had to offer.

Not knowing what to do to make ReadyRoll a genuine success, I started to become disheartened. The amount of time I was investing vs the results I was getting just really weren’t adding up anymore. And to be perfectly honest, I was really quite lonely. I didn’t have a business partner I could bounce ideas off, nor did I have someone who I could share my frustration with at the end of the day.

After nearly five years of ReadyRoll, I had hit a brick wall.

New beginnings

It was around this time I met my wonderful partner, Mattias. After being on my own practically my whole life, suddenly I had someone I could see the world with and experience all the highs and lows that life has to offer. In September of this year, Mattias and I will celebrate 10 fabulous years together.

In a sense, the timing was actually quite fortuitous, as it was clear that I needed some quality time away from ReadyRoll. This gave me the space to properly ponder how to help the product find its audience, even if that meant handing it over for someone else to take it on. It was with this frame of mind that I headed back to Business of Software conference in 2014.

It was over breakfast that I bumped into John Theron of Redgate Software. Redgate were looking for new ventures at the time and he indicated that ReadyRoll could be a good fit for them. I was a little surprised by that, given that in effect ReadyRoll was a direct competitor to Redgate’s set of database deployment tools. But I was excited by his invitation to visit the Redgate offices and wanted to meet the team behind the products that in many ways inspired me to create ReadyRoll.

Do over?

The next months started a very different chapter of this story, one that probably deserves a blog post of its own. Suffice it to say the time I spent working on ReadyRoll was without a doubt the most challenging yet satisfying and rewarding few years of my whole life, and there’s not a day that goes by that I ponder, should I do it all over again?

While I don’t have regrets about any part of the journey, there are definitely times when I questioned whether the startup life was the right thing for me. In the years since ReadyRoll, I’ve discovered the joy and the reward that comes from collaborating with others. So if I managed to find someone to share all the highs and lows with, I would seriously consider giving it another go.

In addition to the support from the people mentioned above, I’d like to call out a couple of other people who made a tremendous impact on ReadyRoll during its fledgling days**:

• Colin Byrne : possibly the bravest chearleader of all, Colin championed ReadyRoll’s first full adoption on a client site in the earliest days
• Rob Sullivan : one the product’s earliest adopters, Rob helped get the word out in the database administrator community and was great company at SQL conferences too
• Doug Rathbone : thanks for being a wonderful sounding board when I really needed it and for introducing me to some other very smart tech people here in Sydney
• Luke Rogers : one of my favourite customers, your insightful feedback had a big influence on the product’s direction and also shaped the way I now think about database delivery

**Apologies all round to the many fantastic people I’ve no doubt neglected to credit in this blog post. I promise to take you out for a 🍺 so you can jog my dwindling memory.