How dogfooding shapes our product

The bugs we find are your bugs

Real example 1: Our rate limiter was taking 707ms per request. We analyzed Redis call patterns, found 4 sequential calls, and refactored into a single mega-pipeline. Now it's 186ms (74% faster).

Real example 2: Our signature validator was making a database query on every request (213ms). We cached the secret hash in the API key middleware. Now it takes 0-1ms (99.5% faster).

Real example 3: During testing, we got mass account creation attacks (someone scripted 500 fake signups). Our rate limiter broke. We rebuilt it with 6 security layers: per-tier quotas, abuse event logging. Now it survives DDoS attempts.

Real example 3: Batch operations were slow because we validated each file individually. We refactored to parallel validation. 100 files now validates in ~800-1000ms instead of 5 seconds.

We don't find these problems in a test suite. We find them when we're trying to ship our own features and the API pisses us off.

Performance numbers aren't marketing claims

We publish response times because we need them to be fast for our own apps. These are real numbers from our production benchmarks:

The difference? Crypto signing is pure math—it happens in 5-15ms regardless of network. Full API response includes authentication, rate limiting, quota checks, and your network latency.

If a provider is slower than expected, we optimize aggressively.

We pay for our own infrastructure

ObitoX's backend runs on Cloudflare Workers (1M requests/month free). Our own dashboard makes ~50,000 requests/month to the API. We're still on the free tier.

When we hit 1M requests, we'll pay the $5-10/month upgrade just like you would. We're not running on "internal credits" or special pricing. We pay the same rates.

This keeps us honest. If pricing gets too expensive, we feel it before you do.

Features exist because we needed them

Batch operations: We were uploading profile photos for 100 users in a bulk import. Making 100 separate API calls was stupid. We built batching (1 API call for 100 files). Now it's a core feature.

JWT tokens: We needed to share files with expiring links (like Dropbox). Generating a new signed URL for every access was overkill. We built JWT-based tokens that work across all providers.

We're not "imagining use cases." We're solving our own problems and sharing the solutions.

Error messages we write for ourselves

Bad error message (most APIs):

Our error message:

We write errors like this because we got stuck debugging "Invalid credentials" at 2am and swore we'd never inflict that on anyone else.

The roadmap is our backlog

We don't have a "vision board" with moonshot features. Our roadmap is literally:

• What broke when we used it last week (highest priority)
• What feature we wished existed while building something
• What users requested that we also need

Current roadmap (Jan 2025):

1. Time-limited download URLs (we need this for sharing files)
2. Custom domains for R2 (we want cdn.obitox.com instead of pub-xxx.r2.dev)
3. Webhooks (we need to know when uploads complete without polling)

These aren't "customer requests." These are features we're building for ourselves and will release to everyone.

Why this matters to you

When you report a bug, you're not talking to a support team who forwards it to engineering who adds it to a backlog that gets reviewed quarterly.

You're talking to the people who built the thing and use it every day. If it's broken for you, it's probably broken for us too. We fix it because we need it fixed.

This is why response times are fast, error messages are helpful, and features actually solve real problems. We're not guessing what developers need. We are developers, and we needed this.