Puck / Measured

Puck, an open-source project, has exploded in popularity, becoming a major focus for Chris Villa and his team. But how do you balance a runaway open-source hit with the demands of running a consultancy? Join Ben Rometsch as he sits down with Chris Villa, co-founder of both Puck and Measured, to dissect this very dilemma. Chris reveals the fascinating origin story of Puck, its meteoric rise, and the overwhelming "pull" from the community that signals a powerful product-market fit. Find out Chris and his team's bold plan to spin Puck out as its entity, poised to take the project to even greater heights.

---

It's a dreary day here in London, and I have a British guest, which is unusual. Chris Villa, who's in Brighton. Chris, since I'm speaking to a fellow Brit, what's the weather like?

Equally dreary. This is in the south of the UK near Brighton, and it's supposedly called the Sunshine Coast, but it's normally pretty gray.

The Development Of The Open-Source Project “Puck”

It is like autumn's coming. Welcome Chris Villa, who has got an interesting, very similar backstory to me that we have been discussing, both in terms of our nationalities and maybe career trajectories with regards to open-source and commercial. Chris, welcome to the show. Do you want to introduce yourself and give everyone a bit of a background on who you are and where you've come from?

Thanks for having me on. I'm working on an open-source drag-and-drop visual editor for React called Puck. It's been quite an interesting weaving career that's led me to this point. The first thing to say is probably I have never had a full-time job. It's pretty much out of university, and before university, I have been freelancing and contracting and trying to spin up different businesses to varying success.

A lot of indie hacker vibes. I have done some small fundraising rounds of stuff. I was always in this state of "I want to do a product," and my contracting and my consultancy, doing all kinds of full-stack web development, was a means to an end. Then over time, it was during the pandemic, I was with two other guys, Scott and Paul. We were all working on a client together. That contract and it was pandemic chaos, had a gap, and in that gap, we decided to form a consultancy called Measured. We'd been working together on quite a few different projects for Thomson Reuters, for BT, quite big brands BT as in British Telecom.

The ex-state telephony operator who, as an aside, was probably the most successful privatization model of the Thatcher era. They made a complete mess of all the others to the point where they are pumping sewage into beautiful lakes all around the country for those that don't know British Telecom, who is a massive entity, and the government did a good job of breaking up that company into component pilots, privatizing them, and now we have got good internet and cheap mobile service. A huge client. Your client list on Measured is crazy impressive.

Thank you. I don't quite know how it happened. It did. Over time, you start to accumulate these big companies.

Agency life is like that. It's a function of time and effort, but mainly time, I find.

It's mainly time and luck. Paul and Scott have been in the industry for longer than me. You should see their CVs. The client list that they have is immense. We wanted to focus on this niche of design systems. That was the thing that was very hot and trendy at that point in time, and we had a very specific approach to that because design systems are quite a broad term. They mean something different to everyone. We had a specific way of building these systems that worked well for our clients, and we wanted to double down on that and scale that out across more clients and just see where that took us.

That was in the pandemic when we started that. Quite quickly, we started landing clients through our network some design system stuff, but also a lot of more long-running, almost technology partner stuff building a lot of products, helping steer their overall technology strategy. At some point over that, we landed Hilton Hotels to build essentially a drag-and-drop visual editor for React.

There's a little bit of history there because I'd worked on the same project a few years earlier, and at that time, the project hadn't succeeded. Then there was a gap of a few years. Hilton came back and asked, "Do I want to come back and build this again?" By this point, I'd founded Measured. I said, "Only if you can bring in Measured." We went through this long, painful six-month enterprise procurement process. Two and a half years later, we are still working with them.

Puck as a project open-source project is not what we are using at Hilton. We have built some proprietary tools. They had a very complicated stack and specific needs, but it is inspired by all of the learnings from doing it several years ago and over the last couple of years doing it more. It's a slightly different space to pure design systems, but there is a lot of overlap.

Moving Beyond A Superficial Understanding Of Design Systems

That's a great question, how would you define what a design system is? I think a lot about Figma and upset designers when someone's changed the padding on a button and things like that but that's probably not a reliable definition.

