DEV Community: Oleksandr Sainchuk

Your SaaS Says “Saved”? Refresh the Page.

Oleksandr Sainchuk — Tue, 10 Nov 2026 21:58:36 +0000

A client of ours vibe-coded their product with AI tools and brought it to a demo. The forms worked, the screens looked finished, and the app said Saved after every action. During that demo it turned out the data had never been stored.

Nothing on the screen hinted at it. From the user's side it looks like this. You type a task, press Save, the task appears in the list, the input clears, and a small green "Saved" shows up under the form. Then you refresh the page and the task is gone, because the server never stored it.

The task appears with a Saved message, then disappears after a page refresh

A false success state is a screen that tells the user an action worked before the server confirmed it, or after the server refused it. This article grew out of that demo. When I review a save flow now, I don't take the green message as proof. I create the record through the UI, reload the page, read the record back through the authenticated API, try the same ID as a different user, and then break the request on purpose to see what the UI says.

To show all four, I built a small React app with an Express API, SQLite and Playwright, then broke it in three different ways. The results surprised me a little. A server that answered 201 and wrote nothing passed the test for failed saves, and a server that leaked tasks between users passed both persistence tests. Every bug got past at least one check, so a single test was never enough.

People write these bugs by hand too. With AI-built features the risk is higher, because an agent can produce a whole flow in minutes and it's easy to accept code you haven't read line by line.

The handler that lies

This is the broken path in the React app. It runs inside the form's submit handler.

setTasks((rows) => [...rows, { id: crypto.randomUUID(), title }]);
setStatus("Saved");
setTitle("");

fetch("/api/tasks", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ title }),
}).catch(() => {});

React adds the row right away, the API answers 503 and writes nothing, and the UI never looks at the answer.

Two things go wrong here. Saved appears before the request finishes, and the code never checks the HTTP status. As MDN explains, fetch() resolves on a 503 the same way it resolves on a 200, so the .catch() fires only for network errors and the 503 goes by unnoticed.

Showing a pending task right away is a fair design choice. The trouble starts when that pending row gets the word Saved, because at that moment the app is confirming something it never checked.

For this small app I picked a simpler contract. The text stays in the input while the request is in flight, the row appears after the server confirms the write, and if confirmation fails, the input keeps the text and an error message shows up.

Give every test its own account

The tests use cookie sessions. A page fixture creates a fresh user for each test and deletes that user's records afterwards. The /__test/* endpoints exist only when TEST_MODE=1 is set and skip real login, so they have no place in a deployed app. In your own project, use seeded test accounts and your real login flow.

import { test as base, expect, Page } from "@playwright/test";
import { randomUUID } from "node:crypto";

const test = base.extend({
  page: async ({ page }, use) => {
    await page.request.post("/__test/session");
    await use(page);
    await page.request.delete("/__test/session");
  },
});

I create a new user per test because a new browser context gives you fresh cookies and storage, and that's all it gives you. Two tests logged in as the same user still write to the same rows on the server. Playwright's authentication guide makes the same point and recommends separate accounts for tests that change server state.

The shared save function starts listening for the POST response before it clicks, so a fast reply can't slip past it.

async function saveTask(page: Page, title: string) {
  await page.goto("/tasks");
  await page.getByLabel("Task name").fill(title);
  const pending = page.waitForResponse(
    (r) =>
      new URL(r.url()).pathname === "/api/tasks" &&
      r.request().method() === "POST",
  );
  await page.getByRole("button", { name: "Save", exact: true }).click();
  const response = await pending;
  await expect(page.getByRole("status")).toHaveText("Saved");
  return response;
}

Test 1. Reload the page

test("saved task survives reload", async ({ page }) => {
  const title = `Release check ${randomUUID()}`;
  await saveTask(page, title);
  await expect(page.getByRole("list", { name: "Tasks" })).toContainText(title);
  await page.reload();
  await expect(page.getByRole("list", { name: "Tasks" })).toContainText(title);
});

With the broken handler, the first assertion passes because the task lives in React state. After the reload the app asks the API for the list, the API returns what it stored, and the task isn't there. This is the same thing the client saw in the demo, caught by a test in a few seconds.

A passing reload test proves less than it seems. An app can rebuild its list from localStorage, IndexedDB, a service worker or an HTTP cache, and then the task survives a refresh with no database row behind it. In this demo the list always comes from the API, responses send Cache-Control: no-store, and the Playwright config blocks service workers. Even so, I want to hear from the server itself.

Test 2. Read the record back through the API

The POST response carries the new record's ID. I use it for a separate authenticated GET and compare the fields I meant to save.

test("saved task is readable through the authenticated API", async ({
  page,
}) => {
  const title = `API check ${randomUUID()}`;
  const write = await saveTask(page, title);
  expect(write.status()).toBe(201);
  const created = await write.json();
  const read = await page.request.get(`/api/tasks/${created.id}`);
  expect(read.status()).toBe(200);
  expect(await read.json()).toEqual({ id: created.id, title });
});

page.request shares cookies with the browser context (see APIRequestContext), so this GET runs as the same user who filled in the form. If your app uses bearer tokens, set the Authorization header yourself. There's no mocked response anywhere in the persistence tests, they talk to the real local API.

The fake201 server mode shows why this test exists. It answers 201 with a believable ID and skips the insert. The status assertion passes, the follow-up GET returns 404, and the test fails.

In this app the GET reads from SQLite. In your architecture it might read a cache or a replica, so check where the read path goes before you call this a persistence test. Async APIs need a different assertion too. A 202 says the server accepted the work and nothing more, so follow the operation ID and poll for the completed state with a timeout.

Test 3. Request the same ID as another user

A record can be saved perfectly and still be readable by the wrong person. This test seeds a private task, checks that its owner can read it, then logs in a second user in a separate browser context and asks for that task by its ID.

test("another user cannot read a known task ID", async ({ page, browser }) => {
  const seed = await page.request.post("/__test/seed", {
    data: { title: `Private ${randomUUID()}` },
  });
  const task = await seed.json();
  expect((await page.request.get(`/api/tasks/${task.id}`)).status()).toBe(200);
  const outsider = await browser.newContext({
    baseURL: "http://127.0.0.1:4173",
  });
  try {
    await outsider.request.post("/__test/session");
    const forbidden = await outsider.request.get(`/api/tasks/${task.id}`);
    expect(forbidden.status()).toBe(404);
    const list = await outsider.request.get("/api/tasks");
    expect(await list.json()).toEqual([]);
  } finally {
    await outsider.request.delete("/__test/session");
    await outsider.close();
  }
});

This API answers 404 for a task the caller doesn't own. If your contract says 403, assert 403. A redirect to the login page, a 500, or a loose !response.ok() check would let a real problem pass here. The owner read at the start is a positive control, because if the task was never created, a 404 for the second user would prove nothing.

The fixed lookup filters by both the ID and the logged-in owner, and req.user comes from the server's session store, never from the request body.

const task = db
  .prepare("SELECT id, title FROM tasks WHERE id = ? AND owner = ?")
  .get(req.params.id, req.user);

A workspace product has real roles, and a teammate may be allowed to see the record. There I'd test someone from another tenant, a read-only member, a member who was removed, and the write endpoints as well as the reads.

Test 4. Make the failed save visible

This one checks what the user sees when the save fails. It intercepts only the POST, answers with a controlled 503, and lets the GET go through to the real server.

test("rejected save keeps the draft and never says Saved", async ({ page }) => {
  const title = `Rejected ${randomUUID()}`;
  await page.route("**/api/tasks", async (route) => {
    if (route.request().method() === "POST")
      await route.fulfill({
        status: 503,
        contentType: "application/json",
        body: '{"error":"Write rejected"}',
      });
    else await route.continue();
  });
  await page.goto("/tasks");
  await page.getByLabel("Task name").fill(title);
  await page.getByRole("button", { name: "Save", exact: true }).click();
  await expect(page.getByRole("alert")).toHaveText(
    "Save was not confirmed. Your draft is still here.",
  );
  await expect(page.getByRole("status")).toBeEmpty();
  await expect(page.getByLabel("Task name")).toHaveValue(title);
  await expect(page.getByRole("list", { name: "Tasks" })).not.toContainText(
    title,
  );
});

This mock tests the frontend's error handling and tells you nothing about the database, so I keep it apart from the real-server tests.

The fixed handler checks the status before it adds the row or clears the draft.

setSaving(true);
setError("");
setStatus("");

try {
  const response = await fetch("/api/tasks", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ title }),
  });

  if (!response.ok) throw Error("Save was not confirmed.");

  const task = await response.json();
  setTasks((rows) => [...rows, task]);
  setTitle("");
  setStatus("Saved");
} catch {
  setError("Save was not confirmed. Your draft is still here.");
} finally {
  setSaving(false);
}

A rejected save and a lost response are two different situations. The network can drop after the server has already committed the write, and then the client has no way of knowing what happened. So the message says the save wasn't confirmed, which is true in both cases. Keeping the draft is safe, and resending it blindly can create a duplicate, so before I add automatic retries to a real create flow, I give each operation a stable idempotency key and deduplicate on the server.

What the tests caught

I ran the same five tests against all four modes in Chromium, with two workers and retries turned off. The fifth test, not shown above, checks that an anonymous request can't list tasks.

Playwright HTML report with the failed reload test in broken mode

Run it yourself

The companion project has the React app, the server, the tests, the Playwright config and a lockfile. I tested it on Node 24, React 19.2.0 and Playwright 1.56.1. From the saved-demo folder on Linux or macOS, these commands run the fixed version.

npm ci
npx playwright install --with-deps chromium
npm test

