7 Ways to Fail at Building a Platform

The build versus buy decision

(0:10) Hi, thanks for having me. What I want to go over today is what I think is very important, and that is thinking about the build versus buy decision when it comes to your platform. This is very important nowadays because - I mean, we're here at PlatformCon, we all know there's an extreme amount of interest in platforms. What's happened is that over, let's say starting about two years or so ago, people have been seriously looking up from the Kubernetes level and thinking about how we layer something on top of just infrastructure. Which can be fine, if that's what you want, but make it more friendly for application developers.

AI makes platforms more important, not less

(0:47) Of course, I can't let even a minute of talking about something go past without talking about AI, but I want to mention why I think platforms are even more important because of AI stuff. Normally we think about platforms for application developers. But if you look at how agentic coding is going - I use Claude Code, you could use Copilot, whatever else you want - a lot of what's going on is that you have a new type of workload, a new type of customer for your platform, and that is, for lack of a better term, the normies. The knowledge workers, who are now using agentic AI to actually write code. They're not writing the code, but their little robot friend does.

(1:25) And those applications, as someone at a bank was telling me, they need to run somewhere. Most platforms that I see out in large organizations aren't quite set up to be that easy. But I think over the next year or so you're going to need the platform not only for application developers, but especially as more and more non-IT, just regular people, start getting access to AI apps that allow them to just code things up. And again, they need to not only run it somewhere, they need to connect to the services that any developer would need to connect to, in the secure, enterprisey way of doing things.

What a platform gets you

(2:02) Now, these are some numbers. I've studied platforms and application development for a long time, and over the years I've collected several numbers. Having a platform has great results. These are all based on people who use Tanzu Platform over the years and currently. As measured by the amount of applications that run and also the amount of people used to manage it: part of the point of the platform is not only running those applications, but doing it in a very efficient way where you don't need a lot of operations people to handle it. You're not running your own company inside of an organization to do it - you're supporting thousands of applications or developers with just a handful of people.

(2:44) And these are apps that banks use, very mission-critical things out there that have high-performance needs. Someone like Charles Schwab - you can imagine the trading when the day opens up and their volume goes way up. They run on top of a platform that supports that kind of doing things. Of course, the best platform in the world, the Tanzu Platform. But I'll try to keep it a little vendor-free here for you.

This is me

(3:10) So, speaking of me - or me speaking - this is me. I've been lucky to work at, starting at Pivotal and then through the acquisition by VMware and the acquisition by Broadcom, now in Tanzu. But I've worked in the same group and role over about 11 years or so now, looking at how large organizations work and really following my interest of how they get good at software. I've written several books. I've got some podcasts, the Software Defined Talk podcast, which has been around for a good 30 or 40 years, it feels like, that we do weekly. And I was a programmer a long time ago. I worked at RedMonk and Dell, all kinds of stuff like that. If you're really interested you can go check it out - there's a blog and a newsletter, all the nonsense that you would want about me.

Seven ways people fail at doing a platform

(3:57) So let's look at these seven ways that I have cataloged that people fail at doing a platform. And, well, "fail" - there's degrees of failure, but they're not completely satisfied. This is based on a paper that I helped revise and update and kind of do the second edition to, that I'll give you a link to at the end. So I'm not the sole person who came up with this stuff, just to call it out. But I think it's important to go over these things again, so that as you're figuring out the platforms you want to put in place for regular workloads or for AI things - or, as we'll get to, maybe you've discovered you have been building your own platform and you discovered some of these issues - these are the things you want to avoid.

#1 Unexpected scope creep

(4:44) So the first one is unexpected scope creep. To get an appreciation of this: most people go into building a platform, and of course very few people say it takes a weekend, but being an application developer, I think all of us developers were always like, why would we use this off-the-shelf thing, or buy this thing, or even this open source project? I could probably code that in a weekend.

