Frontend is essential!

Ideas & Features
1

Hear me out…

This post is a suggestion that I believe is critical for Fibery’s future, and it requires careful reflection. I’m asking you to read this not as just another feature request to be upvoted, but as a proposal about the very soul and strategic direction of the product. Please take the time to consider the entire argument before forming an opinion.

First, let’s rethink our language. We use words like “Entities,” “Databases,” and “Documents.” These are developer-centric or legacy terms. The real paradigm we should be discussing is Backend and Frontend.

  • Backend is the structure: the data, the relationships, the logic, the rules, and the automations.
  • Frontend is the presentation: the user interface, the forms, the dashboards, the client portals, and the way we interact with the backend data.

Thinking this way is more honest and clarifies the problem we’re trying to solve.

Fibery is already a world-class Backend. The ability to create a custom domain with flexible relationships is its superpower. This aligns perfectly with Fibery’s stated vision, which is “to help companies to generate unexpected insights from information… To augment the intelligence of teams and organizations.” The grand idea is to build a platform “that replaces many tools inside a company and grows with the company from startup till the end.”

But to truly achieve this vision, we must recognize that replacing tools and augmenting intelligence doesn’t just happen in the backend. It happens where the user touches the system: the Frontend. To replace many tools, Fibery must also replace their interfaces. A company can’t get rid of its specialized survey tool, client portal software, or internal dashboarding tool if Fibery only provides a powerful engine but no way to build the car.

Let’s look at the spectrum of tools through this more detailed, 7-point lens:

  1. Raw Backend / Headless: Purely for developers. These are powerful engines like PostgreSQL or Firebase that have no native user interface.
  2. Low-Code Backend: This is where Fibery currently sits. These tools have an incredibly powerful and flexible backend for data modeling and logic, but their frontend is primarily functional, designed for internal teams who understand the structure.
  3. Integrated Databases: This is Airtable. It started with a robust, spreadsheet-like backend and has since invested heavily in a user-friendly frontend (“Interface Designer”) to create apps on top of its data.
  4. The True All-in-One (The Goal): This is the ideal, balanced state. A platform with a flexible, powerful backend seamlessly fused with a first-class, no-compromise visual application builder for creating both internal and external frontends. This category is the strategic destination.
  5. Document-Centric Workspaces: This is Notion and Coda. They lead with a user-friendly, frontend-first “document” or “canvas” metaphor, with database capabilities embedded within. Their weakness is often a less-rigid or scalable backend.
  6. No-Code App Builders: These are pure frontend builders like Softr or Toodle that are designed to create beautiful interfaces but must connect to an external backend (like Airtable or Google Sheets) to function.
  7. Pure Frontend / Web Builders: This is Webflow. Its primary focus is on building visually stunning public-facing websites, with its backend serving mainly as a Content Management System (CMS).

The suggestion is for Fibery to make a strategic push from its current position at #2 on this spectrum towards becoming a #4. It must evolve into a truly balanced platform with a Frontend as powerful as its Backend.

This isn’t a new idea. It’s the unspoken need behind many of the community’s most persistent requests. When users ask for a better mobile version, form fixes, tabs, interactive buttons, improved document editing, and white-labeling for client portals, they are all asking for the same thing in different ways: a better frontend. They are asking for more power to control the presentation and interaction layer.

The only company that is working on this properly at the moment is Airtable, with its clear move from #3 towards the #4 spot. Their investment in the “Interface Designer,” even after partnering with third parties, shows a recognition that a native, integrated solution is the superior long-term strategy.

But what does a true Fibery Frontend look like?

Think of the Fibery.io website itself. The game-changer would be if that entire, beautiful website could be built within Fibery. To do this, we don’t need to reinvent the wheel. We need a flexible, visual builder with core components:

  • Sections and Containers to structure layouts.
  • Flexible Columns and Rows for responsive design.
  • Interactive Cards to display data from the Fibery backend.
  • Customizable Buttons that trigger Fibery automations and actions.

With these building blocks, the possibilities become exponential. A company could build its entire public website on Fibery. More importantly, they could build true, interactive web apps where a user’s action on the page (like clicking a “buy” button) instantly interacts with the backend (updating inventory, creating an invoice, notifying a team) and presents the result back to the user on the frontend.

This would unlock the most common, high-value applications that businesses need, all in one place:

  • Blogs
  • Client Portals
  • Marketplaces
  • Learning Management Systems (LMS)
  • Advanced, multi-step forms
  • And countless other custom web apps.