I don't know if there is a good definition. That's part of the problem. Everybody has a different idea of what it means. Designers often think a design system is a Figma library and some Figma docs. A developer might think a design system is a component library. Someone from content might think a design system is words and a website. It's all of those things and none of those things. A design system is what the individual organization needs rather than a predetermined set of tools and approaches.

‍

When we talk about building or working in design systems, we are working in that space but the thing that we tend to try and build is something we call a UI system. We focus on the UI layer, and we advise on how they might optimize their design ops. How do developers and designers communicate? How does content fit into that? How do you document all of this?

We have a very specific approach for that UI system slice, which in our heads includes components and Figma or their design tool and figures out how to keep those in lockstep, how to keep them in unison, and how you document that and scale that out across your digital experience but also, a lot of our clients have multiple brands. How do you scale that out across multiple brands? That's a bit of a rat's nest to get into.

Hearing you describe it, there are potholes and minefields everywhere with what you've talked about. There are large, massive, multi-regional, multinational, multi-brand organizations. There's a constant flux in design tools and front-end frameworks. Everyone knows the memes around that. Potentially thousands or possibly even tens of thousands of people are involved in terms of touching this stuff. It sounds like a very complicated problem.

It is a complicated problem, and that's also what makes it enticing and challenging on a day-to-day basis.

A UI system is a complicated problem, and that's what makes it enticing and challenging.

That's probably what makes it hard to define as well.

Honestly, technology moves so quickly. That's why so much of it needs to be grounded in standards and going back to basics because the standards outlive all the technologies. Technologies evolve all the time. Given the choice, we'll do stuff in React, but often it's a thin layer of React on top of foundations that are just principles, HTML, and CSS.

You don't need much React to get that going. It's a tool to glue it together. You could do the same thing in almost any other front-end framework. Understanding that framework of how you approach things, the underlying model there will scale into almost any technology so that's how we approach all of that stuff.

The “Checkbox” Analogy And Real-World Problems

If you were to condense it down, is the solution those large companies are trying to achieve or acquire effectively like consistency across their entire portfolio and estate with regards to the user interface? We used to have a joke when I was running an agency. We used to get rescue projects all the time. One of the jokes we had within the company was when we wanted to get a proxy for how bad or how much of a bin fire this project was that was coming over as a rescue project. We'd try and count the number of different checkbox components or styles in the existing project. Our record was seven. There were checkboxes that looked different in seven different ways throughout this application. Is that too much of a reduction to say that's what people are trying to achieve?

It depends on who you are speaking to. Some people care about that. Some people frankly don't care about that at all. Some people want stuff to feel better or look better, and it's a qualitative assessment. They will look at their stuff and say, “It doesn't look good. Can you make it better?” On the technical side, you think we need a design system, but there's a whole business case somewhere. You've got somewhere in between that gap that you have to build and figure out how you are going to get buy-in from the business side.

Sometimes it is more technical. Sometimes you have a technical person who comes to us and says, “We need a design system, help us build one,” but often, we are building new products, or we feel like our digital experience isn't very good or our web experience isn't very good. Help us make it better. The conclusion is, to consider a design system or a UI system but I do think the important point from our point of view is that "design system" has become this catchall term for what organizations need rather than the thing in particular. Everybody has a vague idea of what it might mean.

‍

There are some good examples of complete design systems, and they have been around for ages, predating the web. When you look at NASA, that web aspect comes into all of this. The content side of all of this is if you have a design system, you still have to have a way to produce websites. You can build websites as a developer or applications as a developer with a development team.

A lot of our clients need to do it at scale. They don't want to involve their developers all the time. It's this sister problem that you have the tools to build the websites technically, but then you want to be able to scale that out across thousands of different web pages. How do you do that? Practically, none of the existing solutions have been fit for purpose for a long time. As our UI has become more and more mature, we have ended up with these nice, neat design systems. The CMS tooling in that space hasn't evolved with it. It's still quite immature. There are a few players in the space now, which is quite interesting. There are companies like Builder.io, that are building these headless CMSs. They position it as if they are reattaching the head.