(5:07) This sentiment - whether it's a weekend or whatever - tends to exist because organizationally people don't really understand the full scope of a platform. Just as a reminder, I know everyone here probably knows what a platform is, but as framing: here's two examples of platforms. You've got the CNCF platform reference architecture, which is fantastic. You've got one version of it, the Tanzu Platform, over there. But it has all of the things, as you well know, needed to run a platform. It's a very large scope.

(5:36) To put it another way, you look at all of the things, the outcomes, the capabilities that a platform delivers on. As you start writing them down, especially for a large organization, you start seeing that this is a huge list of things. An important thing here is that Kubernetes - the most popular infrastructure, it seems, that people think about in the platform space, or talk about - is not all of this, to put it in an odd way. What you're doing is building a lot of stuff on top of your infrastructure, Kubernetes. Think about all of this stuff. That becomes the full scope of what you're doing: not just a portal, not just a CI/CD tool, not just integration with YAML copying and stuff.

• App delivery.
• Backup and restore.
• Patch management.
• Observability, logs, monitoring.
• Service management and use.
• RBAC, etc.
• Vulnerability scanning.
• Dev framework integration.
• High availability and the other -ilities.
• Multi-region deployment.
• Sovereign cloud.
• Auditing and compliance.
• Multi-tenancy.
• Upgrading the platform.
• Gateways, brokers, load balancers, etc.
• CI/CD, itself or integration.

(6:23) To give you more of an idea of the scope, if you look at the Cloud Native Maturity Model from the CNCF - this is from a beta version, I think - you look at the phases of an organization as they become a platform organization, all of the stuff that they go through. And if this slide looks overwhelming, that's the point of it. There's a lot going on there. When you read it, there's kind of an offhand estimate that this is going to take you about three to five years to get through, and most organizations don't actually get through the whole maturity model. So the scope of what you're doing is much larger than most people anticipate. It seems like it's going to be something that's simple at first, but again, you look at the full scope of what a platform is - there's a lot going on there.

(7:08) Plus integrating with all of the stuff around it. All those services that you're bringing in, whether it's databases or nowadays your AI services, your brokers, all of that kind of stuff.

#2 Underestimating the ongoing investment

(7:18) Once you underestimate the scope, you also underestimate the investment. I see this a lot, over the years, where people started up an initiative, often to build on top of Kubernetes - and sometimes they even do that on their own, which seems like madness - and after one or a couple of years they realize that the cost of doing this is going to be a lot more than that initial team they had. Remember, the scope is bigger, so you end up needing more people.

(7:47) So you start off thinking, even if you think you only need one team of three to eight people, you can see that when you think of it cumulatively over time. Because in a buy versus build decision, you're comparing the amount you're paying to buy something with the cumulative amount you'd be paying in salary. If you see the cumulative amount you're paying for one team, you can see over a five-year term that it gets to be, I don't know, around 5 million or so. Now, as a person, that's wonderful. You want to be hired for that.

(8:19) The other thing that I think people miss is that you're not going to have just one team. Again, think of the scope of the platform, all those things we just went over that it does. And also the project management, the product management, all of the associated things around it - and you're talking about somewhere in the order of three to eight teams, which multiplies your cost out much, much more. These kinds of expenses creep up on people if they didn't have the right scope, and therefore they didn't have the right thinking about how much it was going to end up costing them. So your scope is generally bigger than you think it will be, and the costs you take on therefore tend to be bigger than you anticipated as well.

#3 Platform as a project instead of a product

(9:01) The next thing that often happens - and this affects the scope and the ongoing cost - is that people think of a platform more as a project instead of, as we all know, a product. It's going to be a one-time deliverable of functionality. They stand it up. You hear this from infrastructure people all the time: that they stood it up, and the developers aren't using it. The difference in thinking about something as a product is that it is an ongoing, continuous - you could say investment, but effort - where you have to add new features to it.

(9:36) Your platform has to evolve. It's got to adapt to what your developers want. Nowadays we've got it right in front of us: all of a sudden you need to add a whole bunch of AI services, not only for code generation and supporting developers using AI, but also for using AI in your applications. These are things that need to be added in, not to mention every single other thing. So it's not a one-and-done sort of thing that you do.