So, this is my suggestion. I ask the team and the community to take time to reflect on this. Let’s consider making a focused, deliberate, and strategic commitment to building a first-class Frontend inside Fibery. This is the path to fulfilling the grand vision of becoming the single, adaptable platform that can truly grow with a company.

2

It seems that you think Airtable is the gold standard to which Fibery should aspire, and yet the specific example you mention (building a public website) is not something you would do with Airtable alone - you even mention softr, whose value proposition seems to be that you can build a website using Airtable as the backend.

I’m not sure I agree with you that these are the applications that all businesses need. They certainly represent examples of public-facing web apps, but I think Fibery is not currently targeting those needs, instead going after companies who need a tool for internal knowledge and process management.

It’s not to say that Fibery’s UI hasn’t got areas for improvement, but I’m not sure Fibery will target the myriad possible ‘apps’ that companies might want.

Of course, it will be interesting to hear what other Fibery users have to say.

2 Likes
3

Fibery is not a low-code backend tool, it is work and process management tool. No tool can be #4 in your terminology, it is just too broad space to win it. You have to maintain some focus. Retool and Airtable also not focusing on ALL use cases, they are for internal business processes more.

In your categorization you miss tools like ClickUp or Monday, and we compete with them more.

Our focus is work and processes management and we are not going to change that. Building a website on Fibery is a use case we will most likely never support, since all we have a just backend, and frontend part of this process is the most complex one.

Custom UI solutions inside Fibery for better use cases are possible in some near future, we are exploring these options, but it I am not sure we will ever evolve into things like Loveable or Bolt.

5 Likes
4

To be fair, you knock Monday out of the park. For an app that talks about simplicity and ease of use, it lacks in all the most important areas

5

Correct and thats what i love about fibery they are very deep into the topic and they are looking for the compititors all sides.

May main concern is either fibery become a full backend low code which like @mdubakov is saying or something beyond that if it goes beyond that then it need a strategic thinking how fibery will move forward. especially this concern become noticable when we see things like this in the main website :

Your company’s operating system

Fibery is a work platform that replaces scattered tools and connects teams. Chosen by nerds, appreciated by everyone.*

or something like this image from " Fibery End Game (Product Company Example)"

image
image1650×843 187 KB

the concern is fibery going to move beyond backend if not that’s amazing and perfect for them and they might partner with something like glide, or softr or something else which align more with fibery … but if fibery is going to go little bit of this and a little bit of this … that might be the main issue here … my recommendation is seek people like airtable i don’t think they are in perfect position but they are working toward it at the end of day Company’s Operating System should have good usable functional frontend and backend or this wouldn’t be called OS. My concern rises when for example most of the operation in fibery occured outside of fibery like blogpost, website, this community etc… to me i feel collaboration among the tools is the way to go but Fibery marketing themselves as the go to all in one tool … this same thing happened to Coda / Notion which i think your main compititors in the space…

for Airtable they have partnered with softr as it become the main frontend for their product but for some reason they just made their interface feature which completely throwing rocks to the partnership they had, and i think that because is a need for airtable users to have a proper frontend even if their main product is backend product … even if not perfect product yet they still thinking of those moves stratigically

so in conclusion, this need stratigic movement toward ending vision and fibery as a product it self need to have this clear vision / mission that even users or new users like me could make most of the product :slight_smile: btw keep those type of discussions its healthy for the product itself.

6

Hmm, thanks for the write up! I have thoughts :))

I completely agree that the difference between Frontend and Backend is needed, but I would argue that fibery does this the best out of any of the competitors out there. Most tool’s hiarchy is database → views of that database. Where Fibery they sit side by side. I see views as the front end, and databases as the backend (which is why they are hidden and are only admins and space creators). Very nice!

But I do think you have a point. One of the most annoying things in Fibery is that the backend and front end are so connected. Views live in spaces, and also databases live in spaces. I just this separation between view access to database access could go a long way. (I think some stuff is happening there, but still not there yet).

In terms of building websites using fibery, that could be pretty cool indeed! I think the big thing its missing is a better entity view creator. A drag and drop entity view maker would be amazing.

But like Michael said, and from the things I’ve read, being a low-code builder isn’t their end goal, but merely a byproduct. I personally think that a low-code app builder is an amazing means to a high quality work and process management app, but i think this is now more of a discussion on long term vision…

2 Likes
7

Welcome to Fibery! :waving_hand:t4:
I’ve seen a few of your posts in the community.
I’ll be curious to see if, after settling in to Fibery and leveraging a lot of it’s current best uses, whether your opinions here change…

8

