In every app
Two things every app does, that a feature list will never tell you.
Every tender asks what the software can do. Nobody asks the question that decides whether people use it: what is it actually like to live with. These are our two answers — what happens when you open an app, and what happens when it lets you down.
25
apps carrying the feedback control
22
app dashboards with the updates strip
6
chart types in one shared, dependency-free kit
0
charting libraries added to the bundle
Every app
It opens on what needs you today.
Fifteen of our app home pages used to be pure tile grids and four more carried a strip of counts. Nobody opens a dashboard to be told the app has a Transfers screen. They open it to find out whether anything needs them today — and a count answers “how many” while only a shape answers “is that a lot”, “is it getting worse”, and “where is it concentrated”.
So every app got a real landing page, built on one shared chart kit rather than nineteen different ones. Bars, lines, donuts, funnels and sparklines inside a card that handles its own loading, empty and error states — and a toggle on every chart that turns it back into the table it was drawn from, because a chart you cannot check is a chart you have to trust.
Charts you can turn back into a table
Every card toggles between the shape and the rows behind it. A figure nobody can check is a figure nobody should act on, and hiding the table is how dashboards become decoration.
It shows only what your role may already see
Each chart is fed by an endpoint the app already calls under your own permissions. A dashboard that reached further would be a row of permission errors for everyone but an administrator.
No charting library, and no loading spinner
Plain SVG in the shared component shelf, rendered on the server with the rest of the page. Nothing to download before a chart appears, and no third-party bundle riding along in every app you open.
The same visual language everywhere
One kit across the family, so a bar chart in Payroll reads the way a bar chart in Stock does. Learning one app teaches you the shape of the rest.
Where this is not finished: Four apps count in the database; the rest still fold a bounded page of rows, and every card that does says so in its own footnote rather than hiding it.Some app homes deliberately have no dashboard — Mail’s landing page is the inbox, and the storefront is a shop rather than an admin surface. A chart there would displace the thing you came for.
Why this is a competitive point and not a design preference
Most business software opens on a menu, because a menu is what the org chart produced.
A tile grid is what you get when each screen is somebody’s deliverable and the landing page is the place they are all listed. It is nobody’s decision and it is the default across this whole category — open an ERP module you have never used and count how long it takes to learn whether anything is wrong today.
Changing it is not hard. It is just work that nobody schedules, because no buyer has ever put “the home page should mean something” in a requirements document. We did it across the family in one pass, on one shared kit, so it is the same everywhere rather than good in the app that had a keen developer.
In every app
Tell us it is wrong, from the screen where it is wrong.
The gap between “we welcome your feedback” and a customer who believes it is entirely mechanism. So there is one: a button beside the notification bell in every app, a dialog that takes the report with the diagnostic context attached automatically, a board where you can see what everyone else asked for, and — the part that closes the loop — an update on the dashboard you open every morning when something happens to what *you* reported.
The board is deliberately cross-customer. You can see what other Rutba customers have asked for and add your weight to it. What you cannot see is which company asked: the request carries a display name and never an organization or an email, because the value of a shared board should not cost anybody their commercial privacy.
Reporting a bug shows you the matches first
The dialog opens on the board rather than on a blank form, filtered to what you have typed. Finding that somebody already reported it, with eleven votes and a status of In progress, is the best possible outcome of a bug report for everyone involved.
The diagnostics come with it, and stay private
The page you were on, the app and engine version, your viewport, recent client errors and an optional screenshot travel with the report so nobody has to ask you to reproduce it. None of it appears on the public board.
Public unless you say otherwise
Every kind is public by default, including bugs, and one tick keeps a request private to you and to Rutba. The disclosure sits above the Send button rather than in a tooltip.
The loop closes where you will see it
Status changes on your own requests arrive in the updates strip on your app dashboard, next to what shipped and what maintenance is planned. A reply nobody reads is not a reply.
The boundaries of it: The board is a channel to Rutba about Rutba. A tenant broadcasting to its own staff is a different feature and is deliberately not assumed.The consumer engine holds an outbox and a cache; the control plane owns the record. If your instance cannot reach us, the report queues rather than failing — but it is queued, not delivered.
What this is really for
A customer inside the development cycle, rather than adjacent to it.
Every vendor has a feedback address. Very few have a mechanism, and the difference shows up in whether anybody uses it twice.
You report from where it broke
Not from a support portal you have to find, log into and describe the problem from memory in. The button is in the toolbar of the screen where the thing went wrong, and the context travels with it.
You can see the queue you are in
The board is shared across customers, so you can tell whether your request is one voice or twenty. That is information a private ticket system structurally cannot give you.
You find out what happened
On the dashboard you already open. Which is the whole point: a loop that does not return to a screen somebody reads is not a loop.
What happens after the request is a commercial question rather than a technical one, and it has its own page: what we build, what we charge for, and what we refuse.
See it rather than read about it.
The demonstration systems are live instances seeded as real trades. Open one and the dashboard is the first thing you get.