MVP scope

The first version of JiesdaPay should stay focused.

In scope

The MVP should prove one complete loop:

1. A developer connects one MCP/API endpoint or hosted skill.
2. The developer configures name, tool description, pricing, and rail binding.
3. JiesdaPay publishes a paid endpoint.
4. A user calls the service through an agent.
5. The first paid call asks for a scoped task budget.
6. The agent runs calls inside that budget.
7. JiesdaPay records call, reason, price, result, approval, and payment event.
8. The user sees a readable spend summary.
9. The developer sees usage and revenue-related events.

Out of scope for the first version

Avoid building too much too early.

The first version should not include:

• Platform-owned wallet.
• Stored user balance.
• Funds custody.
• Recharge and withdrawal.
• Invoice system.
• Complex revenue sharing.
• Large marketplace.
• Arbitrary script execution.
• Consumer mobile app.
• Full enterprise procurement suite.

Why the scope matters

The core product risk is not whether a generic SaaS dashboard can be built. The core risk is whether paid agent calls can be made safe, explainable, and monetizable with less friction than building a custom payment and audit stack.

The MVP should test that exact risk.