Here are a few ideas:
- It'd be useful to curb the belief that you have a reasonable amount of funds at your disposal. Think like a pauper startup or you will go back to being one.
- You are a living book of the product and you need to communicate the product arc and vision, and the rationale of your decisions. One way to speed things up is with a "This is what I think, and here is why I think it" because then, other members can send in pull requests to your thinking.
This is especially true because you built the initial versions of the app, therefore, some scar tissue has formed and those initial conditions have influenced the current state of the application, whether the stack, the architecture, etc. Why things were implemented the way they were, what were the constraints at the time, what were the hypotheses. The rationale of things must be documented somehow and shared, because then it can be "diffed" and people can send in pull requests. Sure, dreamer7 has implemented this part like this because at that time, there was poor bluetooth support, but now X has a new driver so we can just change X and have 40% less battery usage.
- Aligning the team: emails that go to all on the direction of the product, the different parts, how they play with each other, what would be a good outcome, things that you're looking into, desirable state (integrations, extensibility, API, etc). How it relates to the job to be done, how it relates to the segment, sector, ecosystem. i.e: also from a top view where your company is just an actor in the world, and not the world. What does it add to the global system.
- A very useful thing to do is to scale yourself and the team: record video calls and put them at the disposal of the team. Even when you have a one-on-one call with a member to discuss implementation details on something. All the members can go back to that call and get a detail they forgot, and it documents product building as it happens. You're scaling yourself. You can use Open Broadcaster Software to record your screen, so anyone watching the video gets the context. This is useful because often times, you'll have a discussion, and are digging through source code, cloning repositories, and writing code on the fly to test things. People can witness problem solving. New hires can just consume that content and learn how product gets built at that shop, so they can improve it and adopt elements from it. They also get context on a particular part of the project. This also means documenting things like meetings, or discussions, or contribution guides, or on-boarding documents, etc.
- Describing goals: you can focus on edits and you will do it often. At some point, you'll notice similar things happening and you're editing similar things. This prompts you to find an abstraction and encapsulate what you're trying to do. For example, you might go over pull requests and suggest a contributor make certain parts addressable with API calls. And then do it another time. And another time. At some point, you may want to abstract that away and have a direction such as: "Anything you can do with point and click must be doable with an API call." That sets the tone and people can auto-review their pull request against that.
- Aligning the team: (yes, I said it twice). A good habit to have is to send a periodic email and blast it to everyone (colleagues, investors, advisors, board members) that recaps what you all are working on, and why you're working on it, and the beliefs and data that lead you to working on it, and the parts you're unsure about, and what shifts you are noticing in the field. You can then go back and forth answering questions because people will say "I thought it was X".
In that email, you can expose top down a few ideas. Everyone must be able to understand it, so you can present an idea from different angles.
Run it through something like https://github.com/shivam5992/textstat to get your text scored. Tweak until you have good scores for readability.
- Proofs of concepts: Here's a way to balance your exploration/details with leveraging the team. Your team members are busy working on implementing features, or fixing bugs. You can help fleshing out issues. You can also take an issue that is important and non trivial, explore the space, and write a prototype, a proof-of-concept that you push to a branch. You can make sure to document things in the issue, your thoughts about the design, etc. The team member who will pick up that issue in the future will have a starting point, an initial implementation. If you do that for the issues you consider important, it will kickstart development.
- Paying attention to the ecosystem: you have a backlog with issues for features and bug fixes. Similar to a garden, you have to tend to those. You can go over them, one by one, and re-think their relevance, doability. Some issues were opened 5 months ago with a "state". The state 5 months ago is different. What has changed that can help close this issue by either fixing the bug or implementing the feature.
Part of it is going over things every week and ask yourself: what was valid a week ago that is not anymore? Or what has changed with respect to this problem? Maybe a new paper came out that even if it doesn't solve your problem, brings you closer to a solution. So you add that to the issue, with your thoughts on how it can play out.
Any contributor who picks up the issue will have a huge context, links for resources, a thought process, experiments that were made, and can choose either to ignore them because it looks trivial to them, or start from there.
Sorry I wasn't more concise.