DEPLOYMENTS / POCENI STROJI
CATALOG + CMSPoceni Stroji
An outlet appliance catalog rebuilt from a legacy Prisma + SQLite + custom-admin stack to Sanity CMS. The client edits everything themselves in an embedded studio; the site revalidates itself through webhooks within seconds. Zero databases to maintain, zero admin panels to patch, and a verify pipeline gates every deploy.
CLIENT
Appliance outlet
YEAR
2026
SYSTEMS
WEB
STATUS
DEPLOYED
60
s worst-case content refresh (ISR fallback)
0
databases left to maintain
100%
content editable by the client
[ THE BRIEF ]
The challenge we walked into.
The old build ran on Prisma with a local SQLite file and disk-stored images — an architecture that couldn't survive on serverless hosting. Editors couldn't restructure categories, images had to be moved manually, and the admin panel was fragile enough that developer help was needed for basic content changes. The client wanted a modern serverless target without giving up self-service editing.
[ TOPOLOGY ]
How the system is wired.
// SYSTEM TOPOLOGY
- LAYER 01
Editor
IN /studio
Visitor
PUBLIC
- LAYER 02
Next.js 15
SSG + ISR
- LAYER 03
Sanity
CONTENT LAKE
Sanity CDN
IMAGE PIPE
- LAYER 04
Sanity Webhook
SIGNED
/api/revalidate
ROUTE-SCOPED
- LAYER 05
/api/stroji/iskanje
SEARCH JSON
[ WHAT WE SHIPPED ]
Feature by feature.
Sanity Studio ships with the site itself.
The Studio lives at /studio inside the same Next.js app. Owner logs in there, edits categories, machines, prices and photos — no external tool, no separate deploy. Editor roles are invite-based and configurable from Sanity's dashboard.
- ▸/studio embedded in the site
- ▸Invite-based editors
- ▸Category restructuring — new capability
- ▸No separate CMS to deploy
[ APPROACH ]
How it came together.
01 — KILL THE FRAGILE ADMIN
Every custom admin ages badly. Sanity does the heavy lifting.
Rather than patch the legacy admin, we deleted it. Sanity provides the CMS surface, the auth, the image pipeline, and the roles. What used to be a maintenance burden became a shrink-wrapped dependency the client can operate themselves — with capabilities (category restructuring, drag-drop image ordering) the old admin never had.
02 — STATICALLY FAST, LIVE CONTENT
The site is pre-rendered — until Sanity says otherwise.
Pages render as static HTML at build time. When content changes, Sanity's webhook triggers on-demand revalidation for just the affected route. Visitors get static-file speed with CMS-driven content — the best of both worlds. A 60-second ISR fallback covers the rare case where the webhook is delayed.
03 — GROQ COLOCATED WITH THE ROUTE
One page, one query, one type.
Every page owns its own GROQ query in a small queries.ts file. next-sanity turns the GROQ into typed results, and the component consumes exactly the shape it declared. No over-fetching, no shared 'god query', no drift between what Sanity returns and what the UI expects.
04 — THE VERIFY PIPELINE
Green verify or the deploy doesn't happen.
npm run verify is the contract. It runs on every push and locally before every merge. When it's green, deploy is safe; when it's red, the failure is loud and specific. The smoke test in particular catches production-only bugs (missing env vars, misconfigured routes) that unit tests can't.
[ DELIVERY ]
What the build looked like.
01 ▊
[ TECH STACK ]
What’s under the hood.
TAP FOR ROLEHOVER FOR ROLE
[ IMPACT ]
What changed.
The client can now do everything the developer used to do — restructure categories, add products, swap images, rewrite metadata. The site is faster than before (static + ISR + Sanity's CDN), the SQLite baggage is gone, and there is no more 'ask us to change the price' friction. Content operations became self-service, and the verify pipeline means the developer never breaks the site trying to help.