Meeting with Cody. Going over UML diagrams that he is working on. Talking about efficiency, reuse, pros and cons of copy and paste, pros and cons of duplicating data, and math on the fly or precalculated math. Lots of good topics. Here are some of my notes:

- The importance of refactoring. Keep refining and paring things down. Make it smoother as we go.

- Talking about mini conversions and other options. Mini conversions is a sub of sub inventory (parent/child inventory). For example: Say you have something that gets sold by the case, by the bottle, and by the fluid ounce. You have to be able to go up and down the conversions to show what is really there. True inventory tracking.

- Talking about lots of suggestions and what makes sense to change out and/or leave.

- On the mini conversions, we might be able to hold the conversion id's and the math all on the same table. Help the users setup the conversion charts and/or relationships. Especially if we don't know the conversion factors or ratios (custom conversions or custom units of measure).

- We have had a lot of wild west style development (anything goes). There is a need for specific roles and company structure (adilas jelly fish model - future plans for where we are heading as a company).

- We mix so many different business verticals. That has been a huge blessing but also a small curse (so diverse).

- Cody was pitching that we need a primary role of a database admin type person (specialists per role). Creating the chain of command, down the different roles. Basically, turning the wild west into a more modern city (modern development environment).

- Talking about someone who knows how to work really hard and how to help them to work smarter and use technology.

- Cody wants us looking into growth, in the long run. Talking about a master plan and then breaking things down into more digestible pieces.

- Talking about internal education and structure. We need our team to know what to do and how it (all of the pieces) fits with the bigger picture or the whole.

- Figuring out what we have, suggestions for what to change, and future plans.

- We then got into time sub inventory and parent/child relationships. It gets deep, pretty quickly.

- Growth is hard to manage sometimes.

- Talking about independent developers, light guidance, and working on our own. Reasons for building out the UML diagram. Not just for Cody but for all other developers who will be working on this project.

- Building out the dream. Getting organized (not really official, but pretending that it was official). It will all help in the long run. Risk vs rewards - push/pull in the organization. Unofficially organize ourselves (at least on the development side).

- Link to the interactive map - small visual for how things are organized.

Working with Shannon. We finished up the adilas lite (fracture) project overviews. We then pushed up the overviews to the correct pages. That is awesome, we've been working hard on some of these overviews. Here's a list of projects. They are not done yet (as of right now) but we are making progress and getting things planned out.

Adilas Lite - Main Homepage
# 1 - The company structure - adilas jelly fish model
# 2 - The overall structure of the adilas platform or system - adilas value add-on core
# 3 - The education and training needs - adilas university
# 4 - The marketplace for the adilas community - adilas marketplace
# 5 - The virtual portal or primary landing spot for the community - adilas cafe and community
# 6 - Deeper dive into the adilas platform or system - adilas lite or fracture
# 7 - The budgets, finances, marketing, and sales plans - other business plans
# 8 - Come take a look!!! - adilas lite videos and research

Working with Shannon. Touching on the adilas value add-on core model and the adilas university overviews for the adilas lite and fracture projects. We also spent some time working on the adilas marketplace project overview. Good work session. We then added the overviews to the web pages where they belonged. See attached for our documents and progress.

Links to the project overviews:

- adilas jelly fish model

- adilas value add-on core model

- adilas university

- adilas marketplace

Lunch meeting with Alan. He was in town so we hooked up for lunch and to chat. Planning, talking about our team, roles, strengths and weaknesses, and industry specific skins. We talked about the jelly fish model, the value add-on core model, adilas university, adilas marketplace, and fracture (adilas lite) stuff. Fun little meeting. Both Alan and I are on the same page as far as vision. That's awesome!

Printing out some elements of time as a back-up paper copy. Prep for a group meeting. Once the meeting started, we did some small intros. There were 10 of us on the meeting. We went over concepts of throwing stuff at the wall, seeing what sticks, organizing things, Alan gave a small PowerPoint presentation (see attached). We talked about exposing the peaks, mountains and ice berg (peaks) analogy, tiered versions, pricing matrix, features & who has access, prototyping with code models, frameworks, libraries, the jelly fish model, a new mini jelly fish model, and tons of other topics.

We got into topics of growth, retention, code development, IT/Servers, and Cafe/Marketplace options. Great discussion on R&D and how R&D plays on both the maintenance side (stabilizing and making the current product better) and the growth side (new stuff and pioneering).

Spent some time talking about the SWOT analysis, lessons learned, and mission statements. This is an idea from Hamid, on the mission statement - Mission: Adilas - Build Your Solutions. We got into some user stories, scenarios, and recruiting help from the guys/gals. We talked about who wants to help and what they could do. Overall, a good meeting. We recorded it, at least the first part (first 23 minutes). It stopped recording when we switched screens and switched presenters. Anyways, see attached for some other notes, the PowerPoint slides, and the link to the video recording.

Good group meeting with a progress report on the ship B, adilas lite stuff, and fracture.

Meeting with Alan on defining roles and responsibilities for parts of the adilas jelly fish model. See element of time # 2284 inside of adilas for details. Not finished yet but some great discussions.

Master Adilas Plan - Jellyfish Model

- The adilas jellyfish model - covers almost all of the departments and sub sections of what we are trying to be as a company. It is not the main product, but more of our internal and external departments, areas, and general areas that we will keep refining and working on.

- Possible numbers for the jellyfish model. Going from top to bottom and from left to right.
1. adilas.biz
2. Admin
3. Monthly Reoccurring Service
4. Sales & Marketing
5. Setup & Training
6. Tech Support
7. Design
8. Custom Code
9. Consulting
10. R&D
11. Project Management
12. Internal Development & Maintenance
13. Adilas University
14. Adilas Marketplace
15. Adilas Cafe & Community - Adilas World
16. Databases, Networks, Servers, & IT

Tons more details and bullet points on element of time # 2284 inside of adilas.

Lunch meeting with Jonathan Johnson from Epic Enterprises. Jonathan is a business consultant here locally in the Cache Valley, Utah area. Great little meeting and he was asking some great questions and feelers to check out parts and pieces of my plan for ship B, fracture, or adilas lite. We talked about pieces of the business plan and how to plan things out and proceed.

- One of the main topics was dealing with talent and getting excellent talent to help run the business.

- Went over our rough plan and talked through steps of the plan. See elements of time # 10179 for more details.

1. Company Structure - Adilas Jelly Fish Model
2. Product Development - Adilas Value Add-On Core Model
3. Education & Training - Internal and External - Adilas University
4. Community & Outside 3rd Party Solutions - Adilas Marketplace
5. Social & Efficiency Options - Adilas Cafe & Community
6. Deeper Product Development - Adilas Lite - Fracture Project
7. Budgets, Finances, Marketing, & Sales - Other Business Plans

