Scrum does not operate on projects but on products. "Implementing features" is not a product but an activity that will lead to an improved product. Your idea of a subdivision into the projects you mentioned is far too low level. A more fitting perspective would be to think of whatever product your startup is developing as - well - a product for scrum. Then maybe the whole of your marketing materials could be another "product" with an attached scrum process containing tasks that will expand and improve them.
Scrum operates in areas where complexity is high and predictability is low. If you apply Scrum to a project where it is easy to produce reliable estimates you're only getting partial benefits from it. If you apply it to work where there already exists a close, successful cooperation betwen customer and company you're only getting partial benefits.
Scrum is not without overhead. If you're not getting the full benefits of Scrum you should consider hard whether there isn't a simpler/leaner process you can use that will give you more bang for your buck.
Scrum requires a certain level of interchangeability (cross-functionality). To ensure you can sensibly plan and execute a sprint for most of your tasks it should not matter much who does them.
Finally you're working with only 6 people. That is barely enough for maybe two scrum teams. Running "25+ simultaneous projects" with only 2 teams is going to be nothing but a logistical nightmare.
What should you do?
Assuming you have the necessary basic level cross-funcionality then put all three devs into one scrum team. Group the things you need them to do into as few products as makes sense. For each resulting product assign one of your business people as PO.
For the business side. Closely evaluate if Scrum really makes sense considering you'll have less than 3 full worker quotas available to form a second team.