Daniel sent us this one — he's been thinking about internal tools, how most of them are basically CRUD with different window dressing, and he's asking whether there are templates or libraries that give you pre-built data schemas for common business apps. Like, if he wants to build a small business CRM, is there something that already defines tables for customers, people, companies, and their relationships so he doesn't have to design the schema from scratch?
Oh, this is a great question. And it gets at something that I think a lot of developers quietly struggle with — you know the CRUD operations are straightforward, but the data model is where you can really paint yourself into a corner.
The buttons and forms are almost never the hard part. It's deciding whether a "contact" belongs to a "company" or a "company" is just a special kind of "contact" or whether you need a junction table because one contact might work at multiple companies and also be a supplier and also be someone's emergency contact.
And the short answer to Daniel's question is yes, these templates exist, but the landscape is messier than you'd hope. There are essentially four approaches out there. One, dedicated schema libraries that are just the data layer. Two, full-stack frameworks that come with opinionated schemas baked in. Three, open-source CRUD platforms where you can actually look at their schema definitions and either use them directly or study them. And four, low-code platforms that abstract the schema away entirely but do have one under the hood.
Before we go further — quick note, today's episode script is being generated by DeepSeek V four Pro. So if anything sounds especially clever, that's probably why.
If anything sounds like a donkey reading a database paper, that part's still me.
So walk me through these four approaches. What actually exists right now that someone could go grab?
Let's start with the dedicated schema libraries because that's closest to what Daniel's asking. There's a project called BottleCRM — it's an open-source CRM built with Prisma, and you can literally go look at their schema file on GitHub. They define models like Account, Contact, Lead, Opportunity, and they've thought through the relationships. An Account can have many Contacts, a Contact belongs to an Account, but they also have an Owner field on each model pointing to a User, so you get multi-tenancy baked in. The whole schema file is about two hundred fifty lines of Prisma definitions.
Two hundred fifty lines is surprisingly compact for a CRM.
It is, and that's the thing — a well-designed schema for a small business CRM doesn't need to be enormous. The BottleCRM schema defines maybe twelve models total. You've got User, Account, Contact, Lead, Opportunity, Activity, Note, and a few supporting tables for things like tags and custom fields. The relationships are straightforward: Accounts have Contacts, Contacts can be associated with Opportunities, every record has a createdBy and an assignedTo user.
If Daniel wanted to build a CRM from that, he could essentially fork that schema file and build his own frontend on top of it.
That's exactly the use case. And BottleCRM is MIT licensed, so there's no restriction on doing that. But here's the catch — and this is where I think the real discussion lives — a schema template only saves you from the blank page problem. It doesn't save you from the "our business actually works differently" problem.
The moment you start customizing, you're back in schema design land, except now you're modifying someone else's assumptions instead of building from your own.
Modifying someone else's schema can be harder than starting fresh, because you have to understand why they made every choice before you can safely change it. Why is the relationship between Contact and Account one-to-many instead of many-to-many? In BottleCRM's case, it's because they're modeling a fairly traditional sales CRM where a contact works at one company. But in the real world, you might have a consultant who works with five different client companies, and suddenly that one-to-many relationship breaks.
The template gives you a starting point, but you still need to think through your own domain.
And I think that's actually the healthy way to use these. Don't use them as a shortcut to avoid thinking. Use them as a reference implementation — here's how someone else modeled customers, companies, and deals, now let me figure out where my business diverges.
What about the second category, the full-stack frameworks with schemas built in?
The big player here is things like Django with its admin interface, or Ruby on Rails with gems like Administrate. But those are more about generating CRUD interfaces quickly — they don't give you a pre-built CRM schema. The schema itself is still yours to define. Where you do get pre-built schemas is in e-commerce platforms. If you install Solidus or Spree on Rails, you get a full product catalog schema — products, variants, orders, shipments, tax categories, all the tables and relationships pre-defined.
Those are domain-specific. They're not general-purpose internal tool templates.
For general internal tools, the ecosystem is thinner than you'd expect. There's a project called Forest Admin that gives you a full admin panel on top of your database, but you still bring your own schema. There's React Admin, same deal — great for building the interface, but the data model is yours. The pre-built schema libraries are surprisingly rare.
Why do you think that is? It seems like an obvious thing to share — here's a canonical way to model customers, invoices, projects, whatever.
I think it's partly because schemas are deceptively personal. Two businesses that look identical from the outside — two consulting firms, two retail shops — will have meaningfully different data models once you dig in. One consulting firm bills by the hour, the other bills by the project. One tracks subcontractors as contacts, the other tracks them as vendors. The schema diverges fast.
The templates that do exist tend to be very opinionated, and if your business doesn't match the opinion, you're fighting the template.
And that brings us to the third category, which I think is actually the most practical for someone in Daniel's position — open-source CRUD platforms where you can study the schema. There's a project called Directus that wraps your database and gives you a full admin interface, but it doesn't prescribe your schema. However, they do publish their own internal schema for managing the Directus platform itself, and you can learn a lot from how they model users, roles, permissions, and content types.
You're not copying their schema, you're reading it like a textbook.
And there are projects like Odoo — massive open-source ERP — where you can look at how they model accounting, inventory, HR, all of it. But Odoo's schema is enormous, thousands of tables. You wouldn't fork it for a small business CRM. You'd study the relevant subset.
What about the fourth category, the low-code platforms?
Airtable, Notion databases, Baserow, NocoDB — these all have schemas under the hood, but they're not exposed as SQL or Prisma definitions. Airtable in particular has a very opinionated data model: everything is a base, bases have tables, tables have records, records have fields. The relationships between records are handled through linked record fields. It's a schema, just not one you'd express in a migration file.
The trade-off is you get a working UI instantly, but you lose control over the data layer.
And for a lot of small businesses, that trade-off is absolutely worth it. If you're a five-person company, you probably don't need a custom PostgreSQL schema. You need something that works today and can be changed by non-developers. But that's not what Daniel's asking — he's asking about building custom internal tools, which implies he wants the control and extensibility of a real database.
If we're advising Daniel directly — he wants to build a small business CRM, he wants a pre-built schema so he doesn't start from scratch — what's the actual recommendation?
I'd say start by looking at BottleCRM's Prisma schema. It's small enough to understand in an afternoon, it's well-commented, and it covers the core CRM entities — accounts, contacts, leads, opportunities, activities. Even if you don't use it directly, it'll show you one coherent way to model these relationships. Then, before you write any code, list out the specific things your CRM needs to do that BottleCRM doesn't handle. Does it need to track email conversations? Does it need to handle quotes and invoices? Does it need multi-currency support?
This is basically your approach from a few months ago — start with three to five tables and only add when a specific question can't be answered.
That approach scales down to schema templates too. Don't start with all twelve BottleCRM models. Start with Account, Contact, and User. Get those relationships right. Then add Lead when you actually need to track prospects separately from contacts. Then add Opportunity when you need to track deals. The template gives you a destination, but you don't have to build the whole thing on day one.
There's another angle here I want to explore. Daniel mentioned "customers, people, companies, and their relationships." That four-word phrase actually hides a genuinely hard modeling problem.
Oh, the party model.
Is a customer a person or a company? What about a supplier who's also a customer? What about a person who works at a company that's a customer, but that person leaves and now works at a different company that's also a customer?
The party model is one of those patterns that every experienced developer eventually discovers, usually after building three or four systems that handle this wrong. The idea is you have a single "Party" table that represents any entity that can enter into a business relationship — person, company, government agency, whatever. Then you have a "PartyRelationship" table that links parties together. A person works for a company — that's a relationship. A company is a customer — that's a role, which you model as a relationship to your own organization.
Most schema templates don't use the party model because it's more abstract and harder to explain to new developers on a project.
BottleCRM doesn't use it. Most CRUD examples don't use it. They use separate Customer and Contact and Company tables because that maps more directly to how non-technical users think about the world. And for a small business CRM, that's probably the right call. The party model is powerful but it adds indirection that makes simple queries more complex.
There's a tension between modeling the world accurately and modeling it in a way that keeps your queries simple and your team productive.
That tension is exactly why schema templates are both useful and dangerous. They're useful because they embody someone else's resolution of that tension — they've already decided where to simplify and where to add complexity. They're dangerous because you might not agree with those decisions, and you won't know until you've built enough on top of the schema to feel the pain.
Are there any schema templates that use the party model? Someone must have published one.
There are, but they tend to be in the enterprise space. Oracle's old Siebel CRM used a party model. Salesforce has something similar under the hood — they call it the "person account" model. But for open-source templates you can just grab, I haven't seen a clean, well-documented party model schema in the Prisma or Django or Rails ecosystems. If someone listening wants to publish one, I think there's demand for it.
That's actually a gap in the ecosystem worth noting. Someone should build a set of well-documented schema templates for common business domains — CRM, project management, inventory, invoicing — published as standalone schema files with explanations of the design decisions.
There have been attempts. There was a project called SchemaBank that tried to do this as a commercial product — basically a library of pre-built database schemas for different industries. I don't think it gained much traction. There's also DatabaseAnswers dot org, which has been around forever and has dozens of data model diagrams for everything from "customers and orders" to "hospital management." But those are diagrams and explanations, not executable schema files you can run.
The landscape in mid two thousand twenty-six is: you can find reference schemas if you search, but they're scattered across GitHub, old tutorial sites, and documentation for larger frameworks. There's no canonical source.
That's actually a problem worth solving. The JavaScript ecosystem has something like this for project structure — create-react-app, Next dot js templates, all these tools that scaffold a working project. But they scaffold the code, not the data model. The data model is still a blank file.
Which is wild when you think about it. The data model is the part that's hardest to change later. The frontend framework you can swap out. The API layer you can rewrite. But once you've got production data in a schema, migrating it is expensive and risky. So you'd think we'd invest more in getting the schema right up front, including borrowing from proven designs.
I think there's a cultural reason for this. Developers like building things from scratch. It's more satisfying to design your own schema than to copy someone else's. And there's a bias toward believing your business is unique — that no off-the-shelf schema could possibly capture your special requirements.
Which is usually wrong for the first eighty percent of the schema. Your CRM probably looks a lot like every other small business CRM. The differences are in the last twenty percent.
And that's the argument for using a template. Get the boring eighty percent from someone who's already debugged it, then customize the interesting twenty percent.
Let's talk about what a good schema template actually needs to include beyond just the table definitions. Because a Prisma schema file is a start, but it's not enough on its own.
A good schema template should include, at minimum: the schema file itself, a data dictionary explaining what each table and column means, a relationship diagram — even if it's just ASCII art in the readme — and a set of example queries for the most common operations. Show me how to get all contacts at a company, how to find deals closing this month, how to list activities for a given account. Those example queries are worth as much as the schema itself.
Because they validate that the schema actually supports the operations you need.
And they teach you the intended query patterns. Someone who's designed a good schema has also thought about how you'll query it. They've added the right indexes. They've denormalized where it makes sense. The example queries expose all of that thinking.
Have you seen any templates that include that level of documentation?
BottleCRM's is decent — they have comments in the schema file and their documentation explains the entity relationships. But no, I haven't seen a schema template that includes a full query cookbook. That's another gap.
If Daniel — or anyone listening — wanted to create and share a schema template, what would be the checklist? You've got the schema file, the data dictionary, the relationship diagram, the query cookbook.
A migration strategy. If I adopt your schema template today and then you release version two in six months, how do I upgrade? Do you provide migration scripts? Do you have a changelog? This is the part that kills schema templates as living projects — they're published once and then abandoned, and anyone who adopted them is stuck on version one forever.
That's a maintenance commitment that most open-source authors aren't willing to make for a schema file.
Honestly, maybe they shouldn't. The value of a schema template might be highest at the moment you start a project. Six months in, your schema has diverged enough that upstream changes probably don't apply cleanly anyway. So maybe the template is best treated as scaffolding — use it to start, then own it.
Which brings us back to your point about starting with three to five tables. Even if you use a template, don't adopt the whole thing. Adopt the core and grow from there.
And I want to be concrete about this for Daniel. If I were building a small business CRM today, here's exactly what I'd do. Step one: grab the BottleCRM Prisma schema and read the whole thing. Step two: create a new project and copy only the User, Account, and Contact models. Step three: build the simplest possible interface — just a list of accounts and a form to add one. Step four: use it for a week and see what hurts. Maybe you realize you need to track which contacts are decision-makers. Maybe you need to log calls. Whatever hurts first, that's the next table you add.
By starting with just three tables, you're not committing to someone else's entire design philosophy. You're borrowing the parts that are clearly right and leaving room for your own decisions on everything else.
And I think that's the honest answer to Daniel's question. Yes, schema templates exist. BottleCRM is a good one. DatabaseAnswers has reference diagrams. Various open-source platforms have schemas you can study. But none of them are plug-and-play in the way that a frontend component library is plug-and-play. You still have to think. You still have to make decisions. The template just gives you a running start.
There's one more thing I want to touch on — the relationship between schema design and the kind of internal tools Daniel's been thinking about. He mentioned that most internal tools are CRUD with different presentation. And that's true at the UI level. But the schema is where the real differentiation lives.
This is a subtle point that's worth drawing out. Two CRUD apps can look identical — same tables, same forms, same buttons — but have radically different schemas underneath. One might have a flat table with twenty columns. Another might have five normalized tables with proper foreign keys. The UI doesn't tell you which is which.
The one with the flat table will be easier to build initially and a nightmare to extend. The one with the normalized tables will take more thought up front but survive the next five feature requests without collapsing under its own weight.
This is why I keep coming back to "start small, but start with good relationships." It doesn't take much longer to set up a proper foreign key than it does to dump everything into a JSON column. But six months later, when you need to report on "all contacts at companies that have open opportunities closing this quarter," the difference is enormous.
The schema template is really a shortcut to good relationships. It's not saving you from writing CREATE TABLE statements — those take thirty seconds. It's saving you from having to discover through painful experience that contacts and accounts should be separate tables, or that you need a junction table between contacts and opportunities.
The template encodes someone's hard-won lessons about what works and what doesn't. And I think that's the right way to evaluate any schema template you find. Don't ask "does this match my business exactly?" Ask "does this encode good patterns that I can learn from and adapt?
Are there any patterns in the BottleCRM schema that you think are particularly worth highlighting? Things that someone new to schema design might not think of?
One is their use of an "assignedTo" field on almost every entity. Accounts, contacts, leads, opportunities — they all have an owner. That's a pattern that seems obvious in retrospect but is easy to miss when you're focused on the entity relationships. Another is their handling of custom fields. They have a separate CustomField model that lets users add arbitrary fields to entities without schema changes. That's smart for a CRM where every business wants to track different things.
The custom fields pattern is interesting because it's a schema design decision about how to handle schema extensibility. You're essentially building a mini schema system inside your schema.
And it's one of those things where a template can show you a pattern you might not have considered. If you're building a CRM from scratch, you might not think about custom fields until a user asks for them, and by then you've got a rigid schema that's hard to extend. Seeing it in a template prompts you to think about it early.
Even if you decide not to implement custom fields, making that decision consciously is better than not having thought about it at all.
And that's the broader value of studying these templates. They surface design questions you didn't know you needed to ask.
To summarize for Daniel — yes, schema templates exist. BottleCRM is the best concrete example we've found for a CRM. DatabaseAnswers has reference diagrams for many domains. Open-source platforms like Odoo have production schemas you can study. But there's no npm install give-me-a-crm-schema. You have to do the work of understanding, adapting, and starting small.
If you do end up building something from a template, publish your version. The ecosystem needs more examples. Even if your schema is specific to your business, someone else will learn from it.
And now: Hilbert's daily fun fact.
The collective noun for a group of sloths is a "snuggle.
What should a listener actually do if they're in Daniel's position — they want to build an internal tool and they don't want to design the schema from scratch?
First, search GitHub for "schema" plus your domain — "CRM schema," "inventory schema," whatever — and filter by your preferred database or ORM. Look for projects that are actively maintained and have documentation, not just a dumped schema file. Second, read the schema before you use it. Understand the relationships. If you can't explain why a table exists, don't include it. Third, start with the absolute minimum — three to five tables — and build from there. The template is a reference, not a requirement.
If you're building something novel where no template exists?
Then study schemas for adjacent domains anyway. If you're building a tool for managing podcast guests, look at CRM schemas — guests are contacts, shows are accounts, episodes are projects. The patterns transfer even when the domain is different.
The other practical step: draw your schema before you code it. Pen and paper, whiteboard, whatever. If you can't fit the core entities and their relationships on one page, your schema is probably too complex for version one.
That's a great rule of thumb. And it forces you to think about what's actually essential.
One last thing — Daniel, if you're listening, we'd love to hear what you end up building. And if you publish your schema, send us the link. We'll add it to the show notes.
Thanks to our producer Hilbert Flumingtop. This has been My Weird Prompts. Find more episodes at myweirdprompts dot com.
Or wherever you get your podcasts. We'll be back with another prompt soon.