To see the bugs, run each mode on its own. These runs are supposed to exit with failures.

MODE=broken npm test
MODE=fake201 npm test
MODE=leaky npm test

In CI, give every job a throwaway database and keep test auth state out of git. The project has a CI workflow for the fixed mode, and the numbers in the table above come from my local run.

Where I'd start in a bigger app

In a real product I wouldn't try to test every form at once. I'd pick the save flow where a lost record costs the most and add one real-server create-and-read test, one access test with a specific expected status, and one controlled failure test.

If an AI agent built the feature, you can hand it this prompt and then review the tests it writes. Replace the parts in square brackets with your own names.

Write Playwright tests for the [create task] flow in this app.

1. Create a [task] through the UI, reload the page, and assert it is still in the [Tasks] list.
2. Take the ID from the POST response, GET [/api/tasks/:id] with the same session, and assert status 200 and the saved fields.
3. Log in a second user in a new browser context, request the same ID, and assert [404].
4. Make the POST return 503 with page.route, then assert that "Saved" never appears, the draft stays in the input, and an error is shown.

Give every test its own user account. Do not mock the API in tests 1 to 3.

Four green tests don't make an app production-ready. They do show whether one specific Saved message holds up after a reload, an API read, a second user and a failed request. Before your next demo, save one record and read it back as the person who will need it tomorrow.

What's the strangest fake success you've seen in an AI-built app? Tell me in the comments.

Frequently asked questions

Why does a task disappear after refreshing an AI-built app?

The frontend may have updated local state even though the write failed, or the reload may query a different account or data source. Look at the POST response and the GET that follows it. A disappearing record on its own doesn't tell you which cause you have.

How do I test database persistence with Playwright?

Create the record through the UI, then read it back by ID through an authenticated API request and compare the stored fields. Confirm that the endpoint reads the database you care about, since a refresh test can pass on browser-stored data.

How do I test data isolation between SaaS accounts?

Create a record for its owner and confirm the owner can read it. Then log in a second user in a separate browser context, request the same ID, and assert the documented denial status. Extend the test to write endpoints and to the tenant roles your product has.

Can I mock API calls in a persistence test?

Mock a failed response when you test how the UI reacts to failure. Use the real write and read endpoints when you check saved state, because a mocked create response passes even when the backend is completely broken.

Thanks everybody!

I'm Lead Full Stack Developer at UITOP. This check is one small piece of taking a vibe-coded prototype to production 🤝

How we keep AI agent actions under server side control in rails

Oleksandr Sainchuk — Thu, 05 Nov 2026 21:36:56 +0000

Here is an endpoint that looks fine in a first agent prototype.

def create
  tool = params[:tool].constantize
  result = tool.call(**params[:arguments])

  render json: result
end

The model returns a tool name and some arguments. Rails finds the class and runs it. It's short, and it works in a demo.

It also gives the model the final say. If the agent reads a poisoned document, picks the wrong target or carries context over from another tenant, this endpoint runs the bad decision as it is.

In a security product the side effects are big. An agent can end a session, disable an account, isolate a machine, rotate a credential or change a cloud policy. I don't want the model to authorize any of that.

So in our product the agent only proposes. It sends a typed action request. Rails takes the tenant and the user from the authenticated session, looks the action up in its own list, validates the arguments, applies policy and saves the request. If a person has to approve it, the approval is tied to the payload they reviewed. Right before execution, Rails checks everything again.

I'm Oleksandr Sainchuk, a Lead Full Stack Developer at UITOP. For three years we've worked with a client on an enterprise cybersecurity platform. It uses role-scoped AI agents for investigation, sensitive-data protection, remediation and audit across AWS and Azure. We design the product, build the interface, write the Rails backend and the agent logic, and maintain it.

I covered the life of one account-disable request in an earlier article. This one is about the Rails layer underneath it.

The case the whole design is built around

An agent investigating a suspicious login finds a leaked session and proposes disabling the identity for 60 minutes. An analyst opens the request, reads the evidence and approves it.

A minute later someone edits the request. The duration becomes 240 minutes, or the target becomes another account. The first approval must not cover the edited version.

Most of the code below exists for that moment.

Start with a registry the server owns

The model picks from the tool descriptions you give it. That list helps generation. It doesn't decide what can run, so Rails needs its own allowlist.

module AgentActions
  class Registry
    ACTIONS = {
      "collect_identity_evidence" => CollectIdentityEvidence,
      "revoke_session"            => RevokeSession,
      "disable_identity"          => DisableIdentity,
      "isolate_endpoint"          => IsolateEndpoint
    }.freeze

    def self.fetch!(name)
      ACTIONS.fetch(name)
    rescue KeyError
      raise UnknownAction, name
    end
  end
end

I never call constantize, public_send, a shell command or a URL that the model supplied. The registry maps a string from the model to one command class that we wrote. An unknown name raises and nothing runs.

It also gives reviewers a single file that lists every action the agent can request. Nobody has to dig through prompts or provider settings to find out.

Give each action an input contract

Strong Parameters filter which attributes reach mass assignment. The Rails guide describes them as an explicit allowlist. They don't know whether an identity belongs to the current tenant or whether a duration is safe. Agent actions need a contract that checks meaning.

module AgentActions
  class DisableIdentity
    include ActiveModel::Model
    include ActiveModel::Attributes

    attribute :identity_id, :string
    attribute :reason, :string
    attribute :duration_minutes, :integer

    validates :identity_id, :reason, presence: true
    validates :duration_minutes,
      inclusion: { in: [15, 30, 60, 120, 240] }

    def resolve_target!(tenant:)
      tenant.identities.find(identity_id)
    end

    def risk_level
      :high
    end
  end
end

The agent can send identity_id, reason and a duration from a fixed list. If it sends tenant_id or approved_by, ActiveModel::UnknownAttributeError is raised, because the contract has no such attribute. I treat that as an invalid proposal. Risk level, policy version and status come from server code.

The target lookup is scoped to the tenant. Identity.find(identity_id) would accept a valid ID from any tenant. tenant.identities.find(identity_id) keeps the scope inside the query.

Save the proposal before doing any work

An approval flow has to survive a page refresh, a deploy and a background job that starts an hour later. So I save the proposal as application data before any connector runs.

class ProposeAgentAction
  def self.call(agent:, raw_call:)
    actor = Current.user
    tenant = Current.tenant

    command_class = AgentActions::Registry.fetch!(raw_call.fetch("name"))
    command = command_class.new(raw_call.fetch("arguments"))
    raise InvalidArguments, command.errors.full_messages unless command.valid?

    target = command.resolve_target!(tenant: tenant)

    decision = AgentActionPolicy.call(
      tenant: tenant,
      actor: actor,
      agent: agent,
      command: command,
      target: target
    )

    AgentAction.create!(
      tenant: tenant,
      requested_by: actor,
      proposed_by_agent_id: agent.id,
      action_type: raw_call.fetch("name"),
      target: target,
      arguments: command.attributes,
      risk_level: decision.risk_level,
      policy_version: decision.policy_version,
      status: decision.status,
      expires_at: decision.expires_at
    )
  end
end

The policy returns one of three statuses: denied, awaiting_approval or approved_for_execution. A read-only evidence lookup can run on its own. Disabling a production identity needs a security administrator. When policy context is missing, the answer is a denial or an approval request, never a guess in favor of running.

The prompt can tell the model about these rules, and Rails is what applies them.

Tie the approval to what the person reviewed

An Approve button means little on its own. Say an administrator reviews this request:

{
  "action": "disable_identity",
  "target_id": "idn_1842",
  "duration_minutes": 60
}

If the target changes to idn_9011 after the review, the old approval must not cover it. The same goes for a changed action type, duration, tenant, policy version or any other argument that matters for security.

We build an approval payload from normalized server data and run it through a versioned canonical serializer.

def approval_payload
  {
    schema_version: 1,
    tenant_id: tenant_id,
    action_type: action_type,
    target_type: target_type,
    target_id: target_id,
    arguments: arguments,
    policy_version: policy_version,
    expires_at: expires_at&.iso8601
  }
end

def current_digest
  AgentActions::Digest.call(approval_payload)
end

The approval record stores the digest, the approver, the decision time and the expiry. At execution time Rails recomputes the digest and compares it with the approved one. An edit changes the digest, so the old approval stops matching.

OWASP's AI Agent Security Cheat Sheet recommends the same for high-impact actions. It says to bind the approval to the actor, tool, target resource and normalized parameters, and to record a timestamp and expiry. It also asks for replay protection and idempotent actions where possible.

Frameworks can pause a run and resume it after a decision. In RubyLLM 2.0, a tool marked requires_approval stays pending, and the pending call and the decision live in your database. Your application still decides who may approve, what they approved and whether that approval is valid now.

Check authorization again at execution time

Policy can change while an action waits. The target can move to another state. The user who started the request can lose access. The approval can expire. So the job loads current records and evaluates current policy.

class ExecuteAgentActionJob < ApplicationJob
  self.enqueue_after_transaction_commit = :always

  def perform(action_id)
    action = AgentAction.find(action_id)

    idempotency_key = action.with_lock do
      next unless action.approved?
      next if action.expires_at&.past?
      next unless action.approved_digest == action.current_digest

      decision = AgentActionPolicy.call_for_execution(action)
      next unless decision.allowed?

      action.update!(
        status: "executing",
        execution_key: action.execution_key || SecureRandom.uuid
      )

      action.execution_key
    end

    return unless idempotency_key

    result = AgentActions::Executor.call(
      action: action.reload,
      idempotency_key: idempotency_key
    )

    action.update!(
      status: "verifying",
      external_reference: result.reference
    )
  rescue Net::ReadTimeout
    # Use whichever timeout error your connector raises.
    action&.update!(status: "execution_unknown")
    ReconcileAgentActionJob.perform_later(action.id) if action
  end