It's interesting because we built our agency several years ago on a CMS and went through these big, different shifts in how companies were using content management systems. I remember the phrase "headless CMS" appearing several years ago. It's interesting as well because everyone was like, "That's cool. You can see the value of that." It was like anything above that API was left for the reader to do whatever they wanted. Everything below that level was all nice and structured. There were structured ways of organizing your content and enforcing consistency and stuff like that but then anything above that was like, "We'll do whatever the hell you want."

Figuring out how to work in that space that's because we were doing design systems. We were often tasked with interfacing with CMSs. That interface is often reinventing the wheel every single time. In enterprise, it's often a Java-based CMS as well. You are talking about completely different paradigms and models. The CMS world traditionally hasn't moved at the same pace as the front-end world. Enterprises work on long software procurement cycles and long software licensing cycles. They are often stuck with a certain tool that might be dated for a decade plus. Whilst we were doing all of this design system stuff, we found this problem that kept coming up. How do you connect the design system to these CMSs, to these headless CMSs? What is the interface there?

We came up with all kinds of crazy solutions, like outputting HTML. I remember one client we output HTML, and their Java developers would import it. We would copy and paste the HTML and rebuild everything in the same abstractions in this Java-based CMS, which we didn't like but that was a solution that, sometimes, was scrappy in enterprise. That was a solution we ended up going into production with.

On top of that, we then built this connection layer that allowed you to programmatically create AEM and Adobe Experience Manager. We would programmatically create AEM components off the back of your React components. You'd create your React component, run it through this pipeline, and then you would end up with a Java component at the other end. We got rid of that copy-and-paste process, which had a whole host of issues.

We had to somehow figure out how to get the React components to render inside a Java runtime and a different Java engine under the hood but we did all of that stuff, and that was essentially what got us to do some talks on it internally but that is essentially what got us the job at Hilton in the first place. After many years, once you see Puck, it's the culmination of all the learnings of that stuff over the years. Which is just, again, stripping it all the way back to basics. React has a good props paradigm, and that scales well. The React tree is a nice way to structure content. You don't even need to think about React. You are thinking about the React AST, the fact that you have a component with a type and props, and that's a way to structure data and nest data.

It was building on that concept and figuring out how to get that into a nice little package that we could bring. The idea was we could package something up. If we do it as open-source and MIT, it's a very modular little unit that we can bring to our clients and say, "This particular slice we can solve. This particular slice we can handle. This integration can interface with all of the tools that you have." That visual editing experience is going to be very front-end oriented to allow them to bring their own React components or whatever other components at the moment have React and somehow interface it with their existing enterprise CMS.

The Advantages Of Working In An Agency Setting

One of the things that's nice about having an agency and then designing and building a product from that is that you get to see the same problems multiple times in multiple clients. They will have different tooling or third-party services like Adobe or whatever it is. Then you get, that's one of the things that I have noticed.

In a startup, you only get 1 or 2 chances to get it right the first time, but when you are working with clients, you have a low risk. The engagement could go completely catastrophically wrong, but you’ve got this low-risk way of starting to solve the same problem multiple times. I have noticed this with Flagsmith too. After 5 or 6 times of this repeating, the mist clears, doesn’t it? Then you start to see, not quite fully formed, but the outline of what a solution looks like. Was that the moment that you saw and were like, "Let’s build an open-source product around this?" Was it more complicated than that?

I think it was solving the same problem multiple times, you end up, as an engineer, your inclination is to abstract away the problems. I had this model in my head for a long time of this open-source or this perfect solution for this problem. The problem is, when you are working on a client, you have to build it to their stack. You have constraints that you can’t necessarily build the perfect product in those circumstances because the perfect solution is often more abstract than what they need.

The perfect product and the perfect solution are often more abstract than what clients need.

At some point well, it was June 2023, last year, summer, we had a full team running the Hilton project. I was not working on it day to day at that time. I took a couple of months in the summer to try and focus on building that thing. I wanted to see how far I could take it, and what it would look like, and needed a little bit of focus time. A lot of people have asked me how long it took to build the first MVP of Puck, and it was only a month or two because everything was the initial thinking. It was all the years of playing around in that space for clients. Once I had the model in my head, I was able to almost smash through it last summer.

