I've both managed and personally built client-side applications, as well as the more standard server-side web apps.
While mature, well-built client-side apps are very attractive in terms of responsiveness and general "sex appeal", if you have an immature product concept, I'd strongly recommend starting with the conventional server-generated pages approach, then once you have a very good idea of how your UI is supposed to function, look at whether it's worth translating into client-side code. Client-side is an architectural labyrinth that you don't need to navigate until you are very clear on how the application delivers value. Server-side, properly optimised, can still deliver excellent UX, through well-understood patterns that are easier to find good technical resources to build. They also tend to deliver much lighter payloads, which is likely to be better in terms of the mobile user experience. Mobile devices have far greater constraints than desktop equivalents for in-browser apps (e.g. RAM).
If you decide to persist with client-side in the short-run, err on the side of paying more, for developers with a lot of experience and some good finished products that they can demonstrate - on both desktop and mobile. Experience counts for a lot in this sphere, because people just haven't been solving problems this way, en masse for very long, compared with server-side. Many of the good client-side guys are to be found in SF, because it's a Mecca for "sexy projects". Good server-side guys are to be found the world over.
In summary: you should pay more for client-side than you would for a good server-side only developer. Standard "supply and demand" economics apply. Choosing client-side is choosing to add overhead to your engineering budget, because you believe the additional product value is great enough to offset the cost.
![[C]oFoundersLab](/img/logo/blue_cropped.png){kind=logo}
