Hi all! how would you define a minimally viable internal developer portal? (and platform too, BTW, since the self-service actions it offers use the portal as its interface). I see some in the space focus on "software catalog" or "service catalog" as the MVP although it doesn't offer developer self-service, and also doesn't usually come with ready-made abstractions, meaning that if you wanted to protect developers from cognitive load you actually created some... I think this issue comes to focusing on an engineering centric view of the portal instead of a jobs-to-be-done approach. At Port, our thinking is that the focus should actually be around the basic SDLC needs for developers - so they won't need to wait for devops. These are our self-service actions for an MVP. What are yours? In which cases would you still do a portal that only has a service catalog?

Nice! I'd say for an MVP there's also definitely the ABAC & RBAC part, and — depending on the context, but probably more often than not — there may be need for some essential data engineering capabilities, but your visualization looks like a nice starting point. It's definitely not far from our vision at Mia-Platform as well! I like this question a lot, really curious to hear some other answers to this 😃

I'd consider self-service onboarding as a starting point for a minimally viable internal developer portal. That's actually a common space where companies tend to build something from scratch either using Office 365 forms or custom web portals. If you miss enabling internal developer portal product at this early stage, it's becoming increasingly hard do it later (as people attach to their previous work).

I think an MVP is going to be different for everyone and dependant on which stage needs the most improvement and/or will provide the highest ROI.

@Roni Floman I love the simplicity and practicality of your MVP flow. I had a capability model fuelling the frontend portal but this is much more humane 🙂 Dev Portals can very quickly become Generic Platforms or Marketplaces where every piece of disjointed automation starts living vs. true 'Dev Enablement'.

Thank you @Abhijeet Singh i fully agree - we need to focus on making work simpler, not making work less simple for the sake of complex portals and platforms

I wonder if there was an analysis of what adds the most value and is demanded the most by developers. To give an example

Scaffold a new service

is happening ONCE during the lifetime of a service and only covers the “start right” aspect. The impact of having that facility is minimal compared to something that influences activities that developers carry out a few times a day, possibly every day, in the lifetime of a service and influence the “keep right” aspect. It seems like this is what is on the drawing board for most projects that purely approach from DX perspective and leave the commercials out.

@Clemens Jütte I agree, I think generally there is a better ROI for optimising code / architecture for readability/maintainability than for writability - the DX experience should be no different. Unless you are scaffolding new teams everyday, you probably shouldn't be scaffolding new services...

I would say that scaffolding is heavy and if a dev is waiting for two days (or more) for that to happen through a ticket - it's a real issue. But the magic in terms of DX is getting Day-2 ops right. This is what we currently see in the market (i'm from Port)