We launched it in September. We built it in the open, but we didn’t have much of a following publicly. Our clients knew about Measured but did not have much brand presence at the time. We launched it in September 2023, and when I say launched, we had this whole marketing strategy. We thought about it, we had all this content we were going to produce. We had this LinkedIn article, we had these blog posts, and in the end, none of that mattered because on a Tuesday, I was heading to the gym, and I thought, "I’m going to post this on Hacker News."

I was about to say, “I knew this was coming.” I thought someone else was going to post it.

No, I thought, “I will post it on Hacker News and see what happens.” I posted it. I wrote little comments at the top of the Hacker News thread. I linked to the GitHub repo, and I went to the gym. I wasn’t thinking about it. An hour or so later, I came back, had a little look, and it was already on the front page. I have posted stuff quite a few times on Hacker News. Especially when you are trying a lot of different ventures and projects, you end up. It’s part of the routine. Most of the time, it goes by the wayside, but then, over the next 24 hours, it completely blows up. We were the top post for quite some time, and we went from something like 6 stars on GitHub to 1,700 in 24 hours.

We have had some big cheeses in the industry comment on it. Simon Willison left a lovely comment on Hacker News, which is, if you don’t know him, he’s one of the creators of Django, singing its praises. We had Guillermo, CEO of Vercel, tweet about it the same night about how much he loved the React ecosystem. That tweet alone garnered several thousand likes and drove another burst of traffic.

If you look at Star history, you see this tiny project with no stars, and then this upward cliff, which is post-Hacker News. Since then, we have hit 5,000 stars. It’s slowed down since that initial Hacker News burst, where it was almost 2,000 in 24 hours, and  3,000 in the first month, but it’s still been purely organic. We have been listening to the community, developing features that they have been requesting, and trying to see what they are doing as well. Not building a faster horse, but figuring out exactly what the use cases are here. One of the key decisions we made was to make it MIT-licensed.

Which is something that Simon mentioned in his comment. I’m looking at the page. It’s the top comment, "MIT-licensed too." We talked about it a lot, and in some ways, we didn't have a choice because it's an NPM package, and because of the way Puck's built, it's a React component that you can drop into your app, and you get this visual editing experience. You can plumb in your React components and start composing pages.

It's an NPM package. Most NPM packages are MIT-licensed. We adhered to what the community would probably expect. The consequence of that is that people are using it for all kinds of things that we never could have conceived. We built it for this page-building context, but because it's this little MIT-licensed modular piece of a wider CMS context, people are doing things like building email builders, taprooms, brewery menu builders, and paper menu builders. Program interfaces. There's a lot of agency-powered CMS solutions being built on top of it. All this stuff has now come off the back of this being MIT-licensed because it's free to do whatever you want with it, which has been amazing to watch. The community has been engaged and had lots of great feedback.

How Puck Functions Within An Application

That's amazing to explain to people because it's sometimes difficult to convey, especially if you are listening to this on a pair of headphones and you are not in front of a computer or whatever. Puck is essentially a UI, like a large user interface widget that people can embed into their applications. The inputs of which are React components that they have designed, and the outputs of which are HTML or other meta components.

It's like if you wanted to build your Squarespace or even if you are using Shopify. It's a UI widget or component that allows you to build the visual drag-and-drop editing portion, a website builder, or any other UI builder. You can add it to, if you are a React developer, you can add it to a portion of your React application. You decide where it goes because it's just a little UI widget. You then bring all of your visual components. Your hero component, your header component, your text blocks, your heading blocks, and anything else that you might have. You tell Puck that these are your components, and you tell Puck what fields you want to show for those components.

Once you've told Puck, it will render the Puck interface with the list of components down the left-hand side and this canvas, and you can start drag-and-drop these components from the component list onto the canvas, and then when you click the component, you'll see a list of the fields that you've determined for that component appear on the right-hand side, and it's all built on top of a simple JSON data model.

