I work on RollTok, an AI API gateway project. Here is a product-scoping question, not a report of validated customer demand. An API gateway could expand into caching, fine-tuning endpoints, retry policies, usage dashboards, team management and billing. Building all of them would turn a focused interface into several products. I'm trying to figure out where to draw the line between "core gateway functionality" and "nice-to-have tooling." My current thinking: Core boundary: Request routing, provider failover, basic cost tracking, API key management. These directly serve the gateway's job—making API calls reliable and observable. Outside boundary: Things like training job orchestration, model evaluation pipelines, or hosted fine-tuning. These feel like separate products that could integrate with a gateway but shouldn't be built into one. The gray zone: Features like request replay for debugging, or automatic prompt versioning. Useful, but do they belong in the gateway itself or as separate tools that consume gateway logs? I'm curious how others approach this, especially if you're building developer tools or infrastructure projects. Do you have a framework for saying no? Do you build extensibility points and let users add their own logic, or do you try to cover common cases out of the box? What's been your experience with scope creep in early-stage projects? How do you validate that a feature request represents real need versus one person's specific workflow?   submitted by   /u/Obvious-Radish990 [link]   [comments]