The Design Philosophy Behind Faceflow: Why We Chose to Build Pages with “Resources”

Before introducing Faceflow, we often clarify one thing first:

Faceflow is not a tool for “drawing pages.”

Instead, it is more like a system that helps you create and manage resources, while pages are simply the result of combining those resources at a specific point in time.

This single idea almost entirely defines the fundamental difference between Faceflow and most visual website builders.

From “Page-First” to “Resource-First”

In traditional website builders or page editors, pages are usually the starting point of everything.

You create a page, add modules, duplicate content, and adjust layouts. Over time, each page becomes an isolated entity—similar in structure, yet disconnected from one another.

Once you need to modify shared content, unify styles, or adjust data structures, maintenance costs rise rapidly.

The original design motivation of Faceflow starts exactly from this problem:

If pages are only the “result,” then what truly deserves careful attention?

Our answer is: resources.

Building Pages Like LEGO Blocks

In Faceflow, you don’t directly “draw pages.” Instead, you first create reusable resources.

These resources include:

• Variable: Reusable data variables and content fragments that can hold text, structure, and even PHP, HTML, CSS, or JavaScript code
• Component: Tailwind CSS–based component modules that encapsulate UI and logic, supporting custom fields and frontend code
• Layout: The structural skeleton of a page, defining overall layout and site-wide content such as headers, footers, or cookie notices
• Form: Visually created forms and validation rules used to collect and manage user data

The page itself is not an isolated editing object, but a combination of these resources under specific routes and data conditions.

In other words, pages are assembled, not stacked.

Can I Use Faceflow Well If I’m Not Technical?

This is a question we’re asked very often.

The answer is yes—and it holds true in two different ways.

If you’re not familiar with frontend or backend technologies, you don’t need to understand every detail from scratch. Through the official marketplace, you can directly obtain pre-built resources: components, layouts, forms, and even complete application structures.

These resources can be imported and used immediately. You simply combine and adjust them according to your needs to build pages and functionality.

If you do have a technical background, Faceflow reveals a completely different side.

You can freely write and extend variables, components, and layouts, treating the visual interface as a structural management tool rather than a limitation. In this scenario, Faceflow is no longer a “simplification tool”—it gradually becomes your home ground.

We don’t require everyone to use Faceflow in the same way. It’s more like an open space that allows users at different stages and with different backgrounds to find their own way in.

Pages Are Just Combinations—Data Is the Core

A Page in Faceflow is not a simple “static page.”

It is directly bound to underlying data objects and remains consistent with the system’s multilingual mechanisms, custom fields, and data structures.

This means:

• Pages can natively support multiple languages
• Content and structure are separated
• The same set of resources can serve different page forms

When business requirements change, you’re not “editing pages,” but adjusting how resources are combined.

Why Go Into Such Detail?

The level of granularity in Faceflow may appear finer than that of most visual tools.

This is a deliberate choice.

Because we don’t assume user requirements are stable, nor do we assume a project will remain at the “content display” stage.

In real-world scenarios, many projects:

• Start as content pages
• Later add forms and interactions
• Eventually evolve into full web applications

If a tool is “page-driven” from the very beginning, the system becomes increasingly difficult to maintain as complexity grows.

Faceflow starts from the resource layer to make this evolution feel natural.

Visualization Does Not Mean Losing Control

In Faceflow, “visual” does not mean “closed.”

Every resource type allows you to directly use HTML, CSS, JavaScript, and even backend logic.

The purpose of visualization is to reduce repetitive work, not to limit expression.

You can start with simple combinations, and when needed, dive deep into the underlying layers for full customization.

What Faceflow Aims to Solve Has Never Been “How to Draw Pages”

We’re not trying to make page creation more flashy.

What Faceflow truly cares about is:

• Whether resources can be reused
• Whether structures can be maintained long-term
• Whether the system can grow alongside evolving requirements