The output that you get from Puck is a JSON. You get a JSON. You can then store that wherever you want, completely portable, store it in your database, store it in another database, and then we also provide the renderer. You pass it that data payload and the same set of component configs that you used to author the page, and then it will render the resulting page.

All of that is based on React, which is how we have built this thing because it's like how React structures its data model, and there's a lot of overlap there. I want to take it part closer to how React structures its data model because right now, there are some nuances that I'd like to try and get rid of. As it's so portable and it was built initially for page building, that is why people are doing all this interesting stuff with it because it's so deep into people's applications, it's like a piece of their stack that Puck is inside people's stacks.

The Complexity Of Building Tools Like Puck

It's also technically challenging as well to build those things. I remember we used Webflow at Flagsmith, and I was always terrified of the visual editor in Webflow because it's so technically impressive and the problems that you have to solve. They are not simple things. You are not going to knock them out in an afternoon or whatever. Here's Simon's comment. He being who he is, is extremely prescient. I have seen so many of these kinds of things over the years, but this one is special. It's not like a novel concept. There must be hundreds of these on GitHub or not exactly based around React or whatever. I know how many CMS wizard editors we've tried over the years. It's like a very thorny problem here be dragon problem, isn't it?

Fundamentally, if there had been a solution that worked for us and our clients, then I might not have gone ahead and built something. There are a lot of tools doing certain parts of that problem. There are a lot of drag-and-drop libraries or you mentioned Webflow. Webflow is designed for a different audience. A lot of, when a lot of people think of no-code page builders, they are almost thinking about page builders that are targeted towards developers who don't want to be spending their time on code.

These tools are so complicated to use, that you still have to understand how the web fits together to be able to use them and what because Puck was originally targeted towards this content use case. Our clients often have content teams that are non-technical. They need to be able to produce pages, web pages at scale. They don't need to be able to control everything. The margins, the padding, all of that stuff. The design systems that they are using under the hoods might have predetermined the rules about padding and margin and all of that stuff. We don't want to expose that stuff. The only thing that they need to be able to control is the content.

Puck has an API that if you're building an integration with it, you could then surface those fields that you wanted that content team to work with.

You can surface exactly the API that you want them to work with and nothing more. If you had a heading component and it had, it took a title and it took a color, the title could be, say, titles a string, your color could be the default color or the brand color, and it's quite a common pattern we see. You are not talking about the color being any color. You want any possible color in the available color space, and maybe that's what you want. More than likely, you have colors that are acceptable.

What Puck will allow you to do is bring that component and create a text field for your title and a select field for your color mode, and it will expose that to the author. It's built on top of the way we think about design systems, and that's why the design system journey is so relevant to the Puck origin story because the design system, is the way we have approached design systems anyway. It's all about reducing the number of decisions that you make when you build a website, and that's what Puck's about. It's about reducing the number of decisions that the user has to make when they are building some experience with Puck.

The Importance Of Clearly Defining The Scope Of A Tool

It seems like one of those tools where that experience, like deciding the hard start and the hard stop of where that tool begins and ends. That's relying on a lot of that experience because it feels to me like that's one of those things where that's the dangerous problem is part, or you start, do you define a start and an end of where it is in that workflow, and then you may be tempted to start pushing the start earlier or the end later, and all of a sudden, it's like, what you lose sight of what it is and what it's doing and who it's for and things like that. Is that fair to say?

That's fair to say. That's the case with all products. When you're trying to build out a product, you're always trying to figure out where you keep building features and where you stop building features because you could build the everything app if you wanted.

‍

Stick a messaging system in it. Add stories.

I will say that we are interested in it because it is this MIT license component library, which has happened as we have had a whole bunch inbound over the last several months as a consultancy of people who need help with design systems or integrating Puck into their system. It takes time for companies to do that because, like often when you're using Puck, you're rebuilding a complicated part of your system or building a new product, so we are still having a lot of conversations, a lot of ongoing conversations, but we are exploring building out some more infrastructure behind Puck to support quite common use cases.

Specifically, very hot off the press, but we have been putting together a plan for the Puck platform that leans into the modularity of Puck but allows you to add certain things that you might not want to build yourself. Providing a series of plugins. Puck has this plugin architecture that you can add to Puck to enhance your visual editing experience. We are exploring things like AI and ML plugins to help you structure your page using ML, and things like multiplayer.

