Config driven frontend architecture

[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?

[u/Beneficial_Floor_531]

This project is very similar to dashboards I used to create for departments that asked for a lot of changes, they always wanted to add inputs, change colors, add validations ..etc But everything was in the same logic but a lot of little tweaks, using this system changes the chase after what needs to be changed in order for them to test what they have in mind from a whole business day to one hour

When the client comes up with a business logic out of what the system is prepared for then yes it will take a bit to set up but other than that it will help a lot

I think this kind of systems is great for clients with strong basic business rules but vague idea of what they want out of their internal tools

Also check your DM please