Pains

Clerk's RBAC capabilities are shallow and insufficient for complex application-level permission requirements. Developers need more granular control over roles and permissions beyond the basic 10 custom roles, especially for domain-specific business logic.

Product teams want higher-level abstractions and self-service capabilities for infrastructure provisioning. Many teams are adopting CDKTF or building internal platforms to bridge the gap, indicating Terraform's abstraction layer is insufficient for modern development velocity.

Railway lacks support for certain geographic regions (e.g., Algeria), which creates compliance and performance issues for teams that need to serve or store data in specific locations.

Railway does not provide built-in edge protection, Web Application Firewall (WAF), or DDoS mitigation out of the box. Developers must add extra layers (CDN, proxy, WAF) manually if their apps need strong security or resilience against bot traffic.

Railway lacks a native worker model for background jobs, async processing, and independent scheduled tasks. Developers must manually set up these as separate services, requiring additional configuration and ongoing management.

Railway's deployment flow is tightly coupled to GitHub, and GitLab integration is only planned with no estimated timeline. Developers using GitLab must work around this significant platform limitation.

Railway explicitly does not support SSH access or remote shell (like `rails console`) to running applications, blocking Ruby and Elixir developers who need interactive debugging and introspection capabilities due to the platform's immutability principle.

When using ssoSilent flow, MSAL loads the redirect URI in an invisible iframe. Content security policies or HTTP headers on the redirect URI page can block this iframe from loading, preventing silent SSO.

OAuth 2.0 is fundamentally for authorization (permissions), not authentication (identity), but developers frequently misuse it for authentication. This conceptual confusion leads to security vulnerabilities and architectural mistakes that compound during production rollouts.

Starting with MSAL 4.52+, developers must explicitly specify parent window handles using WithParentActivityOrWindow APIs for Windows broker (WAM) authentication. Omitting this causes poor UX where auth windows hide behind the application, and window inference is no longer feasible.

Windows Broker (WAM) implementation has significant limitations: B2C and ADFS authorities aren't supported, it only works on Windows 10+ and Server 2019+, and older platforms must fall back to browser-based authentication. Developers must handle these constraints in multi-platform applications.

Many AWS services are incomplete or poorly designed (e.g., SageMaker Studio vs regular SageMaker). The vast product portfolio means quality varies significantly and some products are not production-ready.

Many organizations lock down Azure tenants with whitelist-based resource and operation controls on administrator advice. This prevents developers from gaining practical Azure experience through trial-and-error, increases time-to-market, and reduces the platform's developer benefits despite Azure being designed as a developer-first cloud.

The pay-as-you-go pricing model with multiple pricing options across services and resources is difficult to navigate, especially for developers new to Azure. Understanding how pricing applies to specific services is challenging.

With over 200 Azure services evolving at a rapid pace, developers struggle to identify the most suitable service for specific scenarios. Documentation frequently falls behind new feature introductions, making it difficult to stay current.

Setting up correct access controls and permissions for resources is tricky, requiring balance between security and usability. Documentation assumes administrative privileges, leaving non-admins without clear guidance on permission discovery and processes.

Database changes across multiple environments require manual coordination between team members, increasing complexity and risk of inconsistencies.

Azure Monitor lacks sufficient custom alerts and notifications for tracking infrastructure health, creating blind spots in monitoring. Many IT directors assume management and monitoring are built-in but find they are under-resourced.

VM-based system images and their management present security risks, requiring careful attention to image creation, storage, and deployment practices to prevent security vulnerabilities.

MongoDB faces challenges protecting data across distributed environments including cloud providers, edge devices, and on-premises systems. Implementing consistent encryption and security policies across AWS, Azure, and edge devices impacts performance and adds complexity.

Developers using Azure feeds experience significant latency caused by geographic distance from data centers, leading to slow package retrieval times and reduced performance for globally distributed teams.

Manual deployment and testing processes create significant overhead, slow release cycles, and increase error rates. Automation is critical but often difficult to implement in Azure environments.

The API does not provide clear feedback on remaining quota or detailed billing breakdowns. Developers cannot easily track usage or understand cost allocation across API calls.

The Azure portal experiences frequent performance issues, unreliable button clicks that may or may not execute, sluggish interface responsiveness, and unknown error messages when performing routine actions like viewing deployment logs or accessing SSH/log functions.