Paradigma Client/Server anche per sviluppare applicazioni "semplici"? Perchè no?

Oggi ho iniziato a sviluppare una piccola applicazione - rigorosamente con Rails -  ad uso interno.

Nulla di complicato, anzi tutt'altro, ma mi sono chiesto se la sua semplicità fosse un buon motivo per non svilupparla "bene", ovvero per non dividere i livelli di logica di business e di presentazione.

Non è che le cose piccole siano per definizioni da fare male, anzi .... la semplicità (così ci insegna la UX) spesso è figlia di molto lavoro ed esperienza.

Veniamo quindi alla nostra applicazione.

Le funzioni richieste sono basilari, e dopo una prima fase di analisi sono riassumibili in:
- deve prevedere accessi profilati ed autenticati
- deve permettere la gestione di settings
- deve permettere la il caricamento di documenti con alcuni metadati (legati agli utenti ed ai setting)
- deve inviare delle notifiche a fronte del caricamento
- deve tracciare le azioni eseguite sul documento

Abbiamo quindi il modello principale DOCUMENT a cui sono funzionali il modello USER ed il modello SETTING

La prima applicazione gestirà la logica di business e le funzioni backend del sistema e sarà interrogabile solo tramite WebService

La seconda applicazione - che potrà anche essere client javascript - consumerà tali servizi e fornirà la User Interface all'utente, definendo la logica di presentazione

I vantaggi - a parte quelli puramente "accademici" - sono molteplici:

1) Possiamo demandare ad un'altro gruppo / persona lo sviluppo dell'interfaccia
2) Possiamo scrivere differenti interfacce per differenti device. Quindi realizzare da un client locale, compilato per la singola piattaforma, ad una webapp, ad un sito mobile
3) Il gruppo che si occupa delle interfacce utente NON POTRA' in alcun modo interferire con la logica di business
4) Nessun codice sarà condiviso tra i due gruppi e pertanto sarà effettivamente possibile DIMEZZARE i tempi di sviluppo (lo so non è vero.. ma passatemi la licenza), a patto di definire bene la struttura dei messaggi

Svantaggi:

1) senza una suite di test chi sviluppa il backend lavorerà alla cieca o dovrà fare dello sviluppo "a perdere".
2) senza una formalizzazione dei messaggi chi lavora al frontend sarà costretto a lavorare senza dati in modo statico

A mio parere questi non sono degli svantaggi, ma una evidente forzatura a costringere lo sviluppatore in termini di ciò che può essere TESTATO e non di ciò che può essere VISTO