end

The row lock stops two workers from claiming the same approved action. Rails supports both optimistic and pessimistic locking, and the Active Record guide covers them.

The connector call runs after the short lock is released. A database transaction can't make a cloud API call atomic with a local update, and Rails' transaction callbacks exist for work that happens outside the database. So the connector receives a stable idempotency key.

enqueue_after_transaction_commit = :always was added in Rails 7.2. It holds the job back until the surrounding transaction commits, so a worker never looks for a record that isn't saved yet. The Active Job guide explains the setting.

If the connector times out, I don't mark the action as failed and send a new request. The remote system may have finished the work. execution_unknown is a real state in our model. A reconciliation job asks the remote system about the operation reference, or inspects the target, before anyone tries again.

Pass record IDs to jobs

Jobs get the action ID and nothing else.

ExecuteAgentActionJob.perform_later(action.id)

The worker reloads the proposal, target, approval and policy context from our database. It never receives the model's original arguments as trusted input.

This matters when a request waits hours for a decision. The chat transcript explains why the agent proposed an action. The database record decides whether the action runs.

Keep audit events apart from the chat log

A chat log gives context, but it's a poor security record. For each action I store structured events:

who and which agent proposed it, and which tenant, incident, target and evidence were involved
which action contract and policy version were evaluated, and which arguments Rails accepted
who approved, rejected or edited it, which digest they approved and when the approval expired
which worker claimed it, with the idempotency key and the external reference
whether verification confirmed the result, and whether a rollback followed

Events hold evidence references and short summaries. They never hold credentials, full sensitive files or hidden model reasoning.

OWASP's Agent Control Standard, now part of the OWASP GenAI Security Project, says agents must be inspectable, traceable and instrumentable. A durable event history gives an application a concrete way to meet that.

Prompt injection is an authorization problem too

Injected text can still convince a model to request disable_identity. That request then meets the same registry, contract, tenant scope, policy, approval, expiry, lock and audit checks as any other proposal. It can't skip a step because the model was persuaded.

Filtering untrusted content and isolating tools still matter. The Rails boundary limits what a successful injection can do. OWASP's prompt injection guidance recommends least privilege and human approval for high-risk actions for that reason.

What I check before an agent changes customer state

Every action the agent can run sits in a server-owned registry with its own input contract.
Tenant, user, roles and policy version come from server state, and targets are found through tenant-scoped queries.
Policy runs when the proposal is saved and again before execution.
An approval covers one normalized action, expires, and stops matching when someone edits the action.
Workers get record IDs, take a lock and reload current state.
External calls carry an idempotency key, and a timeout leads to a reconciliation step.
Audit events record the decision and the outcome and keep secrets out.

An AI Agent Wants to Disable an Account. What Should the Rails App Do Next?

Oleksandr Sainchuk — Thu, 29 Oct 2026 22:09:11 +0000

An incident response agent connects several alerts to the same user session. Someone opened a sensitive file, started an outbound transfer to an unauthorized destination, and used the same token from an unfamiliar endpoint.

The agent recommends revoking the session, disabling the account, and isolating the endpoint.

At this point, the model has done useful work. It has grouped the evidence and proposed a response. It still hasn't changed anything in the customer's environment.

The next decision belongs to the application.

The Rails backend has to check the agent's permissions, the target account, the current policy, the risk of each action, and the person allowed to approve it. If any part of that check fails, the action stops.

UITOP has been working on an enterprise cybersecurity product through an ongoing three-year product partnership. The platform uses role-scoped sub-agents for security investigation, sensitive-data protection, remediation, and audit. Our work includes product design, interface implementation, Ruby on Rails development, agent logic, and product maintenance.

I've changed the product name and left out client-specific architecture. The control model in this article reflects the engineering decisions we worked through in the real product.

Save the proposal before calling a security tool

I treat an agent response as untrusted input at the authorization boundary. Valid JSON doesn't make an operation safe to run.

The application first turns the recommendation into a durable action record. That record stays with the operation during policy evaluation, approval, execution, verification, and audit.

create_table :agent_actions do |t|
  t.references :incident, null: false, foreign_key: true
  t.string :proposed_by_agent_id, null: false

  t.string :action_type, null: false
  t.string :target_type, null: false
  t.string :target_id, null: false
  t.jsonb :parameters, null: false, default: {}

  t.string :risk_level, null: false
  t.string :policy_version, null: false
  t.string :fingerprint, null: false
  t.string :status, null: false, default: "proposed"

  t.references :approved_by_user, foreign_key: { to_table: :users }
  t.string :approved_fingerprint
  t.datetime :approved_at
  t.datetime :expires_at

  t.string :execution_reference
  t.jsonb :verification_data, null: false, default: {}
  t.datetime :verified_at

  t.integer :lock_version, null: false, default: 0
  t.timestamps
end

add_index :agent_actions, :fingerprint
add_index :agent_actions, [:incident_id, :status]

action_type comes from an application-owned allowlist. In this case, it may contain revoke_session, disable_account, and isolate_endpoint. A model-generated tool name never becomes an executable operation on its own.

The fingerprint ties approval to one version of the action.

class AgentAction < ApplicationRecord
  before_validation :set_fingerprint

  private

  def set_fingerprint
    self.fingerprint = ActionFingerprint.call(
      action_type: action_type,
      target_type: target_type,
      target_id: target_id,
      parameters: parameters,
      policy_version: policy_version
    )
  end
end

ActionFingerprint serializes parameters in a canonical order. Two equivalent payloads should produce the same value even if their keys arrive in a different sequence.

Let Rails assign the effective risk

The agent may suggest that an action is Low, Medium, High, or Critical. Rails makes the final decision.

In the product we worked on, each sub-agent had its own role, data scope, tools, and permissions. Access to identity evidence did not grant permission to disable an identity. Any operation outside an explicit policy was blocked.

The policy service receives the proposing agent, the initiating user, the incident, and the requested action.

decision = AgentActionPolicy.call(
  actor: current_user,
  agent: proposing_agent,
  incident: incident,
  action: action
)

case decision.outcome
when :denied
  action.update!(
    status: :policy_denied,
    policy_version: decision.policy_version
  )
when :approval_required
  action.update!(
    status: :awaiting_approval,
    risk_level: decision.risk_level,
    policy_version: decision.policy_version,
    expires_at: decision.expires_at
  )
when :automatic
  action.update!(
    status: :approved,
    risk_level: decision.risk_level,
    policy_version: decision.policy_version,
    approved_fingerprint: action.fingerprint
  )
  ExecuteAgentActionJob.perform_later(action.id)
end

The decision can depend on the environment, data sensitivity, destination, target type, and current incident state. A production account suspension should not inherit the same path as a read-only evidence lookup.

We kept automatic execution narrow. A policy could allow evidence collection or an immediate block on a forbidden outbound transfer. Disabling an account, isolating production infrastructure, rotating credentials, and changing IAM or firewall rules required an authorized person.

OWASP recommends a similar split in its AI Agent Security Cheat Sheet. The agent proposes an operation. Application-controlled policy and execution layers validate scope, privilege, and approval before a high-impact side effect.

Make the approval specific

Imagine that an administrator reviews the proposed account suspension. The original plan disables the account indefinitely and revokes every active session. The administrator changes it to a two-hour freeze and revokes only the suspicious session.

The old approval is no longer valid because the operation has changed.

class ApproveAgentAction
  def self.call(action:, approver:, expected_lock_version:)
    action.with_lock do
      raise StaleAction if action.lock_version != expected_lock_version
      raise InvalidState unless action.awaiting_approval?
      raise ExpiredAction if action.expires_at&.past?

      decision = AgentActionPolicy.call(
        actor: approver,
        agent: action.proposing_agent,
        incident: action.incident,
        action: action
      )

      raise Forbidden unless decision.approver?
      raise PolicyChanged unless decision.policy_version == action.policy_version

      action.update!(
        status: :approved,
        approved_by_user: approver,
        approved_at: Time.current,
        approved_fingerprint: action.fingerprint
      )

      AuditEvent.record!(
        incident: action.incident,
        actor: approver,
        event_type: "agent_action.approved",
        subject: action,
        data: {
          fingerprint: action.fingerprint,
          policy_version: action.policy_version
        }
      )
    end

    ExecuteAgentActionJob.perform_later(action.id)
  end
end

Rails gives us with_lock for the row-level lock. It prevents two approval requests from consuming the same pending action at the same time. lock_version also catches a reviewer acting on an older version.

The browser sends the action ID, the decision, and the version shown to the reviewer. The server loads its own record, authenticates the person, checks authorization again, and stores the decision atomically.

The OpenAI Agents SDK human-in-the-loop guide makes the same boundary clear. Approval state should live in server-controlled storage. A run ID or decision ID cannot prove that the person submitting it has permission to approve the tool call.

Recheck every edited remediation plan

Administrators in the product could remove a proposed action, change its target, or submit a different response. The revised plan went through policy evaluation again. It also required a second confirmation before execution.

I would clear the previous approval inside the edit transaction.

action.with_lock do
  action.assign_attributes(parameters: revised_parameters)
  action.status = :proposed
  action.approved_by_user = nil
  action.approved_at = nil
  action.approved_fingerprint = nil
  action.save!
end

EvaluateAgentActionJob.perform_later(action.id)

