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