DEV Community: Oleksandr Sainchuk

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

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

Claude gave me a tidy expense inbox. It had a table, statuses, buttons, and all the other signs of a functioning SaaS product. Then I 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. I wanted to see what would happen if I 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?

I recorded the full experiment on YouTube. I 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.

I started by telling Claude who would use the product: a finance manager reviewing employee expenses. I 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.

I 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.

I used Figma to define what Claude should repeat

I moved the initial UI into Figma and worked through its foundations, components, and larger screen patterns. I changed the default indigo/purple direction to blue, adjusted the header and branding, and organized the components so I 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, I 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, I 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.

I 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.

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

Then I sent Claude back to the React prototype

After the Figma pass, I 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. I 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, I 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. I 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 I 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.

My quick check for the next generated page

I 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, I 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/