The callback creates a new fingerprint. Policy evaluation may assign another risk level or block the edited action. The audit history still shows the earlier proposal, while execution accepts only the current fingerprint.

This behavior has to match the approval interface. If the administrator changes a target and presses confirm, the backend must not reuse a decision attached to the old parameters.

Claim the action once

The execution job uses a short transaction to claim the approved action. It calls the external security connector after releasing the database lock.

class ExecuteAgentActionJob < ApplicationJob
  self.enqueue_after_transaction_commit = true

  def perform(action_id)
    action = AgentAction.find(action_id)

    claimed = action.with_lock do
      next false unless action.approved?
      next false unless action.approved_fingerprint == action.fingerprint
      next false if action.expires_at&.past?

      action.update!(status: :executing)
      true
    end

    return unless claimed

    response = SecurityConnector.for(action).call(
      action_type: action.action_type,
      target_id: action.target_id,
      parameters: action.parameters,
      idempotency_key: "agent-action-#{action.id}-#{action.fingerprint}"
    )

    action.update!(
      status: :verifying,
      execution_reference: response.reference
    )

    VerifyAgentActionJob.perform_later(action.id)
  rescue SecurityConnector::Timeout
    action.update!(status: :execution_unknown)
    ReconcileAgentActionJob.perform_later(action.id)
  end
end

The idempotency key represents one approved operation. A timeout leaves us with uncertainty. The connector may have disabled the account even though Rails never received the response.

Blindly repeating the request can create a second ticket, rotate a credential twice, or apply another policy change. I prefer an honest execution_unknown state. A reconciliation job can query the downstream system by operation ID or inspect the target before it retries anything.

Rails supports enqueue_after_transaction_commit for jobs that need committed data. The worker cannot pick up an approval record that is still inside an open transaction.

Verify the security outcome

Now return to the original incident. Session revocation succeeds. The account is disabled. Endpoint isolation times out.

The remediation plan is still open because the endpoint may still have access.

The execution worker stores the connector response. A separate worker checks the downstream state.

verification = SecurityConnector.for(action).verify(
  action_type: action.action_type,
  target_id: action.target_id,
  execution_reference: action.execution_reference
)

if verification.confirmed?
  action.update!(
    status: :completed,
    verified_at: Time.current,
    verification_data: verification.safe_metadata
  )
else
  action.update!(
    status: :failed,
    verification_data: verification.safe_metadata
  )
end

Each action needs its own verification rule. Session revocation checks that the session no longer exists. Account suspension reads the current account state. Endpoint isolation confirms the containment policy or network state.

The incident closes after its required actions reach an accepted terminal state. A partial failure stays visible with its owner and remaining exposure. Rollback, when supported, becomes another policy-checked action with its own approval and verification record.

Keep an audit trail people can use

For a high-risk action, I want the audit history to answer practical questions.

Which incident produced the proposal?
Which agent proposed it?
Which evidence supported it?
Which policy version evaluated it?
Who approved, rejected, or edited it?
Which fingerprint did that person approve?
What did the connector attempt?
What did the downstream system report?
Did verification pass?
Did someone roll the action back later?

I would leave raw secrets, access tokens, full sensitive files, and hidden model reasoning out of the payload. Stable evidence references and application-written summaries are enough to preserve the basis of the decision and the resulting action.

Microsoft's shared responsibility model for AI agents keeps per-action authorization, approval for high-impact operations, agent identity, and audit logging with the application owner.

Test the uncomfortable paths before release

I would run one incident through the following cases before letting the agent disable a real account.

The agent proposes an allowed action for a permitted target.
The same agent requests a tool outside its role.
An unauthorized employee tries to approve the action.
An administrator edits the target after reviewing the plan.
Two approval requests arrive almost together.
The connector finishes after Rails times out.
Execution succeeds and verification fails.
A different authorized administrator requests rollback.

For every run, I would compare the server state, the interface, and the audit history. They should describe the same operation.

An enterprise AI security agent becomes useful when it can move an incident forward. It becomes safe enough to operate when the surrounding product limits what it can see, what it can propose, what it can execute, and whose approval it needs.

That work spans the full product. The interface has to show evidence, risk, scope, and current state clearly. The Rails application has to enforce the policy even if the model, the browser, or the connector behaves unexpectedly.

I lead product development at UITOP. If you're building an enterprise AI agent that can touch company accounts, cloud resources, or sensitive data, feel free to message me. I'd be interested to hear how your team handles edited approvals, uncertain execution, and verification after a security action.

Replacing an ERP interface? Define API contracts, keep business rules and permissions on the server

Oleksandr Sainchuk — Wed, 28 Oct 2026 21:19:39 +0000

An ERP frontend migration can keep every endpoint and still break the business. Picture a new release where the stock table labels on-hand inventory as "available." A new form skips a validation that used to live in the old browser code. And the submit button shows a nice green toast, and the operator still has no idea whether the transfer posted.

None of these show up in an API diff. So when you modernize an ERP frontend, the API schema is only half the agreement. The other half is the workflow: which records people act on, what the numbers on screen mean, and which server response confirms that an action happened.

To keep this concrete, we'll follow one small workflow the whole way: a warehouse operator reviews stock and posts a transfer.

Start with one complete workflow

Pick a workflow with a clear start and a visible business result. In our example, the operator finds an item in a source warehouse, checks availability, picks a destination and submits a quantity. The ERP either accepts the transfer or says why it can't.

Before you design anything, watch that workflow in the current app. Ask an operator to show you a normal transaction and one that needs intervention. Open the browser's network tab and look at the code that builds each request. Note any spreadsheet or manual step people use to finish the job.

You'll find rules that look strange. A waiting period might enforce an approval policy, or it might be left over from a batch job nobody runs anymore. To tell them apart, find the business owner and ask what the rule is for. Keep the behavior until that person agrees on a change and how to accept it.

A short note per uncertain rule is enough to start: what you saw, where it's implemented, who owns it, why it exists, and what you decided. Now engineering has something concrete to verify.

At UITOP we redesigned Slabstack, a CRM for heavy construction materials producers, around how companies, projects and daily operations connect. The same habit helps in ERP work: map those operational relationships first, and the scope of each workflow becomes much clearer.

Write the contract around the workflow

For the stock transfer, write down these agreements:

Settle these with the people who own the ERP rules. A frontend team can only show a useful distinction if it knows what the backend values mean.

Describe the HTTP side with OpenAPI: parameters, request bodies, response schemas and known errors. Add field descriptions for units and business meaning. Keep the workflow acceptance scenarios next to the spec, including the document or ledger state each one should produce.

One trap to watch: a response can keep the same shape while a field quietly changes meaning. That's still a contract change, so review it like one.

Find the rules hiding in the old frontend

Old screens do more than display data. They prepare quantities, fill hidden fields, pick a document type and run validation before sending a request. New markup doesn't bring any of that along by itself.

So list the client scripts and the events that trigger them. Trace what each one calculates, what it only displays, and which rules the server also checks. Don't skip the rare paths, like cancelling a document or reopening a rejected request.

Frappe is a good real-world example. Its docs note that Client Script validations run through the standard browser form. If a rule must also apply to API access, it needs server-side validation. A separate React frontend skips that browser form entirely, so it needs a plan for every rule that lived there.

As you go, give each rule an owner and a home. Presentation logic can stay in the frontend. Business validation and authorization belong on the server too.

Put an adapter between the ERP and your components

Keep the ERP's field names at one defined boundary. Your components then work with a small model whose names match the interface.

Below is the full adapter for our example. The contract sends quantities as plain decimal strings. Strings keep the precision the ERP supplied, and the adapter does no stock math of its own.

export type StockSnapshot = Readonly<{
  sku: string;
  warehouseId: string;
  onHand: string;
  available: string;
  unit: string;
  revision: string;
}>;

function text(value: unknown, field: string): string {
  if (typeof value !== "string" || value.trim() === "") {
    throw new TypeError(`Expected a non-empty string: ${field}`);
  }
  return value;
}

function quantity(value: unknown, field: string): string {
  const result = text(value, field);
  if (!/^-?\d+(?:\.\d+)?$/.test(result)) {
    throw new TypeError(`Expected a decimal string: ${field}`);
  }
  return result;
}

export function decodeStockSnapshot(input: unknown): StockSnapshot {
  if (input === null || typeof input !== "object" || Array.isArray(input)) {
    throw new TypeError("Expected a stock response object");
  }
  const row = input as Record<string, unknown>;
  return {
    sku: text(row.item_code, "item_code"),
    warehouseId: text(row.warehouse_code, "warehouse_code"),
    onHand: quantity(row.qty_on_hand, "qty_on_hand"),
    available: quantity(row.qty_available, "qty_available"),
    unit: text(row.stock_uom, "stock_uom"),
    revision: text(row.record_version, "record_version"),
  };
}

Say the response has qty_on_hand: "148.000" and qty_available: "118.000". The interface gets both values and shows the ERP's availability as is. The frontend doesn't calculate it, because the ERP's number can include rules beyond "on hand minus reserved," and the frontend doesn't know them.

If availability is missing, the adapter throws. Showing zero would be worse: it turns a broken contract into wrong inventory data that someone might act on. The caller should catch the error and show a loading error that fits the workflow.

The example tests cover decimal precision, missing and malformed fields, identifiers, revision handling and extra response fields. All ten local tests pass. Keep their scope in mind, though: they test this response boundary. They don't call a running ERP or prove that a transfer posts.

Use whatever validation your codebase already has. A schema library or a generated client can replace these small helpers. What matters is that runtime response checking has a clear place in the app.

Keep authorization on the server, at every entry point

A simpler interface can hide advanced modules and show fewer actions. That's fine for the UI. The API still has to check what the current user can do.

