https://unsplash.com/photos/a-stack-of-colorful-cups-sitting-on-top-of-each-other-BnzqQwerUOY

The Stack

This is a breakdown of how Logier is actually built across the desktop app and the website.

The Technology Behind Logier

I posted a tutorial on this topic on Medium.

Logier is split into two main systems:

• —A desktop application that processes logs locally and needs to be fast.
• —A web platform that handles authentication, billing, onboarding, and content.

They share no runtime and solve completely different problems.

Website (Next.js stack)#

The website uses a standard server-rendered React setup built with Next.js.

The reason for choosing Next.js is not because of SSR hype, but because it solves practical problems:

• —Routing and API routes in one place
• —Simple deployment through Vercel
• —Good integration with authentication and billing flows

The UI is built with Tailwind and shadcn/ui.

This combination is mostly about one thing: moving fast.

Data & Backend#

The backend layer is intentionally minimal.

Supabase handles:

• —Database
• —Authentication
• —User sessions and identity

The reasoning is simple: authentication is already a solved problem. Building it from scratch would only introduce more complexity and more possible failure points.

Payments#

Stripe handles subscriptions and billing.

It is one of the most established payment platforms available, with excellent documentation and a reliable checkout experience.

Email#

Resend is used for transactional emails.

It acts purely as an email delivery layer, avoiding the limitations and costs associated with sending emails directly through Supabase.

Edge, Protection & Infrastructure#

The web platform uses a few external services to keep infrastructure simple:

• —Cloudflare Turnstile for bot protection on public forms
• —Vercel for deployment

The goal is simple: reduce operational overhead. No self-managed servers for the web layer.

Content & Product Tooling#

Some services are not part of the core architecture, but they support the product development loop:

• —Sanity for CMS content such as news and documentation
• —Ahrefs for SEO tracking and analysis

These tools do not power Logier directly, but they help shape how the product evolves.

Desktop App (Electron stack)

The desktop application is where the actual log processing happens.

It is built with:

• —Electron for the cross-platform desktop runtime
• —Electron Forge for packaging and tooling
• —Vite + React for the renderer
• —Tailwind for styling

Electron was chosen because Logier needs:

• —Full file system access
• —Local log processing
• —No dependency on cloud ingestion

Your logs stay on your machine and are processed locally.

Rendering & Performance#

Logs become large very quickly, so performance is a major consideration.

The UI relies on:

• —react-window for virtualized rendering of log lines
• —recharts for visualizing patterns such as errors, spikes, and anomalies

Without virtualization, large log files would quickly become unusable.

State & Navigation#

The application uses:

• —zustand for state management
• —react-router-dom for internal navigation

There is no Redux-style architecture. The application state is mostly temporary — open files, filters, selections, and analysis state — so a lightweight store is enough.

Even though Logier is a desktop application, routing is still useful for separating different views and workflows.

Shared Parsing Logic#

The core parsing layer of Logier is intentionally isolated from the UI.

This shared logic powers the main behavior of the application and can evolve independently from both the desktop app and the web platform.

This is also the foundation behind the open-source parsing packages.

External Services

These are the production services Logier relies on:

• —Supabase → backend and authentication
• —Stripe → payments
• —Resend → transactional emails
• —Vercel → hosting
• —Cloudflare → edge protection
• —Flagsmith → feature flags
• —Sanity → CMS
• —Ahrefs → SEO analysis

None of these services are deeply tied into Logier’s core logic.

They exist to avoid building infrastructure that is not part of Logier’s actual problem domain.

What the stack is optimized for

The stack is optimized for:

• —Low cognitive overhead
• —Fast local iteration
• —Minimal backend complexity
• —Predictable external services
• —No custom infrastructure unless absolutely necessary

Most decisions follow one simple rule:

If it does not help interpret logs faster, it should stay simple or be handled externally.