u/Beneficial_Floor_531

I built a project mainly for my resume, but the goal wasn’t really the CRUD app itself. The goal was to focus on frontend architecture and system design instead of just building another standard React project.

So I made a simple Laravel real estate app with basic CRUD operations, tables with pagination, filters, and drawer forms. Nothing especially complex from a business perspective.

The part I cared about was the frontend architecture behind it.

Instead of hardcoding forms, filters, tables, and page behavior directly into components, I turned them into config-driven systems.

For example, the form system takes a config array with fields like this:

{
    name: 'lease_type',
    label: 'Lease Type',
    type: 'radio',
    required: true,
    options: [
        { label: 'New', value: 'new' },
        { label: 'Renewal', value: 'renewal' },
    ],
    defaultValue: 'new',
}

From that config, the system automatically creates the React Hook Form setup, generates the Zod schema, maps the correct inputs, and handles validation and data flow.

I applied the same idea to filters, tables, and pagination, so most new sections are created by describing behavior through config instead of rebuilding logic every time.

The thing I’m most proud of isn’t really the UI. It’s that I managed to make the systems work together in a predictable way without the data flow turning into complete chaos.

A lot of the actual work ended up being around keeping rendering stable, making TypeScript useful instead of fighting me, protecting the systems from broken configs, and trying to keep the architecture flexible without making it messy.

At the same time, I know the project has limitations.

I didn’t try to turn it into a polished framework or npm package, and I definitely didn’t handle every edge case. Some validations aren't covered, and some parts are more tightly coupled internally than I’d like.

Honestly, even getting it to this point already took much more work than I originally expected because connecting reusable systems together cleanly is harder than building isolated components.

Most of the production systems I worked on in previous jobs are private, so I can’t publicly show the actual architecture work I did there. That’s a big part of why I built this project in the first place.

I mostly wanted to build something that demonstrates how I think about frontend systems, maintainability, and reusable architecture instead of just visual components.

Curious how more experienced frontend engineers look at projects like this.

Do you think config-driven frontend systems are actually valuable in real-world teams, or do they usually become overengineering unless the scale is large enough?

I made a project for my resume that creates almost the entire index page through config files, and I want honest opinions on whether this is actually valuable or not

The idea behind the project was to focus less on the programming itself and more on frontend architecture and system design

So I built a simple Laravel real estate project ( basic CRUD - tables with pagination - filters - drawer forms )

But instead of hardcoding everything, I turned each part into a reusable config-driven system

For example, the form system takes a config array that has config fields like this:

{
    name: 'lease_type',
    label: 'Lease Type',
    type: 'radio',
    required: true,
    options: [
        { label: 'New', value: 'new' },
        { label: 'Renewal', value: 'renewal' },
    ],
    defaultValue: 'new',
}

From that config, the system automatically:
creates the React Hook Form setup - generates the Zod schema - maps the correct inputs - handles validation and data flow

The important part is that the system is not just reusable inside the same project it's reusable across any React project

I did the same thing for filters, tables and pagination

So the final result is that if I want to create a new section, I mostly just describe it through config files instead of rebuilding the logic every time

The main goal was to show that I can think in systems and architecture, not just components, that said, I also know the project has a lot of limitations

Since this was mainly for my resume I didn’t handle every edge case like validations are not perfect or cover all the cases , it’s reusable, but not packaged as an npm library and some parts are still tightly connected internally

I didn't turn it into a framework because honestly it already took a lot of time just to make the systems work together correctly.

most of the work was for : making the data flow predictable - avoiding rendering problems - keeping TypeScript useful instead of fighting me - protecting the systems from broken configs - making the architecture flexible without becoming messy

Most of the production systems I worked on in previous jobs are private, so I can’t share the actual code publicly. That’s part of why I built this project in the first place.

So I wanted honest opinions from people with more experience in frontend architecture:
Is this actually a good project, or am I overestimating it?
Is this enough proof of architectural thinking for recruiters/interviews?
Is it worth continuing and turning into a proper package/library?
Do companies actually hire frontend engineers for this kind of architecture-focused work?

I’m not looking for sugar-coated answers. I genuinely want to know how this looks from the outside.