The Problem

When building frontends, I didn't want to hardcode JSON data everywhere. I wanted to build against actual API endpoints and practice the integration work, but spinning up a real backend for every prototype felt like overkill.

After doing this dance too many times - writing throwaway Express servers or mocking fetch calls with static JSON - I realized other developers probably face this same friction.

The typical workflow looked like this:

1. Start building a React component

2. Realize I need user data

3. Choose between: hardcoded JSON arrays OR spinning up Express/Django

4. If I chose Django: pip install requirements, define models, run migrations, write views/URLs, configure CORS

5. All this before writing a single line of frontend logic

This context-switching killed momentum. I'd spend 30 minutes on backend setup for a feature that takes 10 minutes to prototype. Multiply this across dozens of projects, and you've lost days to infrastructure overhead.

That's why I built MockMyData.io.

What It Does

MockMyData.io lets developers generate mock REST API endpoints in seconds. When you sign up, you're automatically assigned a subdomain and API key. Then you define your data schema (field names and types) to create your endpoints.

You can either:

Enter custom JSON - Full control over your mock data

Auto-generate records - MockMyData.io creates realistic data based on your field types

Want to try it? Head to https://mockmydata.io - you can generate a demo mock API right from the landing page and start making requests immediately. No sign-up required.

Perfect for:

The Journey: 2.5 Months Solo

I went from concept to launch in about 10 weeks, building everything myself. The aggressive timeline kept me focused on shipping rather than over-engineering.

Tech Stack:

Architecture Decisions

Multi-Tenant Subdomain Architecture

The core challenge was giving each project its own API endpoint while keeping infrastructure simple. I went with subdomain-based routing where users get automatically assigned subdomains on signup (e.g., `random-name-123.api.mockmydata.io`). Pro users can create custom subdomains and change them anytime.

How it works:

- User signs up and gets assigned a subdomain

- Pro users can customize: `mycompany.api.mockmydata.io`

- All API requests hit their subdomain endpoint

Implementation challenges:

1. DNS Management

Had to set up wildcard DNS records pointing all subdomains to the same server. Used Cloudflare for DNS with a wildcard A record (`*.api.mockmydata.io`).

2. SSL Certificates

Needed wildcard SSL certificates to handle unlimited subdomains. Render.com handles automatic SSL certificate provisioning and renewal for wildcard domains, which simplified deployment significantly.

3. Request Routing

Django's URL routing doesn't natively support subdomain-based tenant isolation. Built custom middleware to:

- Extract subdomain from request

- Look up project in database

- Attach project context to request object

- Route to appropriate data

# Simplified middleware example
class SubdomainMiddleware:
  def init(self, get_response):
    self.get_response = get_response
  def call(self, request):
    subdomain = request.get_host().split('.')[0]
    try:
      project = Project.objects.get(subdomain=subdomain)
      request.project = project
    except Project.DoesNotExist:
      return HttpResponse('Project not found', status=404)
    return self.get_response(request)

Database Design

Used PostgreSQL with a shared schema approach rather than separate databases per tenant. Each endpoint and record has a `project_id` foreign key. This keeps infrastructure simple while maintaining data isolation through application-level filtering.

Why not separate databases per tenant?

- Simpler infrastructure (one database to manage)

- Easier backups and migrations

- Cost-effective for free tier users

- Row-level security handles isolation

Technical Challenge

#1: Multi-Tier Rate Limiting

This was trickier than expected. I needed two types of rate limiting:

Daily Quotas - Tier-based limits

- Free: 100 requests/day,

- Pro: Unlimited

Request Throttling - Spam prevention

- All tiers: Max 60 requests/minute

Why Redis?

Needed atomic increments and TTL support. Redis handles both perfectly:

def check_daily_quota(self, user):
  """Hard limits for FREE users"""
  daily_count = self.get_daily_count(user.id)

  DAILY_LIMIT = 100

  if daily_count >= DAILY_LIMIT:
    return False, f'Daily limit reached ({DAILY_LIMIT} requests/day)'

  return True, 'OK'

# CloudFlare helps with rate limiting and makes it simple and reliable

The Challenge: Making this performant at scale

- Redis calls add latency

- Need to fail fast for rate-limited requests