(10:04) It's an ongoing staffing, an ongoing project. It's something that you now own and are responsible for. Doing things in this platform-as-a-product way is widely understood to be what drives a lot of success for platforms in organizations, as you can see at Mercedes-Benz. As Thomas Müller there put it: "We are building this platform not for us, we are building it for Mercedes-Benz developers." It's a great talk if you want to dive into that a little bit more.

#4 Homegrown lock-in

(10:28) Another thing that comes up: one of the reasons you want to implement your own thing is that you want to avoid lock-in. I think the problem in thinking here is getting ahead of yourself about what it is you want when you're trying to avoid lock-in. Of course, if you build your own platform, you are locked into your own platform. You're now responsible for all the security updates, which we find more and more of, as I'll get into. Adding all these things and supporting it. And it's your unique thing that isn't really compatible with other stuff, versus a more widely used platform that's out there.

(11:07) So I would think about the goals you have with your lock-in avoidance. You probably just want the portability, the freedom to leave, as Simon Phipps talked about it. And you want your switching costs to be low. So think about these lock-in problems in those terms - not just "we're using proprietary stuff," or "we're using something backed by a vendor, we've got to use this open source thing or this thing that we did." It's all kind of mixed together nowadays with how this is done. So no matter what you use, rate it by these categories and really pay attention to what the lock-in thinking is. Gregor Hohpe's "Don't get locked up into avoiding lock-in" and Keith Townsend's "Thinking About VMware Alternatives?" are both useful here.

#5 Retaining skilled people

(11:40) Next, the issue that you have is retaining skilled people. Every time a survey comes out about a new technology, the same issue arises: we don't have the skills. Now, the people surveyed often also don't spend a lot of time training people.

(11:59) But when you get skilled at something like Kubernetes or other platforms, that's an incredibly valuable skill that you have. And I see over and over again that often the core team of people who built the platform can now go get another job somewhere else. And they often leave. So if you've built your own platform, the people who know about it - there's a high chance, or at least a non-zero chance, that they might leave. Which kind of is a bummer, now that you're locked into that platform.

#6 Keeping up with security and compliance

(12:27) Next - I mentioned this earlier - you are also responsible for keeping up with security and patches and compliance. This is an older chart, it doesn't include 2026, but the amount of CVEs and the need to patch have been increasing incredibly fast. And now with the way that AIs are finding things, it's insane how many bugs are found and how much patching needs to happen.

(12:55) This becomes a huge deal if you have to manage and do this kind of hardening yourself. Whereas if you're using a standard platform - if you're even buying a platform from someone - you have someone else who's doing that for you.

(13:11) Now, the other thing that's very current at the moment - hopefully not for much longer - is people wanting sovereignty, wanting control of where their platform is running, where the applications running on it are.

(13:28) You can think of this broadly as governance and compliance. This is another thing that you now own. Do you need to run in multiple regions? Your platform needs to support that. Do you need to comply with, for example, the DORA banking law - not the DORA DevOps stuff? That's something you now need to take care of in your platform. So you can see how these things pile up more and more when you start to build your own platform, instead of having it shared amongst all the people who are using a common platform in the industry.

#7 Resume-driven development

(14:01) So the final one is that a lot of people succumb to doing a platform because of resume-driven development. They do it because it's cool and fun and will help their resume out. And there's actually a paper, which is great and fun to go read, where they've studied this phenomenon. As you can imagine, when you do resume-driven development, it doesn't really result in fantastic usable technology.

Stop building platforms. Start building apps.

(14:27) Finally, I think there's a lot of other voices out there, people who will tell you that building your own platform is not a great idea. It's much better to focus on what you actually want - those capabilities, the applications - and to spend as little time as possible on this commoditized thing. Your business isn't really going to succeed because you've got a unique, cool platform, when you could have just gotten a platform that is equally cool and functional.

(14:58) So I would encourage you: one of the ways to avoid failing at platforms is to stop building platforms and start building apps. With that, thanks for having me. It was fun talking with you. And if you're interested in more, feel free to reach out.