Great ideas. Although, I’m not convinced that you want to go that far into the frontend as you are suggesting, otherwise you will end up with something like Go High Level, which is a flaming pile of garbage. But maybe Fibery could build more frontend widgets to be embedded into a website. Adding a better experience for things like calendar scheduling for example would eliminate the need for tools like Calendly.

I do see an opportunity for Fibery to become a Gold standard for building company operation web and mobile apps that are used by it’s employees for workflows, and it clients as ways to interact with the company. Although with the current pricing model client portals are still a challenge.

I also see a massive opportunity for Fibery to head into the Email Marketing space. If they did that they would be able to compete with Hubspot and Active Campaign. This could even be a stand alone product. The crazy thing is I can already mostly do this with their existing functionality, but its still just a little too poor of an experience to justify the build.

9

As for now i feel fibery has something that no body is doing in most platform which is showing multiple databases in one view … that alone is a game changer … another thing fibery creators are communitive and they engage in all platform which makes it more trustworthy … so now im a piad memeber to give it a shot this year… however im disappointed that i saw videos in fibery channel showing space as a view with databases as tabs … i tought that was amazing … idk why as user i want each database to be seen seperately , i would do that myself using the views… i paid just for that feature and i think its no longer there :slightly_smiling_face: .. anyway the fibery blog is beyond amazing it has less bias but not fully unbias but they informative, good worth of time .. lastly i believe in the team it lack of proper mobile version which this post is about too, fibery lack of any proper usable view that the main issue im facing right now… the product it self is amazing as backend … it has the best chart views, notion just made feed view which i think toward teams, their formula are less functional than coda but still better than airtable or notion … but for example there are some weird things like i can have 1 image/ comment / file field in the entity idk why … its better if we can dl unlimited like all other fields so i can have multiple type of files for each project like sources pdf files , and end product like book for example or video file … some of the decsion in fibery are weird … anyway there some ups and down which seens in all platforms :+1:

10

@danielbmarsh @mdubakov

To be honest fibery is going to be forced to have a frontend … at the end if you didnt do frontend, other by product will do it … we have seen this in all other platforms … and im sure mobile version is going to be mostly frontend …

Views, documents are the front end right now but both of them are struggle as a feature … its hard to use them , they have huge limitations like for example calendar view has no text wrapping … i cant see unschedule task and drag and drop it to the calendar view, hard to create entity in it etc etc comparing that to google calendar or outlook you lose by a mile …

At the end fibery promsing to be the whole operating system for enterprise companies …

If i want to suggest a view … ill call it website view :sweat_smile: this will replace document … idk why dpcument are seperared from views anyway … this view has one special component or field , which is container this can contain be a row or column … and from that component you can have either dynamic view of the data or static … so these container field has setting like shape, color , backgrournd , stroke , i can put icon on it , text or data and i can query some of the specific data using {{ }} like saying hello, {{user first name}} … those containers snap into a 12 grid which later when we view it in mobile it adjust …

Its so simple everything is already exist in fibery just a good abstract thinking before doing those views …

11

It may be the case that a third-party app can interface with the database as a presentation layer for end users, like a client portal that can style the forms nicely and add an abstraction to direct CRUD. But I don’t think Fibery was ever meant to be a fully functioning CMS. There are other apps that do this well enough for the majority of use cases, and while it would be a nice to have feature, I think so long as the API is intuitive and the data transmission is timely, you can put any front-end on top without being locked down to a specific app or builder tool.

2 Likes
12

Thats the problem that im addressing … if some other company worked in the frontend better than fibery … this mean fibery is no longer company’s operating system … its only backend which there is other services better than fibery .. sure its more complicated but at the end they are more powerful, fast, reliable …

i believe if fibery made frontend behind paywall , people are willing to pay for that more than purely backend…

think of any operating system … andriod or microsoft .. most people work on frontend windows or app … the backend usually is not the day-to-day interaction … i keep bringing back operating system because this is fibery ultimate goal

13

I’m not sure I follow your train of thought. You just wrote…

and yet in the first post of this topic, you wrote…

I get that you have concerns about the quality of some of the Fibery ‘frontend’ components:

so feedback on how the existing views (= frontend) can be improved is very welcome (and you will no doubt already find plenty of suggestions for improvement here in the community).

Note: I wouldn’t get too hung up on the terminology of “Your company’s operating system” and expect it to mean that Fibery is somehow analogous to Windows or Android.
It is more that a company can expect to be able to manage a large part of its operations within Fibery. This means being able to store and share company knowledge and then execute on the activities that are needed to keep the company operating.