- Lots of talk about division, departments, and managing the entity and the projects. Defining those roles and what is needed. Once that is finished, we will put or assign/invite the who (people and talent) to the what.

- We talked a lot about inviting and enticing the talent. Not all of the talent will be hourly or employee level people. Some of the talent or high-end knowledge workers contribute in different ways. That was a small paradigm shift for me, thinking wise. More of projects and contributions vs hours and physical output.

- What needs to be done for the product development pieces - plans, marketing, sales, and roll outs.

- Talking about building out a pitch deck to help pitch the project and product (the whole package).

- 5 main personality types - There are five major roles that need to be fulfilled in a company. Instead of just roles, ideally, you actually have people in place who can carry each of these roles and own it. Otherwise, you just have a smaller number wearing multiple hats. The five people are: An organizer, a doer, a creative type, a consultant, and a salesman. The goal is to align talents with tasks. I grabbed this bullet point from entry # 5295 - another meeting with Jonathan Johnson (early on, back in 2019).

- Talking about the root words in authority (author or create), accountability (count or manage), and responsibility (respond or react). Who does what and how that all plays into the mix.

- See attached for a napkin with some notes on it - Here is what Jonathan wanted me to do - 4 steps he wants me to work on... 1. Define the division and structure of the company, 2. Invite the talent to fill the roles defined, 3. Product development MVP, and 4. Build the pitch deck. All of these need to be at least good enough. Shooting for an MVP level on all of them.

Meeting with Alan. Going over and reviewing my meeting this morning with Aaron and what we are learning and discovering. Alan was showing us (Aspen and I) some VueJS stuff (JavaScript framework). Lots of shortcuts. Mini caching of variables. Listeners and watchers. Two-way passing back and forth. Comparing VueJS to React JS stuff. Event handling and looking into options.

We switched gears and went over needs for training and outside training resources. We did some review of some older R&D stuff from Jonathan Wells. We talked about some new user's stories. I got some notes from Alan (see attached). Light ideas of what Alan wants to do with adilas lite and fracture. We then rolled into a small work session doing stuff with the jelly fish model. See elements of time # 2284 inside of adilas for verbiage there.

Meeting with both Alan and Aspen. I took some notes and Aspen took some notes. After the meeting, I did some more note recording and note digitizing for 6/15/23 and for 6/16/23.

Alan was on with us for the first hour. Here are some of my notes. See attached for all of them.

- Let's build out the MVP for the plan - general fracture or adilas lite planning session - what documents does that mean and/or require?

- Two of the first main things we want to do is define the jelly fish model (business structure) and the value add-on core model. Those two are some known needs of where we are heading.

- We spent quite a bit of time talking about how to break functionality and features up. We want to keep those separate as far as options.

- I showed Alan the presentation gallery and the outline of the business functions. There is quite a bit of work that has already been done there. Great resources.

- Small packages and/or starting points - We could call it whatever - recipes, packages, templates, industry specific skins, presets, etc.

- Alan wanted us to think about tiers and scaling - both vertical and horizontal. I was thinking, what about the Z scale or the depth/layering axis. Just for fun 3D scaling and 3D world building. It might be fun to explore this.

- We talked a little bit about pricing and tier levels. We would like to set breakpoints, ranges, and fees for going over.

- We asked Alan about his vision for adilas lite and fracture - He is really excited about creating a solution that is light weight and very efficient. In his words, he said, How can I get the most power with the least amount of drag? We went on to talk about hiding things that they don't need and getting them to the meat of the operation as quickly as possible. We will do future planning sessions where we look at each section and slim it down to the minimum or minimal requirements.

- This is a side note, but as I have been thinking about minimal pieces, I keep coming back to a concept that we were looking into called standalone declarations (full entries without any other connections and/or supporting documentation). They exist by themselves but they also may be mapped and pointed to the right place. We could sum them up, count them, map them, and keep it super simple. Originally it was going to be something that could be made for financial documents (P&L and the balance sheet)  but technically we could use them in any way. Simple standalone pieces.

- Spend the time and do some market research on what business verticals we could hit and take care of.

- Lots of talk about automation and even automating the setup of new systems. Let people try things out as a free or limited version. We would setup thresholds, limits, ranges, or whatever. We want people to try it out and like it.

- We talked about ice bergs and mountains (perception of how big it is). We also switched and talked about the depth of the water... pretend levels of swimming - Imagine that you are at the beach - you could get your feet wet, do some wading, swimming, snorkeling, or scuba diving. All at the same place, just how deep and serious are you or what are you looking for?

- Once we have a list of things that need to be done and/or worked on, we get to prioritize that list. What do we want to build out and when?

- Alan had the idea of putting our outline information into a database. That way we could just query things (just in time) as needed. That way we could make the lists super small and then allow for it to be expanded at will. Great idea. Simple displays with drill-downs. Almost the presentation gallery for sales, marketing, pricing, features, and education.

- We also want to highlight future plans and what is up and coming. We change things all the time. Make that part of the plan and the part of the presentation. Put it in a database and let our users pull back what information they want and/or need. Self-building templates, feature lists, tiers, and other levels.

Just thinking about some ideas for financial products for adilas and adilas lite (fracture).

- We could offer short term investments - 2-5 years for payouts on investments or loans. These could be higher interest rates as we would be paying them back quicker. May need to research rates.

- We could offer long term or longer term investments - 5-50+ years - These could be lower interest rates as we would be paying them back either over longer periods or potentially letting them sit in the long term liabilities (loans and long term payables) for long time periods. They, the lender/investor would still get paid, it would be more of a long term deal where they were making money off of the interest while still having the payable on the books and financials (balance sheet).

- There are at least 4 main entities that I can think of right now. They are the main adilas, llc (main or mother ship), the adilas shop (development, IT, and R&D stuff for adilas and special projects), the adilas university (education and training entity), and the adilas marketplace that could have a number of subs underneath and/or somehow associated with it. See the adilas jelly fish model for rough sketch of the corporate structure and how they all play together. Long story short, adilas creates a number of byproducts and has a constant need for other supporting products and professional services. That's pretty cool! All of these could be their own business or entity.

- On the adilas marketplace concept, maybe treat it like virtual real estate or a mini mall type venue. Tons of different options. See attached for a small graphic of what it could be like (just a concept). I'd love to see business funding, investments, marketing, and planning to join the existing ideas of accountants, CPA's, attorneys, bookkeepers, consultants, custom code, developers, graphic design, hardware, merchant processing, sales, tech support, and other third party solutions. It could be anything, either built under the adilas umbrella and/or a complete independent third party. Tons of options there. Along with this idea... maybe treat it like a railroad. We own the railroad tracks but others can own cars, businesses, etc.

