Service Oriented Architecture is one of those industry buzzwords that is getting huge traction in last couple of years. As with many shiny new things, it is often overrated, abused and misused. The idea of splitting you application in multiple pieces might be a good way to go in some cases, but ,more often then not, it's a bad idea. Let me state some reasons why I think that way.
Reason 1: Hardships of deployment and what to do when stuff breaks?
If you choose to go SOA path, keep in mind that you will have two or more applications that you will have to deploy. Just think about additional overhead it will cause your DevOps team to handle all of it. Think of what will happen if one of the services goes down? Do you show an error page or your app just stops working? Or maybe the whole app should be stopped?
Reason 2: SOA as an excuse for poor OO design
There was a time when I thought that it is a great idea to split components in to the services. One of the most attractive properties of such systems for me was isolation. That means clear boundaries between your systems. How often you have been in situation when you have a legacy app at your hands that has tons of callbacks in your persistence layer that do business logic and only God himself knows why they are there. I have been there for sure.
If you split out the components of your system and put clear boundaries on them, the urge to switch to SOA goes away.
Please focus on boundaries and good OO design. SOA should not be an excuse for poor architecture.
Reason 3: Moving at a slow pace
Let's imagine that you have two teams that are working on separate services. Each of them has to maintain backwards compatibility on an API to ensure that they don't bring other team's application down.
If you have a clearly versioned API, then that might be a good way to go, but keep in mind, that stable API is not something a startup can afford. If you want to move at a quick pace, probably SOA is not the greatest way to go.
So, smart pants, what do you offer?
I offer to think about the design of your application. Put boundaries between components in your system. If you are working on tightly coupled legacy monolith, start small. Each time you touch a file, make it better. Eventually you will start to see your system become more and more understandable. Remember that tomorrow you will have more information than today.
SOA might be a way to go if you have clearly defined API's. In my experience, something like a billing service can be a good idea once your app gets stable enough and is generating enough income.