Of course, there are myriad types of company, each with different processes and use cases, and Fibery will not be able to support them all.

It sounds like some of the processes you consider to be important to a company are not well supported by Fibery, e.g.

But it’s fair to say that Fibery is already being used by many types of companies for the processes they need.

1 Like
14

You’re right to be confused by my statements, and thank you for pointing it out. Your confusion actually highlights the exact problem I’m trying to define. Let me clarify.

When I say “Fibery is already a world-class Backend,” I am speaking about its specific superpower: creating a custom domain with flexible relationships for internal work and process management with low code/no code approach.

However, when I say “there is other services better than fibery,” I am referring to the scenario where Fibery is forced to act only as a backend for a separate, custom-built frontend. In that situation, it’s competing with purely headless backends, which is not its strength.

This leads us to the exact problem, which is not just about Fibery, but a crisis facing many platforms in this space.

The Identity Crisis: All-in-One vs. One-Part-of-the-Whole

The problem is a fundamental identity crisis between the platform’s marketing and its product reality.

  1. The Promise (The “All-in-One”): Platforms like Fibery market themselves as the “company’s operating system” or the “all-in-one” tool that “replaces many tools”. This promise attracts users who want a single, unified system to run their business.
  2. The Reality (The “One-Part-of-the-Whole”): The backend becomes incredibly powerful, but the native frontend tools remain limited. Users are then told that building websites or client portals is a use case Fibery will likely never support and they must connect to third-party tools to build the interfaces they need.

This is the crisis: the platform promises to be the whole system but, in practice, acts as just one part of a fragmented system.

Instead of getting stuck on this abstract problem, let’s consider a concrete solution I suggested earlier. To begin resolving this, Fibery can introduce a single, powerful new view.

I called it a “Website View”. The core of this would be a special “container” component that can be set as a row or column. This container could hold dynamic data from the backend or static text and images. We could query data using {{ }} (e.g., Hello, {{user first name}} ) and have these containers snap into a 12-grid system that automatically adjusts for mobile.

Introducing a view like this would be a strategic first step. It would give users the building blocks to start creating the rich interfaces they need, directly connecting the powerful backend to a flexible frontend and beginning to truly fulfill the promise of an all-in-one system.

15

I agree with that. Tools in general are quickly becoming easier for a large public. If Fibery does not decide to make its UI more userfriendly, it will lose out. There is a clear trend that the distiction between backend and front end is disappearing, and any argument that ‘fibery is a backend tool’ is not a very strong argument to keep the UI confusing with major context loss issues (which is still the casee in my view).

16

I don’t see anyone at Fibery making this argument. Fibery is not a backend tool.

17

“since all we have a just backend, and frontend part of this process is the most complex one”

Maybe in this discussion the term ‘back end’ and ‘front end’ is used in various meanings, and the term ‘website’ is sometimes seen equivalent to front end, which of course is not always the case. But I assess this topic as aiming to go beyond being a semantic discussion.

The point in my view is that the tool should be accessible for non-techinical users, and that common expectations about context needs to be covered.

So I don’t think the suggestion here was ‘building a website on fibery’ as mdubakov answers, but that the UI is made more accessible in what one would expect in a website in general, meaning intuitive contextual navigation and usage.

18

It is exactly what mdubakov was answering:

:roll_eyes:

19

I you read back, you will see the following happend in this discussion:

  1. salim111212 suggests Fibery improve its frontend to be modern and user-friendly, like a “Website View” with customizable containers. salim111212 uses “building a website” as an example to show how a better UI supports Fibery’s “all-in-one” goal. salim111212 clarifies the goal is a flexible interface, not turning Fibery into a website builder.
  2. mdubakov assumes the idea is about website-building, emphasizes Fibery’s backend focus, and misses the UI improvement point.
  3. Chr1sG fixates on the website example, says Fibery is for internal tasks, and overlooks the flexible UI idea.
  4. I just support and explained the proposal is for a user-friendly, web-like UI.

So the issue is that mdubakov does not respond to the entire scope and meaning of the first message, but picks out and rejects the term Website, and you defend that too.

While its about the entire front-end UI experience.

1 Like
20

It’s fair that we might not always understand what all the other topic contributors are coming from, and may focus on different elements of what has been written, but I think the fundamental is this

TBH I don’t understand what the ‘website view’ aka ‘special container component’ is all about, so I may be naive in assuming it relates to creating external-facing UIs - a use case for which Fibery does not excel, but also does not target. And yes, Fibery is primarily for ‘internal tasks’.