Test warehouse access through the list, the record detail, the transaction endpoint and reports. Include a user who can view a warehouse but can't move its stock, and a user who belongs to several departments. A filtered dropdown can't enforce any of this. OWASP's authorization guidance recommends checking permissions on every request.

If the new frontend runs on a separate origin, write down how it authenticates and keeps the session alive. Check the ERP's supported browser auth flow, its cookie and CSRF requirements, and the allowed origins. Remember that CORS only controls which browsers can read responses. It doesn't give a user permission to any business record. And keep privileged integration credentials on the server, never in browser code.

Add session expiry to your workflow tests too. If auth expires in the middle of a transfer, the operator needs a clear way to recover.

Decide on stale data and retries before release

Two operators can work with the same stock while a transfer form sits open. The quantity that was available when the form loaded may be gone by the time someone clicks submit.

If the API supports version checks, send the version the operator reviewed and let the server check it in the same atomic step as the write. HTTP APIs can do this with an ETag and [If-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-Match), and a failed precondition returns 412. Other systems use an explicit version field. Either way, the header only works if the server supports it.

A timeout is a different problem. The server may have committed the transfer even though the browser never got a confirmation. So decide how the client looks up the outcome. If the API supports idempotent writes, reuse the same operation ID when you retry, and let the server handle duplicates. AWS walks through this in its guide to idempotent APIs.

Disabling the submit button helps with double clicks. It doesn't replace retry and duplicate rules on the write API.

Test the business result after each action

Use representative, access-controlled test records, and check what the ERP recorded after each action. Check the resulting document and stock state along with the success message, because that state shows what happened.

Playwright can run API checks alongside browser steps, including checks on server-side results. Run integration tests against the ERP for anything a mocked response can't prove. Keep UI-state and adapter tests for their narrower jobs.

Compare old and new outputs for a stable set of inputs. When they differ, take it to the business owner. If it's an intentional fix, it gets its own decision and acceptance criteria. Just don't keep a known bug alive only to make the outputs match.

Roll out one workflow and keep a way back

Decide which users and routes see the new interface, what stays in the old app, and who can pause the rollout. Check deep links, navigation to related records, shared auth and existing exports.

A route or feature flag lets people switch back to the old interface. Make sure the old app can still read records created in the new one. And remember that rolling back a frontend release doesn't undo posted transfers or reverse a schema change. Those need their own recovery plan.

Your first scope should name one workflow, its dependencies, the checks it must pass and the evidence you need before expanding. This is also a good test for a modernization partner: ask how they'll find the existing rules and how they'll prove the result in the working system.

At UITOP we designed and built LogiCore, a logistics and warehouse application that connects shipment monitoring, warehouse structures and inventory, with a React/TypeScript frontend on a REST backend. The lesson carries over to ERP work: interface decisions and operational data are tied together, and when the frontend changes, those ties need to stay visible.

You could wonder right now:

Can we add a modern frontend while keeping the existing ERP backend?

Yes, if the backend already exposes the operations and access controls the new interface needs. Start with one bounded workflow and verify reads, writes, authentication and business validation. If the API has gaps, scope the server or integration work together with the frontend.

How do we tell real business rules from historical workarounds?

Walk through the behavior with an operator and the business owner responsible for the outcome. Check the code, integrations and downstream reports. Write down why you keep, change or remove it. At UITOP, the design question we ask first is which operational dependency the interface must preserve, because visual simplification only works with that context.

Can ERP upgrades break existing custom scripts?

Yes, when scripts depend on fields, events, APIs or libraries that changed. List those dependencies and test the target version in staging. If you're replacing a standard form with a custom frontend, also check which validations ran only in the original browser form and which the server enforces.

How should warehouse access be isolated between departments?

Define which records and actions each department membership allows, then enforce that policy on the server. Test detail views, writes and reports along with lists, and include users who belong to several departments. Interface filters should reflect the policy, but every endpoint needs its own access check.

How should a standalone React frontend authenticate with an existing ERP?

Use the ERP's supported browser authentication, and document session expiry, CSRF protection and allowed origins. Check the user's permissions on every API request. Never put privileged integration credentials in browser code. A working CORS setup is only one part of the picture, next to authentication and authorization.

Why do ERP data problems often show up late in UAT?

Early checks often confirm that fields load and miss whether the records work together to complete a transaction. Test full transactions and downstream reports with business users earlier. At UITOP, we treat the operational result, like the resulting stock document, as part of acceptance, next to the screen the user sees.

Which ERP workflow would you modernize first, and what business result would tell you the replacement works?

A React and TypeScript walkthrough. Redesign an existing SaaS screen, keep record identity and filters intact, and test the behavior

Oleksandr Sainchuk — Thu, 22 Oct 2026 13:20:46 +0000

A lot of React apps start life in an AI builder now. Auth works, routes work, customer records load. Then someone looks at the screens and says the UI needs design work.

When you change a screen, you can quietly change how people get their work done on it. A row that used to open the right record now opens the wrong one. A filter that used to stick now resets. Nothing crashes, so nobody notices until a user complains.

So before touching the layout, write down what the screen must keep doing. Which record an action opens. Which filters survive navigation. What happens while data loads or fails. Then check every design decision against that list.

To show how this works, I built a small React and TypeScript feedback inbox with made-up customer requests. The flow is narrow on purpose: filter requests, open one, read it, and go back to the filtered list.

1. Write the behavior down before you move a pixel

Start with a short scenario that a designer and a developer can both read:

Choose Reporting in the product-area filter.
Open FR-108: Export feedback to CSV.
Confirm that the detail shows Northline, the customer attached to FR-108.
Choose Back to requests.
Confirm that Reporting is still selected and keyboard focus returns to the request button.

Now every design idea has a test to pass. Moving the status badge is presentation, so go ahead. Opening a different record, clearing the filter, or changing what "Planned" means is behavior, and it needs a conversation first.

In a real app, write down the existing route, permission checks, API contracts and action callbacks next to the scenario. A UI change can usually leave those alone. If a new design needs a new endpoint or a different permission rule, the task just grew, so scope it that way.

Our example runs on local records. A real product also needs checks against its real data and auth rules.

2. Let the row show what people scan for

First question: what does someone need to see before they open a request?

Selection and status mean different things, so they need different looks. An open request can still be New, Planned or In review. If selection looked like a status, a click would read like a status change.

This is the whole row component:

export function RequestRow({
  request,
  selected,
  onOpen,
}: {
  request: FeedbackRequest;
  selected: boolean;
  onOpen: (id: string, button: HTMLButtonElement) => void;
}) {
  return (
    <li>
      <button
        type="button"
        className="request-row"
        aria-expanded={selected}
        aria-controls={selected ? "request-detail" : undefined}
        onClick={(event) => onOpen(request.id, event.currentTarget)}
      >
        <span className="request-copy">
          <strong className="request-title">{request.title}</strong>
          <span className="request-meta">
            {request.company} · {request.id}
          </span>
        </span>
        <span className="status" data-status={request.status}>
          {request.status}
        </span>
      </button>
    </li>
  );
}

FeedbackRequest holds the record's ID, title, customer, product area, status and message. The row gets a record and an open callback. It never changes the status.

Why a native button? You get keyboard support for free. Because the button reveals related content, aria-expanded tells assistive tech whether that content is open. When the detail opens, its heading gets focus, and Back to requests sends focus back to the row you came from. The WAI-ARIA disclosure pattern explains the expanded-state part.

This works because our detail panel is read-only. If your rows hold checkboxes, menus or inline actions, you need a different structure, because each control needs its own valid target.

3. Store the ID, not the record

The inbox keeps three pieces of UI state:

const [query, setQuery] = useState("");
const [area, setArea] = useState("All");
const [selectedId, setSelectedId] = useState<string | null>(null);

const visible = requests.filter((request) => {
  const matchesArea = area === "All" || request.area === area;
  const text = `${request.title} ${request.company} ${request.id}`
    .toLowerCase();
  return matchesArea && text.includes(query.trim().toLowerCase());
});

const selected = loadState === "ready"
  ? visible.find((request) => request.id === selectedId)
  : undefined;

Why derive selected instead of storing it? A second copy of the record goes stale. If the parent sends an updated status for the same ID, the list and the detail both show it, because both read from the same records. React's state-structure guidance recommends this selected-ID approach.

Search and the area filter work together. Changing either one closes the detail panel here. That's a deliberate product rule: the open record always belongs to the visible results. If your product keeps the detail open while filtering, pick a different rule and write a test for it.

Render rows with key={request.id}. And during a redesign, watch the component type, position and keys around stateful parts of the screen. React ties state to a component's place in the render tree, so wrapping a stateful component in a new container can quietly reset it. More on that in preserving and resetting state.

In other words, keeping the same API calls isn't enough. The component tree matters too.

4. One state, two layouts

On a wide screen, the list and detail sit side by side. On a narrow screen, the detail takes over, and Back to requests returns to the list.

The inbox component owns the filters and selected ID in both layouts. CSS only changes what's visible. There are no separate desktop and mobile copies of state to drift apart:

.inbox-layout.has-detail {
  grid-template-columns: minmax(0, 1.1fr) minmax(0, 1fr);
}

@media (max-width: 760px) {
  .inbox-layout.has-detail {
    grid-template-columns: minmax(0, 1fr);
  }
  .has-detail .inbox {
    display: none;
  }
}

760px is simply where this layout stops fitting. Check where yours does. Long titles, translated labels, enlarged text and an open detail panel will find problems that a short desktop fixture never shows.