- Back to other financial products for adilas - We could offer options for ship A - current adilas. We could offer packages or options for ship B - future adilas buildout - fracture or adilas lite.

- We could offer options for sponsor for certain features. This could be all internal, approved third parties, or a mix of whatever. Small side note, I was exploring this concept more on 6/14/23 about possible sponsors for modules and features.

- This is more for me, but I'd like to meet with some of my friends to get some ideas from them. Allen Marler, Sheldon Archibald, Matt Funk, etc. Good guys that I know and that I could learn from.

Working with Aspen to go over our plan for making the plan. Light review and discussing expectations and where we are going. Started in on adding some research links to part of our plan. Pushed up the new stuff to the google doc that John and I had started.

Here is a light version of where we are heading... (just barely starting - for the record, it looks nicer in the google doc)

Master Adilas Plan or Adilas Master Plan

1. Company Structure - Adilas Jelly Fish Model
2. Product Development - Adilas Value Add-On Core Model
3. Education & Training - Adilas University
4. Community & Outside 3rd Party Solutions - Adilas Marketplace
5. Social & Efficiency Options - Adilas Cafe & Community
6. Deeper Product Development - Adilas Lite - Fracture Project
7. Budgets, Finances, Marketing, & Sales - Other Business Plans

New note added on 8/14/23 - For a pretty good breakdown of these projects - just at a high level, see this element of time 10377 and it's photo gallery.

________________

Table of Contents. To-do

All time id's are inside of adilas

2283 - Main Index

2284 - Jellyfish Model

- Research on the Jellyfish model - link

2285 - Value Add-On Core Model

- Research - link

2286 - Adilas University

- Research - link

2287 - Adilas Marketplace

- Research - link

2288 - Adilas Cafe & Community

- Research - link

2289 - Fracture - Future Project

- Research - link

- Adobe XD mock-ups with options

2290 - Budgets & Finances

2291 - Marketing & Sales

- Adobe XD mock-ups with options

- World Building Concepts and Concepts of the Data Assembly Line - Pitching the concepts

- Research on world building, research on data assembly line

- Presentation Gallery - great start for an outline of what adilas does

2292 - Other Timelines, Plans & Projects

Back to the main index for the master adilas plan

Master Adilas Plan - Jellyfish Model

Brainstorming Ideas and Topics:

- How big do you want to be? – See also the internal questionnaire responses and survey - tons of good info there - almost a mini plan by itself. Also, question 7 on the survey has a whole write up on the adilas jellyfish or jelly fish model and explains it further.

- The adilas jellyfish model - see attached - covers almost all of the departments and sub sections of what we are trying to be as a company. It is not the main product, but more of our internal and external departments, areas, and general areas that we will keep refining and working on.

- Possible numbers for the jellyfish model. Going from top to bottom and from left to right.
1. adilas.biz
2. Admin
3. Monthly Reoccurring Service
4. Sales & Marketing
5. Setup & Training
6. Tech Support
7. Design
8. Custom Code
9. Consulting
10. R&D
11. Project Management
12. Internal Development & Maintenance
13. Adilas University
14. Adilas Marketplace
15. Adilas Cafe & Community - Adilas World
16. Databases, Networks, Servers, & IT

Areas, sections, and departments in more detail:

** for me - go deeper into each section **

1. adilas.biz

• Are we going to stay the same entity? Are we the same or are we different entities? Are we rebranding? Are we piggybacking?
• What version are we on?
• Adilas.biz or adilas lite? Branding? Marketing? etc.
• The thing that keeps us all together is the reoccurring monthly services subscription for the main adilas.biz system. It has been the glue that keeps us together.
• Offering upgrades from ship A (current adilas) to ship B (fracture or adilas lite)
• What are our goals for ship A? What are our goals for ship B? Are we building it up to sell it? Are we going to be replacing ship A? How do you transition between the two.
• We want to make our current product better. It then grew into a full or bigger rewrite. It seems to be changing more and more. Originally, it was pretty small changes.
• Timelines to get things done? What will it take?
• Ship A will be great salespeople for ship B, once ready.
• If people change from ship A to ship B, there needs to be an increase or at least a re-evaluation of monthly fees and services.
• Ship B, we are planning for tiered pricing and dynamic billing based on functions, sizes, usage, storage, and preset packages.
• Ship B, they can toggle on/off different settings, include other features, and change what they want. All of this will reflect on dynamic billing options.
• Talking about future plans - selling it, royalties, secession, retirement, etc.

2. Admin

• The admin's role is to manage the budget, make decisions as to the direction that we need to go, do HR type functions, payroll, manage the different groups and departments, communication channels, general running of the day to day business.
• This could be one person, multiple people, a board, a council, etc. Somebody or some entity needs to be in control.
• Co-owners, Co-Founders, CEO's, presidents, vice-presidents, board members, etc. We can figure that out.
• If we do one person, we need to have VP's or managers in the other departments.
• One of our problems is that none of us (on the current team) want to be that person or take on this whole responsibility.

3. Monthly Reoccurring Service - aka Billing (new name)

• This is billing, invoicing, receiving, dealing with monies coming in and reaching out to our clients.
• Accounts receivables
• This could be tied in with admin roles
• Debt collection, bad debt, accounting, financials, etc.
• Setting up new corps (currently) and sending welcome emails and collecting business contact info.
• Bank reconciliation, paying bills, prep the budget info, etc.
• We could automate some of this, in the future.

4. Sales & Marketing

• We like that they are together. This is anything to generate and keep new clients to keep coming in and paying for our services. This could be publicity, knowledge about the system, get new demos, entice our clients to buy and keep buying from us. Serving their needs.
• Currently, the main method of marketing is word of mouth and referrals.
• We have used sales reps, consultants, and light networking. Steve and Kelly have been some of our biggest sales type people.
• We want to listen to what feedback they are bringing back. Currently, the sales people and the developers almost live in two different places.
• Sales should have a good pulse on what is working, what is not working, and what people and our clients are asking for. We tend to get lots of good ideas from clients. Sometimes, what that takes or the priority, that can get tricky.
• How big do we want to be? Get everybody or get enough (sufficient)? Keep pushing into other markets or be content with good ROI?
• Helping with market research, looking around and checking out markets, and what do we need to do to penetrate those markets?
• We almost feel like being in no man's land - too big for just a few people to push on it, not quite big enough to really have the team that we need to push it. Do we push and go bigger? Or do we trim down and keep it like it is (not really coasting but strategically developing as we can)? There are associated questions about speed, reliability, and uptime.
• Along with sales and marketing, there are expectations that are set and keep changing (trends and expectations).
• We need to know who we are servicing. Currently, we are kind of all over the place. We have little accounts, medium accounts, and some big accounts. We could go any direction. We just need to decide. Where is the sweet spot?
• If we want to be big and grand, we will need some major funding and thus major sales and marketing. Or do we figure out the sweet spot and really refine and focus in on things.
• Making things more stable and more reliable. Keep improving.
• We have a lot to offer - no one has even heard of us.
• The new and upcoming business owners are going to be fully connected and have certain expectations. If you want to get those guys/gals, you're going to have to revamp things.
• Our current mix is very developer heavy. We really need to switch that focus and get things that people want. Easy, Powerful, and Pretty!
• We need this department to really keep us in the know on what is going on. Currently, we don't have anyone fully dedicated or assigned to this department. We've been missing this piece.

