A domain-first platform practice for operators building internal tools, client portals, and vertical SaaS when the off-the-shelf stack ran out. Next.js, Rails, or Django. Built around how your team actually works.
We have turned away more custom platform briefs than we have built. Before any code, we run a build-vs-buy ledger. For roughly 70 percent of internal-tool briefs, an existing SaaS (Retool, Airtable, Monday, Zoho, HubSpot) covers 80 percent of the requirement. We name the SaaS, the 80 percent, and the 20 percent gap. If the gap is small, we recommend the SaaS and refuse the build. If the gap is genuinely bespoke and long-horizon, custom wins. Honest advice up front is the single biggest way we save clients from six-figure mistakes.
Internal tool. Client portal. Vertical SaaS. These are the three shapes we ship. Each has a distinct architecture, auth model, and success measure. Knowing which shape the brief fits is the difference between a 10-week MVP and a 40-week rebuild.
Admin dashboards, ops tools, data entry platforms. Internal users only, standard auth, read-heavy workflows with periodic writes. 15 to 30 screens typical.
timeline: 8-14 weeks
White-label, organization-per-client, per-user permissions, usage visibility, support tickets. Often paired with existing operations or project management internally.
timeline: 12-20 weeks
Marketing site, onboarding, billing (Stripe Billing), product, API, admin. Domain-specific, for brands who discovered operating their business requires shipping the tool.
timeline: 16-28 weeks
A custom platform is not a feature list. It is a lattice of connected modules whose dependency graph is the architecture. The animation below is the lattice that underlies the internal-tool and client-portal shapes we ship most often.
Every platform has a core noun: an Order, a Patient, a Shipment, a Claim, a Contract. The whole platform is dependencies around that noun. We spend week one mapping the domain model (entities, relationships, lifecycle states, events) before writing any code. The architectural decision record (ADR) that comes out of week one sets the ceiling for every shortcut a later engineer might be tempted to take.
| Next.js + Postgres | Rails + Postgres | Django + Postgres | |
|---|---|---|---|
| best for team | React/TS engineers | Rails veterans, CRUD-heavy | Python teams, data-heavy |
| shipping speed | good | fastest CRUD | fast |
| admin generators | build or Retool for admin | ActiveAdmin, Avo | Django admin (the best in class) |
| marketing site co-located | yes, natural | possible, usually separate | possible, usually separate |
| best fit shape | client portal, vertical SaaS | internal tool, CRUD platform | data-heavy, ML-adjacent, regulated |
We do not hand-roll authentication. Clerk, Auth0, Supabase Auth, or NextAuth with a managed OAuth provider do authentication better than any custom implementation. What we build is the permission model on top: roles, capabilities, row-level security, and the audit log that proves who changed what.
The biggest difference between a platform that stays alive and one that becomes legacy is migration discipline. Every schema change goes through a migration file in the repository. Migrations are reversible. Migrations run in CI before they run in production. Production databases are never hand-edited. This single habit extends platform lifespan by years.
Platforms that ship as "request-response only" eventually hit a scaling wall where every user action blocks on downstream work (emails, webhooks, cache invalidation, analytics). We design event-driven from week one. State changes fire events. Background workers consume them via a queue. The platform stays responsive under load and integrations stay decoupled from the core.
Signup, password reset, invoice, notification. Via Resend, Postmark, or SendGrid. Retries with exponential backoff.
Outbound to third-party integrations. Signed, retried 5 times with backoff. Dead-letter queue for permanent failures with admin notification.
Report generation, data export, large backfills. Via Inngest, Sidekiq, or Celery. Progress tracked, cancelable.
Every integration lives behind a dedicated service layer. Never inline in the domain logic. If Salesforce changes their API, we swap the Salesforce service class without touching the core. If the business moves from NetSuite to SAP, the migration is localized. This isolation is cheap to do up front and expensive to retrofit later.
NetSuite, SAP, Dynamics, QuickBooks, Xero, Acumatica
Salesforce, HubSpot, Pipedrive, Zoho
Snowflake, BigQuery, Redshift via Airbyte or Fivetran
Sentry, Datadog, Logtail, PostHog for product analytics
Custom shipment-routing tool with real-time carrier rates, per-user permissions, NetSuite sync, audit log. Rails + Postgres + Sidekiq + Stimulus. 12 weeks from discovery to production.
Multi-organization client platform, per-user HIPAA-adjacent permissions, Stripe Billing, white-label per org, audit log. Next.js + Prisma + Postgres + Inngest + Clerk. 18 weeks to production.
2 weeks. Domain model, build-vs-buy, stack reco, ADR log. Refundable. Contact for quote.
8-14 weeks. Auth, roles, 15-30 screens, integrations. Contact for quote.
12-20 weeks. Multi-tenant, per-user perms, billing. Contact for quote.
16-28 weeks. Marketing + product + billing + admin. Contact for quote.
Three conditions usually tip it to custom. First, the permission model is genuinely bespoke and no SaaS row-level security comes close. Second, the data entities are proprietary to the business (custom legal contracts, regulated healthcare workflows, industry-specific inventory) and owning the schema outweighs the SaaS convenience. Third, the platform will be used for 5+ years by 50+ users daily, making the build cost amortize cleanly. Retool wins for quick internal admin tools; Airtable wins when the team already works in tables; custom wins when neither covers the workflow and the brief is long-horizon.
Three defaults we go to most often. Next.js with TypeScript for teams already working in React and JavaScript, or for platforms that need a public marketing surface + authenticated product on one codebase. Ruby on Rails for teams valuing shipping speed, rich admin generators, and a mature ecosystem, especially when the domain is CRUD-heavy. Django for Python-native teams or for data-heavy platforms where Python libraries in the domain (scientific computing, ML, scraping) matter more than framework speed. We do not ideologically prefer one stack. We pick based on who will run the platform after we hand off.
Platform work is quoted by scope, team composition, and domain complexity. An internal tool MVP runs 8 to 14 weeks. A multi-tenant client portal runs 12 to 20 weeks. A vertical SaaS build (marketing site plus product plus billing plus admin) runs 16 to 28 weeks. US and UK senior platform engineers are $140 to $190 per hour at boutique agencies; Indian senior engineers are $85 to $130. A 2-week discovery runs as a fixed fee and is refundable against any engagement that follows. Scoped quote in 48 hours of an intro call.
Auth: we default to managed providers (Auth0, Clerk, Supabase Auth, or NextAuth with a managed OAuth provider). We do not hand-roll authentication for production platforms. Permissions: row-level security is the default pattern, not endpoint-level authorization. We model permissions as capabilities (can_invoice, can_approve_refund) mapped to roles, mapped to users, with row-level scoping through a tenant or organization column on every row. For platforms with complex permission matrices we add attribute-based access control (ABAC) on top. Every permission change is audit-logged.
You do, entirely. GitHub repository under your organization from day one. Infrastructure on your accounts (Vercel, AWS, Google Cloud, Cloudflare). Database in your region on your cloud. Environment variables, API keys, and third-party integrations under your billing. DH engineers get named access, removable any time. On exit: repository transferred, deployment documentation written, runbook for production incidents recorded as Loom, 30-day support tail. No vendor lock-in through code, config, or hosting.
Three habits. One, dependency versions pinned and a quarterly upgrade cadence we budget into retainer. Two, database migrations treated as first-class (forward + reverse, tested in CI, never hand-edited in production). Three, an architectural decision record (ADR) log where every significant choice is written down with context, so a future engineer (yours or ours) can understand why the code looks the way it does. Most custom platforms become legacy because the original team left and nothing was documented. We document as we go.
Named integrations with NetSuite, SAP, Salesforce, HubSpot, QuickBooks, Xero, Snowflake, BigQuery, and Segment. Three integration patterns cover most: webhook-based for real-time events, queue-driven for bulk syncs (Kafka, RabbitMQ, or a managed queue), and scheduled ETL via Airbyte or Fivetran for warehouse loads. We always isolate integrations behind a dedicated service layer so the core platform can outlive any single integration partner.
Two weeks. Domain model, build-vs-buy analysis, stack recommendation, ADR log. Refundable against any build that follows. Scoped quote in 48 hours.