Beyond that, because Puck doesn't have any backend tool, users often have to implement their database, their versioning, their digital asset manager, and all of that stuff. A lot of the time, that's exactly what the user needs to do because they are integrating it deep into their product, but other times users are building a net new product and it's a bit of a pain.

That's the last thing you want to do or not the last thing, but it's got to be near the bottom of the list.

Yes. We are exploring how we can support that to help Puck be even further adopted. As an open-source project, Puck has been a tremendous success. It still hasn't hit V1. We have got plans to get there. We are getting closer now, but we are thinking about what is the next step for Puck. What is the next phase?

Balancing Open Source Development With Commercial Viability

My next question is going to be your thoughts on making this sustainable commercially and from an open-source point of view. Are there particular projects that have inspired you that have that model around? What you're talking about is that it sounds like you've got something quite nice, because like I said, if you are defining those starts and ends in the boundary of what the MIT tool does, clearly that's like a natural opportunity then to say, “All the stuff around it, that's the commercial opportunity.” Are there projects that have inspired you in terms of that model?

That is probably where the opportunity is. You have this MIT core and then that has a lot of value to the community as it is, and then figuring out what people are doing with that thing, and then supporting them is the opportunity. I'm still seeking inspiration in that space, and I'm not sure I have found any good examples yet for other projects.

If you squint, I guess Vercel is next.

Potentially a platform like Vercel is worth looking at, and we have tried to position Puck. We don't have an awful lot of a brand. We have a website, we have a logo, but we have tried to position it quite closely to Vercel and Next.js, partly because it resonates with the Vercel and Next.js community, maybe there's some overlap there, but we are still figuring it out.

I have always been impressed by the way they manage to add or enhance like the Vercel platform manages to enhance the Next.js developer experience and products and stuff and do it in a super careful way where at least as far as I'm aware anyway. You don't get pointed to Next.js where you're like, “I can't use that next feature because I need to pay Guillermo some money.” That never happens.

There's a clear ethical boundary of where that is and the contract with because that's the thing, is it, the contract you have with the people implementing Puck into their platforms is extremely, not delicate, but there's a lot of two-way trust there, isn't there? I don't know the licensing or even making significant changes to the API contracts or things like that. There's quite a, quite a potential, you've got a lot of care and fragility in your hands in regards to that.

It takes quite a lot to manage that.

Does that take up a lot of your mental energy?

It does, and it's a challenge because I also have consultancy and running. That's part of the reason we are having these conversations around the next steps because we want Puck to exist for the future, and if it's not commercially sustainable, then can you support an MIT project in perpetuity? I don't think anyone can. You have to have a realistic chat about what we are doing with this thing. It's been great marketing for Measured. We could say, “It's marketing for Measured,” and leave it at that and keep developing it in that way, but there is an opportunity here because it has had such rapid adoption to do something more that amplifies the MIT project like figuring out how you can create that flywheel.

They are a perpetual motion machine with two components that are accelerating each other.

There aren't that many examples of companies that have done exactly that, and maybe that's slightly naive on my part, but it's a little bit hard to figure out exactly where the boundaries of that are. We are speaking to quite a lot of our users about where we might be able to plug the gaps, and where we might be able to amplify what they are building.

There's quite a lot of talk with agencies and consultancies who need a White-label CMS solution for their clients. That's quite an easy conversation to have because that's our wheelhouse. We are trying to figure out how to put all the pieces together and working on this product roadmap off the back of that and then the natural tension between consultancy and product.

That's part of the reason I wanted to speak to you in the first place was that it does create tension because they are two different business models. Building a product around an open-source project is different from running a consultancy. If you see the open-source project as part of the marketing consultancy, then that is one way to handle that tension and use that open-source project to propel the business forward and justify the project but as soon as you start looking at product, then that does create a bit of a tension between the sides of the business, and you have to start thinking, “How do we reconcile that tension? Do we need to spin out the project as a separate company? Does the company, the consultancy itself change shape to only support Puck? And I don't think we are interested in doing that because Measured is going well, has a good roster of clients, and it's growing and it's moving forward. That's where we are at.

