GraphQL is a great tool. It is also the wrong default for 90 percent of the products we ship at Xenotix Labs (https://www.xenotixlabs.com). Here is our reasoning after 30+ production apps.

When GraphQL wins

GraphQL genuinely helps when (1) you have many different clients with very different data shape requirements, (2) your data has deep nested relationships that REST endpoints would over-fetch on, and (3) your team has the discipline to maintain a schema layer on top of your services. For Shopify, Facebook, GitHub, these conditions are true. For most startup MVPs, none of them are.

Why we default to REST

For an Indian founder's MVP: a single mobile app, a single admin dashboard, both built by the same team, with <100 endpoints. REST is the simpler choice. Every engineer on the planet knows how to debug a REST call. OpenAPI specs are easy to generate. Versioning via URL prefix is straightforward. Caching via HTTP semantics is free.

We use REST for ClaimsMitra (114+ endpoints across 8 services), Legal Owl (LegalTech with 7 user personas), Veda Milk (D2C subscription), Cricket Winner (real-time cricket on Kafka + WebSockets, with REST for non-realtime), and Growara (WhatsApp automation). No GraphQL anywhere.

Where we do use GraphQL

We shipped one project on GraphQL end-to-end: an educational content aggregator with multiple content sources (YouTube, PDFs, quizzes, user-generated notes) and 4 different client apps (student, teacher, parent, admin). Each client wanted different slices of the same underlying data. GraphQL saved us from writing 4x the REST endpoints.

Even there, we kept the GraphQL layer thin—it's a gateway over REST microservices, not a full rewrite of the business logic. The GraphQL resolvers call our internal REST APIs and compose the response. This lets us stay REST-native on the service side while still serving a GraphQL surface to clients that need it.

What to watch out for

GraphQL's complexity shows up in auth, error handling, and caching. Auth: instead of one middleware per endpoint, you need per-field or per-resolver auth, which is more code and more edge cases. Error handling: a GraphQL response can be partially successful, which is hard to reason about. Caching: you lose HTTP caching and have to invent your own.

Also: N+1 queries are easier to stumble into than you'd think. DataLoader helps but isn't automatic; we've debugged GraphQL perf regressions that would have been impossible in REST.

The practical rule

If you're a founder with 1 mobile app, 1 web dashboard, and <150 API endpoints, default to REST. Reach for GraphQL when you have 3+ client surfaces with materially different data needs, or when your team genuinely wants the schema-first discipline.

About Xenotix Labs

We ship 30+ production apps from India. Flutter, Next.js, Node.js on AWS. Veda Milk (D2C dairy), Cricket Winner (real-time cricket on Kafka + WebSockets), Legal Owl (LegalTech super-app), ClaimsMitra (114+ REST APIs), Growara (AI WhatsApp automation), 7S Samiti (offline-first AI tutor for rural India). If you're shipping an MVP and want the simplest stack that works, visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.