Daniel sent us this one — he built what he calls a Frankenstein of software for a nonprofit event during Climate Week in New York. The brief was basically: send press invites, track RSVPs, manage check-in, issue credentials. They didn't want Eventbrite, didn't want anything off the shelf, so he ended up standing up an entirely bespoke system on Airtable with a custom UI scaffolded around it. It worked, but it got him thinking — when you're building these internal tools, these CRUD apps that are all slight variations on the same pattern, is there an actual framework that gives you the skeleton? Not just a front-end starter like Refine, but the core back-end logic, the data layer, something you can deploy on Vercel and not have to define every table from scratch. What exists across different stacks that gives you a genuine starting point?
This is one of those questions where the answer depends entirely on how much scaffolding you actually want versus how much control you're willing to trade away. CRUD describes a colossal amount of business software. You're just building relationships between tables and adding business logic on top. The problem is that the market has bifurcated in a weird way. On one end, you've got the full no-code platforms — Appsmith, ToolJet, Budibase — where you get a complete internal tool builder. On the other end, you've got headless CMS platforms and back-end-as-a-service offerings that give you the data layer and let you bring your own front end. And then there's this middle ground that's much less populated, where you want actual code you own and deploy but you don't want to write the same boilerplate for the four hundredth time.
That middle ground is exactly what the prompt is poking at. Not a platform you log into, not a service you subscribe to — actual code that lives in your repo, that you deploy on your own infrastructure, but that handles the boring eighty percent.
And the boring eighty percent is remarkably consistent across projects. Authentication, authorization, database migrations, API generation, basic CRUD endpoints, file upload, email sending. Every single internal tool needs these things. And yet most developers start from a blank directory and install Express and just start writing routes.
Which is the software equivalent of milling your own flour every time you want to make bread.
Perfect way to put it. So let me walk through what actually exists, because there are real options here and they're not all obvious. Let me start with the one the prompt mentioned — Refine. Refine is genuinely interesting because it's not a platform, it's a React framework specifically for building enterprise-grade internal tools. The key architectural decision is that Refine is completely headless by default. It doesn't ship with a UI framework. You bring your own — Material UI, Ant Design, Chakra, Mantine, whatever. It provides the data hooks, the routing, the authentication state management, the form handling, all the CRUD operations, and then you render however you want.
It's the logic layer without the visual layer. That's a useful separation, because the visual layer is where most of the bespoke requirements live anyway.
It's back-end agnostic. You can connect it to a REST API, GraphQL, Supabase, Strapi, Airtable, even direct database connections. So in the case of the event system from the prompt, you could have kept Airtable as the data source and used Refine to build the admin interface on top of it, getting all the CRUD operations, table views, form validation, and authentication flow without writing any of that from scratch. Refine handles data fetching, caching, invalidation, optimistic updates — it's built on React Query under the hood, so you get all that for free. It's MIT licensed, full open source. The company makes money from Refine Cloud and enterprise support. It's been around since about twenty twenty-one, with something like thirty thousand GitHub stars and a pretty active community.
Thirty thousand stars is respectable. But the prompt asked about the back-end side specifically. Refine is front-end heavy, even if it connects to anything. What about the actual data layer? The part where you define your tables and relationships and get an API automatically?
This is where things get interesting and slightly fragmented. Let me start with the most opinionated and work toward the most flexible. The most opinionated approach is something like Supabase. Supabase gives you a Postgres database, and when you define your tables through their schema designer or migrations, it automatically generates a REST API for every table. It also gives you row-level security policies, real-time subscriptions, authentication, file storage. It's essentially an open-source Firebase alternative. The generated API is instant — you create a table called journalists, you immediately get endpoints for selecting, inserting, updating, and deleting. The API uses PostgREST under the hood, a Haskell-based web server that turns a Postgres database into a RESTful API.
I've used Supabase. The auto-generated API is magical the first time you see it. You create a table, refresh a page, and there's a fully documented endpoint. But the minute your business logic gets beyond basic CRUD, you're writing Postgres functions or edge functions, and suddenly you're in a different complexity tier.
That's the trade-off, and it's exactly where these projects tend to hit a wall. The prompt described a system that needed mail merge, RSVP tracking, press credential generation — that's not just CRUD. That's workflows. And workflows are where most of these frameworks show their seams. But Supabase has been building toward this exact problem. Their edge functions — Deno-based and deployed globally — are designed to handle this kind of business logic. You write a function that triggers when a row is inserted into the RSVP table, it sends the confirmation email, updates the press credentials table, and logs the activity. It's serverless, deploys on their infrastructure, and you can call it from your front end or from database triggers.
If you want to deploy on Vercel, which the prompt specifically asked about, Supabase plays nicely. You host the database at Supabase, the front end on Vercel, and the edge functions can live on either platform. The boundary is clean.
And Supabase has a generous free tier — for a single event like the one in the prompt, you'd never leave it. But here's the thing — the prompt wasn't asking about platforms. It was asking about frameworks. Code you own, code you deploy. And Supabase, for all its virtues, is a platform. You don't self-host the generated API layer. You could — Supabase is open source — but practically speaking, most people don't.
Which brings us to the actual code-first frameworks. This is the middle ground you mentioned.
And there are a few that deserve real attention. Let me start with the one I think is most directly relevant: RedwoodJS. Redwood is a full-stack JavaScript framework specifically designed for startups and small teams building web applications. It combines React on the front end with a GraphQL API layer on the back end, and it uses Prisma as the ORM. The key thing is that it has something called scaffolds. You define your data model in a Prisma schema file — your journalists table, your events table, your RSVPs table, your press credentials table — and then you run a single command: yarn redwood generate scaffold journalist. And it generates the GraphQL type definitions, the service file with all the CRUD operations, and the React components for listing, creating, editing, and viewing that entity. It's not a no-code tool. It generates actual code that lives in your repository, that you can modify, extend, override.
That's the critical distinction. Generated code you then own, versus a platform that owns the logic and you just configure it. The prompt's whole scenario — a bespoke event system with very specific, non-standard requirements — that's exactly where generated code wins. The scaffold gives you the starting point, and then you modify the parts that need to be different.
Redwood's philosophy is "convention over configuration" in the Rails tradition, but with a modern JavaScript stack. Your database schema is the source of truth. Everything flows from that. And because it uses Prisma, you get type safety all the way from the database to the front end. If you change a column name in your schema, TypeScript tells you everywhere you need to update.
That TypeScript coverage across the full stack is one of those things that sounds like a nice-to-have until you've done a project without it, and then it's a must-have. So Redwood gives you the back-end scaffold. What about the deployment story? The prompt specifically asked about Vercel.
Redwood deploys to Vercel, Netlify, AWS, anywhere that supports Node and serverless functions. They have a Vercel deploy guide that is, I think, three steps. The database can be anywhere — PlanetScale, Supabase, Railway, a plain Postgres instance. Redwood doesn't care. It just needs a connection string. And the serverless story is solid because Redwood splits your GraphQL API into individual serverless functions per operation. So a query that fetches journalists runs as one function, a mutation that creates an RSVP runs as another. They scale independently.
That's clever architecture. Most serverless deployments dump the entire API into a single function. Splitting by operation means you get granular scaling and cold starts only affect the specific operation being called.
Cold starts on Redwood are fast because the functions are small — tens of milliseconds, not seconds. But let me move to another option that takes a different approach entirely: Payload CMS. Payload is technically a headless CMS, but calling it that undersells it. It's really an application framework that happens to have a built-in admin panel. You define your collections — basically database tables with extra metadata — and Payload automatically generates a full REST and GraphQL API, an admin UI with role-based access control, file upload handling, email sending, and localization. All in TypeScript. All open source under the MIT license.
The admin UI is the part that's relevant here, because the prompt described building a custom interface around Airtable. If you used Payload instead, you'd get that admin interface for free, and you could still build the public-facing parts however you wanted.
The admin UI is fully customizable — custom components, custom views, custom fields. It's built with React, so if you need a specialized dashboard for checking in attendees, you can build that as a custom view within the Payload admin. And because Payload generates a full REST and GraphQL API, anything you can do in the admin UI, you can also do programmatically. Your press invitation system could use the API to trigger email sends, update RSVP statuses, generate credentials — all from custom server-side logic written as Payload hooks.
Hooks are the secret weapon here. A hook that fires after an RSVP is marked as accepted, sends the press pass email, and updates the credential database. That's the kind of workflow logic that makes these systems feel cohesive rather than like a collection of disconnected tables.
Payload's hook system is extensive. You've got before and after hooks on every operation — create, read, update, delete — at both the collection level and the field level. You can hook into authentication events and file uploads. It's designed for exactly the kind of business logic that turns a CRUD app into an actual business tool. The newest version, Payload three point oh, moved to Next.js as its underlying framework. That means you get the entire Next.js ecosystem — server components, server actions, the App Router — with Payload's admin and API layer on top. And it deploys natively on Vercel.
That's a significant architectural shift. js as the foundation means you're not learning a custom server framework, you're learning extensions to something a lot of developers already know. And the Vercel deployment story becomes trivial.
The downside with Payload is that it's more opinionated than Redwood. With Redwood, you get generated code you can take in any direction. With Payload, you're working within the Payload paradigm. The admin UI is fantastic, but if you need something that doesn't fit the Payload model, you're fighting the framework. For the specific event scenario from the prompt, Payload would actually be an excellent fit because it's built for content-driven applications with structured data and workflows. An event with media lists, RSVPs, and credentials is fundamentally a content management problem with some workflow automation.
That's a useful reframe. The prompt described it as a Frankenstein of software, but it's really a content management problem with a very specific content model and a set of automated actions tied to state changes. Most bespoke business software is exactly that.
Let me throw one more into the mix, because it takes a fundamentally different philosophical approach: Blitz.js, built on Next.The core idea is that it eliminates the API layer entirely. Instead of writing REST endpoints or GraphQL resolvers, you write functions that run on the server, and you call them directly from your front-end components. Blitz handles the serialization, the network boundary, the authentication. You write a function called createJournalist, you import it in your React component, you call it. That's it. No API route, no fetch call, no data fetching library.
Wait, so it compiles away the network boundary? The function looks like a local call, but at build time it becomes an API route?
It's the RPC pattern — remote procedure call. The function always runs on the server, but from the developer's perspective, it's just an async function call. Blitz uses a compiler to split your code and generate the API routes automatically. This is similar to what React Server Actions do now, but Blitz was doing it years earlier. The advantage is that you eliminate an entire layer of indirection. No REST endpoints to design, no GraphQL schema to define, no data fetching hooks to configure. You write your business logic as plain TypeScript functions and call them from your UI.
That's philosophically appealing. The API layer in most applications is pure ceremony — translating between two representations of the same data, adding latency and surface area for bugs. Eliminating it entirely is a radical simplification. But I assume there's a trade-off somewhere.
The biggest is that you're tightly coupled to Blitz's compilation step. If you ever want to expose a public API for third parties, you have to build that separately. The second is that the mental model takes adjustment — developers are used to thinking about the network boundary as a hard line. Blitz makes it invisible, which is great until something goes wrong and you need to debug what's actually happening over the wire. And the third is that Blitz has had a somewhat turbulent development history. The original founder stepped back, the framework went through a rewrite, and the community is smaller than Redwood's or Payload's.
It's the most elegant abstraction with the most questions about long-term viability. Not a dealbreaker for a single project, but worth knowing going in.
That's a good segue to talk about the lower-level building blocks, because a lot of the time, the right answer isn't a full framework. It's a collection of libraries that each do one thing well, composed together. The prompt mentioned wanting to avoid reinventing the wheel. There are some excellent wheels available.
Give me the library composition approach. If someone said, I don't want a framework, I want to pick my own pieces, what does that stack look like in twenty twenty-six?
The core is an ORM with strong migration support and type generation. Prisma is still the dominant player — you define your schema declaratively, Prisma generates a fully typed client, and you get migrations for free. Drizzle is the newer challenger that's gained traction — it's lighter weight, generates SQL closer to what you'd write by hand, and doesn't require a generation step for every schema change. It uses TypeScript's type inference directly. For a project like the event system, you'd define your journalists, events, RSVPs, and credentials tables in either Prisma or Drizzle, and you'd get type-safe database access immediately. That's your data layer sorted.
Then the API layer?
If you're on Next.js, you can use API routes or route handlers — serverless functions that query the database and return JSON. That's fine for a few endpoints, but it gets repetitive fast. A better option is tRPC, which gives you end-to-end type safety from your database to your front end without a GraphQL layer. You define your procedures — your create, read, update, delete operations — as TypeScript functions, and tRPC generates a typed client for your React components. It's similar in spirit to Blitz's RPC approach, but more explicit about the API boundary. You know you're making a server call, you just don't have to worry about the types being wrong.
TRPC has become the de facto standard for this in the TypeScript ecosystem, hasn't it? I see it everywhere now.
It has, and it's earned that position. The developer experience is excellent. You change a database column, update your Prisma schema, regenerate the client, and TypeScript immediately tells you every front-end component that's accessing the old column name. You can't ship a type mismatch. For a project with tight deadlines — which the prompt described — that kind of safety net is invaluable.
The library composition stack is something like: Drizzle or Prisma for the database layer, tRPC for the API layer, Next.js for the deployment framework, and something like NextAuth for authentication. That's four libraries that together give you most of what a full framework like Redwood gives you, but with more flexibility and more decisions to make.
The decision fatigue is real. Every one of those choices has alternatives that are also good. Instead of Next.js, you could use Remix or SvelteKit. Instead of tRPC, you could use GraphQL with something like Pothos for code-first schema generation. Instead of Prisma, you could use Kysely for a lower-level query builder. The combinatorics get overwhelming. This is actually the strongest argument for a full framework like Redwood or Payload — someone else has already made these decisions, and they've made them in a way that's internally consistent and tested together.
There's a parallel here to the prompt's original scenario. The client didn't want Eventbrite because it was "too complicated." But what they ended up with was a bespoke system that was vastly more complicated to build and maintain. The instinct to avoid off-the-shelf solutions because they have features you don't need is understandable, but it often leads to underestimating the complexity of what you do need.
That's the build versus buy dilemma in a nutshell. And with internal tools, the calculus is different than with consumer products. If you're building a SaaS product, the features you don't need are bloat. If you're building an internal tool for a single event, the features you don't need are irrelevant. You can ignore them. The cost of ignoring unused features is zero. The cost of building those features from scratch is substantial.
Though the prompt makes a fair counterpoint. The client needed deep media list management, mail merge, and RSVP-to-credential workflows. Most newsletter platforms give you media list management as a secondary feature bolted onto an email marketing engine. The core competency isn't the media list, it's the email campaigns. So you're paying for — in complexity and cognitive load, if not in dollars — a system optimized for something other than what you need.
That's where the headless CMS approach becomes compelling. Something like Directus or Strapi gives you exactly the data management layer without any assumptions about what you're building on top. Directus is particularly interesting because it wraps around an existing database rather than requiring you to build your schema inside its own abstraction. You point Directus at a Postgres database, it reads your schema, and it instantly generates a REST and GraphQL API, an admin panel, and a full permissions system. You don't have to define your tables in a Directus-specific format. They're just Postgres tables.
That's a fundamentally different philosophy from Payload or Strapi, which want to own the schema definition. Directus says: your database is the source of truth, we'll just provide a nice interface on top. That's appealing if you're migrating from something like Airtable, where you've already defined your data model and just want an API and admin UI around it.
Directus is also open source under the GPL, with a cloud offering. It's been around since about twenty twenty, and the admin UI is built with Vue, but the API is framework-agnostic. You can connect any front end to it. And because it wraps your own database, you can always bypass Directus entirely and query the database directly if you need to. You're not locked in.
That's the escape hatch that makes it viable for production systems. If Directus goes away, you still have your database with all your data in a standard format. No migration needed.
For the event scenario, you could do something like: define your schema in Postgres, point Directus at it, get an instant admin panel for managing journalists and RSVPs, use Directus's built-in roles and permissions to control access, and then build a lightweight custom front end for the public-facing parts — the invitation page, the check-in interface, the credential display. The custom front end talks to Directus's API. The admin team uses the Directus panel. Everyone's happy.
That's an architecture I can see working for a lot of the use cases the prompt is hinting at. The personal CRM for a solo consultant, the event management system, the internal tool for tracking literally anything. Define your data model, get an API and admin panel for free, build only the custom parts.
The custom parts are where you spend your time on the things that actually differentiate the system. The mail merge logic that sends personalized invitations to journalists. The check-in flow that validates credentials and updates attendance in real time. The dashboard that shows RSVP rates and media coverage. None of that is generic CRUD. It's specific business logic that no off-the-shelf platform would handle exactly right.
This is the core insight, I think. The prompt asked about frameworks that provide the basis for building these tools, and the answer isn't one framework. It's a spectrum. On one end, you've got platforms like Appsmith and Budibase where you don't write code at all — you drag components onto a canvas and connect them to data sources. On the other end, you've got library compositions where you hand-pick every piece. In the middle, you've got Redwood and Payload and Directus, which give you different amounts of scaffolding and different escape hatches.
Let me fill in the no-code end of that spectrum, because it's more relevant than it might seem. Appsmith is an open-source platform — Apache licensed — for building internal tools. You connect it to a database or an API, and you drag and drop tables, forms, charts, and buttons onto a canvas. It generates a fully functional web application. You can write JavaScript anywhere you need custom logic. The whole thing can be self-hosted or used via their cloud offering. For something like the event system, you could build the entire admin interface — the journalist list, the RSVP tracker, the credential manager — without writing a single line of front-end code.
The downside is what? Because there's always a downside.
The downside is that you're now dependent on Appsmith's platform. If you need something their components don't support, you're either writing custom JavaScript inside their constrained environment or you're out of luck. The other downside is that the generated applications tend to look like Appsmith applications. They have a certain aesthetic that's hard to escape. For an internal tool, that's usually fine. For something customer-facing, it's less fine.
For the prompt's scenario — a system that included a media-facing component, presumably with some level of branding and custom design — Appsmith would handle the internal admin parts beautifully but you'd still need a custom front end for the public-facing pieces.
That's a perfectly valid split. Admin on Appsmith, public pages on something custom. The two talk to the same database. It's not elegant, but it's pragmatic.
Pragmatic is underrated. The prompt's event system was a Frankenstein, and it worked. Sometimes the measure of success isn't architectural purity, it's whether the journalists got their invitations and the credentials scanned correctly at the door.
There's a concept in software that I think about a lot — the value of a system is not proportional to the elegance of its architecture. It's proportional to how well it solves the actual problem. The event system solved the problem. It was a nightmare to build and the developer never wanted to touch it again, but it worked. And I think the question behind the prompt is: can we get the same outcome with less suffering? Can we have the bespoke solution without the bespoke pain?
That's the question. And I think the answer is yes, but only if you're willing to accept some constraints. The frameworks and platforms we've talked about each constrain you in different ways. Redwood constrains your architectural choices in exchange for generated code. Payload constrains your data modeling in exchange for an admin UI. Appsmith constrains your visual design in exchange for zero front-end code. The suffering comes from fighting the constraints instead of working within them.
The suffering also comes from not knowing which constraints you're signing up for until you're deep into the project. Every framework looks great in the tutorial. The pain points only emerge when you're building something real, with real edge cases, on a real deadline. And the prompt described exactly that — significant time pressure, a litany of requirements that spanned traditional tech silos, and a client who didn't want the standard solutions.
That last part is worth dwelling on. The client didn't want Eventbrite because it was "too complicated." That's a red flag every developer recognizes. When a client says a mature, battle-tested platform is too complicated, what they often mean is that they don't want to learn someone else's mental model. They want the system to conform to their mental model. That's a reasonable desire for the user, but it's an enormous burden for the builder.
It's the "I just want it to work the way I think" problem. And the dirty secret of software development is that making something work the way a specific person thinks is vastly harder than making something work the way a thousand people think, because the thousand-person solution has been refined through feedback and iteration. The one-person solution has to be invented from scratch.
This is why the framework question matters so much. If you're going to build something that conforms to a specific client's mental model, you need to spend as little time as possible on the parts that don't differentiate. The database CRUD, the authentication, the API layer, the file handling — all of that should come from a framework or a platform. Your creative energy should go into the bespoke workflows, the custom business logic, the specific user experience that makes the client feel like the system was built for them.
That's the pitch for Redwood, or Payload, or Directus plus tRPC. They handle the undifferentiated heavy lifting. You handle the part that actually matters to the user. The mail merge that pulls journalist names and outlet names into a template. The credential generator that creates a PDF pass with the journalist's photo and a QR code. The check-in dashboard that updates in real time as people arrive. None of those are CRUD. They're workflows. And workflows are where frameworks should get out of your way.
If someone came to you and said, I need to build something like this — a bespoke internal tool with a specific workflow, deploying on Vercel, serverless back end, I don't want to define every table from scratch — what would you tell them?
I'd ask them one question first: how much of this system is internal-facing versus public-facing? If it's mostly internal — admin panels, dashboards, data management — I'd point them at Directus or Payload. You get an admin UI for free that handles ninety percent of what you need, and you build the remaining ten percent as custom extensions. If it's mostly public-facing — customer portals, event pages, invitation systems — I'd point them at Redwood or the tRPC-plus-Prisma stack. You get generated CRUD operations and type safety, and you build the UI exactly the way you want it. If it's fifty-fifty, I'd probably go with Payload, because the admin UI is good enough for internal use and the API is flexible enough to power a custom front end.
The Vercel constraint?
All of these deploy on Vercel. Payload three point oh is built on Next.js, so it's native. Redwood has a Vercel adapter. Directus is the outlier — you'd run it on a separate server or use Directus Cloud, and your Vercel-deployed front end would talk to it via the API. But that's a perfectly reasonable architecture. The admin panel runs on Directus infrastructure, the public site runs on Vercel. They share a database.
That's a good answer. It's not one framework to rule them all, it's picking the right constraint trade-off for the specific project. And I think that's the real insight here. The prompt asked for starting points across different tech ecosystems, and the starting points exist. They're good. They're better than they were even two or three years ago. But they're not interchangeable. Redwood is not Payload is not Directus is not tRPC. They make different bets about what you'll need to customize and what you'll want to accept as given.
The bets you're willing to accept depend entirely on the project. For a single event with a six-week timeline, you want maximum scaffolding and minimum decisions. For a personal CRM you'll use for years and continuously modify, you want maximum flexibility and ownership. The frameworks serve different points on that spectrum.
I think that's the note to end on. The tools exist. They're mature, they're open source, they're deployable on modern infrastructure. The hard part isn't finding a starting point — it's being honest about which trade-offs you're actually willing to accept.
Now: Hilbert's daily fun fact.
Hilbert: During the high medieval period, the Seychelles archipelago was entirely uninhabited, with a documented human population of exactly zero until Arab traders began making landfall in the ninth century — though permanent settlement wouldn't begin for another eight hundred years.
The population was zero, which is technically a count statistic. I respect the commitment to the bit.
Zero humans, presumably a lot of giant tortoises.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you enjoyed this episode, leave us a review wherever you listen — it helps. We'll be back with another prompt soon.