5. Setup & Training

• Originally, we didn't charge for any of this. We just wanted people to get on our system. We are now charging for this and even trying to presale some of the training, deployment, and setup stuff. We are finding and have found, that people who get setup correctly and have the correct amount of training stay longer on our system. It has a learning curve, and that proper setup and training goes a long way.
• Currently, one of our system admin persons has to go in and create the corp, do a bunch of the settings, assign the master users, setup the logos and colors, and get them going. Most of that requires someone from our team to hold their hand along that process.
• Futuristically, we really want to help automate a bunch of that. Have them setup their own corp, let them pick what industries they want to play into, help them with their settings (wizard style), and then even help them pull in their data (without any other involvement). Let them create a test account or a free version, play around, and then either upgrade or get some help.
• Offer services to help our clients. Also have a number of self-help tools and features to let them do it themselves.
• We would love to develop a number of preset packages and industry specific skins.
• We would like the setup and training to be coupled with education and the adilas university side of things. They are very related.
• Getting products, customers, vendors, and other info into the system easily. Currently, we have to do a bunch of that (data imports) on a one-by-one basis. We need to make that more global and self-help level.
• Provide a good starting point to help them succeed. Show them the benefits and advantages of doing it our way or how we help them succeed.
• This department or division could include the adilas university, training, tech support, setup, and training.
• Easy access to get help and direction if needed.
• We see a lot of user error type problems. Figure out ways of helping them stay in their lane better or put up guardrails or bumpers to keep them on track.
• It has only been recently that we have added more focus on the setup, deployment, and training.
• This department could also include on-going training and retention. That is huge. Things constantly keep changing and we keep adding on new features.

6. Tech Support

• Currently, we allow people to email or call for tech support. It's free but often bleeds over into full on training, not tech support.
• We could build out a report a bug or open up a ticket or an issue. Make it easier to get support.
• We could provide better help files, tips, how-to's, videos, tutorials, and in-person training events.
• Everybody uses the system so differently, that makes it kind of tough. It would be nice if we have tech support stuff that was industry specific or catered to a specific industry.
• Tech support really should be part of the training, setup, and deployment stuff.
• Tech support could be a small carrot for deeper training and/or offering other paid services.
• Helping to show the value of deeper training and education.
• Having a standard way of getting to training and even industry specific training.
• Offer some adilas university training courses - covering various subjects on scheduled dates/times.
• Really helping to push the training and education stuff. Tech support should be quick, temporary, and non reoccurring. Show them the benefits of getting properly trained.
• As we move forward, we are planning on simplifying things. That should help with the training needs and the tech support stuff. Helping them figure it out on their own.
• If people (our clients) really want more tech support, we could offer more robust or advanced support packages.

7. Design

• This could be websites, forms, reports, interfaces, dashboards, UI/UX (user interfaces and user experience). This is the pretty and easy part of it. The powerful may be from a feature or backend process.
• Most of our current guys are developers, not designers.
• We don't charge enough, as such, we tend to skimp on the design phases and processes. This tends to get skipped or minimalized.
• We tend to do function over form - however, most clients say that they want function over form, but really, they want form over function - they want it to work and look pretty.
• Our project management tends to be a simple one liner. Do such and such. No other plans, requirements, mock-ups, or fixed specs exist.
• Mock-ups, prototypes, samples, wireframes, flow charts, graphics, videos, etc. We want to show the plan, air it out, and then build to the specs.
• Modern look and feel and user experience keeps changing. We need someone to keep watching and keeping up with trends, expectations, and options. This needs to be monitored and maintained regularly.
• Figuring out and sticking to a style guide. We do have a section called the "adilas docs". We have been working on it, but it has not been fully adopted yet. We need to set those standards and then stick to it. This is our style guide, and we are sticking to it.
• Doing some test cases and getting user/client feedback. How did their experience work out and what did we learn from that?
• Planning in maintenance and upkeep.
• Our clients squawk at things not being consistent. I don't mind change but I don't like some change and other things not being consistent. We could also introduce settings.
• We could allow the users, or corporations, to choose their default layouts. Horizontal forms, vertical forms, stacked forms, or auto formatted. We also want to store those settings and allow them to change it on the fly on per user basis.
• We need some consistency - this deals with who the designer is, what we are designing and outputting, people's preferences and opinions, and where we are heading. We can all be different, but we need to be consistent.
• Allow people to try things out and/or fully switch over.
• There is a point when we need to keep moving forward so we don't have to keep supporting all of the older styles and themes. Help make that as smooth as possible.
• We have some needs for design work out in ecommerce, customer facing sites, portals, and even business websites or web presence stuff.
• We need designers to help with marketing and social media stuff. Once again, consistency, specific plans, strategic campaigns, etc.

8. Custom Code