Building a product around an open-source project is different from running a consultancy. You have to reconcile that tension.

That's tough. I remember thinking back now, there were two discrete phases with Flagsmith, which started life as Bullet Trading, and the first one was the period that we started writing the first line of code, we turned on the ability to make money out of it. We built a hosted API and started charging for that. There was a balance we were trying to strike between like, how much time do we spend on this and how much don't?

We jumped to that question a little bit because I remember we weren't that busy as an agency. It's a problem. If the agency's successful and everyone, or most of the people that are working on it are busy, that's a problem because then you're saying, “I'm going to like say no to this money from this customer because I'm going to instead spend that time working on something that doesn't have a commercial output right now.”

For Flagsmith, we jumped to that question because we weren't massively busy at the time. The answer was like, if you're not billing, you work. You are working on this. I have talked about this a lot. Tons of mad stuff that was commercially absurd. That's one thing but then the second part was, you're making $50 a month or $300 a month or whatever, and then it's a question of like, you've got a dial in front of you, which is like, “Do you want to spend $1,000 a month of your time on that or what's the ratio?”

If I look back at it I'm honest to myself and the mistake. It's not a mistake because you are never quite sure, but in hindsight, we were too timid in that at the start of that second phase where we were selling a little bit on this hosted API, but we were getting inbound leads from massive companies wanting enterprise on-premise.

That should have been an alarm bell of like that's a massive opportunity and you should be actively turning down paid work from customers so that you can start pushing and building all of these features that there's the market, that's the obvious niche that you are going to be in. You need to start building out the features like fine-grained access control and SAML and no IDC and all that stuff, and instead, what we decided was that during the pandemic, it would be a good idea for me to sit by myself in my loft and work on it by myself. If we look back on it now, we would have had half the company working on it and we would have tried to figure out how we could have afforded that.

For us, it was the question of whether we wanted to be passive about those decisions or active about them, and we were passive about them because it was like, “If you've not got billable work on Flagsmith if you have got billable work, do that.” We were sidestepping having to make the decision at all because that seems like a natural and obvious thing to do.

What we should have done when we started to make a little bit of money and it was slowly going up and we started to get these inbound leads from large organizations, that was when we should have acted, and it's difficult as well. There's not a single moment when that changes. It's difficult to say there's no step change in the signal that we are getting from this project and from this business because there's never a step change signal.

I may be posting on Hacker News and get this stuff. You are not going to get these ten clients or potential enterprise customers aren't going to turn up at your door all asking for the same thing at the same time. It's instead like this gradual process. I do look back on it and think it's a bit about risk tolerance and how much money you've got in the bank. There are all these external factors.

If there's one thing that I have taken away from that is that these opportunities, and we, because we have been trying to do this so much with an agency that's 25 years old come around very infrequently. Going from 6 stars to 2,000 in a day, that does not happen very often. There are probably only a few thousand instances of that ever happening in the universe.

The trick is to like, we are like what you've done in that moment is push that hard as long as you can, and then what the mistake that we made was like when we got what was, if you look back in a clear signal around enterprise on-premise, we should have gone push hard then like step on the accelerator as hard as you can like you can stomach or whatever and be reactive if you're not converting those deals.

It turns out that with Flagsmith, we needed help with the sales cycle of those deals. I didn't have any experience in it whatsoever. That's how we got Polychrome on board and they helped do that. It's difficult because, especially if you've got a growing business, and it sounds trite, but even if it's not the one that you wanted to do, there are people's salaries, careers, and mortgages and all this stuff, and it becomes much more of a human complicated decision. I feel like what you guys have done in that first instance of like 2,000 stars and then you're at 5,000 now. That's astonishing. That's the thing. It's when to make those acts or decisions.

We have had a lot of signals. I do think we have been more passive than perhaps we should have, but I don't think we necessarily knew what we wanted to do with it.

That's also the problem because you don't have to answer that question when you push something to GitHub. Maybe you push it to GitHub because you haven't made that decision.

