This message was deleted.

Hey @Saim Safdar - Kubiya.ai just published an ebook that covers these topics. Check it out here! https://go.kubiya.ai/ai-in-idp

And/or you can check the history - I asked exactly the same question :D https://platformengin-b0m7058.slack.com/archives/C02DF3KKNES/p1697354295195139?thread_ts=1697354295.195139&cid=C02DF3KKNES

The limitations and constraints are always dictated by the outcome you’re looking for - what is the outcome you want?

Andrew: somewhere along, while IDPs can help with scalability, they also need to be scalable themselves, Customization Challenges, what sort of applications are not suitable. Jakub: thanks for sharing an insightful wisdom @Christina Hupy that's something really interesting to read, also LMK someone from team happy to join my podcast, covering the same topic and learning about recent challenges and new wisdoms.

I second that challenges will depend on the outcome. One generic thing in my opinion is to acknowledge you'll never make all of your users happy. Especially if there's a lot of them, so depending on the organisation, you may need to negotiate what cases are you going to support

What do you mean by scalability? Engineering team growth? Code Growth? Service Growth? the IDP itself not scaling?

I think the first problem you will want to solve is what Dominik is highlighting - user adoption/happiness etc. If you can create a structure around and within the IDP that facilitates what @Craig Tracey calls Engineer Led Efficiency you can smooth much of that over. You help the consumers of the platform define the requirements as they emerge. This does imply certain tradeoffs, but will most likely drive wider and faster adoption of the platform, which is really when the value prop of an IDP kicks in