Your Desktop App Is Your Best API Auditor

Most web applications ship APIs that look complete on paper but have never been tested by a real client. The web app — the only consumer — bypasses the API entirely, rendering data server-side with template logic. The API exists, the docs page works, but nobody has actually built anything against it.

The Web App Can Cheat

Django (or Rails, or any server-rendered framework) can cheat. Need a list of projects with their task counts? Throw a queryset annotation into the view, pass it to a template tag, done. The data never touches the API.

This means:
- Endpoints that return incomplete data go unnoticed
- Missing filters, search, and custom actions aren't felt
- Inconsistent URL patterns don't matter when the server handles routing
- Data shapes that would be awkward for a client are invisible

A Native Client Can't Cheat

When you build a desktop or mobile app against your own API, every shortcut is exposed:

• Missing endpoints: The Flutter app tried to load events and hit a 404 — the ViewSet existed but wasn't registered in the main router. The web app worked fine because it never used that route.
• Fragmented paths: Notes at /api/notes/, messages at /messages/api/threads/. Three separate routers for one API. A web app doesn't care. A mobile developer stares at this for an hour wondering what they're doing wrong.
• Missing actions: Need to filter tasks by project AND status? The web app just chains .filter() in the view. The API might not expose those query parameters at all.
• Incomplete responses: The web template can call file.derived_files.count in a loop. The API serializer might not include that field, because nobody asked for it.

The Hidden Cost to Outside Developers

This is where it really hurts. You ship your API, someone gets hired to build an integration, and they hit wall after wall:

• Endpoints at inconsistent paths
• Filters that work on some resources but not others
• Data shaped differently between similar endpoints
• Custom actions that aren't documented because the web app never needed them

And they blame themselves. "I must be doing something wrong." They spend days debugging what's actually a gap in your API. They might not even realize the problem is on your side — they just think your API is hard to work with and move on.

You'd never hear about it.

The Native App as First External Developer

Building a desktop or mobile client against your own API is the cheapest way to find these problems before a customer does. Every pain point the native app hits is a pain point an integration partner would hit.

In practice, building the AskRobots Flutter app exposed:
- An events endpoint that was registered at the wrong path
- API path fragmentation across three separate routers
- Missing REST endpoints for features that only had MCP access
- Dashboard data that had no API at all — the web page aggregated it server-side
- The realization that 5 features could be added immediately (API ready) while 5 others needed backend work first

None of this was visible from the web app. Everything worked. The API just hadn't been pressure-tested.

The Virtuous Cycle

Each client you add tightens the whole system:

1. Flutter app tries to build a screen → finds API gap
2. Fix the API for Flutter → MCP server gets better (same endpoints)
3. Better MCP → AI agents work more reliably
4. AI agents hit the API harder → find more edge cases
5. Outside developers eventually connect → everything just works

The first native client is the most valuable one. Not because of the app itself, but because of everything it forces you to fix underneath.