• This is one of the things that really sets us apart from other systems. We love it and even encourage it.
• We currently have tons of black box options. That was a solution at the time. There are some great concepts there (black box stuff) but we did run into problems.
• The code base keeps changing. We have had people ask for things, we build it custom for them and then wrap back and make it standard. The ones who got the custom version are now off on their own vs being fully integrated into the main codebase.
• We offer a lot of this. Having said that, we don't charge enough.
• We would like to move as much as possible to data driven settings and permissions.
• One of our current issues in maintainability. If it was on the side (like a black box page) it got left behind. The main pages always got updated but anything custom was harder to test, and harder to main it.
• If we do custom code, we need to build in some maintenance costs to help maintain that.
• We could do a community type approach - who ever helps build it out, gets a commission or a usage fee for others using it. Kinda like a sponsorship or something. We just need to get enough to plan it out, build it out, test it, market it, and then do some sort of kickback or reoccurring usage fee. There may be different levels  - one-time, reoccurring, built in, full one-off custom code, settings, combined projects (we pay, they pay, we then get to use it).
• Custom code should be by our internal developers and internal development team. We need to make sure that it works and doesn't affect something else.
• We have had some maintenance issues. Who made it, what does it do, how does it work, what does it touch, what else does it touch up/down stream, where does it live, how can you get to it, and was there any planning or testing done to the custom code? Tons of potential far reaching questions.
• If we build something... we really need to get an ROI and market those pieces.
• We could do some pay as you go build outs. Monthly fees that get added to their bill. They could pay upfront and then get a payment plan, or set it up on a reoccurring basis, or whatever.
• We need to charge enough. We often shoot ourselves in the foot. We charge pennies to build on top of multi-million dollar platforms and applications.
• We need good planning, good project management, good estimates, and then good developing.
• Estimates - take what you think it will take and double it. Then double that. It's almost a 4x ratio. By the time you add the work to get the work, the work before the work, the work, the work in between the work, the work after the work. It all plays in.
• Paying for both quality and speed.
• On the estimates, we also need to think about opportunity costs and what are we not working on, while doing custom code work.
• Approving custom code. Just because someone wants it... doesn't mean we should build it out. How does it fit with our mission statement, goals, and overarching plans and rollouts?

9. Consulting

• Byproduct of the main reoccurring business services. Once we are in, the system starts generating byproducts and people need to know what is next, how to do certain things, where they could go, options, next steps, phases, etc.
• We haven't really tapped into this yet. We do it, but we could do it so much more.
• This could be tied into the training, setup, and education stuff. Teaching our clients the best way to use the system to get the most out of the system or platform.
• You start getting into paying for knowledge and experience and expertise.
• We have seen many of our power-users become consultants. They know the system, they know how to make it run, sing, dance, and play. That provides a value to others. Those people then offer their expertise and know how to help others.
• Currently, some of this is done on the side. Adilas has no part in it, and no kickback exits. We would love to bring this more inside but that takes money to keep those people on call or on staff.
• This could be a great thing to add to the adilas marketplace.
• We may allow some outside stuff to go on, but we need some rules. We could configure this any way we want, we just need some rules.
• This could be part of the adilas cafe scenario - our clients seeking out a professional to help them out.
• Do we want to manage this internally? What would that look like? Once again, we may need some rules here.

10. R&D

• Research and Development - You have to spend time here to move the ball forward. If you aren't going to move forward, nothing will happen, you will live and die. You have to keep up, especially with tech stuff.
• Exploring different avenues - there are costs for exploring.
• Cutting edge, bleeding edge, sweet spot, new ish, or older/classic?
• How much does it cost to be on that cutting edge?
• Vision, plans, and looking to the future. Where are we/you heading? Plans, how are you going to get there?
• It really comes down to where do you want to play (on the spectrum)?
• Training what is new.
• Maintenance for what was or has been developed. Technical debt.
• Stable and known or less stable and new - How quick will the older pieces change and/or be deprecated? If it's so new, it may not even stick.
• We make things and then it sits on a shelf. That hurts. There could be difference between development that didn't get fully funded vs totally new prototyping and experimenting.
• Is this something we should do? On not? Figuring out what it takes to make something happen.
• Looking into speed, efficiency, demand, cost analysis, needs analysis, scope, scale, and reality of doing certain things.
• Beta testing, prototypes, experiments, testing, pushing boundaries.
• Currently some of our R&D is mixed in with our code. We try things to see if it works. Without being consistent with other pages and code. We often have good intentions (prepping for the future - mini stubs or prepping for stuff) but then get pulled on to other projects. We do a lot of experimenting within our projects. Almost a revolving door or revolving code set. Basically, a fully working, living prototype.
• We are seeing a mix between custom code, R&D, and project management.
• Back tracing or reverse engineering things. Sometimes if you know what you want, you can then figure out a way to get there, that might be easier or better.
• Being aware of what's out there? How could I use some of that in my projects?

11. Project Management

• We have really been missing this piece. We do a ton of just in time project management. We are not very good at doing a more full design, plan, or architecture type layout.
• We do a lot of this one-on-one right now. One project and one developer.
• The project manager can and does act as the shield between the client and the developer. Buying some time or deflecting decisions.
• They help with quotes, estimates, and project specs, scope, costs, timelines, and details. Lots of potential back and forth communication is needed.
• We have spent a ton of time and money going back and fixing things that should have been planned out originally. We have also spent money where a developer makes a decision and just does something and doesn't ask or doesn't get any clarification.
• Teams - authority, accountability, and responsibilities - setting up clear expectations. We have played around here a bit. We need to refine things here a bit, based on our needs. We had some people who were so worried about how to do scrum that it didn't actually happen. We also had some problems with free riders. We want to use some small teams, but still need to get it refined a bit better.
• Dealing with teams, we were trying to do some training... and we didn't really have it all defined. Wasted time in meetings, talking about code, and what is needed. We then fall down based on assumptions or just verbal communication. It needs to be just a little bit deeper and more consistent.
• Team sizes and dynamics.
• As a project manager, not assigning yourself to a required task. Actually, make an assignment to do the project management.
• Someone needs to be available and be the virtual babysitter. Getting rid of hurdles and what is expected of them. Helping them stay on task/track. The project manager's job to help other people succeed.
• Slowdown
• We build and build and build... we need to slow down and test it, train on it, market it, and push it.
• Being able to plan it out so that we can reuse as much code as possible. Giving the developers guidelines, handrails, samples, and good instructions. If it's too tight, they don't want to do it (it takes out the fun of figuring it out). Figure out what developer needs what (how detailed) and then play accordingly. Developers need to accomplish something. Not just follow A-Z and you're done. It is a mix and a spectrum.

12. Internal Development & Maintenance

• This internally funded by adilas to work on adilas. This comes from revenue and budgets to keep the system up and running.
• Bug fixes, maintenance, changes, next steps, phases, testing, documentation, code review, etc.
• This needs to be tied into project management and custom code.
• This is the most defined area that we have inside of adilas.
• We get a plan from project management, we then build it out, test it, deploy it, and make sure that it works.
• We have had problems with guys following style guides. Everybody has their own ideas on what a good style guide is. This could be whitespace in code, tabs, naming conventions, etc. It also happens on the look and feel part of page or report.
• Alan had the idea of having a way of helping to force or standardize the output. Almost a forced style guide or validator of sorts. It all has to comply to a certain standard. Whitespace, naming conventions, comments, indents, variable names, components, etc.
• Keeping things separated - backend, database, objects, services, views, logic, functions, classes, etc.
• In object-oriented programming, you need good encapsulation (only contains what is needed) and low coupling (lower number of steps as possible).
• There is some great value in teams and getting different points of view. A better solution because we worked on it as a team. More well-rounded.