- Must be accurate (can't lose count data)

Solution: Batched Redis commands using pipelines reduced roundtrips, cutting rate-check latency significantly. I also implemented a circuit breaker pattern - if Redis goes down, requests pass through to prevent complete service outage.

Technical Challenge #2: Handling Pro-to-Free Downgrades

Free users can create up to 3 endpoints. However, when Pro users downgrade to Free, they might already have dozens of endpoints created. Rather than force them to delete endpoints, I let them choose which 3 remain active and accessible via API.

This required:

- Real-time enforcement in middleware before database queries

- Caching to avoid N+1 queries on every API request

- Graceful Redis fallback if caching fails

The system checks endpoint access on every API request:

#(Sample code)
def _check_endpoint_selection(self, request, user, project):
    """Check if endpoint is accessible for downgraded free users"""
    # Pro users: all endpoints accessible
    if user.is_pro_active:
        return True, None   

    # Count total endpoints (cached)
    endpoint_count = cache.get(f'project:{project.id}:endpoint_count')
    # If <=3 endpoints total, all are accessible
    if endpoint_count <= 3:
        return True, None

    # They have >3 endpoints (downgraded from Pro)
    # Check if THIS endpoint is in their selected 3
    endpoint = cache.get(f'endpoint:{project.id}:{path}')
    if not endpoint.default_selected:
        return False, JsonResponse({
            'error': 'Endpoint Not Selected',
            'message': 'This endpoint is not in your active selection. Free users can only have 3 active endpoints.',
            'action_required': 'Visit your dashboard to manage active endpoints'
        }, status=403) 
        
    # If cache miss then we fetch from database

This gracefully handles downgrades without data loss - users keep all their endpoints but must choose which 3 are live.

Technical Challenge #3: Handling Anonymous Demo Endpoints

Users can create temporary mock APIs without signing up. These urls expire within a short time and have strict limits on the total requests. The challenge was:

- Storing temporary projects in Redis (not database)

- Enforcing limits without database writes

- Supporting full CRUD operations on anonymous data

- Updating Redis cache after POST/PUT/PATCH/DELETE

All anonymous endpoints get a `demo-` prefix and live entirely in Redis with proper cache updates after mutations.

Technical Challenge #4: Storage Limits & Payload Validation

Implemented 4-layer protection to prevent abuse:

Layer 1: Request payload size

- Free: 5KB per request

- Pro: 30KB per request

Layer 2: Individual field size

- Free: 2KB per field

- Pro: 10KB per field

Layer 3: Item count per endpoint

- Free: 20 items

- Pro: 200 items

Layer 4: Total endpoint storage

- Free: 15KB per endpoint

- Pro: 400KB per endpoint

This prevents users from storing massive datasets while keeping the service performant and cost-effective.

What's Next: Django Project Generator

I'm building a feature that exports your mock API as production-ready backend code starting with Django. Here's how it works:

Input: Your MockMyData.io project with endpoints defined

Output: Complete Django REST Framework project with:

- Models generated from your schema

- Serializers for each endpoint

- CRUD operations

- URL routing configured

- Authentication setup (Optional)

- README with additional instructions & Suggestions

Example transformation:

Your MockMyData endpoint:

  {
  "name": "users",
  "fields": {
  "username": "string",
  "email": "email",
  "age": "integer"
  }
}

Generates Django model:

class User(models.Model):
username = models.CharField(max_length=255)
email = models.EmailField()
age = models.IntegerField()
created_at = models.DateTimeField(auto_now_add=True)

Plus serializers, views, and URLs - everything a user need to run their server right away. I also plan on exploring other backends too

Why this matters:

Turns MockMyData.io from a testing tool into a full development accelerator. Prototype with mock data, export to production code when ready.

Lessons Learned

1. Ship fast, iterate faster

The 2.5-month timeline was aggressive but kept me focused on shipping. Rather than building every possible feature upfront, I launched with the core product working and plan to aggressively iterate based on what users actually need.

2. Rate limiting is harder than you think

Especially across multiple tiers and preventing race conditions. Redis pipelines were essential.

3. Cache everything strategically

Redis saved my infrastructure costs. Without caching, I'd be paying 3-4x more for database and compute.

4. Stripe webhooks are your friend

Once you understand them. The documentation is excellent, and webhook-driven subscription management is reliable

6. Build for failure

My circuit breaker pattern for Redis means the service stays up even when caching fails. Graceful degradation is better than complete outages.

Try It Out

🚀 https://mockmydata.io - Free tier available, no credit card required

🎉 Launching on Product Hunt January 14th - Would love your support!

💬 Questions I'd love feedback on:

What backend frameworks would you want for code export? (Django, Express, FastAPI, Rails?)

What's missing that would make this a must-have tool for you?

Drop a comment below - happy to answer questions about Django, React, multi-tenant architecture, or building a SaaS solo! You can also connect with me @marcuscodes.