Why we built ManyRows

The same problem, every time

Every project starts the same way. You scaffold the app, pick your framework, and start building the thing that makes your product unique. Then reality sets in.

You need user registration. Login. Password reset. Sessions. Roles and permissions. Feature flags. Config values that change per environment. Audit logs so you can answer “who changed what?” six months from now.

None of this is your product. But all of it is required.

What we kept rebuilding

Over the years, we noticed we were writing the same code again and again:

• User management: registration, email verification, profile editing
• Auth & sessions: JWT tokens, refresh logic, logout
• Roles & permissions: defining roles, assigning them, checking access
• Feature flags: enabling features per environment or customer
• Config keys: typed runtime configuration without redeploying
• Audit logs: tracking every change for compliance

Each project implemented these slightly differently. Each one had its own bugs. Each one took weeks to get right.

ManyRows: the boring parts, handled

ManyRows is the platform we wished we had. It gives you:

1. A control plane: a web dashboard where you manage users, roles, environments, config, and feature flags. No code required, changes take effect instantly.
2. A REST API: every feature is accessible from any language or framework via standard HTTP endpoints.
3. AppKit (optional): a React SDK that wraps the API into hooks and components. Drop it in and get a complete auth UI, user management, and runtime data in minutes.

The key word is optional. AppKit is a convenience for React apps, but everything it does is available through the REST API. Use Python, Go, Swift, or plain fetch, ManyRows doesn’t care.

What’s next

We’re shipping image and file management, webhook integrations, and more. The goal stays the same: if every app needs it but it’s not your differentiator, ManyRows should handle it.