We also gave flex and grid children min-width: 0, let long text wrap, and kept the Back button in the normal document flow, so narrow layouts behave predictably.

5. Decide once, reuse everywhere

Before you spread the design to more pages, agree on a few shared decisions: text hierarchy, spacing, focus style, selection style and status labels. Map them to the tokens and components the product already has.

The example names its selection colors:

:root {
  --selection-bg: #eef3ff;
  --selection-border: #294fc2;
}

.request-row[aria-expanded="true"] {
  background: var(--selection-bg);
  border-inline-start-color: var(--selection-border);
}

.status[data-status="Planned"] {
  color: #594013;
  background: #fff2d7;
}

If your design system already has fitting tokens, use them. The new screen stays consistent with its neighbors, and later changes are easier to review.

Design the loading, empty and error states alongside the main screen, not after it. In this inbox, loading has its own message. An empty filter result offers Clear filters. A failed request offers Retry and keeps your search and filter.

Each state answers a different question. Is it working? Does anything match? Did the data load? So each one needs its own next step.

6. Test behavior, not only pixels

A screenshot catches clipped text, uneven spacing or an unreadable badge. It can't tell you that a row opens the right customer or that Retry kept your filters.

So the browser check runs the scenario from step 1 directly. These lines come from its Playwright script:

await page.getByLabel("Product area").selectOption("Reporting");
await page.locator(".request-row").first().click();

assert.equal(
  await page.locator("#request-detail h2").textContent(),
  "Export feedback to CSV"
);
assert((await page.locator("#request-detail").textContent())
  .includes("Northline"));

await page.getByRole("button", { name: "Back to requests" }).click();
assert.equal(
  await page.getByLabel("Product area").inputValue(),
  "Reporting"
);

The full script also covers keyboard activation and focus return, combined filters, a record update reaching the open detail, narrow layouts, loading, empty results and retry. All 14 checks passed in a local Chromium run, and the output logs the browser version and each check.

For screenshot comparisons, use fixed records, a fixed viewport and the same rendering environment every time. Look at the first image yourself before you accept it as a baseline. Playwright's visual-comparison docs cover baselines and environment differences.

These checks cover local UI behavior only. Real API integration, authorization, real devices and a screen-reader session are separate work.

7. Hand off decisions, not only files

A good handoff lists the changed components, why you made each design decision, the acceptance scenarios and the checks you ran. It also flags anything that needs another owner, like a new response field or a permission rule.

This matters most when design and frontend share responsibility for a working product. At UITOP we ran into this on LogiCore, a logistics platform where we handled both the design and the React/TypeScript development, including shipment tracking and warehouse inventory. Interface decisions there had to match how the operational data behaved, or the screens looked right and worked wrong.

So for a React UI refinement, start with one important workflow. Make its component and state decisions easy to review, run the agreed checks, and only then roll the patterns out across the product.

Questions

Can I keep a React redesign limited to the UI layer?

Yes, if you scope it to presentation components, styles and their existing callbacks. Write down the routes, record IDs, API contracts, permissions and state that must keep working. Then review the changed files and run the affected workflow. Telling an AI agent "UI only" doesn't verify the code it writes.

Should I define design tokens and shared components before updating the pages?

Look at what the app already uses first. Settle shared decisions on one representative workflow, including its error and narrow-screen states, then reuse them. Building a big new token system before checking the existing components can turn a small refinement into a migration.

How should a team structure large AI-generated designs for implementation?

Separate shared styles and components from page-specific content. Give each task one bounded screen or workflow, with its dependencies and acceptance scenarios. Check the exports against your real React architecture, because a large generated HTML file doesn't define component boundaries or data ownership.

How can I use screenshot comparison to review a React UI redesign?

Capture stable fixtures at agreed viewports and compare them against baselines a person has reviewed, in a consistent environment. Add interaction checks for record identity, filters, focus and actions. A screenshot can match perfectly while the workflow behind it is broken.

How can new features follow the existing brand guidelines?

Turn the guidelines into the tokens, component variants and content rules your codebase uses. Review one representative feature against those decisions before extending it. A reference image gives useful context, but the code needs explicit rules for typography, color, spacing and states.

Should I hire a UI/UX designer, a frontend developer, or someone who handles both?

Let the unresolved work decide. Flow and hierarchy decisions need design ownership. Component integration and state behavior need frontend ownership. When both are in scope, give the team shared acceptance criteria and one clear implementation reviewer. UITOP combines product design and frontend development, and we scope that work around the workflow and codebase that need attention.

Which workflow in your React app needs a design change, and which behavior has to stay the same?

We Took a Claude-Built SaaS UI into Figma and Back to React

Oleksandr Sainchuk — Mon, 19 Oct 2026 20:33:34 +0000

Claude gave us a tidy expense inbox. It had a table, statuses, buttons, and all the other signs of a functioning SaaS product. Then my teammate Katerina looked at one expense that was missing a cost center. The reason it needed attention was easy to miss.

That seemed like a good place to start. We wanted to see what would happen if we built a screen with Claude, refined its design system in Figma, and asked Claude to continue the React prototype using the new design. Could it keep the same product decisions across an inbox, an expense detail view, and a dashboard?

Katerina recorded the full experiment on YouTube. She used a spend management demo for the experiment, with a finance manager and a connected expense review flow.

The first screen looked plausible. The queue still needed work.

Kate started by telling Claude who would use the product: a finance manager reviewing employee expenses. She described the inbox, the information needed to make a decision, and the actions a manager could take. Claude built the first UI in React with reusable pieces.

It was a useful starting point. But the merchant, the review reason, the urgency, and the available action competed for attention. If you're scanning a queue, you want to know why this expense is here before you spend time opening it. “Missing cost center” should be hard to miss. The button can wait its turn.

We kept one expense in mind throughout the rest of the experiment: Alex Morgan submitted a $2,480 Atlas Cloud charge, and the cost center is missing. The manager opens it, checks the receipt and recent spending, then asks Alex for that information. The expense moves from Needs review to Waiting for employee, and the request appears in its activity.

The short task note I would hand an AI coding tool includes:

User: finance manager
Task: review Alex Morgan's $2,480 Atlas Cloud expense
Problem: cost center is missing
Show: receipt, recent spending, reason for review
Action: request the cost center from Alex
After the action: Waiting for employee
Also show: the request in activity and the updated item in the queue

Now there is something to check besides whether the screen looks nice.

We used Figma to define what Claude should repeat

Kate moved the initial UI into Figma and worked through its foundations, components, and larger screen patterns. Then changed the default indigo/purple direction to blue, adjusted the header and branding, and organized the components so we could use them across the product.

The color change is the most obvious part of the video. The more useful part is deciding what a row, a status, and a review action mean in this product. If Waiting for employee appears in both the queue and the expense detail, we want the label and treatment to agree. If a dashboard card points to Needs attention, it should lead somewhere useful. Claude needs those patterns when it builds the next page.

In Figma, we used variables for repeated values and components for repeated UI. Figma's variables guide explains how values can be applied across a design; aliases let one variable reference another. A token named for its role, such as status/waiting, tells a future implementer more than a blue swatch does. Variants help when a component has predictable states.

We also gave Claude patterns for choosing between tables and cards. A review queue needs dense rows you can scan. An expense detail needs room for the receipt, context, and action. Those are different jobs, even when both screens share the same buttons and statuses.

We didn't resolve every UX question in Figma. We wanted to see what Claude would do once it had a stronger design reference.

Then we sent Claude back to the React prototype

After the Figma pass, we connected the design through MCP and told Claude to use the refined system for the next implementation pass. Otherwise, it could happily keep following its first UI. AI tools can be loyal to an old decision long after you've changed your mind.

Figma's MCP server can provide an agent with design context, including components and variables. Code Connect can map Figma components to their code counterparts. Those references help Claude understand what to build. We still inspected the React screen and clicked through the flow.

For this expense, a blue Request information button would be a very small victory if clicking it left the expense in Needs review. The prototype needed to show the request, change the status, and update the activity. The queue then needed to reflect the new state.

There's a straightforward React point here too. Give the expense one status value such as needs_review or waiting_for_employee; don't maintain several independent booleans that can disagree. The React docs on state structure explain why mutually exclusive states help avoid impossible combinations. A real finance product would need persistence and permission rules around this action. The demo tests the screen flow.

The dashboard gave me another useful surprise

Once the expense flow was in place, we asked Claude for a dashboard for the same finance manager. It brought in a Needs attention area, spending against the monthly budget, categories and merchants, notifications, and recent activity. Those pieces made sense for the product we had described.

One choice still bothered me: recent activity had its own white card and looked too prominent. It was getting prime dashboard real estate for telling me what had already happened. We removed that card treatment and put the activity on a quieter gray background. The items needing the manager's decision could take the lead.

That is the part of an AI-generated dashboard we keep checking. The model can assemble all the requested sections. Someone still has to decide what the person should notice first. In this case, a pending expense deserves more attention than a routine activity log.

UITOP's quick check for the next generated page

We would run through the same expense again before asking for five more screens:

Can I spot the missing cost center from the queue?
Does the detail view give me enough context to decide what to do?
When I request information, do I see the new status and an activity entry?
Does the queue show the updated expense when I return?
Does Needs attention on the dashboard take me to the right work?
Did the implementation use the current Figma components and values?

If one of those fails, you have a specific problem to give Claude. “Make the UX better” is a much harder prompt to review.

Questions I've seen developers ask about Figma and AI coding tools

Does my Figma file need auto layout and components before Claude can use it?

Claude can work from a visual reference. A well-structured file gives it more to work with: layout, named components, variants, and variables bound to the elements you care about. Start with one relevant frame and check what appears in code. You still have to describe behavior such as what happens after Request information. A static frame doesn't contain that whole story.

