Cycle World
Web Development Client ProjectA Catalogue That Needs to Rank, and Load Instantly
A headless e-commerce storefront for a real bike dealership, built to load fast, rank well in search, and stay simple to manage on the backend, using server rendering and row-level security instead of a heavier off-the-shelf platform.
01
Problem
What problem were you solving?
A product catalogue needs to be both discoverable and fast: search engines need to crawl it properly, and shoppers need pages to load before they lose patience. Client-rendered storefronts tend to struggle at one or the other.
02
Solution
What did you build?
A server-rendered Next.js storefront backed by Supabase, so pages arrive fully formed for both crawlers and users, while row-level security keeps data access rules close to the data itself.
03
Key Features
Server-side rendering
Sub-second time-to-first-byte on catalogue pages.
SEO-first routing
Rendering architecture built around crawlability.
Row-level security
Access rules enforced at the database layer.
Realtime & edge delivery
Live data over an edge-cached delivery layer.
04
Architecture
How does it work?
Row-level security is enforced as the default posture, not layered on afterward: access rules live with the data instead of scattered across application code.
05
Tech Stack & Tools
| Layer | Tools |
|---|---|
| Frontend | Next.js, server-rendered routing |
| Backend | Supabase, PostgreSQL, Row-Level Security |
| Realtime | Supabase Realtime subscriptions |
| Delivery | Vercel, edge caching |
06
Technical Decisions
Why these technologies?
Why Next.js?
Server-side rendering gets crawlable, fast-loading pages without hand-rolling a rendering pipeline.
Why Supabase?
Postgres, auth, and realtime in one place, with row-level security as a first-class primitive rather than an add-on.
Why RLS by default?
Putting access control at the database layer means every client, present or future, inherits the same guarantees.
Why Vercel + edge caching?
Pairs naturally with Next.js and keeps static and cacheable content close to the user without extra infrastructure.
07
Results
SEO shaped the architecture from the start, not just the copy: the rendering strategy was chosen specifically so the catalogue would be crawlable and fast at the same time.
08
Challenges
What difficulties did you face?
- Balancing SSR freshness against edge-cache hit rate
- Designing RLS policies that stayed correct as the schema grew
- Keeping realtime updates consistent with cached pages
09
Limitations
What could be better
- No offline or degraded-network fallback yet
- Search is catalogue-field based, not full-text
- Admin tooling is minimal beyond Supabase's own dashboard
10
What I Learned
- SEO shapes the architecture, not just the copy
- RLS as the default, not an add-on
- Edge caching and realtime can coexist
11
Future Improvements
- Full-text search across the catalogue
- A lightweight internal admin dashboard
- Image optimization pipeline for product photos