13. Adilas University

• This goes hand in hand with the training and deployment section. This is the training arm of the system. It may also tie in with tech support or consulting. We could combine some of this as needed. Similar type people and knowledge resources.
• General topics for training - One, how do you use the system? Two, how do you run your business? Consulting is a part of this as well - what are the best business practices and how to get the most out of the system.
• There could be standard stuff, custom stuff, and internal stuff.
• Each page would have how to videos, quick videos, and options for more or deeper training.
• We also need to offer some custom or live training events.
• For fracture, we experimented with a thing called the education mode. You could turn it on/off and the system would hide or show more options and information. You could turn it on from any page and all of sudden it would react differently. We have some great screenshots on this from Jonathan Wells. Along with this, the help files could be shown, side-by-side with the page that they are referencing. There were also options to toggle into the actual adilas university site as a tab withing the side-by-side help window.
• There is a known missing gap here on the education and training side of things.
• There could be free levels, basic stuff, and deeper more paid type levels of training and consulting.
• There could also be certification levels, requirements, status, and other testing and certification stuff.
• We are hoping that the adilas lite and fracture project will make it even easier to help train the users and because they can tweak everything, there will actually be less of a need for certain pieces of the education and training. They will still be there, just hidden as needed.
• This could be a whole other business entity, if needed.
• A new user really wants to be guided through - holding their hand. An advanced user may not want any of that stuff in their way, just let them do it quickly.
• Link to this from the adilas cafe.
• If we do certifications, maybe show or allow some of that basic info to show to other users, if they are seeking trained professionals to help them out.
• If we have trained users, those become a value to others who are looking for help or pros on those topics.
• Adilas University could be a stand-alone product, or it could be interwoven with the entire site. Both have the same content, they just either have a standalone navigation system or we help navigate for them based on what page the users are on (context stuff).
• There could be levels to the training... Think of a triangle - simple, basic, intermediate, advanced, and deep or backend logic or design level stuff.
• There may be both external and internal training pieces. Along with that, we may have to have permissions or something that open/closes those training modules for certain people or parties.

14. Adilas Marketplace

• Part of the adilas cafe. People could sell their products and services, buy products and services. Including adilas skills and other professional skills.
• Adilas creates lots of byproducts. This is a way to help harness and gather up those byproducts. 
• Options for 3rd party solutions, white labeling, advertising, marketing, etc.
• Online mini marketplace for adilas products and/or our users could sell their products and services on a mini Amazon or eBay type level (mini consignment type shop built for our users and companies that use our products).
• Possible payment solutions with interest, fees, commissions, and other small kickbacks for using the marketplace.
• Limitless potential for other byproducts and additional services that could be added on to this piece of the puzzle.
• This may need a separate team to help run, manage, and administer this piece of the puzzle. Automate as much as possible.
• Here is a rough draft - Russell did - way back - don't get stuck here... It could be so much more. Adilas Market

15. Adilas Cafe & Community - Adilas World

• A landing spot outside of any corporation or entity.
• A corp selector - where can I go (have permissions or access)?
• Get to the marketplace type stuff.
• Get to the adilas university stuff.
• Forum type stuff - ask Q&A type stuff. This could be answered by staff and/or other users. This would need a moderator or forum manager.
• Let people show that they have the skills that others (businesses and/or individuals) could be looking for. This may include direct messaging or some other way of communicating.
• White labeling options.
• Standardized portal - single sign in be able to jump between servers and corporations.
• Dynamic billing and making payments.
• Mini marketplace for adilas products.
• Sales and creation of new accounts - tiered pricing and auto setup options
• News and updates - configure news feed as needed.
• Interface with other companies and corporations. Get assigned, hub type model.
• Work, play (demo sites), buy, sell, training, social stuff, and participate.

16. Databases, Networks, Servers, & IT

• This is the whole backend of the application or hardware side of things.
• Load management, reliability, up time, speed, redundancy, backups, storage, orchestration, etc.
• Lots of security needs and requirements. They will also be majorly involved in implementation of security.
• Code interacts with these things, but they are separate entities or divisions.
• We will need our own documentation, permissions, training, etc.
• Maintenance and upkeep, prototyping, standardizing, testing, databases, servers, hardware, clusters, network, security, IT stuff.
• Patches, updates, protection, hacker prevention stuff.
• Email servers, text or communication servers, web servers, database servers, backend logic servers (ColdFusion or whatever).
• Monitoring services, requests, traffic, load balancing, stats, specs, remote access, database indexing, automation scripts, tons of IT type stuff.
• Migration stuff, off-hour updates and maintenance, backups, restores, and other tasks.
• Move data around, put things into and out of cold storage, special bulk data manipulation stuff, zip and archiving things, etc.
• Future proofing things.
• Offloading bigger or longer processes.
• API sockets, API endpoints, and being able to load balance traffic, requests, deal with sessions, server config, clustering, and managing small microservices.
• We need a way to get rid or purge some of the pieces. The current system builds and builds. It never really releases or virtually poops (dumps).
• We would love to get a full data dictionary to allow our new frontend to be more data driven.
• This could be multiple people - DBA, IT/Server guys, etc. They could cross over, but these are high level skills and high level people or teams.
• Everything on the hosting side of things. This gets deep but just think - what do we need for hosting? - SSL's, domain names, hard drive space, spinning up servers just in time, pointer records, DNS, DSN, puppet, orchestration, bit bucket, code repositories, ColdFusion Administrator, Fusion Reactor, Papertrail, Nagios, tons of outside services and tools.
• Servers - hard drive sizes, backups, RAM, CPU's, configs, and the list goes on.
• This could go deep and deeper... Etc.

-------------------------

- Alan and I were playing with a mini version or what that might look like (see attached for a mini mock-up of the smaller mini model):

Adilas.biz - admin, monthly billing, and day to day running the company. They could do their own R&D (progress, speed, what the clients are wanting).

Sales & marketing - They could do their own R&D (advertising, pricing, features, marketing materials, etc.).

Consulting, tech support, setup & training, and retention. This could also be part of the adilas university (similar folk). They could do their own R&D (tied into sales, marketing, training, etc.).

Development stuff - project management, custom code, internal development, maintenance, & design. They could do their own R&D (code, frameworks, layouts, look and feel, etc.).

IT stuff - Databases, servers, hardware, hosting, etc. They could do their own R&D (speed, load balancing, redundancy, monitoring, etc.).

Marketplace and adilas cafe - This could be their own little piece or small team. They could do their own R&D (product research, options, pricing, hardware options, services, etc.).