We have let the community lead us a little bit, and that's partly because it's MIT-licensed. They are showing us all the things that they can do with it. Now we know how to support you. We have had a few inbound leads that are probably similar signals to the ones that you experienced. We are very much trying to lean into that aggressively rather than being passive and waiting for it to mature by itself, like pursuing that as an opportunity.

It’s interesting what you're saying about how you weren't particularly busy at the time when you started working on this stuff, because we feel very busy, and as these opportunities come in, we have this natural tension where we could offer to build them a bespoke solution using Puck as a consultancy, as a consultancy, and that is probably in terms of a single deal worth more than if you sold them a license to some on-prem solution, at least in the immediate term.

You have this tension between consultancy and products. It's come around quite quickly, and I have two amazing co-founders in the consultancy, and they want to give Puck its moment and its opportunity, and we are accepting that we are or there is an acceptance that we have to try and find that balance between when do we turn down a consultancy opportunity in favor of a potentially lower-value Puck opportunity, because that Puck opportunity can scale in a way that the bespoke.

The fundamentals of one business are going to be, in my opinion anyway, radically better than the other. There’s another business that I’m involved in that I want to get into, but we have done that, and we dragged that ramping phase out too long as well. That’s another interesting thing as well. In our experience, when you make that decision you are going to eschew paid client work for lines of code in Puck or the business that it becomes.

I feel like you want to then speed that transition, that ramp as quickly as you possibly can. Raising money would be the way of doing it, as quickly as possible because you go, “We are raising money.” We can get a two-year runway or whatever it is, and then we don’t have to do any client work again. You’ve got contractual obligations with some of those customers or whatever, but I do feel like those tensions are always going to be there, and so you want to not have to answer that question as quickly as possible, and the way to do that is to become a product business as quickly as you possibly can.

We have had a lot of conversations about this. We want to keep Measured as a consultancy business, but I do think we are now seriously considering spinning Puck out.

That’s what we did at Flagsmith. I pilfered a couple of people from the agency into Flagsmith. Everyone’s happy with that. They are now two very separate like, they are legally separated. They are two completely separate businesses. They happen to have me poking around in both of them. That’s how we spread that off.

We should chat more about that.

We can do it. I realized what time we were at. It's been super interesting talking. Maybe you could come back in several months. It'd be interesting if you were happy to talk about these decisions as they are crystallizing in terms of their effect. The path that Measured, Puck, Solid State, and Flagsmith have taken, in my opinion, is like it never gets talked about as much as going and raising bazillion dollars from West Coast Americans and then spending it all on nice offices and stuff, and it’s for people who don't want to do that like the most healthy way of trying to get there. I’d love to chat more and see what decisions you are thinking of. Sometimes I speak to people and like, “ I don't know how you would generate a thriving commercial open-source business out of this,” but I feel like where Puck is, there is, but I agree. That’s what it looks like. I have no idea.

Again in a few months and do another one of these. That’ll be a pleasure. I have had various open-source projects. Some have nothing's been taken off as much as Puck, but this is the first one where I have felt. As it was born out of a real need for our clients, nothing has had the opportunity that you can feel with this.

There’s a saying, isn’t there that you know when you find product-market fit? I don’t think we found a commercial product-market fit, obviously we haven’t yet. We have such a strong signal. It’s a pull, it’s not a push. That’s the difference between this and every other project that I have had where I have tried to find commercial success. That’s always been an uphill battle. This feels like I’m rolling down the hill, for sure, and I need to avoid the obstacles.

That feeling didn’t come to Flagsmith in one dopamine hit. You wake up one day and you’re like, “I’m getting inbound leads from megacorps, and I don’t have anyone doing marketing. I don’t regard myself doing it.” It’d be great to have you back on and see where you’re at, but thanks so much for your time, yes, it’s been adding a star, and I will be pulling up the star history graph after this call because I can imagine how hilarious that looks.

Thanks. It’s been an absolute pleasure talking to you.

Thanks, Chris. Take care.

‍

Important Links

• Puck
• Measured
• Flagsmith
• Chris Villa