Don't use Scrum - it doesn't seem appropriate for this situation. I wrote an answer on Software Engineering Stack Exchange about the minimum number of people to implement Scrum. Right now, you describe the bare minimum number of people to form a Scrum Team (a company owner as Product Owner, 3 developers with one being the Scrum Master).
I can see a few hiccups with this plan. First, the Scrum Master needs to be able to be a coach to the Product Owner as well as the organization - can the person that you select to fill this role have the necessary influence with the owner who is acting as Product Owner and the rest of the organization? Second, do the people that you've identified have the necessary time, knowledge, and experience to function as Product Owner and Scrum Master?
Instead of Scrum, I'd start by looking at an approach modeled after Kanban.
First, create a board to contain work items. Work with the team and the people managing the product to determine what information is necessary for the team to be able to do work. This is sometimes called a Definition of Ready. Instead of having the owners interrupt work, they begin to formulate a work item that meets the Definition of Ready. They may need help from the team to do this, though - set aside time on a regular basis to manage this. You can take some guidance from "grooming" or "backlog refinement" sessions from Scrum on how to manage Definition of Ready and ensuring work is in a good state.
Then, prioritize the work items. I'd try to make sure that one person has the final say in priority ordering. The ordering of the work items determines the order that the developers do work. As soon as a developer finishes a work item, they look at the top of the backlog and choose the top-most item that they are capable of doing, progressing that from "to-do" to a done state. It is important to have work-in-progress (WIP) limits set and enforced.
Generally, the principles from Lean Software Development should be helpful. Your planning, review, and retrospective activities should happen appropriately. You may choose an approach more like Scrum where these happen on a regular cadence. Or you may choose an approach where they happen as needed.
If you have a decent backlog, good definitions of "ready" and "done" for stories, and good habits around planning, review, and retrospective, you should be able to scale your process. If your team grows, you can consider adopting a framework such as Scrum. If you start growing to multiple teams, you can look at other frameworks such as Nexus or LeSS for scaling Scrum. You can also learn from Disciplined Agile Delivery with respect to tailoring and growing your process.