We would love to see each of these sections or divisions (departments) be able to meet and interact with each other on a consistent basis (at least monthly or semi-monthly). Nobody is left on an island by themselves. Communication is huge.

Shannon was a great sounding board for me today. She often takes on that role and does a great job. Earlier this morning we had meetings on rules and regulations for accounting, a small question and answer session with an internal auditor, and a meeting dealing with servers, configuration, and custom project requests and needs. All over the place.

Here are some notes from our meeting today. It was pretty much all over the place as well. I guess that is us...

- Rules are part of the checks and balances. Having those rules in place create the checks and balances. Those rules help our company and culture to out live us. As needed, it is ok to keep changing the rules. Sometimes we feel like we have to nail it perfectly the first time... not so, we get to keep playing and playing and practicing as we go. That is super important.

- We play the game on a dynamic and changing playground - everyday.

- Talking about a rigid structure, like the internal audit we are conducting, do we want to be really structured or on purpose, be a more open type model?

- If we are trying to compare... our virtual boxes (where you store things and say, yes, that is done) are not a one and done type of box... our boxes sometimes takes days, weeks, months, and even years (plural).

- We are doing a lot of great things right now. Maybe just keep polishing and refining. A phrase that works for us is "tweaking" or micro adjustments.

- Often we try to be a perfectionist. That's hard for anyone to fill those shoes.

