II SPA frontend backend Facebook SMB consultancy MVC Ruby on Rails HTML API software web applications Google

We specialized in
web applications
. There was actually a time when we considered going into desktop and native applications, but the demand for web apps was just too big that I guess my partner and I never even had the chance to decide. Our path was chosen for us.

We opened up shop after the
SPA
craze had already hit. So clients were already okay with and often wanting their solution to be a single page app. Initially I was gung-ho about SPAs as well. It sounded like a good way of separating concerns and you could separate
frontend
and
backend
developers quite easily.

Only once we began writing actual apps I learned that these benefits were hardily afforded to a team our size. I mean I can understand why huge convoluted webs of teams at
Facebook
or
Google
would want to write apps that way, but for an
SMB
consultancy
like ours, I honestly think we would've been more effective going with the bread and butter
MVC
frameworks.

Man I had a friend who worked at a startup that used
Ruby on Rails
and damn could they not write features any faster. They could have a design, generate that
HTML
and do all their programmatic functionality all using this unified codebase. Clean as a whistle, and fits just the bill for a team of around 3 engineers.

But for a variety of reasons, most of it being that the client came to us with some existing limitations and/or inclinations, we couldn't go with a standard MVC stack. We often made SPAs with a separate backend
API
.

We still managed to write good
software
but we couldn't fly like my friend with that startup.

Shark Swim