Summary

Today, a Directify directory is built around a single listing type—the templates, pages, and custom fields are all optimized for one kind of content (businesses, events, jobs, etc.). But many real-world directory operators aren't running a single-type directory. They're running a platform: one brand that needs to house several fundamentally different content types, each with its own fields, layout, and browsing experience.

Right now, there's no clean way to do this in Directify. I'd like to propose supporting it, and I see a few possible implementation paths (detailed below). Each would unblock this use case—they just have different tradeoffs.

The Use Case

My project is a community platform for the Armenian diaspora in Los Angeles. Under one brand, I need directories for:

1. Events — community events with dates, times, ticketing links, organizers

2. Businesses — restaurants, shops, and services with hours, categories, contact info

3. Organizations — nonprofits, churches, cultural centers

4. Places — historical sites and points of interest

Each of these needs its own custom fields, its own listing template, and its own browsing/filtering experience—but they all belong to one brand, one domain, and ideally one shared design system.

This is not a niche need. Consider a private business club: they maintain a member directory (people, with companies, industries, and locations) and a heavy events calendar—two directory types under one organization, presented in one unified dashboard. The same pattern shows up everywhere:

• Chambers of commerce (member businesses + events + job boards)

• Alumni networks (members + events + businesses owned by alumni)

• City/tourism portals (places + events + local businesses)

• Professional associations (members + events + resources)

Any of these operators evaluating Directify today hits the same wall: the product is excellent at one directory type, but their organization needs three or four.

Approach 1: Custom Domain Routing (1 Domain, Multiple Directify Directories)

Allow multiple Directify directories to be routed under a single custom domain via path prefixes:

• example.com/events → Events directory

• example.com/businesses → Businesses directory

• example.com/organizations → Organizations directory

• example.com/places → Places directory

How it works: Each content type lives in its own Directify directory with its own template, custom fields, and settings. The routing layer simply maps URL paths to directories.

Pros:

• Each directory keeps using the template purpose-built for its listing type—no changes needed to the template/page system

• Likely the lower-lift implementation, since directories remain fully independent under the hood

• Operators can adopt it incrementally (start with one directory, add more later)

Cons / open problems:

• Data is siloed. Cross-directory features become impossible or awkward—e.g., linking an event to the business hosting it, a unified site-wide search, or a single "organizer" entity that appears in both the events and organizations directories.

• Brand consistency is manual. Navigation, headers, footers, fonts, and colors have to be replicated and kept in sync across N directories. Without shared theming or shared navigation, the seams show.

• Disjointed UX risk. Visitors moving between /events and /businesses may notice they're effectively on different sites stitched together—separate search, separate accounts/submissions, separate everything.

If this approach is chosen, I'd argue it needs at minimum: shared navigation across routed directories, shared theme/branding inheritance, and ideally a global search that spans them. Otherwise, it solves the URL problem but not the platform problem.

Approach 2: Custom Listing Types (1 Domain, 1 Directory, Multiple Listing Types)

Allow a single Directify directory to contain multiple listing types, each with its own set of custom fields, its own listing page layout, and its own browse/index page:

• One directory: "My Platform"

• Listing types within it: Event, Business, Organization, Place

• Each type gets its own custom field schema, its own listing detail template, and its own filtered index page

Pros:

• Data lives together. Relationships between types become natural—an event can reference a business as its venue, an organization as its organizer. Global search, unified analytics, one submission system, one subscriber base.

• One brand, natively. Single theme, single navigation, single domain—no synchronization overhead.

• This is the architecturally "correct" model for the platform use case, and it's how tools like Airtable-backed directory builders and headless CMS setups (collections/content types) handle it.

Cons/open problems:

• This cuts against Directify's current architecture. Templates and pages are deeply optimized per listing type—a business template doesn't know what an event is. Supporting listing types would require the template system to become type-aware: per-type detail layouts, per-type index pages, per-type filters, and custom field scoping.

• Larger engineering lift, and probably touches most of the product surface (editor, forms, search, SEO, feeds).

Approach 3: Templates as Type-Bound Presentation Layers (1 Domain, 1 Directory, Existing Templates Reused Per Listing Type)

This is a refinement of Approach 2 that reuses what Directify has already built. The key insight: a template is just a presentation of data. Today, a template defines an entire directory. Instead, let a template be bound to a listing type within a directory:

• One directory: "My Platform"—one domain, one brand, one dataset

• Business listings render using the existing business template

• Event listings render using the existing events template

• Organization and job listings render using their respective templates

How it works: The templates that Directify has already optimized for each listing type become reusable presentation components ("widgets") applied at the listing-type level rather than the directory level. When a visitor opens a business listing, they get the business detail layout; when they open an event, they get the event layout—all within the same directory.

What this changes architecturally: Very little on the visual/design side—the templates already exist and are already good. The work concentrates in two places:

1. Global brand control. One theme layer (logo, colors, fonts, navigation, header/footer) that sits above the templates, so every listing type inherits the same brand while keeping its type-specific layout.

2. Scoped discovery. Search and map views become configurable: site-wide across all listing types, or scoped to a specific type (search-only businesses, map-only events, etc.). Index pages would be per-type, with an optional global "everything" view.

Pros:

• Achieves everything Approach 2 achieves— unified data, cross-type relationships, one brand, one submission, and subscriber base

• Reuses the existing template investment instead of requiring a new type-aware template system built from scratch; the per-type optimization Directify already did becomes the feature rather than the obstacle

• Cleaner mental model for operators: "Pick a listing type; it comes with the right template"

Cons/open problems:

• Custom fields, forms, filters, and SEO still need to be scoped per listing type (shared with Approach 2)

• Search and map need type-scoping logic that doesn't exist today

• Some template internals may assume they own the whole directory (routing, index pages, settings) and would need to be made composable