How do I get Claude to use our existing components?

Show it the relevant Figma design and point it to the components in your codebase. Say which existing variants and tokens the screen should use. If you have Code Connect mappings, they can provide a more explicit link. Then inspect what Claude wrote: did it import the existing component, or make a slightly different button that will become everyone's problem next month?

Do I need one huge `design.md` file?

I prefer a short product context, a place to find the design-system rules, and a task brief for the current flow. Claude should be able to find the role, the current components, and what changes after a click. There's no magic file count. In the video, the finance scenario and the refined Figma system did more work than a long list of generic design adjectives.

Will MCP keep Figma and React in sync for me?

It gives the agent access to Figma context. You still need to ask for the code change and review the rendered screen. I explicitly told Claude that the refined Figma work was the current design reference before it continued the React prototype. MCP doesn't know whether Alex's expense changed status just because the component looks right.

How do you test a coded prototype before putting it in front of users?

Click through a real task. In this demo, I can request Alex's missing cost center and check the status, queue, and activity. That catches broken connections between screens. It doesn't tell me whether finance managers understand the flow; for that, I'd ask people who do the job to try it and watch what happens. The video shows the first kind of check.

How do you keep Claude consistent as it generates more screens?

Give it the current components and a bounded task. Review the new page against existing screens, including states and behavior. A waiting expense should use the same status language in the inbox and detail view. Check the implementation for one-off colors or duplicate components too. Figma's MCP tools can supply design context; the screen still needs your review.

You can watch the full Claude, Figma, and React walkthrough here, including the initial inbox, the design-system pass, the expense request, and the dashboard change. At UITOP, this is the kind of B2B SaaS work we spend time on: what a screen needs to show, what changes when someone takes an action, and whether the next screen still makes sense.

How to Structure a B2B SaaS Frontend Around Changing Operational Data

Oleksandr Sainchuk — Thu, 15 Oct 2026 05:15:19 +0000

Imagine you're working in a logistics dashboard. You filter shipments to see everything that's delayed. You open one record, check its ETA, and start investigating the problem.

Meanwhile, new shipment information arrives from the server. One shipment changes status. Another gets a new ETA. A background request finishes just after you've changed your filters.

What should the interface do?

If every update replaces the entire screen state, users can lose their place. If the application keeps showing old records, the interface becomes unreliable.

We worked with this type of operational data while designing and developing LogiCore, a logistics and warehouse SaaS application at UITOP.

The product connects shipment monitoring, warehouse locations, inventory records, and operational metrics. Its frontend uses React, TypeScript, and Zustand, with data served through REST APIs backed by Node.js, Express, PostgreSQL, and Prisma.

For shipment monitoring, our team used Zustand-managed polling to retrieve updated status, ETA, and timestamp information. That project gives us a useful starting point for a broader engineering question:

How should a React application manage user interactions and changing server data at the same time?

Start by separating three kinds of state

A common source of frontend bugs is treating every piece of information on a screen as one large object.

Consider a shipment monitoring page. It may contain:

Current shipment records and their statuses
Active filters and pagination
The shipment the user has selected
Loading and refresh indicators
Errors from API requests
A timestamp showing when the data was updated

These values have different responsibilities. I find it useful to separate them into three groups.

Server data

This represents information the application receives from its backend.

Shipment ID
Current shipment status
ETA
Last carrier update
Total number of records matching a query

The backend determines the current business state. The frontend presents a snapshot of that information.

User interface state

This represents the user's current interaction with the page.

Active status filter
Current page
Selected shipment ID
Expanded details
Open dialogs

A background data refresh generally should not reset these choices.

Request state

This describes what's happening while the application communicates with the server.

Initial loading
Background refresh in progress
Last successful response
Request failure
Data that may be stale

This third group matters because a screen can have valid data and an active request at the same time. A user should still be able to inspect the current results while the application retrieves newer information.

Make the user's current view explicit

Suppose a shipment table supports two filters: All and Delayed. The user can also navigate between pages and select a shipment. Those interactions can be represented independently from the returned shipment records.

Zustand example:

import { create } from "zustand";

type StatusFilter = "all" | "delayed";

type ShipmentViewState = {
  status: StatusFilter;
  page: number;
  selectedShipmentId: string | null;

  setStatus: (status: StatusFilter) => void;
  setPage: (page: number) => void;
  selectShipment: (id: string | null) => void;
};

export const useShipmentView =
  create<ShipmentViewState>((set) => ({
    status: "all",
    page: 1,
    selectedShipmentId: null,

    setStatus: (status) =>
      set({
        status,
        page: 1,
        selectedShipmentId: null,
      }),

    setPage: (page) => set({ page }),

    selectShipment: (id) =>
      set({ selectedShipmentId: id }),
  }));

Changing the status filter resets pagination to page 1. The previous page might not exist in the filtered result.

Selection is stored by shipment ID. If shipment records are refreshed, the application can still identify the selected item. The selected object doesn't need to be stored as a separate copy of the entire record.

Whether selection should be cleared when filters change depends on the workflow. In this example, we clear it explicitly. In other products, keeping the detail view open may be preferable.

The important part is making that behavior intentional.

Keep polling separate from table interactions

In LogiCore, shipment status and ETA information are refreshed through background requests to the REST API.

Polling is a reasonable approach when the application needs periodic updates and the source data doesn't require a continuous streaming connection. The challenge is managing those requests as the user changes the current view.

A naive implementation might look like this:

setInterval(async () => {
  const response = await fetch("/api/shipments");
  const data = await response.json();

  setShipments(data);
}, 15000);

It doesn't account for current filters or pagination. It has no error handling. Requests can overlap if one response takes longer than the interval.

It also doesn't address what happens when the component unmounts or the user switches to a different query. A more reliable implementation gives the polling process a clear lifecycle.

React polling example

import { useEffect, useState } from "react";

type Shipment = {
  id: string;
  status: string;
  eta: string | null;
};

type ShipmentPage = {
  items: Shipment[];
  total: number;
  updatedAt: string | null;
};

type FeedState = {
  key: string;
  data: ShipmentPage | null;
  syncing: boolean;
  error: string | null;
};

export function useShipmentFeed(
  status: string,
  page: number
) {
  const key = `${status}:${page}`;

  const [feed, setFeed] = useState<FeedState>({
    key,
    data: null,
    syncing: true,
    error: null,
  });

  useEffect(() => {
    const controller = new AbortController();
    let active = true;
    let timer: ReturnType<typeof setTimeout>;

    setFeed({
      key,
      data: null,
      syncing: true,
      error: null,
    });

    async function refresh() {
      if (!active) return;

      setFeed((previous) =>
        previous.key === key
          ? { ...previous, syncing: true }
          : previous
      );

      try {
        const params = new URLSearchParams({
          status,
          page: String(page),
        });

        const response = await fetch(
          `/api/shipments?${params}`,
          { signal: controller.signal }
        );

        if (!response.ok) {
          throw new Error(`HTTP ${response.status}`);
        }

        const data =
          (await response.json()) as ShipmentPage;

        if (active) {
          setFeed({
            key,
            data,
            syncing: false,
            error: null,
          });
        }
      } catch (error) {
        if (active && !controller.signal.aborted) {
          setFeed((previous) =>
            previous.key === key
              ? {
                  ...previous,
                  syncing: false,
                  error: "Could not refresh shipments",
                }
              : previous
          );
        }
      } finally {
        if (active) {
          timer = setTimeout(refresh, 15000);
        }
      }
    }

    void refresh();

    return () => {
      active = false;
      controller.abort();
      clearTimeout(timer);
    };
  }, [key, status, page]);

  return feed.key === key
    ? feed
    : {
        key,
        data: null,
        syncing: true,
        error: null,
      };
}

The endpoint, response shape, and 15-second interval are illustrative.

Several common problems here:

Requests follow the active query

The effect depends on the current filter and page. When either changes, React cleans up the previous effect and starts a new request process for the new query.

Old requests cannot update the new view

The cleanup aborts the previous fetch. The active check also prevents a response from updating component state after its effect has been cleaned up. That matters because network requests do not necessarily finish in the order they started. Imagine the user selects Delayed and immediately switches back to All.

The Delayed request may finish last. Its response should not replace the current All result.

Polling requests don't overlap

The next timer is scheduled after the current request settles. That prevents this particular polling loop from starting another request while its previous request is still pending. In a production application, I would also consider an upper limit on request duration.

Existing results remain available during a refresh

After the initial load succeeds, setting syncing to true doesn't clear the current response. The interface can continue showing its most recent results while the next request is in progress. This makes a useful distinction between initial loading and refreshing existing data.

For a real application, I would also consider request deduplication, visibility-aware polling, authentication expiration, retry backoff, and how multiple components share the same data. A dedicated server-state library may be appropriate when those responsibilities grow.

Give every refresh a predictable UI behavior

Fetching current data is only half the implementation. The frontend also needs rules for presenting that data. Consider a shipment with this information:

If the user is looking at that shipment, the interface should present the newer information in the relevant record. But the application must also decide what happens if the new status changes which rows match the active filter.

Suppose the current view shows only In transit shipments. After a refresh, a shipment becomes Delayed.

Should it disappear immediately?

There isn't one correct answer for every operational product. Immediate removal maintains strict consistency with the filter. It can also make a row disappear while someone is examining it.

An alternative interaction is to retain the currently displayed set temporarily and indicate that newer results are available.

