How We Built a Multilingual Crypto Arbitrage Monitoring Platform with Next.js

Exarbi — Fri, 17 Jul 2026 20:50:42 +0000

Building a crypto product is not only about collecting price data.

Once we started working on Exarbi, we quickly realized that a visible price difference between two exchanges does not automatically mean there is a usable arbitrage opportunity.

Transfer networks, deposit and withdrawal availability, data freshness, fees, liquidity, and authentication architecture all affect the final product.

This post explains some of the technical decisions behind Exarbi, a multilingual crypto arbitrage monitoring platform built with Next.js.

What Exarbi does

Exarbi helps users compare price differences across centralized crypto exchanges and review operational signals that may affect an opportunity.

The platform brings together:

Cross-exchange price differences
Deposit and withdrawal availability
Network compatibility
Transfer-readiness signals
Data freshness
Risk indicators
Exchange filtering
Telegram alerts

Exarbi is a monitoring and decision-support platform.

It does not:

Request exchange API keys
Execute trades on behalf of users
Hold user funds
Act as an automated trading bot

Users remain responsible for reviewing the data and making their own trading decisions.

Why we chose Next.js App Router

Exarbi uses Next.js with the App Router and TypeScript.

The application contains two distinct areas:

Public marketing and educational pages
Authenticated application routes

The public side includes landing pages, pricing, exchange coverage, legal pages, and a multilingual blog.

The authenticated side includes dashboards, alerts, market scanning, exchange data, and account features.

Keeping these areas separate became important for both performance and SEO.

Public pages should produce complete server-rendered HTML, while private application routes should never appear as indexable pages to search-engine crawlers.

Separating public and protected routes

One issue we found during technical SEO testing was that an unauthenticated request to /dashboard could return an HTTP 200 response before a client-side redirect moved the visitor to the login page.

For users, the behavior looked correct.

For crawlers, however, the protected route could look like a real page.

We moved the authoritative authentication check to the server layout layer. Protected routes now verify the session before rendering.

The resulting behavior is:

Authenticated users receive the protected page
Unauthenticated users receive a real HTTP redirect
Client-side session monitoring remains only as a fallback

This avoids exposing private application shells to crawlers and reduces unnecessary dashboard JavaScript for unauthenticated visitors.

Supporting eight languages

Exarbi currently supports:

Turkish
English
German
French
Russian
Arabic
Japanese
Chinese

Multilingual SEO requires more than translating visible text.

For every indexable public page, we need to consider:

Locale-aware canonical URLs
Reciprocal hreflang links
x-default
Localized titles and descriptions
Translated route slugs
Sitemap consistency
Arabic right-to-left layout
Japanese and Chinese text segmentation

Private and authentication pages follow a different policy.

Login, registration, password reset, verification, account, and dashboard pages are marked as noindex. They do not publish canonical or hreflang clusters because they are not intended to appear in search results.

Avoiding misleading arbitrage signals

A raw spread is not enough to describe a practical arbitrage opportunity.

For example, two exchanges may show different prices while:

Withdrawals are suspended
The token uses different contract addresses
The required network is unavailable
Liquidity is too low
Fees remove the apparent profit
The price data is stale
The spread disappears before a transfer completes

This is why the product UI focuses on context in addition to price differences.

The objective is not to label every spread as profitable. It is to make the conditions behind the spread easier to inspect.

Reducing unnecessary client-side JavaScript

Another challenge was the amount of shared JavaScript loaded by public routes.

Our public layout originally handled several responsibilities inside one large client component:

Authentication state
Mobile navigation
Language selection
Logout dialogs
Header state
Footer rendering

This meant mostly static public pages inherited a larger hydration boundary than necessary.

We are moving toward a server-shell and client-island architecture.

The server renders:

Navigation structure
Logo and branding
Footer content
Legal links
Product links
Static calls to action

Small client components handle only the interactive parts:

Authentication controls
Language menu
Mobile drawer
Logout dialog
Live homepage data

The goal is not to force the number of JavaScript files down. Next.js naturally generates multiple cacheable chunks.

The useful metrics are:

Total transferred JavaScript
Hydration scope
Parse and execution time
Unused JavaScript
Total Blocking Time
Interaction latency

One large bundle is not automatically better than several small, cacheable chunks.

Consent-aware third-party scripts

Exarbi uses services such as analytics, customer support, payments, and transactional email.

Third-party scripts need to be treated carefully because they can affect both performance and privacy.

Our general approach is:

Do not load analytics before the required consent
Load support tooling lazily
Avoid loading Stripe JavaScript on pages that do not need checkout
Keep server-side email services out of the browser bundle
Prevent duplicate script initialization during client navigation

This work is incremental because aggressive script restrictions can easily break login, payment, analytics, or support flows.

Technical SEO as an engineering problem

Many SEO issues in modern web applications are architecture issues rather than copywriting issues.

Some examples we encountered include:

Client-side redirects returning HTTP 200
Private routes receiving public internal links
noindex pages inheriting hreflang metadata
Query-based category pages creating crawl noise
Shared client layouts increasing public JavaScript
Sitemap URLs not matching live canonical behavior

Tools such as Screaming Frog and Seobility helped identify symptoms, but every warning still required inspection.

For example, multiple JavaScript chunks are normal in Next.js. Repeated footer text is also normal. A short contact page is not automatically thin content.

The important step is finding the component or routing behavior behind the warning before changing the site.

What we learned

The most important lesson has been that market data, application architecture, performance, and SEO cannot be treated as isolated systems.

A decision in one layer often affects several others.

Moving authentication checks to the server improved:

Security boundaries
Crawl behavior
Redirect semantics
Public bundle isolation

Splitting public components into server and client boundaries improves:

Initial JavaScript transfer
Hydration cost
Cache behavior
Maintainability

Adding transfer and risk context improves:

Product clarity
User decision-making
The accuracy of product positioning

We are continuing to improve Exarbi gradually, measuring each architectural change before moving to the next one.

You can see the public product here:

You can explore the public product at Exarbi.

DEV Community: Exarbi