Haplo Retrospective

This is a work in progress, last updated 2 Dec 2021. Send feedback or subscribe to updates.

About Haplo

In the early days, we got a lot of advice. It was useful. But we quickly learnt that you can only use advice if you understand the experiences of the person giving the advice.

After a while, we’d say to each other “all advice is autobiographical”, a sort of shorthand to remind ourselves that any advice is mostly talking about things which worked for someone else… in very different circumstances.

This is Haplo’s autobiography. It’s the background to show how the decisions we made were enabled, and constrained, by the context we were working in. Pick the bits which work in your environment.

That said, I am convinced that kindness always scales. It won’t be possible to do everything the way we did, but you must always build a respectful workplace where everyone is valued by everyone else.

Bootstrapped

We never took investment. “Ah, so you’re bootstrapped”, people in the startup scene would say to us. I never liked the term, especially as it always seemed to be followed by a dismissal of us as a “lifestyle” company.

This lack of investment was our biggest constraint, and it forced us into thinking very carefully about how we used our limited resources. I’m not sure, though, that it ever really prevented us doing anything that would have given a better outcome.

In the years since we started, the world has changed. It’s much harder to avoid investment now, and realistically you either limit yourself to never scaling beyond the team of founders, or you take investment.

Slow start

Not being pressured by investors also enabled us to do completely the wrong thing, and accidentally build the foundations which would enable us to grow when we finally worked out what the right thing was.

Our original goal was to build a highly configurable system which would allow any organisation to manage their information effectively, as a by-product of using tools which made their day-to-day working lives easier.

Unfortunately, this is a terrible business idea. Not least because it’s incredibly hard to sell something so generic.

Yet, we persisted for years, as we had just enough success to keep going. Then one day, we were introduced to universities, where we found everything we had built solved problems perfectly.

At that point, we started to grow the team beyond the two founders.

Team building

We decided on a strategy of hiring developers early in their careers. As with everything we did, we did it because it felt like the right thing to do. Someone has to start people off in their careers, and experience has to be gained somewhere. But also, if we’re being honest about it, they’re cheaper.

Soon though, it became our competitive advantage. Because we’d built an organisation around learning and support, we could offer them a workplace where they’d learn fast and progress rapidly. It was a compelling offer, and enabled us to recruit amazing people who learnt quickly and pushed our company forward.

Of all the things we did, I am most proud of the team we built together. Each and every one of them excelled individually while lifting the team as a whole.

A research administration product and service

Our product was a multi-tenant software-as-a-service product, where we ran highly customised applications on top of a common product. We used design patterns which made it easy to build these applications by assembling building blocks of functionality, and controlling them through small amounts of code on top.

Therefore, the business had two main functions, product development, and professional services to implement them. We mixed the two together, so people would work on implementations which drove product development.

We had several products, which were delivered as a single fully integrated application. Each colleague would be nominally assigned to one product, but the common foundations meant they could easily move between them. There would be one developer who would “lead” each product, and that leadership would naturally emerge from the flat structure.

Two companies

As it turned out, the acquisition of Haplo by Cayuse was the second significant acquisition of a company built on top of our technology.

The core Haplo platform enabled one of our early customers to build another valuable business in a market unrelated to research or universities. After we started their product development, they quickly took over and built their own development team. At the end of 2020, they were acquired by a huge US corporation a few months before our acquisition, and I’m pleased that the use of Haplo Platform has expanded within the combined organisation.

New leadership

The beginning of the end of our leadership of Haplo was prompted by two things. We expanded overseas, and a pandemic happened. Both put a lot of pressure on the founders and the team, and it became clear that investment was required and the organisation needed to be restructured.

Our flat structure and deliberate avoidance of specialisation only worked up until a point, and the Cayuse acquisition reorganised things along more usual lines. Specialised roles were added, and the product and implementation functions were split into separate teams. While being a generalist is a great way to learn quickly, specialising made the whole process easier.

It has been wonderful to watch the new leadership take over, and use the principles and culture we put in place to take their work to even greater success.


Table of contents