- A couple different models that are somewhat similar, if you look deep enough. The city on a floating platform powered by a core engine, a town that has a railroad or tracks helping to setup a town (a railroad town), the adilas jelly fish model (a cap of the monthly reoccurring business platform and all of the services that are needed to support that reoccurring monthly entity (code, design, consulting, training, project management, hardware, servers, data entry, other services). All of these models have a primary element that brings everything else together. Without the primary element, all of the other pieces would only exist by themselves as smaller independent pieces, there would be no need for grouping or combing assets and resources. That primary element is a big key to the puzzle.

- Shannon and I were talking about opposites. We said that a structured or linear format was one side of the puzzle. The other side of the puzzle was round or more all inclusive. Shannon kept using the word "sphere". Just for fun... think of one eternal round - not climbing a ladder but working and refining things all over the place - a sphere or data sphere type model.

- Going back to world building... If that is our goal, then a model of a sphere is perfect. Lots of different levels and pieces.

- What are our priorities?

- Seeking happiness vs full compliance. We talked about what drives people to work or do certain things. We brought up the points: some people work for money (pretty simple), some people may even work harder for other people (doing something for someone else), and some people may even work the hardest when they are driven by a cause (some form of deep passionate form of motivation more that other people and money).

- Our next few topics got into some mental factors that sometimes get overlooked. Such as fulfillment, progression, being able to take away comparison, and being ok with our own skin. That word comparison sure can add a lot of stress and pressure.

- Going back to the sphere concept, not an up or down, able to work on different levels and layers of the whole. All of the pieces of the puzzle are important.

- Concepts of the data assembly line - time based, checkpoints, flex bubbles, depth, permissions, advancing the ball as needed, ability to add in flex.

- Compassion to self and others - that is a huge thing. Be a little kinder, show some compassion.

This is sort of silly... but Shannon and I talk a lot about adilas and business principles in our meetings. We also end up talking a lot about just life in general. Maybe that's why we enjoy these meeting so much. It's a great time to reflect, learn, and express where things are at. Good stuff. I wouldn't trade it. I love it.

Shannon joined at 11 am and we wrapped up the prior meeting. Eventually, only Wayne and Shannon were on the meeting. These are a couple of notes that I got from Wayne. He is hitting walls and boundaries on the servers. He wants to keep pushing them forward and tuning them, but he needs the following three projects done:

1. We have two really big tables that need to be pared down. He wants to consolidate some of the fields into objects of settings. Currently, we have hundreds of settings, all in their own database fields and columns. That is ok, but it makes the tables so big that we can't change the database table engine from MyISAM tables to InnoDB tables. This is all related to different table structures on the MySQL database model. MyISAM tables are an older model and if a lock happens, it locks the entire table. The InnoDB tables are more modern and if a lock happens, it is on a line by line level vs a full table lock. There are also some performance options as well as security pieces that differ between the database table engines. Long story made short, Wayne wants us to prep things in order to convert everything to InnoDB tables.

2. Some of our databases are getting huge... Gigs and Gigs worth of data. That is awesome and means that things are getting used, but because of the structure, we can't split and load balance things very easily. We have to physically pull systems off of one system and put them on their own system to do the load balancing right now. This is a very manual process. We have a project called the datasource project or splitting up the database (bus to motorcycles - world building) project. There have been multiple efforts in this direction, but we keep getting pulled off of things. This would be huge and would allow us to change the size and configuration of the databases. Small companies would only be dealing with their data vs being on a somewhat shared environment and dealing with all of the other bigger businesses traffic. You can't access the other companies data (virtual walls and sandbox type environments), but there is basically other traffic from neighbors who are on the same server. In order to grow, like we would like to, we need to fix this.

3. The way we store files, images, and media/content limits our growth model. We allow systems to store and record information directly back to our boxes. That works great for single servers. However, if you plan on clustering and/or stacking servers, to get more power, that placement of those files and assets needs to be addressed. There are tons of other entries in the developer's notebook about media/content, servers, paths, and storage locations. It works great right now, but it also is somewhat limited in the scalability of those pieces. A single company won't see the limits, but the more companies that you get on there and playing with some of the same resources, that's where you see some of the scalability issues starting to show up. Some of those same limiting factors also prevent the clustering, stacking, and auto load balancing pieces. We need to figure out a way to store the files, images, and media/content assets in a place that is configurable vs hardcoded or built in to the app or software package.

As a side note on the file storage stuff, Wayne has some code that he was working on when we were kicking around the AWS (amazon web services) stuff. We may be able to harness some of that work and effort to make this happen.

Wayne wanted to know what are plans are for these 3 projects. I told him that I would email Steve and Cory and see what they say. Without putting anybody under the bus... we've known about some of these projects for years. We push on them here and there, but we haven't really finished up any of them yet. That's where it gets hard. We can't control all of the other variables (time, money, other projects, other demands, etc.). It's a challenge.

////////////////////////////////

Switching other to what Shannon and I were going over...

Lots of moving pieces and we are getting internal pressure to stabilize and standardize certain pieces. We have had quite a few of our key players state that we've had meetings and meetings and keep rehashing the same pieces with no changes. That gets really frustrating.

Currently, Steve and I's approach has been to keep chipping away at things and wearing multiple hats, all at once. Another analogy is spinning plates on a stick... We spin what we can and hopefully the other plates keep spinning. Sadly, we are dropping some of the plates here and there. There is a disconnect between what is needed (on a management level) and who is playing and what time is available. We are doing the best we can, but we really need some help.

Shannon and I met and talked about maximizing vs optimizing. We tend toward the maximizing side of things. That is pretty natural. We also talked about setting up a MVP (minimal viable plan) dealing with our management structure and business model. Shannon and I are going to be working on a business plan, but that could take weeks and weeks (months) to tighten up and finalize. We may need an MVP type approach for the time being.

As part of that, we are thinking of proposing the adilas jelly fish model as the current plan. Our goal would be to keep firming it up and moving into a more structured environment. We would like to specify lead dependables and cofounders in certain areas. Those would be the adilas team leads for the different areas and/or virtual departments. I think we could establish this type of an MVP plan for our business model pretty quickly.

Shannon and I also talked about a couple of the current hang-ups that we are seeing and facing. There is pain in transitions some times. Nobody wants to take on the full load, if they really know what is going on, due to it's size. Shannon and I chatted about pairing people up and almost doing a buddy type system to help with managing the different areas. We may need to mix and blend to create our teams. Some of those teams already exist, but they are very loose level teams. The goal is to firm that or those pieces up a bit. I think that would help.

Sometime "titles" have become a barrier. For example: nobody wants to be the main boss, the top executive, the full owner, etc. We may need to stick with words and phrases like: founders, cofounders, advisors, mentors, trustees, dependables, etc. Along with this... Shannon said, you guys love to create new terminology, why not do the same thing for what position you hold.

Good ideas coming in from all of the people around us. We need to keep coming up with our own company structure. Along with that, we need to decide and try things. It's ok to change it up later on. Nothing is set in stone. Think phases, pick and choose, and try storming type mentalities.

Shannon and I reviewed this previous element of time (#5295) and the drawings attached (scans and handwritten notes) to get some notes and it helped us go through a great discussion.

Russell and I were going to be meeting and going over projects and code. However, we switched gears and invited Chuck to join us and we did a small session on some vision for what we want our company to be and what kind of culture we would like. The notes below come from both a meeting with Chuck and Russell, as well as a meeting with Shannon to go over what these two had said. This is somewhat of a mix, but good stuff.

- From Russell and Chuck - What they want and/or are looking for:

- Group of people that we trust

- Able to express their ideas

- Big system - virtual floating orbital system/engine (see attached for a drawing from Russell) - Think of a floating city where there is enough room to build and build and each person could carve out their own space. Having said that, the whole (floating platform or city) is run off of a dynamic core engine and/or core structure. Once again, see the drawing.

- Each person could be as big as they wanted to be

- Platform

- Independent model

- Build what you want but help support the core or the core principles

- Feed yourself type model - this doesn't mean that you don't ever need help... it just means that you are a self starter and willing to work

- Incentives and benefits or year-end bonuses - health care, sick pay, vacation pay, new hardware, etc. Originally thinking bigger numbers like: $10K/per person >> 10 people on the team = $100K (original thoughts) - (stepping stones or later thoughts) $1K or $2K/per person >> 10 people on the team = $20K (after thoughts)

- Keep the freedom but also provide some of the other incentives that help keep people around - retention of good people

- Dreams... having dreams and being able to act on them... - From Chris Jonnie - We support people with dreams

- From Shannon - Almost like each person has their own freedom to run their own business, but they have the support and security of a small community - a fusion between owning and operating your own business and being an employee at the same time.

- Family comes first

- The guys liked that there was a limit to hours... just dealing with direct billing - you could still do your own thing - this includes management in the limit on hours per week. Stay in that healthy and maintainable realm - less burnout.

- Residual pay and reoccurring revenue

- For Steve - in order to help him - Question - How can we help to split your work load? - Maybe even doing a project to help with that.

- Sales - You've got to believe in it - what you are selling - Shannon and I were talking... Think about dad... he really believes in what he is pushing- He can pass on the excitement and the energy - even if it isn't quite soo cool (funny stories)

- Seeing a need or opportunity and being able to jump in you want to

- They loved - being able to think of something and then build a product or service or solution to match - still playing right along that platform type model - adilas creates all kinds of byproducts and byservices (pretend that is a new word).

- Training and keeping that model going... Maybe something like - work 10 hours, be able to do 1 hour of training. So, if you work 30 hours a week, that would be 3 hours of training that you could do. Keeping up on the new technologies - lots of self improvement options - all of these things build value.

- Our platform or our framework - some ownership or skin in the game

- Shannon and I - how can we focus on different places (departments or areas of need) within the adilas jelly fish model? - See the need and then help to point people in that correct direction - delegation at the bigger picture level

- Going back to helping Steve - how can we help pull some pieces off of him so that we don't burn him out. He is one of our greatest assets.

Scanning and recording some notes from a meeting with my daughter Aspen. She helped me out back on 5/7/20 and we took a few pages of handwritten notes. Great meeting. Recording some of those notes.

Got on a GoToMeeting with Shari O. The subject was dealing with email accounts, settings, and how to best handle some of those pieces. Here are a couple notes:

- Being able to send emails have been around for quite awhile. Here are some of the project rounds as I see them. 1. Can I do it? Yes, it is done and we can send emails for invoices, quotes, statements, and custom. 2. How well does that work? This is where we are at right now. We could really use more histories, logging, error handling, notifications,  Wayne's touch, Russell's touch, etc. 3. The third round might be full automation and being able skip adilas all together to get the emails and communications going.

- We talked about outsourcing some of the big and small projects and pieces. There are times that we really need more manpower and skills.

- There are waves that pass over all of us. If we watch out for each other, we can help de-stress and transfer the load as needed.

- Shari O. and I talked about the jelly fish model - dealing with how the adilas model, tasks, and talent pool is constructed. See attached for a rough drawing.

Lots of different topics today. Mostly it was just Steve and I on the morning meeting. We covered sales ideas, some strategy, intellectual property stuff, investment ideas, and a full report on numerous meetings that went on yesterday with some of our dependables. Good stuff. Steve and I also drew some things (using the GoToMeeting drawing tools), talked over ideas, and did a little bit of dreaming.

Wayne joined us for about half and hour. We talked servers, splitting up databases, automated SQL scripts, and other server topics.

Steve would really like to get back to the sales side of things. He has been helping out on the developer side of things for years. It seems that we are really getting a good team and we may be able to let him go play out in sales, where he wants to be. As a fun side note, he is seeing sales more than just monthly reoccurring for system usage. He is seeing setup, training, consulting, project management, custom code, design, and even server options as new avenues where he could start playing. Almost the "Jelly Fish Model" where there is a bigger overarching umbrella and then tons of smaller sub pieces underneath that. See attached for a scan of a post it note.