How we help speed up your UI without ever reading your records

Your ops team's speed is your customer's experience. A payment held for manual review, a document that needs a second look, a dispute waiting on a decision: each one runs through a screen somebody is sitting in front of. When that screen takes eight seconds, the queue takes all afternoon.

In a regulated business you carry a second constraint at the same time. Customer records cannot leave your infrastructure. The usual trade-off runs between the two. Keep your vendor out of the data plane and accept that they have less to work with when something is slow, or hand them the visibility and hand them the records along with it.

We have spent a lot of time on the part of that trade-off that turns out to be avoidable. We are also specific about the part that is not.

Your Forest backend runs in your infrastructure, so your records never transit Forest

Three parties are involved when someone on your team opens a screen.

• The browser, where your operator works.

• Forest, which serves the interface, the layouts and the permission rules.

• Your Forest backend, which you host, inside your own network, next to your database.

The browser makes two separate sets of calls: one to Forest for the interface, one to your backend for the records. Your records travel the second route only. They are never in the first.

Worth being precise about what does live on Forest, rather than claiming nothing does. Your schema metadata is there: table names, column names, the relationships between them. So are your user identities and the permission rules your admins configure. That is what lets us render the right screen and enforce who is allowed to open it. The rows behind the screen stay on your side.

We measure every call from the browser, which sits above that boundary

Monitoring runs in your operators' browsers, not on our servers. It times every call the interface makes and records which ones failed, on the hops to Forest and the hops to your backend alike. Because it sits above the point where the two separate, it can compare them.

Three things come out of that.

• Which side. Calls to your backend and calls to Forest are timed independently, so "the backoffice is slow" resolves into one or the other in minutes rather than in a thread.

• Which screen. Timings break down per collection, so a general complaint becomes a named list view and a number. A reported slowdown turns into "the issued cards list answers in 13 seconds at p95", which is a conversation your team and ours can both act on.

• Which direction. Percentiles kept over months show whether a screen has been drifting since a migration or whether one bad week was an incident that already resolved itself.

Two words that do the work there. p75 is the experience of three users out of four. p95 is the experience of the slowest one in twenty, which is the one who writes to you. Averages hide exactly the moments worth looking at, so we do not use them.

One honest limit: sessions are sampled. Trends and percentiles are solid; any single call is a matter of luck. If an operator tells you a specific click failed at 14:32, we often cannot go and find it, and we would rather say so than promise otherwise.

What the measurement locates, and what your team has to open up

Browser timing tells us a list view takes six seconds. It does not tell us what those six seconds were spent on.

The shortlist is usually short: an index missing on a foreign key, a filter scanning a forty-million-row table, a computed field making an external API call once per row. Every one of those happens inside your infrastructure, which is the one place we deliberately cannot see.

So the work splits, and it splits cleanly. We bring the measurement, the comparison between the two sides, and the pattern we have seen on other schemas. Your team brings the query plans, the table statistics and the authority to add an index. Neither half gets a screen from six seconds to under one on its own.

Five schema decisions that settle how fast your screens feel

Across the backoffices we have helped tune, most of the slowdowns trace back to the same handful of choices.

• Real foreign keys, with an index on each. Relationships are read from your schema. A column named user_id with no constraint behind it is an integer as far as anything automated is concerned, and PostgreSQL does not index the referencing side for you.

• Indexed sort and filter columns. The default sort of each collection, plus the fields your ops team filters on every single day. Those are worth asking them about directly; the answer is rarely the one the schema suggests.

• Bounded global search. Unrestricted search across every text column means a full scan of the table on every keystroke. Restrict the searchable fields, or add trigram indexes on the ones that matter.

• Counts and pagination on large tables. COUNT(*) walks the whole table every time a list renders. Past a few million rows that cost belongs behind a setting rather than on every page load.

• No per-row external API call in a list view. Live data from your payment provider or your KYC vendor belongs in the detail view, or behind a cache. In a list it multiplies by the page size.

None of these are exotic. They are the kind of thing that is obvious once someone has looked, and invisible until then.

Run a data readiness review with us before go-live

This is the part we would rather do early than explain late. One of our forward deployed engineers sits down with your DBA or backend lead, walks the schema against the list above, captures a performance baseline, and checks that monitoring is live on your backend before anything goes to production. Without that baseline, no later fix can be proven to have worked.

Afterwards the two teams watch the heaviest queries together, and run the review again after any significant schema migration. Missing indexes on new foreign keys are the single most common cause of a backoffice that was fast in June and is not in September.

The speed of your backoffice rests on two drivers: your database and our UI

Your team owns the data plane: the database, the queries, the records that never leave your network. We own the interface, the measurement across the boundary, and the tuning work we do alongside you.

That split is what lets a backoffice be fast and stay private at the same time. It also means neither of us gets there alone, which is why we would rather start the conversation before you are live than after someone writes to say the backoffice is slow.

Book a data readiness review with one of our engineers.