> Actual scheduled planning meetings instead of random thoughts about business at the kitchen table
By all means don't go Model U.N. or play house. These random thoughts about business at the kitchen table are some of the most valuable you will ever have. These are collisions that engender sparks. What you can do is write down what has been discussed immediately _after_ it has been discussed to capture that. Don't worry about editing, just dump all you've got and structure after you downloaded your brains. This will be raw material of your marketing, your user stories, and your features. Formal and diligent aren't the same thing.
Attitude:
- Model U.N., also known as playing house, is better avoided.
- CEO, COO, CTO are titles that bow down to getting shit done.
Work:
It is useful to write down things and dump everyone's knowledge.
- Carrying a pen and sketching (projects parts interactions, functionality, interface, etc.)
- Writing the product description as if it existed. Continuously edit for conciseness and clarity
- Meeting users
- A versioned design document describing different parts and how they interact
- Code versioning
- Issue templates for bugs and features to reduce friction to write a good issue: anyone who reads your issue should know what you were talking about and have a preliminary action plan. Writing good issues takes a bit of practice, and templates help in avoiding "blank page" and guide the contributor into writing a good one.
- If you've deployed something to users, having a link setup with your ticketing system so they can write an email and an issue is created can help.
- All bugs or features or ideas go to issues
- Writing unit/integration tests & tracking coverage without becoming a slave
- CI tests. You _should_ get an email if the build fails.
- Modular architecture: you don't have to go crazy and read too much from people who design perfect software that only lives in their mind or Medium posts, but features shouldn't too tied. Plugins that can be added or removed
- Write a short documentation about your very easy to use library and then write the code to make it true
- When you get an idea, write it down and get back to work. Explore later. No Wikipedia effect where you wander too much. It has a time and place
- Documenting code
- Good commit messages with root cause analysis when you fix a bug: assumptions that led to the bug. When you do that, bugs don't become a one off thing and _patterns_ start to emerge which will help you eliminate the problem. In other words, a "family" of bugs becomes clear and then you'll develop a solution that makes such bugs impossible to happen again. Also, write tests for bugs so they don't creep back.
- A versioned wiki (for the project) with a page for all the resources you stumble upon that could help your ship:
- Book titles, what the book is about, where you heard of it, why it matters and what will it solve
- Open source tools you can use, where you heard of them, why they're relevant and what they'll solve
- Libraries, you catch my drift.
- Video talks that describe an aspect of one of your problems
- Blog posts that describe solutions to parts of your problem
- Research papers you might want to implement
- Technical:
- Onboarding document - one page -: describing workflow, stack, books to read. Won't need it now.
- How you set up a certain software stack
- Mini tutorials on a tool/library you played with on the week-end to get someone started
- How you use a certain API
- Paperwork (anyone who reads this should be able to operate the company):
- What are the things to take care of (weekly/monthly/quarterly) like bank, IRS, etc.
- Company information (bank accounts if any, legal documents, etc.)
- Necessary employees information
- How to pay taxes, step by step, form by form, with images and where to sign and where to pay
- How to convert from WA LLC to a Delaware C Corp
- How to setup a WA LLC