I think the question is wrong.
All startups I took part in did not have a FE-BE only architecture.
Most startups I know have:
- Core - the actual product that exposes an interface
- UI - BE and FE. The BE uses the Core's API.
APIs are stateless and easily mocked - even without the need of a Core Developer.
Hell, if I had to start a project from scratch I might start with an entire UI that works purely on mocks - which will be great for presentations.
Most of the feedback is due to UI. Customers note that more - ( depends on your target audience. )
For example - Google Search has the Core component which crawls the web, indexes it etc.. and the Google UI is a totally different world.
This core can easily support non WWW searches, while the UI cannot.
This way your UI is "pluggable" and you have separation of concerns.
You referred to Development knowledge, however you're overlooking project management aspects. While the core team might need 2 weeks sprint duration, the UI team will use CI - everything is uploaded all the time. The Core team will need backward compatibility while UI will not.
Language differs. You will probably want C developers for the Core component - and you will be ok if it runs on a single OS, where as the UI will be written in a Cross OS Language.
Tests differ. The UI test world is one of the most complex I know in software development. Most startups neglect it and regret this decision later on.
You cannot separate BE and FE when testing. It has to be a single unit that handles it.
Open Source UI - one of the greatest benefits of separating the two is that you can open source your UI. UI project need open source support.
I cannot imagine a UI developer that cannot understand the entire
If you go on having 3 teams : Core, BE and FE, it is a waste of resources imho. What about DB? should you have DBAs? Why should a BE developer know DB and a FE developer not know BE and DB? There's no limit.
If you require experts, and you will, outsourcing them works pretty well. They usually deliver quality code and they do it quite fast. You do not necessarily want them in-house because you will get lost if they leave. Besides you can get great advice online today. Cutting edge stuff might require different approach.
So the outcome is basically a very thin BE in the UI that every FE developer can develop. If you have a thick BE in the UI you most probably have some API functionality required in the Core.
There's always at least one developer that stands out of the rest.
Given such a thin FE, he/she can manage giving support (not develop) other developers in BE code. My opinion is that this developer is in a very good position and should be awarded appropriately (not in salary though, something else). I also trust that they will be able to handle build process and build properly.
This model gives you a great flexibility regarding BE development. The BE world have known several turnarounds in the last couple of years, so I don't recommend relying on BE stability too much anyway. Core is a different story.
There still remains the question - should FE and BE be the same project? You should note the following
- Static resources are best served from front-server. Since Front-End servers (e.g. nginx) are very powerful and since you can use Cache for static resources, you can manage with a single deployment of your static resources (which should be all HTML content, JS, CSS, Images).
- Backend code does not have the same luxuries, so you must have a distributed system - which is also managed by a front-server.
- The build process is completely different - and that can even include patches delivery, upgrade, installation etc..
I can go on, but I hope it is clear that I think BE and FE should be the same team, but maybe different projects.