Caso studio · E-commerce demo
Benidorm: l'e-commerce
che puoi smontare*
* Letteralmente. È una demo pubblica costruita a spese nostre, non il progetto di un cliente pagante: lo diciamo subito, così non lo scopri dopo.
La risposta in 30 secondi
Benidorm è l'e-commerce dimostrativo di Polonord Studio: catalogo, schede prodotto, carrello, checkout e prenotazione appuntamenti, costruito con Next.js e Supabase e pubblicato su benidorm.polonord.studio. Non è il sito di un cliente pagante: è una demo a spese nostre, online perché chiunque possa ispezionarla prima di affidarci un progetto.
Perché costruire un e-commerce che non vende niente?
Ogni agenzia dice di saper fare e-commerce. Quasi nessuna te ne fa toccare uno prima di firmare: vedrai slide, mockup e screenshot scelti con cura. Noi abbiamo preferito l'alternativa scomoda: costruire un negozio online completo e lasciarlo aperto al pubblico.
Benidorm è il risultato: un e-commerce di materassi con meccaniche reali — varianti di misura, carrello, checkout, prenotazione di un appuntamento in showroom — e dati di esempio nei contenuti. Stesso processo, stesso rigore e stesse scelte tecniche che portiamo nei progetti di sviluppo e-commerce per i clienti. Con una differenza: questo lo puoi aprire adesso, senza parlare con nessuno.
Se non hai tempo, leggi solo gli elenchi puntati e le tabelle. Bastano quelli.
I numeri
Un numero vale solo
col metodo accanto.
Metodo: Lighthouse 13.4 su Chrome headless, throttling simulato, misure del 12 giugno 2026 sulla home della demo. La demo è pubblica: puoi rifare il test quando vuoi e confrontare i numeri.
Demo live
Aprila. Provala.
Cerca i difetti.
Niente screenshot ritoccati: la demo è online e si giudica da sola. Tre cose da provare, meglio se dal telefono:
- Apri una scheda prodotto e cambia la misura: prezzi e disponibilità seguono la variante.
- Completa un checkout di prova: i pagamenti sono simulati, ma l'ordine finisce in un database vero.
- Prenota un appuntamento in showroom e guarda come viene gestito il flusso.
Apri la demo live benidorm.polonord.studio
Cosa abbiamo costruito,
esattamente?
Catalogo con varianti
Materassi, reti e guanciali, ognuno con le sue misure. I prodotti senza variante confermata restano visibili ma non acquistabili: niente ordini impossibili.
Carrello e checkout guest
Percorso d'acquisto completo senza registrazione obbligatoria, con pagamenti simulati: carta, PayPal mock e bonifico manuale.
Prenotazione appuntamenti
Chi vuole provare un materasso dal vivo fissa un appuntamento in showroom: la richiesta viene salvata e tracciata su database.
Ordini su database vero
Ogni ordine di prova viene scritto su Postgres via Supabase, con conferma a schermo: persistenza reale, non una finzione in localStorage.
Tutto config-driven
Prezzi, metodi di pagamento, policy, orari e contatti vivono in file di configurazione e seed: cambiare un valore non richiede di toccare il codice.
SEO tecnica predisposta
Dati strutturati e policy in bozza, con un dettaglio onesto: le superfici di produzione restano disattivate finché non ci sono dati legali veri.
Con quale stack?
Ogni scelta ha una riga di motivazione. Se una tecnologia non si lascia spiegare in una frase, di solito è la tecnologia sbagliata.
| Livello | Scelta | Perché |
|---|---|---|
| Framework | Next.js 15 (App Router) + React 19 | Pagine renderizzate sul server: contenuto e dati strutturati nell'HTML, non dietro JavaScript. |
| Linguaggio | TypeScript | Tipi sul dominio — prodotti, varianti, ordini — significano meno bug nei flussi che toccano i soldi. |
| Database | Supabase (Postgres) | Ordini e appuntamenti persistiti davvero su database, non finti nel browser. |
| Configurazione | File JSON + seed | Prezzi, pagamenti, policy e orari vivono nella configurazione, mai dentro il codice. |
| Hosting | Vercel | Deploy continuo dalla storia git, HTTPS e CDN inclusi. |
| Test mobile | Playwright a 375 px | Ogni schermata verificata sul viewport più stretto: zero overflow orizzontale. |
Quanto ci abbiamo messo?
Quattro giorni di lavoro tra l'8 e il 12 giugno 2026, ricostruibili commit per commit dalla storia git del progetto. Il 10 giugno non c'è nessun commit: si lavorava ad altro, e la storia git non si ritocca.
| Giorno | Data | Cosa è successo |
|---|---|---|
| 1 | 8 giugno 2026 | Audit del sito esistente, decisioni di prodotto e wireframe dei flussi d'acquisto. |
| 2 | 9 giugno 2026 | Primo commit: catalogo con varianti, schede prodotto, carrello, pagamenti simulati, database. |
| 3 | 11 giugno 2026 | Immagini di prodotto, navigazione mobile, aggiornamenti di sicurezza del framework. |
| 4 | 12 giugno 2026 | Fix mobile finali, analytics e demo pubblica online. |
Tempi di una demo, non di un progetto cliente: senza contenuti reali, integrazioni di pagamento vere e revisioni condivise. Nei preventivi la timeline è una data scritta, non una stagione.
Performance
Quanto è veloce davvero?
Lighthouse, senza ritocchi.
Punteggi misurati il 12 giugno 2026 sulla home della demo — Lighthouse 13.4, Chrome headless, throttling simulato. Compresa la riga che non ci fa fare bella figura.
| Categoria Lighthouse | Mobile | Desktop |
|---|---|---|
| Performance | 71 | 74 |
| Accessibilità | 100 | 100 |
| Best practice | 100 | 100 |
| SEO | 100 | 100 |
| Metrica (lab) | Mobile | Desktop |
|---|---|---|
| Largest Contentful Paint (LCP) | 27,6 s | 3,9 s |
| Cumulative Layout Shift (CLS) | 0 | 0 |
| Total Blocking Time (TBT) | 70 ms | 0 ms |
| First Contentful Paint (FCP) | 1,9 s | 1,3 s |
| Speed Index | 4,6 s | 1,7 s |
Il numero brutto è la performance mobile: 71, trascinata da un LCP fuori soglia. La causa è nota e documentata: le immagini fotografiche generate per la demo pesano oltre 2 MB l'una e non sono ancora state compresse. In un progetto cliente è il primo intervento in lista — formati moderni, dimensioni esplicite, compressione — e questo report è lo stesso che consegneremmo a te: i difetti si dichiarano, non si ritoccano.
Il resto della pagella regge il confronto: accessibilità, best practice e SEO a 100 su mobile e desktop, CLS a zero — la pagina non salta mentre la leggi — e total blocking time tra 0 e 70 ms. Una seconda run mobile ha dato performance 73 e LCP 20,1 s: la variabilità è normale nei test di laboratorio, la diagnosi non cambia.
La disciplina UX dietro la demo
La parte che non si vede: ogni flusso — dalla scheda prodotto al checkout — è stato prima disegnato a bassa fedeltà, criticato e corretto, e solo dopo implementato. Il viewport di riferimento è 375 px: se una schermata funziona lì, funziona ovunque. Il CLS a zero non è fortuna, è layout progettato perché niente si sposti sotto il dito.
È lo stesso approccio del nostro servizio di UX/UI design: decisioni motivate dai flussi reali degli utenti, non dal gusto del designer di turno.
Cosa questa demo NON è
Un caso studio onesto dichiara anche i confini. Eccoli, senza note a piè di pagina:
- Non è un cliente pagante — nessuno ci ha commissionato Benidorm. L'abbiamo costruito a spese nostre per mostrare il metodo, e lo dichiariamo ovunque.
- I pagamenti sono simulati — carta e PayPal sono mock dichiarati; il checkout di produzione resta disabilitato finché non esistono credenziali e policy legali vere.
- Prezzi e contenuti sono di esempio — dati segnaposto configurati per essere sostituiti da quelli reali in un progetto vero.
- Le immagini non sono ottimizzate — ed è esattamente il motivo del punteggio performance che leggi in questa pagina.
E il tuo e-commerce?
Se questa demo ti sembra un buon biglietto da visita, le strade per lavorare insieme sono due. La prima è lo sviluppo e-commerce a preventivo: perimetro, prezzi e tempi fissati per iscritto prima di iniziare. La seconda è il modello in revenue share: l'e-commerce lo costruiamo a spese nostre — esattamente come abbiamo fatto con Benidorm — e guadagniamo una percentuale solo sulle vendite. In entrambi i casi, quello che hai appena ispezionato è il livello minimo che puoi pretendere da noi.
Pronti a far succedere qualcosa?
Raccontaci il progetto in due righe: ti rispondiamo entro un giorno lavorativo, con prezzi e tempi chiari.