Custom Next.js admin with real RBAC, audit log, and your existing integrations. Ships in 4–6 weeks on a flat monthly subscription.
- Scope
- Ship
- Iterate
monthly subscription
Who this is for
Ops or engineering lead at a 10–100 person company where Retool has hit a wall — permissions are too coarse, audit logging isn't court-defensible, or five separate Retool apps have calcified into a maintenance burden nobody owns. You need internal admin panel development that produces a real codebase, not another low-code dependency.
The pain today
- Retool seats and workflow runs billing $8k–$20k/year while requirements still grow
- Role-based access Retool can't express below team level — every support agent sees everything
- Compliance asking for an audit log Retool Business can't provide without custom workarounds
- Operators living in spreadsheets because the tool doesn't match real workflows
- Engineering rebuilding the same filter and bulk-action UI across four different Retool apps
The outcome you get
- Next.js admin with RBAC scoped to resource and record level, not just team
- Audit log capturing actor, timestamp, table, row ID, and before/after diff on every write
- Single admin wired to Postgres, Salesforce, Stripe, and your internal APIs
- URL-persisted filters and bulk actions that match how operators actually work
- Flat monthly subscription — priorities shift weekly and the cadence absorbs that
Build custom vs. keep Retool vs. switch to open-source
Three questions settle this fast. First: do you need RBAC below team level — individual roles, resource-scoped permissions, record-level visibility rules? If yes, build custom. Second: does compliance require a write-history log that's queryable, exportable, and court-defensible (fintech, healthcare, legal)? If yes, build custom. Third: are engineering hours going into maintaining five overlapping Retool apps instead of the product? If yes, a custom admin panel with a shared component library saves more than it costs within a year.
For teams of 5–20 operators with straightforward data-viewing needs, Retool, Appsmith, or Refine are often the right call. They're faster to prototype, cheaper to start, and fine until complexity compounds. I'll tell you honestly which path fits the situation. The Applications service exists for the cases where a real codebase is the only answer.
Next.js admin with RBAC scoped to resource and record level, not just team
Core capabilities every admin panel needs
Every internal tool I ship includes the same foundation. RBAC: users, roles, and permissions scoped to resources — a support agent sees their team's tickets, not the full customer table. Audit log: every write action recorded with user ID, role, timestamp, table, row ID, old value, and new value, queryable by any dimension and exportable to CSV. Cross-resource search: find anything by name, email, or ID with debounced server-side queries that don't hammer the database. Composable filters: URL-persisted so a link to a filtered view can be shared in Slack. Bulk actions: select-many, trigger action, confirm, with undo where the data model allows. Exports: CSV and JSON for any filtered view.
These are the features that determine whether an internal tool actually gets used. A panel without URL-persisted filters gets replaced by a spreadsheet within a month. An admin without audit log gets blocked by compliance before it reaches production.
120k+: Properties indexed and searchable.
Integrations to your existing stack
An admin tool earns its cost by replacing 'check three systems' with 'check one.' I wire it to whatever you already run: Postgres or MySQL as the primary data source, with read replicas for heavy queries so reporting doesn't slow down operations. Salesforce or HubSpot for customer context with two-way sync. Stripe for billing state, subscription status, and payment history. Internal APIs for anything proprietary. Slack for notifications on high-value events — a flagged account, a failed payment, a manual review triggered by an operator action.
All integrations respect the RBAC layer. The admin shows what the logged-in operator is permitted to see, not everything the service account can access. That distinction is where the compliance story lives, and it's easier to build right from the start than to retrofit.
Compliance, audit log depth, and access control architecture
Teams in fintech, healthcare, and legal aren't asking for audit logging as a nice-to-have. They need a write history that satisfies a SOC 2 Type II controls review or a HIPAA access-log requirement. The audit log I build captures every write action — not just deletes, but updates and creates too — with the full before/after diff stored alongside actor identity and timestamp. Logs are append-only in storage, queryable via the admin interface, and exportable for external auditors without requiring a database admin to run a query.
The access control architecture uses a three-layer model: role definition (what actions a role can perform on what resource types), team or tenant assignment (which data partition the user belongs to), and record-level rules (optional — blocks access below the team layer). Building this in Next.js with a proper middleware layer means every API route and every UI component is guarded by the same permission check. There's no way to reach a record through the UI that the access rules don't permit.
Case study: Imohub admin handling 120k+ records
Imohub's internal admin had to handle 120k+ property records spanning 40+ property types, multi-agent workflows, and deduplication of listings arriving continuously from 20+ scraping sources. I built the admin as a Next.js application backed by Laravel APIs, with MongoDB for property storage and Meilisearch powering cross-field search.
Operators could search, filter, merge duplicate records, flag listings for review, and export any filtered set in under 0.5 seconds end-to-end. Infrastructure cost dropped 70% versus the legacy stack. The consumer portal stayed fast because the admin gave operators the tools to keep data clean — good internal tooling is the hidden layer behind any high-scale consumer product, and it rarely gets the credit it deserves.
Monthly subscription pricing and timeline
Custom admin panel work runs under the Applications service: Standard tier at $4,999/mo, Pro tier at $5,499/mo. The subscription model means I ship continuously — new features, integrations, refactors, and fixes land in 2–4 day cycles. There's no 'phase 2 next quarter' bottleneck when operators find a better workflow in week three.
Typical first-version timeline is 4–6 weeks from kickoff to a production admin that operators are actively using. After that, most customers stay on subscription for 4–8 months through the full buildout, then step down to a lower-intensity maintenance cadence. Work Made for Hire: the code, infrastructure-as-code, credentials, and documentation are yours from day one. 14-day money-back guarantee; cancel anytime after.
Why fixed-price contracts fail for internal tools
Internal admin panels are living tools. Operators discover edge cases the week after launch that nobody modeled in a spec document. Fixed-price contracts force a choice: either say no to small, valuable changes, or run an endless change-order process that strains the relationship.
A monthly subscription removes that friction. If something small needs to ship, it ships this week. If something large appears mid-month, the priority conversation is about trade-offs, not budget. I've found that most teams deliver 3–5x more useful functionality under subscription than under a fixed-price 'ship it and maintain' contract — because the feedback loop between operators and shipping is fast enough to act on.
Recent proof
A comparable engagement, delivered and documented.
Rebuilt a real estate portal at a fraction of the cost
Rebuilt Imóveis SC's real estate portal as ImoHub, a faster, more scalable successor, handling 120k+ properties with sub-second search and drastically reduced AWS costs.
Read the case studyFrequently asked questions
The questions prospects ask before they book.
First production version is typically 4–6 weeks from kickoff. That covers RBAC, audit log, core data views, and the integrations scoped in the initial plan. More complex panels — multiple data sources, custom reporting, advanced bulk workflows — can run 8–12 weeks before the first full release. The subscription model means 'done' isn't a cliff; the admin keeps improving week by week after launch.
Yes, and gradual is usually the right way. The common pattern: keep Retool running for everything except the first module I ship. Once that's stable and operators prefer it, the second workflow migrates. Over 3–6 months the custom admin replaces Retool one area at a time. No big-bang cutover, no disrupted operations, no moment where the team is running blind.
Every write action: who (user ID and role), when (UTC timestamp), what (table name, record ID), and the before/after diff of changed fields stored as JSON. Logs are append-only, queryable through the admin interface by any combination of user, date, table, or record, and exportable to CSV for external auditors. This is what turns a custom admin into a court-defensible system of record rather than just a nicer UI.
That's exactly why Applications runs on a monthly subscription instead of fixed-price. Internal tool requirements shift as operators learn the product and discover better workflows. I ship in 2–4 day cycles, so new requirements land in the same week they're raised. No change-order negotiation, no waiting for 'the next phase' to be scoped and priced.
Yes. The app deploys on Vercel or AWS depending on data residency requirements and traffic scale, with a CI/CD pipeline, staging environment, error monitoring via Sentry or Datadog, and automated backups. Infrastructure is code using Terraform or Pulumi so nothing lives only in a console. If the engagement ends, another engineer can pick up the infrastructure the same day without needing me to hand anything over manually.
Retool's permissions work at the app and team level: a user either has access to an app or they don't, and within a team, access is mostly binary. Record-level RBAC adds a third layer: a support agent assigned to Region A sees only that region's tickets, not a global customer table they can filter. That distinction matters the moment you have internal users who shouldn't see each other's data — sales reps, regional managers, external contractors with limited portal access.
You keep everything. Work Made for Hire means the codebase, infrastructure-as-code, credentials, and documentation are fully yours from the first line of code. At cancellation I hand over a full export: git repository, environment variable documentation, deployment runbook, and any relevant database migration history. Cancel anytime after the 14-day money-back window with no termination fees.