Emails and other to list stuff.

Talking with Russell over the phone. We had a great conversation.

- Concept for fracture - Being able to remove any of the extra pieces. This goes clear down to the permission level. If they, our customers, only want invoicing and time management. That's all that they see. Even on the permission side of things. They only see what they have turned on. That may require us to stack and group the permissions better. It goes clear down to the ice berg vs the mountain model. We have to be able to remove all of the pieces otherwise the user still sees the mountain even though we are trying to just show an ice berg.

- The other really important thing for fracture is smaller getters and setters. This allows us to add/edit things in a very modular manner. If you want to change something, you can just change it. If you want to add something, you can just do it. This could help out with API sockets, quick calls, and even web components. Back to the old adage, build it once and use it many.

- We lose so much in our transition times - switching between projects. It is very costly both physically and mentally. It is real.

- Working models - if you look really close, we have a number of great working models and proof of concept stuff. There is some real value there. Keep building on that keep working to bring all of those working models and proof of concept pieces more into fruition.

- Empower the users - you can make it happen - we can help you build your dreams. A big part of what we peddle (sell) is potential and hope.

- We spent some time talking about the concept of elements of time. We have build in so many pieces that it becomes a virtual mountain. Russell was talking about a Leatherman (multi tool) vs a simple knife, a simple screwdriver, etc. We really want to help the users. Sometimes they want the big multi tool and sometime they just like the simple knife. We may need both.

- Because of the load, we are able to gain some traction.

- Talking about database pieces and options. There are multiple different models. You have file share databases, server databases, relational databases, document databases (objects and JSON storage), transactional data, aggregated data, object data, etc. You gain if you can mix and blend and get best of the different worlds - connections, storing, searching/filtering, and reporting.

- Helping other people to succeed. That is a huge piece of the puzzle.

- Creating the ecosystem that feeds the people who provide the byproduct services that are needed and wanted.

- Futuristically speaking - There may be some new business needs. This could be adding new departments underneath of adilas or it could be completely new companies (mother/daughter type companies). Thinking of things within the concept of the adilas café - we know that we will eventually need a company for the adilas market, adilas university, core adilas, tons of other options for the other products and services that are needed.

- As we get more into project management, some of our project managers may need some stacking underneath them. For example, Steve may have some projects that he pushed off to some other project manager(s) underneath himself to manage some of those projects. Organizational stacking (who reports to who and how is that organized).