Custom Fields or a Content Construction Kit?

What core fields give you

Fields are defined per component and per category, in groups, and appear in the editing form alongside the article. The types cover the ordinary cases: text, textarea, list, checkboxes, radio, integer, URL, editor, calendar, colour, image, media, user, usergroup, SQL — the last one populating options from a query.

They render automatically in article layouts, positioned above or below the text, or you can place each one yourself in a template override:

use Joomla\CMS\HTML\HTMLHelper;

$fields = $this->item->jcfields ?? [];

foreach ($fields as $field) {
    if ($field->name === 'floor-area') {
        echo '<p class="spec">' . $field->value . ' m²</p>';
    }
}

Values are indexed by Smart Search and can be shown in listings, which covers most of what people wanted from a construction kit: structured input, controlled output, searchable data.

Model the content before choosing a tool

The mistake that costs the most is not picking the wrong extension — it is not deciding what the content is first.

Write down every entity and its attributes: which are required, which repeat, which reference each other, which need to be filtered on. Do that on paper, and the answer usually becomes obvious. Ten flat attributes on one entity is a job for core fields. Three entities referring to one another, each with repeating groups, is not.

Where core fields run out

Honest limits:

• Repeating groups. A property with an arbitrary number of rooms, each with its own attributes, is awkward. Core fields are flat.
• Relationships between items. "This event happens at that venue", where the venue is another content item with its own page, is not something fields express well.
• Its own list views. Fields attach to articles. If the entity needs its own listing with its own filters and its own routes, you are describing a component.
• Complex validation across several fields at once.

Hit two or more of those and a construction kit — or a purpose-built component — stops being over-engineering.

What a kit costs

The same thing every deep dependency costs. Content modelled in a kit lives in that kit's tables and is retrieved through its API, so leaving means a data migration rather than a switch. Your Joomla upgrades wait for its compatibility. And whoever maintains the site after you has to learn it before they can change a label.

None of which is an argument against using one. It is an argument for being sure you need it, because the exit is expensive and the entry is easy.

The middle path

Often the best answer is core fields for the attributes, plus a small custom component only for the entity that genuinely needs its own listing and routes. You keep the editorial experience Joomla already provides and write a few hundred lines instead of adopting a framework.

Start there, and add the kit when you can name the specific thing it does that you could not otherwise do.