The appropriate behavior depends on the task. For a monitoring dashboard, timely changes may take priority. For a table where operators select records and perform multi-step actions, preserving working context may be more important. This is a product decision that frontend and UX teams should agree on before implementation.

Treat timestamps as part of data reliability

A label such as "Last updated" sounds simple, but developers need to agree on what it represents.

When the external carrier produced the information
When the backend received the update
When the API response was generated
When the frontend successfully fetched the response

These times can differ. A successful API request at 12:30 doesn't prove that the carrier supplied new data at 12:30.

In LogiCore, shipment monitoring includes status information, ETA drift indicators, and last-update timestamps associated with refreshed carrier data.

For similar systems, I would make timestamp ownership explicit in the API contract. The response might distinguish:

{
  "shipmentId": "SHP-2048",
  "status": "delayed",
  "eta": "2026-10-23T16:10:00Z",
  "carrierUpdatedAt": "2026-10-23T12:24:00Z",
  "fetchedAt": "2026-10-23T12:30:00Z"
}

It can show when the shipment information last changed and separately track when the application last synchronized.

This distinction becomes useful during outages, integration delays, and incidents where a user needs to know how current the information actually is.

A failed refresh should be visible

Imagine a dispatcher reviewing 40 shipments. The page initially loads correctly. Five minutes later, the network becomes unstable and the background refresh fails.

Should the table disappear?

Usually, the application still has a previously successful response that the user can inspect. The interface can preserve those records and show that the latest refresh failed. A useful set of UI states will include:

An expired session needs special handling. The product should not keep issuing the same unauthorized request every few seconds. If the request fails repeatedly, retry logic may need an increasing delay.

These are recommended patterns for operational software. Their exact implementation should follow the application's security requirements and data sensitivity.

Don't let background updates interrupt active work

There is another problem that appears when a product moves beyond read-only dashboards.

Suppose a user is editing the assigned carrier or reviewing a shipment exception while new information arrives from the backend. A refresh that blindly replaces an entire local object can overwrite in-progress changes.

For editable records, I would define which fields belong to the current server snapshot and which fields belong to an active local operation. The application also needs a policy for conflicts.

Has the record changed since the user opened it?
Is the user editing the same field that changed on the server?
Can the operation be submitted against the newer record version?
Does the user need to review the difference before continuing?

Depending on the product, that may require version fields, conditional updates, or a conflict-resolution interaction.

These decisions are especially important in ERP, CRM, warehouse management, and other B2B applications where multiple users work with related records. This is a general implementation consideration, not a claim about a specific LogiCore editing workflow.

What I would test before release

For a React interface with changing operational data, I would test scenarios beyond the happy path.

Rapid filter changes. Switch between filters while requests are pending. Confirm that the UI displays the result for the current query.

Slow responses. Simulate a request taking longer than the normal refresh interval.

Unmounting. Navigate away while a request is pending. Confirm that the polling process stops.

Repeated failures. Simulate network errors and authentication expiration. Check what remains visible and how the interface recovers.

Changing records. Update a shipment while a user is reviewing its details. Confirm that selection and navigation behave as intended.

Inactive tabs. Check whether background polling continues unnecessarily when the page isn't being used.

Different refresh speeds. Evaluate whether status changes appear frequently enough for the operational requirements and whether polling creates unnecessary backend traffic.

I would also review accessibility: refresh indicators should communicate meaningful changes, and frequent updates should not continuously interrupt screen-reader users.

What LogiCore taught us about operational frontend architecture

UITOP designed and developed LogiCore as one application connecting shipment monitoring, warehouse structures, inventory, and operational data.

The shipment interface uses React and TypeScript, with TanStack Table for table behavior and Zustand-managed polling for refreshed shipment information.

The backend uses Node.js, Express, PostgreSQL, Prisma, and REST APIs.

Those implementation decisions illustrate an important relationship between the frontend and its data sources. Users control filters, pagination, and navigation. The backend supplies current operational records. The request lifecycle determines when newer data reaches the interface.

A frontend architecture needs to manage those responsibilities consistently as the product grows. If I were reviewing an existing B2B SaaS product today, I would start with one practical scenario:

What happens when the user changes a filter at the same moment a background request returns newer data?
The answer reveals a lot about the quality of the application's state management, request handling, and user experience.

If you read this, read also about the project and the team

LogiCore is a logistics and warehouse SaaS designed and developed by UITOP, a product design and software development team specializing in complex B2B applications.

The project covered product design, frontend and backend development, database architecture, API development, and QA.

Read the LogiCore case study.

Building a shipment table for thousands of live records. What I learned on LogiCore?

Oleksandr Sainchuk — Tue, 13 Oct 2026 15:30:58 +0000

A shipment table seems easy, a few columns, some filters, a status badge. Then real data shows up...

THOUSANDS of shipments, statuses that change all day, and operators who need to find the one late truck fast.

A table that feels fine with 50 test rows can crawl with 5,000.

I ran into this on LogiCore, a logistics and warehouse management platform UITOP designed and built from scratch, for a UK logistics company. The client ran a multi-million dollar business across three or four separate tools. Data didn’t match between them, updates came late, and managers made big calls without the full picture. They wanted one system for the warehouse floor and the office.

Our design, project management, development and QA teams worked on it together. Here’s how we built the shipment table, and why we made each choice.

What the table had to do

Operators used the table to find shipments and spot the ones that need attention. And they did it while statuses and ETAs kept changing.

The frontend runs on React, TypeScript and Vite, with TanStack Table (React Table v8), Zustand and Tailwind CSS. The backend uses Node.js, Express, PostgreSQL and Prisma ORM behind a REST API.

We had three separate problems to solve:

too much data to load,
too many rows to draw,
data that goes stale while the page is open.

Problem 1: the browser doesn’t need every shipment

Why load thousands of records when the operator looks at one screen at a time? Loading everything makes the first view slow and wastes memory.

So we used server-side pagination. The frontend asks the API for one page. PostgreSQL runs the query with the active filters and returns only that page.

Details matter more than they look:

Reset the page when a filter changes. If someone sits on page 12 and the new filter returns three pages, they should land on page 1, not on an empty screen.
Keep sorting stable. Records change all day, so the API needs a fixed order. Otherwise rows jump between pages and people lose their place.

Problem 2: one page can still be heavy

Pagination cuts how much data comes back. It doesn’t cut how much the browser has to draw. Each shipment row carries a status badge, an ETA drift indicator and a “Last Updated” timestamp. Draw hundreds of those at once, and React has a lot of work to do.

So we added row virtualization on top. The table only mounts the rows on screen, plus a small buffer for scrolling. TanStack Table handles the table logic, and the virtualization layer decides which rows exist in the DOM right now.

The two techniques solve different problems:

Server-side pagination controls how much data travels from the database to the browser.
Virtualization controls how much the browser renders.

So you test both: API response times and rendering.

Problem 3: the data changes while someone is looking at it

A shipment moves to a new status. An ETA slips. A carrier sends an update. If the screen shows old data, the operator decides based on a stale picture, and that’s the problem LogiCore was built to fix.

We handled this with background polling. A Zustand store fetches fresh data from the REST API on a schedule, and the badges, ETA drift indicators and timestamps update from it. “Last Updated” shows the latest carrier update, not a cached value.

The tricky part here is UX. If a badge changes while someone reads the list, the table shouldn’t reset their filters or scroll position. Polling also raises its own questions: how often to refresh, what to do with failed requests, and whether to keep polling when nobody is at the screen.

Polling fit LogiCore’s update rhythm. A product that needs second-by-second updates might be better off with WebSockets or server-sent events.

The backend decides how fast the table feels

A slow query makes even a well-tuned React table feel broken. So a lot of the speed work happened below the UI.

On the inventory screen, a multi-location SKU expands with a scoped REST call that fetches only that item’s child records. The first load stays at 100 rows, no matter how deep the data goes. The warehouse location tree loads the same way, one level at a time, from facility down to shelf.

Filters by client, warehouse or SKU run through Prisma’s dynamic where clauses. That way we avoid raw SQL and still support any filter combination. For the KPI cards, PostgreSQL window functions calculate week-over-week changes inside the database, and the frontend just shows the result.

Design and performance are one conversation

More columns don’t make a table more useful. They make it harder to scan. We gave status and timing a fixed place in each row, because that’s what operators check first.

Every design choice here has a frontend cost. Columns decide how heavy each cell is. Filters decide what the API has to query. And the design system needs states for loading and errors, not only the happy path.

What came out of it

Before launch, our QA team ran stress tests under heavy load, and the platform held at 100% stability. The office and the warehouse now work from the same live data. Managers see transit delays and stock shortages as they happen, so they fix problems before those cost money. Daily shipping decisions got 2x faster.

Where to start with your own table

If you’re building a B2B SaaS product with big tables, start with three questions. How much data does the screen request? How much does it render? What happens when the records change? The answers usually point to the next engineering decision.

FAQ

How do you make a React table fast with thousands of records?
Combine server-side pagination with row virtualization. Pagination limits what the API sends, and virtualization limits what the browser draws. On LogiCore, we used both with TanStack Table.

Should a logistics dashboard use polling or WebSockets?
It depends on how fast the data changes. Polling worked for LogiCore’s shipment statuses and ETAs. If operators need second-by-second updates, WebSockets or server-sent events fit better.

What should I look for in a team building custom warehouse management software?
Look for a team that covers design, backend and QA together, because table speed depends on the database as much as on the UI. UITOP built LogiCore that way, and the platform held 100% stability under peak-load stress tests.

About the project

LogiCore is a logistics and warehouse management platform designed and built by UITOP, a product design and development studio for complex B2B software.

Case study: https://uitop.design/case-studies/logicore/