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 on project overviews. We did some work on the adilas cafe overview and then on to the adilas lite and fracture overviews. We made a few website changes and Shannon attached the documents that we are working on. See attached.

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

Meeting with Shannon. Looking for and seeing trends and patterns. Some of the hot topics right now are building industry specific skins (customer interfaces), BI or business intelligence reporting, AI or artificial intelligence options and marketing, job costing, manufacturing, and harvesting services and byproducts that adilas creates.

We spent most of our session reviewing and working on notes for the adilas university project dealing with education and training (No. 3 in the adilas lite or fracture plan). See attached for our notes and progress.

Just for fun, Shannon and I were talking, and we made an analogy of chasing a ball down the hill. It just keeps going (out in front of you). We talked about communications and collaboration options. We, our goal, is to stay out in front of the guys/gals with some rough plans. As the guys/gals get to the next levels, they will be looking for the next thing. We will keep feeding in the pieces that we have done or roughed out. We will let them interpret those plans and make them (the plans) their own. Basically, help to point and influence a direction without directly forcing it.

We also talked about how we learn by repetition and relearning things over and over again. It seems to really help to write things down, then re-sharing it back to someone else. That helps it gain clarity and makes it stick better.

Sometimes we present our clients with tooooo many options. We love that but it can be overwhelming and distracting to someone who is brand new. As part of our discussion on education and training, we talked a lot about industry specific skins and matching training and verbiage to those industry specific skins. See our attached notes for some other ideas.

Lastly, as we were talking, I mentioned to Shannon that Steve has a dream of offering basic business classes (business principles) to cities and communities. He would like to use adilas as the teaching tool. The class would be on the business principles, we would just use adilas to show those principles (how to do it and how easy it is to do it using adilas). I also wanted to record that another dream that Steve has is jumping in his plane and flying around and talking to CPA's. If CPA's really used adilas and adilas for their clients, they could do way more tax returns and also offer other ongoing oversight services, consulting, training, etc. It could be pretty cool! Just wanted to record those ideas from past meetings with Steve.

Meeting with Shannon. One of the goals is helping Steve out with sales. On our overviews... for the adilas lite and fracture project, we would like to cut things down to the top 3 main pieces or topics. Maybe simplify the adilas lite model (web pages - take off the accordions and make it really simple...).  What are the three main points? Less is more. Focused and to the point. We did some comparing between the old and the new. When we can, some of the new graphics are going to be worth a thousand words.

Meeting with Kelly and Cory and Shari O. over a Zoom meeting. The main goal of the meeting was to look at some bad data for a client on data 10. We can't make it happen again, it was data from well over 1.5 years ago, and everything since then has been good. I'm just being silly, but it was a bit of a beat-up drill and a brow lashing of sorts. The good thing is we found the issue (limited number of bad records). At least we have a starting point to work from. We do not have a plan yet but that will come.

I was pitching the idea of a known issues report. Instead of just showing data (normal reports), we could actually look for bad data or errors in our code or data mismatches. That would be a small level of AI (artificial intelligence) on the reporting side. Imagine a report that said... check this and that... these things are known to be off the rails. That would be super cool. Side note, we actually started a known issues report way back (3/11/09)... at least listing out known areas that might have trouble. We just haven't been able to get around to building out that report. The actual report is in our code at this location... (top_secret/secure/known_issues.cfm). It has a huge list of possible problem areas, date mismatches, flow problems (something happened out of order or out of normal flow), and id/relationship possible problems.

As soon as we get a chance, it would be super cool to help uncover these and other possible problems and issues. Kelly had the idea of working backwards to help find the errors and exceptions.

One big take away, and something that we want to keep in mind for fracture (adilas lite) are these key pillars... We track money, inventory, finances, and full histories (Kelly was saying that those pieces are huge keys to what makes adilas awesome).

Note form Cory about what the meeting was going to be about: Cannapages has been trying to connect to Leafly through our API. We have opened up two API's for them but they are still having issues. Steve suggested a quick meeting with you to help facilitate this.

Here are my notes from the call, conversation, and meeting:

- They, the Cannapages guys, are super into their own vertical. They had some deep questions about things that are very specific to their industry. We use a very general or generic tool that has lots of dynamics. That works great for our clients as they are able to setup whatever key datapoints that they need. That is not very good if you are trying to standardize things and play with economy of scale (lots of people doing the same thing). There is a need for things to be standardized.

- Lots of talk about setting standards for certain 3rd party solutions and integrations. We can allow our users to set them up or we could automate things and either lead them through a valid setup and/or force them to use certain attributes and flows. If things are more standard, it just helps downstream flow and data transfer and sharing. Basically, a way to get normalized data for a specific integration and/or 3rd party solution.

- Our developers have full access to the whole adilas database. Some of the outside developers have to use API sockets and connections to open up specific endpoints. That is great and all but can be very frustrating, if they don't know which endpoints to use (virtual windows and doors into the data and records). Lots of talk about documentation and ease of use, from an outside developer's point of view.

- What is the best or biggest value for our customers or for the people using it? Some of our customers are real clients and some are outside developers. Keep those different parties in mind when developing. They have different needs.

- There are costs to do industry specific hook-ups. There needs to be a plan, settings, requirements, and set standards per integration. Otherwise, the outside developers feel like they are chasing their tails.

- Making things human readable... Many of our API sockets (backend developer endpoints through the API) are coded to id numbers or techy look-ups. Some of these outside developers really want an easy way to get at the data (plain English vs techy id look-ups). We spent some time talking about building different attribute look-ups based on text or names vs id or control number stuff. That led to talks about requirements, possible mapping options, and making settings that help with setup and automation. Otherwise, there are too many variables.

- This 3rd party needs lots of specific and categorized data (called meta data). We talked a lot about meta publishing data and being able to construct the names and associated data values. We need to put the data in the correct columns and in the correct format (standards). That makes it easier for filtering and matching things. Eventually, things will get parsed or broken up into smaller and smaller parts and pieces. This allows for things to be tagged and flagged as certain things. Once again, getting clear down to the meta data level.

- They gave us a few wish lists for the existing API. Cory took some notes there. Basically, was to standardize things and make it go and flow faster for them.

- I didn't know this, but the Cannapages guys are actually building a standalone side project to help some of our clients. Imagine something like this... a bulk tool that takes raw inventory data from adilas, strips out what they need (for their industry), standardizes it, allows for bulk edits and classifications, and then takes the new data (in bulk) and adds it to their database. They then serve up that modified data to an outside 3rd party that does or has a key industry specific website and data filtration process. I didn't really know what they were doing until this meeting. We are not even as close to industry specific as these guys are. It's basically a 3rd party bulk tool to provide data to another 3rd party. Kinda interesting.

- The last major topic was data and views. We have data (what is needed and recorded) and views (what it looks like) for multiple different parties. We have to have views and data for employee/users, data and views for state compliance agencies, and data and views for outside or normal customers, clients, and patients. That's a lot of different data and possible views (what it looks like). All of that, based off of stored data that got stored and entered into the system. Pretty high requirements.

- Some of the above notes may apply to our future fracture and adilas lite build outs. Whether it is dealing with different views, industry specific skins, normalizing data, and making the API sockets and endpoints easier to use and consume (plain English vs techy id/number stuff). Lots of good lessons being learned by being in the trenches.

Meeting with Cory and Shari O. on projects. We went over some yearend documents and forms and progress there. We spent quite a bit of time on some new quotes. One was a revamp on a prior quote. We added in some new requirements and needs for histories for flex attributes. Randomly enough, there were other requests for other hidden history records and reports. Some of our clients want us to watch almost every single place and record histories (some visual to the users and some that are hidden and only seen by administrators). I thought that was very interesting and something that we need to be on top of for fracture and adilas lite.

One of the places that they want us to watch was settings and who turns things on/off (like a gram controller for the shopping cart) and other setting changes. We also went over more requests to tie things to elements of time (like PO's and E/R's). We have some clients that are using elements of time for help with production runs and delivery options. Interesting what people need.

The last quote that we worked on was for a better or more standard report or export for the balance sheet, P&L (income statement), and general chart of accounts (deposit types and expense types and balance sheet types). The requests was for a report that showed each segment in a nice grid like fashion. On some of the existing reports, the values are all there, they are just hyphenated, the request was to break each data piece down and export it in a simplified grid, no other formatting. I think that the end goal is to pull it into Microsoft Excel and do some tweaking of the data and values there. Just guessing.

The last thing that I wanted to say was put in another plug for better aggregated data to help provide some better speed and business intelligence (BI). We have this planned as part of the fracture and adilas lite project, it just takes time and resources to get there. There is a whole project called the adilas value add-on core model where we will be working on these layers over and on top of the transactional core. Just for fun, here is a link with other references to the adilas value add-on core model.

Random start to the morning. I was planning on doing some yearend payroll updates. I ended up doing about 2.5 hours of phone calls instead. Emails and then a quick phone call with Calvin Chipman. He was trying to help a client with some changes to an inventory API socket for custom labels.

I then got a phone call from Steve. We were chatting for over an hour. Good update on where things are at, current projects, upcoming projects, sales, networking connections, update on ship A and ship B (current adilas vs fracture or adilas lite). I told Steve that we have gathered tons of information and notes. We are now formatting things and trying to make that information get into a presentable version and format. We have tons and tons of the main things researched and prepped. Anyways, that will continue to unfold as we roll into 2024. Great phone call. We also talked about developers and clients.

After talking on the phone with Steve, I got on a call with Bryan. He had some questions on where we are going with certain projects and looking for direction. Jumped back on a call with Calvin and we did some testing and debugging on the API socket calls. We ended up on the phone for over 45 minutes. Testing and looking at things on data 4 for the client. Emails back and forth with info.

Good work session with Shannon. We were going over the SWOT analysis document. See attached for our progress. We are currently working through the weaknesses section. We had some great conversations and are definitely learning some great lessons and things. We are also trying to capture the story and history from ship A (original adilas) and trying to figure out what we want to do with fracture or adilas light (ship B or the next level of the adilas application, platform, and system).

- Just for fun. Here were a few things that I wrote down today. See attached for tons more notes and ideas.

- Adilas is like a buffet with access to a kitchen as well. Instead of just getting an all you can eat buffet, imagine the possibilities if you could arrange, cook, and alter what is provided. Kinda fun to think about it.

- Sometimes talking through things and about things helps bring clarity as we talk and have open and honest discussions on certain topics.

- Being real - sometimes not the most comfortable - being vulnerable and showing or admitting weaknesses.

I really enjoyed our session today. We are talking about things that we are learning that are normal everyday life lessons, not just adilas lessons. That's pretty cool!

Meeting with Shannon. We were going over the SWOT analysis document. Shannon had taken all of the pieces and put them together into a single document. See attached. It is very rough still, but a good start. Most of our session we were talking about plans and how we want to organize things. We decided to do two different SWOT analysis. One will be for the current - ship A - or adilas as it is right now. The other will be ship B - fracture or adilas lite - where we are headed. We also decided that we are going to do a small summary (quick and dirty) and then provide more for those who really want to read it. Not everybody likes to pour over all of the details.

Meeting with Shannon. She is planning on helping me two days a week going through Ship B stuff for fracture and adilas lite. Our goal is to start going through the outline (high-level look at the upcoming projects) and detailing things out. That is exciting.

We also went over a book called "Who Moved My Cheese" by Dr. Spencer Johnson. This was an assignment that I gave her. See attached for some of our notes. We had a good discussion and chatted for a bit.

We also put a few new elements of time on the calendar for the next couple of weeks. Good stuff.

Meeting with Alan over the GoToMeeting session. We did some catch-up and then started talking about plans and priorities. Alan was saying that we could potentially break things down into smaller and smaller pieces. We totally will and need to do that. Just for fun, he said, we could start fracturing fracture (project codename). We looked at the 7-8 projects for adilas lite and talked about priorities and how each one plays into the others. We are planning on focusing more on the value add-on core model project next. We need to lay some things out, define it, and then (even now) start building some of those pieces.

Anything that can be reusable, including concepts and code, we want to build out those pieces. Be able to reuse as much as possible. That way they can help both ship A and ship B out. Good catch-up meeting.

We decided that for the next couple of weeks, we would both focus on some ship A stuff to help out the main adilas system. We have a small deadline to try to hit by October 1st.

Adding some small tweaks to the main adilas lite website (view page). Added a crumb trail, new sub navigation to bounce to each subpage, a more standard header, and a link to the fracture - PDF outline. Pushed up new code.

On the phone with Steve going over a new possible shopping cart. We talked tech stuff, look and feel stuff, as well as logic stuff. Steve has a client that really wants a scan only cart (just barcodes, nothing else). We talked about the pro and cons and challenges of different possibilities and paths. We decided to mix and blend some of the tech.

We also talked about how some of our competition shoots for a best-in-class status but only does one a small portion of the puzzle. The end user or companies are then required to use multiple pieces of software, and then try to marry them together in some sort of mash-up or combined solution (conglomerate) of sorts. That creates other pains and problems. Our systemized approach has some great value.

Steve and I also talked about how some of the new fracture (adilas lite) code is actually project # 6 on the to do list. We can really help push on ship A (current adilas model) before we jump right into fracture. That's a good plan, for now.

Recording notes from earlier meetings. Spent some time reading over a document with a general outline of the adilas lite and fracture projects. Got the outline document from Hamid last night. I made a few small changes. Making progress. See attached for both the original from Hamid and few of my changes. We are going to bat it around a bit and figure out what else is needed. Nice little work session.

Emails and getting ready for the day.

Zoom meeting with Russell. See my notes below.

After meeting with Russell, I was on a phone call with John for about 30 minutes. Talking about what is going on with Adilas and Adilas Lite. Going over possible work options. He is going to reach out to Steve and Cory and we'll go from there.

Some of my notes from meeting with Russell:

- Working with Russell on his tool and homemade framework project. He has learned a lot by building it. He can then take that information and know how and apply it to his other projects. Interesting learning method.

- We talked about project bloat - and how using outside libraries and themes are faster, but it tends to bloat the project (you get more than you want or need - code wise).

- Instruction heavy vs automated

- A framework sets a standard. You can then start expecting certain things. Almost like a miniature set of rules and expectations.

- Starter kits vs the end all, be all - You have to start somewhere. Things will keep morphing over time.

- Tools tend to be built as a box (sort of rigid). Often, people and companies want to add on to the box (customize or add custom code or custom work flow). You then have to ask yourself, does your (my) code fit in the box? Yes/No - then trying to match up tools with company structure and needs. Russell was drawing a standard code set and then a non-standard code set. Imagine one being like a box and the other looking like a blob or a flower with different peddles. We were talking about what fits in the box and what has to be custom. We had some good conversations about that. What is the core? What are the plugins? What is custom? What is allowed? What tools or tooling is being used? Etc.

- API's and API sockets - Allowing outside parties to virtually play at the wall - The backend code could be whatever. The frontend is more structured, meaning the API interface needs to be open to outside traffic (permissioned and approved) and a standard that could be used over and over again. Basically, how it is presented back to the user or developer, needs to be well documented and as standard as possible. The true backend has more flexibility. The backend creates the content that is given back. It also interprets the inbound requests.

- The system and it's architecture and code are all based on trade-offs. You then have to accept those trade-offs. Speed, flexibility, rigidity, rules, scale, custom, standard, hardcoded, dynamic, etc. You have to look and balance the trade-offs.

- If you are doing the full API socket thing, you could actually do a headless CMS (content management system). Basically, if you are going the API route for quick and dirty stuff, it (the new application) doesn't have to look like or follow the same rules (thus becoming headless). You separate the content from the layout or view of that content. Imagine a WordPress type app that is built better and interacts with our internal pieces. We talked about the flexibility of the API. It would be so cool if you could mix and match API calls (quickness) and the whole power of the adilas backend. Inbound and outbound requests could return simple JSON. Lots of potential here. For fracture and adilas lite, we want to run the whole thing off of API socket calls. Our own internal headless CMS, in a way.

- Doing everything on your own (one man show or lone wolf) requires you to know too many topics and subjects. Jack of many trades, master of none. You can gain a lot by allowing for specialists and teams. Correctly done, they can make some amazing things happen.

- Setting up rules and then enforcing those rules. Firm, fair, consistent.

- When pushing API content back, sometimes it is helpful if you can add in helpful stuff to help out the users - For example: Pagination values and page links. Ideally, it is all done through settings, requests, and options. Only return what they want, but make it available if needed. Try to think - what would help the user and/or developer on the other side of the API request?

- Building out basic functions that could be plug and play (self-documenting, self-validating, etc.)

- Russell is trying to build an auto generating REST API for his stuff. The auto generating portion is based on the database (data dictionary). Virtually a set of interpreted rules, assignments, and instruction.

- There is a database level and a service level. Each needs to be built separately. In our terms, we are trying to do DAO's (data or database access objects) and services (things that do something including connecting to the DAO's).

- Build the super complex stuff once, and then use it many.

- We talked about the analogy of a set of railroad tracks. If you build out the known railroad tracks and have proven the methods, you can use it over and over again. Railroad tracks are great for that. If you have to keep building out new ones, and you don't get to use them over and over again, why make railroad tracks, make a simple road instead.

- Figuring out your own testing strategy

- Helping the users use things correctly based on validation and/or information or feedback to the users. Basically, force them down the path and don't give them too much wiggle room (helps the devs manage things). Sometimes too many choices cause more problems.

- Usability and error handling and error messages (good communication back to the client or end-user or even back to the developers).

- From Russell - When your code structure or architecture is bad, your testing will scream at you. If you have a good structure or architecture, your tests should be easy or easier.

- The value of training

- If the servers are down, you don't build tests, you just fix. If you have the time, you build the tests and get the whole thing done.

- Having a good system helps you go faster.

- Dealing with testing, you are going to test anyways, may as well write it in a test. This enables you to be able to go back and rerun those tests. If you have good tests, it should help you in finding those error and bugs faster. Progress moves at the speed of trust. If it's your mess (code), you know how to clean it up and fix it, you also know what it affects (touches or reaches out to - dependencies). What about the other guy (someone who comes in and works on your code)? How do you pass on the notes and instructions? You really have to think about looking out for the other guys/gals that will be coming along later.

We had an update meeting to show progress on ship B stuff (adilas lite and fracture). We had 10 people on the meeting. We had Alan, Hamid, Steve, Sean, Danny, Cory, Shari O., Shannon, Bryan, and Brandon (myself).

We did record it. The recording is right about an hour long. The first 20-30 minutes were from Alan going over market research and tech deck decisions for fracture. After that, I introduced a new website to publish some of our work on the adilas lite or fracture project. Here are a couple of links:

Adilas Lite - Project Home - https://data0.adilas.biz/lite/

Adilas Lite - Videos & Research - https://data0.adilas.biz/lite/adilas_lite_videos.cfm

The meeting went well. As a side note, Shari O. recommended that we have a fun, non work, meeting just to catch-up and say hi and what not. She is kinda like our mother hen, for the adilas team. Fun times. See attached for some other videos and assets.

After the meeting, I spent some time uploading things and doing some light clean-up from the day. Busy day. 

Back working on the website for adilas lite projects (fracture). Trying to get the main pages in place for our meeting tonight.

Alan I jumped on a GoToMeeting session for about 15 minutes to go over the flow and agenda for tonight's meeting. He handed off a PowerPoint for his part of the presentation. I showed him the work that I was doing for the web page for adilas lite and fracture stuff.

After Alan and I finished. I pushed up some new code on the adilas lite (fracture) site for some of the videos that we have been working on. That's a cool little resource and shows a bunch of the videos that we have harvested from Jonathan Wells and his Adobe XD documents. Good stuff. Here is the link to that site (video resources): https://data0.adilas.biz/lite/adilas_lite_videos.cfm

Working on a new website to help highlight and show adilas lite (fracture) projects. Here is the new site address: https://data0.adilas.biz/lite/

Video prep work on the adilas style guide and some possible look and feel options. Taking ideas from Jonathan Wells and some of his Adobe XD mock-ups.

- Video - Fracture style guide overview - 00:02:08

Also got a call from Eric. He is working on some new functionality for tips on credit card transactions. We talked about a number of options including some possible settings. I was recommending that we somewhat follow the existing code for change due on cart and invoice payments. We talked some accounting and Eric is going to reach out to a few other people and contacts to make sure that we have all of the pieces that we need. Good stuff.

Went back in and did another video showing some of the existing navigation, pieces, and elements. This one is a little bit more raw (showing it in the Adobe XD interface) vs a nice slide or PowerPoint type view.

- Video - Mapping out the system - 00:05:00

Chaning my email settings and trying to get things working locally on my computer. I could use a web interface to get to my email, but I couldn't use Outlook Express, on my local laptop. We just changed some email server stuff.

Back looking through Adobe XD files and prep work for harvesting small R&D videos from stuff that Jonathan Wells did for us. Made two new videos. One for the cart and one for a small tour of the fracture or adilas lite interface. See attached.

- Video - Internal shopping cart - round 1 - 00:03:49

- Video - Fracture - Tour of the interface for adilas lite - 00:05:05

Also did some prep work for one on some different look and feel options and the beginnings of an adilas style guide.

I got a phone call from Shannon, my sister, and she was checking in and seeing if she could help out a bit. That would be awesome. She has been a huge asset, over and over again. I would love her help. That's exciting!

Zoom meeting with Russell. We were going over some testing strategies and ideas on how to get better overall testing coverage. Pros and cons and costs of testing or costs of not testing. He was showing me a project that he is working on, and I was asking questions and taking notes. Here are a few things that I wrote down.

- The company that Russell works for allows for 4 hours a week for continuing education. That's pretty cool. I like that idea.

- We looked at some Lucid chart diagrams. UML diagrams, flow charts, and wireframe diagrams.

- Talked about stacking API socket requests using GraphQL vs simple or single Rest API calls.

- Patterns and strategies

- Using a data dictionary of sorts - For example: Defining a field, it's value, it's name, it's datatype, etc. We have a table inside of adilas called db_field_settings. It allows for things like: mins, maxes, validation rules, sort orders, names, aliases, special instructions, look-up values, defaults, etc. That's not exactly what a data dictionary is, but we will end up using more and more of this type of things as build out fracture. I have many needs for this level of control inside the application. Here is an example of a past entry dealing with elements of time and time templates (see EOT # 8004).

- Pseudo code, tracer code, or simple scratch files. Great way to get started and do mini prototyping without having to tie in everything.

- Different kinds of testing - unit testing, integration testing, and end to end testing. They tend to go in that order... if you are building new. They sometimes go in reverse order if you are adding tests for existing pieces. It depends on your architecture. Usually, you will have the most unit tests, then less integration tests, and even less end to end tests. That's the ideal.

- From Russell - If your tests are hard to write, then your code architecture may need some help.

- Providing a mock or mocked up data. Often, you may want to certify that your mock is similar to what really happens with real data. You want to make sure that you are comparing apples to apples. Ideally, you don't want to run tests on production servers. Most of the testing is pre-production, if possible.

- Russell and I were talking about time management. Often, we get pulled in different directions. We tend to go where we are needed. That may not always be where we want to go.

- There are huge demands in all areas. Backend, frontend, and even middle management stuff.

- With good testing and good testing coverage, it almost allows for a license to be almost careless in refactoring. If it needs fixing, you can just fix it vs leaving it alone because it may break something else. If something is wrong and you don't fix it, and you keep building on that piece or function, you tend to stack up technical debt.

- Everything has a connected ripple type affect. If you add more people, you will need to add more people to manage those people and what they are doing. Everything in a system affects other pieces of the puzzle or system (ecosystem).

- We talked about the challenges of a multi-use scenario or how our users use our product. Each company is so different. That can really make it kind of hard to test and predict every scenario. Welcome to our world.

- At some point, you almost feel like you have lost control of your users and what they do. It's almost too open or too freeform. There are pros and cons to that approach. It tends to come down to three things - 1. Permissions, 2. Settings, and 3. Templates or virtual instructions (rules and assignments).

- Lots of time talking about pressure from upper management, budgets, timelines, or others (even clients). What happens if you push things out too quickly? You end up getting what you pay for. It's really hard to get both fast code and good code (bug free and super stable). If you want the more stable code, you have to plan it out, build it out, plan the testing, check it off, and probably do more testing. The combo of both fast and good is really hard to get, especially if you have multiple developers involved. Long story made short, it takes time and planning.

- What price are you willing to pay? Great question.

- Learning about different tools and when to best use them. Each tool is best suited for a specific task and/or activity. Not every job only uses a hammer (and nothing else). It depends on the job. The hammer might be the correct choice, but it may not be. It all depends on job (project, task, activity, function).

- Start where you are and build from there.

- If your code is modular, well tested, that allows for future refactoring.

Lunch meeting with Josh Hanks. He's a friend from church and lives close by me in Richmond, UT. He has a fun startup story, and I found a lot of similarities to how I got started. He would go work for a company, figure out their processes, make improvements, and help them become better. Anyways, we had a fun chat and were able to find a number of similar circumstances as we got started.

Josh has used a few different CRM (customer relationship management) tools and I was going to pick his brain on likes, dislikes, wish lists, etc. See attached for some of my notes. Fun conversations and topics.

Here are a few takeaways:

- On SaaS (software as a service), here are some of the main complaints (not our product specifically but in general). People don't like extra steps, or required steps added by admin to do simple things. If the interface is too hard or too many clicks, it turns people off. If changes are made to flow, processes, or verbiage, people want to know (and yet they don't want to know everything - delicate balance).

- Mobile is really nice, but there are certain things that still work so much better on a laptop or desktop environment.

- Almost all of us have numerous channels and applications to use and balance. That could be emails, messaging, calendars, software, etc.

- People like to be able to edit things. If you lock it down too tight, it causes different problems. Let permissions, histories, and settings play in as needed to keep things secure but still open.

- People like options to control popups, reminders, feedback, snooze options, finished/completions, follow-ups, etc. They just want to control what hits them (virtually).

- There can be major pain trying to bounce and juggle too many calendars. For example, one for CRM stuff, one for projects, one for mail stuff, and one for personal. It can get kinda crazy. Lots of bouncing between multiple windows.

- We talked about one-to-many relationships and subs of time.

- As a wish list for CRM software - Josh loves to see recent activity, follow-ups, associated quotes, associated projects, progress and completion percentages, and even projections. Other things that are needed are good data, quick access, quick notes, and great drill-downs to other details and information.

- We talked lots about the need for custom fields and custom data points - per industry and per company.

- Opportunity costs and client acquisition costs - the hidden costs.

- The whole last part of the conversation flipped from CRM over to logging projects, hours (timecards per project or per location), quick notes, and logging mileage. Ideally, all of those things all nice and tied together. Josh was wanting and needing an app to do just those things (projects, hours, notes, and mileage). We talked about maybe making a mini version on some adilas features to make that happen. That could be really cool. The other need to that was availability to upload pictures and scans to those calendar events. Here's the kicker, we already do all of those things inside of adilas. We would just have to tweak it a little bit to make it flow, just like he wants. A small custom wire job of the existing tools and features. Pretty cool!

- Lastly, this is more for me, but when we build out fracture and adilas lite, I really want to revisit the settings and options for elements of time and scheduling. See element of time 8004 in the shop for more details. Lots of cool ideas.

Phone call with Hamid. Touching base and going over some ideas for fracture and adilas lite. We talked about possible networking options with our connections. We also spent quite a bit of time going over some tech stack decisions and talking about needs for adilas lite. We went over three main avenues. 1. Is Planning - business plans, tech documents, etc. 2. Training needs - both internal and external, and 3. More billboard sites - sites that point to adilas. We talked about banking hours and no limits as far as investment opportunities (working hours for future payoffs and percentage ownership options). Nice phone call.

Meeting with Alan. Going over some market research that he was doing. I took a few screenshots of what he was showing me. See attached. Here are some rough notes:

- What does Adilas have that is unique - Everything under one roof, operations based accounting, in-depth inventory management, flex grid (custom data relationships), completely customizable, tons of permissions and settings, and ability to track things (inventory, financials, etc.) through time.

- What do others have - Their sites look more modern/nicer, single page applications, eCommerce integration with outside platforms (they don't have their own), mobile app available, nice page showing pricing, they have done lots of advertising/marketing.

See attachments for more details. We also went over possible ways of integrating adilas lite (fracture) with banks to help speed things up. This could be done by integrating with a system called Plaid or other software. We also spent some time talking about outside eCommerce integrations such as Amazon or whatever. We could still offer our own, plus integrate with other bigger key players (as we choose, or our clients make requests and are willing to help fund the development efforts).

Alan is using Adobe XD as a huge whiteboard and then moving things and pieces around as needed. Basically, brainstorming, putting together different elements on the screen, and then moving or organizing them in a big drag-and-drop type interface. He's using it like a giant whiteboard of sorts.

As part of our discussion, we were talking about our approach vs other company's approach. It seems that most other companies, at least right now, are doing some sort of super mashup type system. They have a product, but the big selling points are the integrations with outside parties or other sites or services. That may sound awesome, but there is some pain there as well (trying to marry everything together). Adilas is more along the lines of a single system that is fully integrated and then ties out to outside sites and services, if needed. Here is a link to a hand drawn graphic that shows the difference in approach.

Towards the end of our meeting, Alan was mentioning that we should focus on who is already using our platform and try to get more of those kinds of people onboard. Create some synergy of sorts. I mentioned that, not only could we do that, but we might be able to offer white label options for certain industries and business verticals.

The last thing that we went over was some market research stuff that Danny is working on. See attached for a screenshot of that as well. After the meeting, I spent some time reading the other sub documents and older sales meeting notes. Good meeting.

Meeting with Aspen. She gave me a full on presentation (powerpoint with 11 sides and tons of notes) on documentation processes and how we are going to do things inside of adilas. See elements of time # 10372 (hours worked by Aspen on fracture) for more details. It may be hidden from view (non-show on the web). Got her paid for her work that she is doing. Entered the reimbursement into adilas.

Quick meeting with Alan. We touched base on where we are at and how is doing what. I've been looking at Adobe XD documents from Jonathan Wells and doing XD training tutorials. I've also been digitizing notes and linking things together. Alan is working on a small wireframe for the adilas cafe login. He is also doing some research on modern UI/UX requirements and expectations. We talked about some domain names and also looking at billboard type sites for pointers to the main adilas.biz site.

I'm going to be harvesting Adobe XD videos and mock-ups. Alan is going to be working on features and making a nice list of features. I pointed him to a document that Shannon and I did for the presentation gallery and a backend outline of some of the features. This is not meant for the public (yet) but it will be a good resource.

We looked at the calendar and decided that we would shoot for our next group meeting for adilas lite and fracture to be on 8/30/23 (a couple weeks away from today). Good stuff.

After the meeting, I went and purchased a few domain names to claim our spot. Also did some other small to do list items.

Working with Alan on ship B, fracture, and adilas lite stuff. We were reporting on what we have been doing and who is doing what. Alan has been digging in deeper and checking out ColdBox, CommandBox, React, VueJS (vue), and other code frameworks. I took a few screenshots of his notes (see attached). Here are some other topics that we talked about:

- We would like to organize the features that we want to include and build out. Still on the wish list - to get this done and all organized

- Code style guides

- Features of CommandBox and ColdBox - products by Ortus Solutions - automation with Git (code repository stuff), sanitizing, formatting, and standardizing data and code.

- Alan is leaning towards VueJS vs React JS. We went over some pros and cons.

- Our current choice or pick for our tech stack is looking something like this: CommandBox, ColdBox, Lucee/ColdFusion, MSQL, Bootstrap 5, and VueJS.

- Lots of talk about routing, events, handlers, and MVC layers and levels (MVC = model view controller framework or methodology).

- Integrated testing for integration test and unit testing.

- Custom layouts

- Lots of white labeling options and data driven design and data driven settings.

- Nesting or sub architecture and modules - inheriting different things

- Little baby apps or configurable widgets

- Building out prototypes and playing with concepts, ideas, and options

- Layers and everything going through API sockets or API endpoints

- We would love to get into drag and drop widgets and options to create your own layouts. This would allow for either preset widgets or mini widgets that could be places, configured, and added to dashboards as needed. Super cool!

- Use of popup modals and one-pager type interfaces.

- We want tons of asynchronous type actions and transactions. Certain things need to flow step by step, but other things can be done asynchronously.

- To start out with, maybe a light mode and dark mode, to keep it simple. We may add more other custom look and feel options later on.

- Doing wireframes and then rolling over to actual mock-ups.

- We would like to look at some of our past R&D options from Jonathan Wells (designer and prototype guy).

Working with Bryan on layout and style guide stuff. Code sign-off, merged, and pushed up some code. As we were working, I noticed a few things that we could do better on...

- We need to make sure that we don't have polluted data, especially on the testing and demo sites. We use them for so many different things and don't finish all of the processes. We end up with polluted data or incorrect data.

- We need more histories on things like sub inventory, parent attributes, corp-wide settings, and other high-level places. We have tons of histories on invoices, customers, deposits, parts/items, etc. We just need to add those other histories to the list. This would be a good thing for the fracture project.

- If we have a big mess, say in a demo site, and it needs to be changed - it sure would be nice if we had some bulk clean-up tools or system admin tools that were super high level but could help clean-up or change data in bulk. We may not want these tools available for normal users (could be a problem).

- Full visibility and full searchability - everything needs search options, exports, reports, and histories.

After Bryan and I finished up on some of the code sign-off and reports that we were working on, we switched gears and started talking about some location-based grouping of data. We ran out of time, but I gave him some small things that will help, and he was going to go in and play with those suggestions.

We had a request from a client to add in some client-side validation to our forms and pages. They submit things and then get an error, when they click the back button, the form has removed their work and they have to do it again. That's the browser that does that, but we could help by having client-side validation to help prompt them even before they submit the page or the form. We really want full coverage of this (client-side validation and server-side validation) for the upcoming fracture or adilas lite project.

Sean got ahold of me and needed his custom credit card fee, that we did for a trailer rental client, to show up at the end of the invoice. The code adds the fee whenever the invoice or cart goes past a certain amount. Because it was just in memory (in the cart), it was hard to control where it would show up. It was just another line item. Anyways, we added some code that when it gets submitted and changes from the cart (memory) into a real invoice, we just flip that line and change the sort number to a higher value, making it show up later or at the bottom of the invoice. Small little tweak.

Added another quick black box page that alters the invoice and changes the line item sort value. Pushed up the new code.

Going over my notes. Talking with John earlier and we were talking about mobile first design and responsive web app. That has to be a required or a requirement for fracture and adilas lite. We want every page to be able to do both mobile and desktop. I added a post-it note to my board and took a new picture. See attached.

Reaching out to a client to setup a meeting and time to chat about requested changes.

Talking with John about the adilas cafe and doing some mock-ups on that interface. We went over some of the older stuff from Jonathan Wells, see entry from back in 9/5/19 for more info. We went over some new mock-ups from John (see attached). After that, we spent the rest of the time going over the SWOT analysis. Today we were finishing up the threats section. See attached for some progress stuff. It is still rough and unfinished, but we are making great progress.

We also got into talking about budgets, making sure that we go mobile first for fracture (adilas lite), and we setup some other times to meet. We are excited to have the first pass done on the SWOT analysis (see attached).

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.

Emails and tech support for High Valley Bike Shuttle for Drew, dealing with online scheduling. Light research on some of his settings and what not. Sent out an email to everybody about an update meeting for adilas lite or fracture.

Planning with Aspen. Doing some brain mapping on a huge board with post-it notes. See attached for some pictures. Lots of high-level planning for adilas lite, fracture, and sub projects within our bigger vision. Once again, see attached. We also got Aspen paid for her work.

Quick breakdown of the different projects:

#1 - Company Structure - Jellyfish Model - Knowlege workers vs hourly workers, define divisions, departments, the who (talent), combine areas as needed, optimize structure, overtime, and compensation. We also want to deal with the different personality types - organizer, doer, creative, consultant, and the salesperson (someone who does sales).

#2 - Product Development - Value Add-On Core - Players, features, each summarized (possibly in a video or multiple videos). Define the current core. Figure out industry specific skins. White labeling options. On the industry specific skins, go minimal for the start. Custom code - data driven, not code driven. BI (business intelligence) level - Model needs to be fully planned out because it doesn't exist as a standalone layer at this time. It is built into the system as a whole. We need to extract those pieces and make a better plan for those numbers, values, and pieces of BI. Enterprise - define it and prep the database to make the jump eventually.

#3 - Education and Training - Adilas University - Internal and external training needs - video clips, organize them (library of sorts), tracking education, SOP's (standard operating procedures) per industry, in general, and company specific options. Make all of this data driven. Easier interactions, easier interface, all dealing with settings (show/hide, rename, aliases, sort order, defaults, etc.). Once again, both internal and external training needs. Online and in person trainings. Minimize the need for education by building out a better interface (fracture and adilas lite). Dynamic content and settings. Program education directly into the interface. Be able to turn the education mode or help mode on/off based on needs and per person.

#4 - Community and 3rd Party Solutions - Adilas Marketplace - Access from the adilas cafe or as a standalone app. Adilas creates tons of byproducts (both products and services). This could be things like consulting, design, custom code, data entry, bank reconciliation, accounting needs, etc. We want to offer ways to both buy and sell both products and services through a controlled interface. Think of a mini Amazon or mini eBay type marketplace. We need a spot to send, organize, and direct 3rd party solutions. Advertising and marketing efforts. More white labeling options (in the marketplace). This section could be further explored and has lots of potential.

#5 - Social and Efficiency Options - Adilas Cafe & Community - White labeling, standardized portal, single login, single sign on, able to jump to any corporation on any server where permissions have been granted. Options for work, play, buy, sell, train, social, and participate. User profile page. Interface with other corporations, get assigned, hub type environment. Mini marketplace for adilas based products and services. Sales and creation of new accounts (automated setup options). Tired pricing. News and updates, this wouldn't be forced on anybody but would be more available. We could allow them to customize their news and update feed. Dynamic billing and making payments for our (adilas) clients.

#6 - Deeper Product Development - Adilas Lite or Fracture - Customize everything. Setup wizard, question to help with setup, industry specific settings and presets, sizes, features, and options to customize as needed. Show/hide almost everything. Other settings such as toggle on/off features, columns, reports, navigation, etc. Everything is configurable to some extent. Sort orders and the ability to move things around (vertically, horizontally, and free form). Settings and making all of these decisions data driven.

Inside of fracture (code name before we got adilas lite) we want to make some server changes, code changes, frontend and backend changes by using frameworks and different languages (code stuff). Entirely composed of API sockets. This will make everything more portable and will also allow other outside developers options to build custom pages, features, and interfaces. Another advantage of using the API sockets for everything, it will standardize how everybody interfaces and interacts with the system or application. It will also let other developers play along without letting them see the underlying code. They just see documentation, examples, and final output from the API socket calls or API endpoints.

Fracture will include testing plans, sections for unit testing, integration testing, automated tests, and good coverage on testing in general. Everything will be modularized and broken into smaller mini components. We plan on using dynamic billing for usage, features, storage, etc. Entirely new interface with the ability to setup your own navigation and your own dashboards. We want lots of white labels and white labeling options. Tons of industry specific stuff as well.

Be able to turn on/off the education mode. We would love to capitalize on numerous lessons learned from 20+ years in the business. Lots of prototyping, new databases with good indexing and normalization. Directly program in teasers and marking. There has even been some talk of using AI (artificial intelligence) to help with suggestions for products and features that they might use or want.

Everything will be mobile ready and responsive. Client-side and server-side validation. We also want to prep things and have a maintenance plan in place as well. That is something that has been somewhat missing from past versions. Basically, take what we have and build from there - learning from the past and building for the future. Everything has a life cycle, prep for the next phase or part of that life cycle.

#7 - Budgets, Finances, Marketing, & Sales - Other business plans - interactive wireframing presentations, SWOT analysis, funding and repayment stuff, timelines, mission statement, profit sharing, budgets per section, per person, per product/feature. Writing business proposals, project scopes, sales pitches, standardization, and master table of contents. Lots of good marketing and campaigns for sales. Sources of profit and ROI (return on investment). Prototyping, testing, and market research.

#8 - Other - Networking and meetings as well as more research. Get in there and get it done!

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.

- Small review of what we have been working on

- Planning out the joint meeting on July 18 for the ship B - fracture and adilas lite team

- We spent a ton of time working on some other notes and brainstorming. See attached.

- We talked about using some of the graphics that show the mix of functions and players. See element of time 4989 for an idea of what we are talking about.

Meeting with John. Working on the SWOT analysis stuff. We were still working through some of the opportunities. At some point, I'd like to copy and paste some of that info into the developer's notebook. Some great stuff. Along with our meeting, we decided to shoot for a new group meeting on June 18th from 5-6 pm. This would be a team meeting for ship B and progress on where we are at.

As a note, I was thinking about the developer's notebook and other web based journals and blogs. I use it all the time. I'd really like to offer something like that for all of our customers. Maybe a possible addition and option for fracture or adilas lite.

Zoom session with Kelly and Cory and Steve. We were looking at a cross corp data issue. Light clean-up on some backend database stuff for both Kelly and Cory. Jumped back on with Kelly, Cory, and John to look at a sales tax calculation issue. It was dealing with how the shopping cart figured out taxes based on customer types (including and excluding calculations). After the meeting, Cory and I chatted about other projects on the to do list.

Small side note, it was amazing watching Kelly navigate around with multiple tabs, quick search options, exports, pulling reports, and bouncing from page to page to get the data. We need to remember how hard some of these pages and functions get pushed on when we build out fracture. We need something that is stable enough to hold up the power users.

Just wanted to record a few more notes from or for the fracture project (adilas lite).

- Make a fun flyer and do some news and updates to show what we are doing.

- Make the plan at the 10,000 foot elevation first. This is pretty general and doesn't have any deep details. It's the overview level.

- Allow for both preset packages (sizes or configurations) and a la carte, pick and choose, features and functions for what people (our clients) can purchase.

- Training and maintenance need to be part of the plan. Those are two critical pieces that need to be part of the bigger picture.

- Recruit help - allow for all kinds of investment - time, money, ideas, networking, connections, sales, etc.

- Offer help to make an industry-specific skin. This could include personal visits to those companies. Get out among our clients and customers. Going along with industry-specific skins, this could be a master list of on/off switches, naming conventions, flow and processes, and other normal industry-specific things and needs.

- Going along with industry-specific skins, I really want to help people build their own virtual or real white labels (using and configuring our product as their own). We need to advertise this and encourage it. We could even offer to come visit them or their facilities to figure out an arrangement to help them build their dreams. Focus on what they want. Once we have the main core, the other parts and pieces shouldn't be that tough or hard (in theory).

- Don't be afraid to travel, as needed.

- Family history - I don't know how this fits in, but I was thinking about it. I'm not sure if we should build things out to allow digital journaling (similar to the developer's notebook or quick list of entries), tracking family history, or what. I was just thinking about it, so I thought that I would record the idea. Once again, I'm not sure how this plays in.

Trip to Logan to meet with Hamid. We met for lunch and talked about fracture and adilas lite. Fun meeting. Here are some of my notes, from the meeting and just driving around.

- Model out each section, similar to the virtual obstacle course we are playing with (see # 10294). It may also be fun to model it out via the plates and cups model (small way of teaching one-to-many relationships for objects).

- Focus on one part or piece at a time. If you don't focus in, it, the whole fracture project, seems way too big and massive.

- If we get lost, we could always focus on mapping out the existing core. That is a "known" and needs to be done.

- We still want to do the rest of the billboard sites (other or outside sites that lead people to the main adilas.biz platform).

- We could offer preset packages for adilas lite. We could also offer an a la carte type option, where they can mix, blend, and pick and choose what they want or don't want.

- Hamid would like to play along with us on building out the dream. He has a number of ideas that he could throw into the mix. Eventually, he would like to transition over to more technical job. Future plans. Once again, great lunch meeting.

Before Alan jumped on, I was working with my sister on some ideas for a simple store front or consignment type ecommerce site. She has a bunch of products (hand built crafts and stuff) that I would like to help her sell using the adilas marketplace (future project or future business idea - planning for fracture and adilas lite).

Meeting with Alan over the GoToMeeting session. We started out and I was reporting on a few entries from yesterday. We reviewed what I learned in the Adobe ColdFusion Training Event (# 10256). Went over the scanned notes that I took. We also talked about the virtual obstacle course that we would like to build to test some of our ideas and prototypes (# 10294). Fun little review.

Next, we switched over to what Alan has been working on and playing with. Lots of fun learning and prototyping. Alan spent some time playing with REST API's and GraphQL options. He was really excited about certain parts of the GraphQL stuff that he was learning. Limiting data that is sent back to the users and making things easier on the servers.

Here are a few of my notes from our meeting:

- Alan was playing with GraphQL, Node JS server, Apollo, Prima, and other tools and features.

- Lots of queries, mutations (things or code that alters the raw queries), resolvers, and subscriptions (observer/subscriber type models).

- Small demo on what Alan learned from playing with GraphQL. This included unique ids, JSON web tokens, tons of files and folders (dummy setup files to put the pieces in place and then you go in and build them out - sort of a prebuilt file/folder structure for your app).

- Looking into web sockets and options to push/pull data - going through those web socket options.

- More talk about API endpoints, automation of the documentation, layers, transactions, locks based on transactions (with full rollback if needed), and throttling API endpoints.

- Tons of other topics such as: NoSQL databases, document stores, relational databases, query caching, ORM models (either object-relational mapping or object-role model), properties, tables, access layers, database updates, etc.

- We talked about using REST API's and having our bigger pieces maybe even broken down into smaller pieces. For example, instead of just having a folder for invoices. We may want something like: invoices/single, invoices/multi, invoices/search, invoices/export, etc. Basically, sub sections within the main invoice player group. We have 12 main application player groups. Each one does stull individually, as a group or a whole, and other sub functions. Maybe think along those lines.

- Spent some time going over security options, JSON web tokens, allowing servers to change the data but the browsers can't change the data. Frontend security, backend security, Node JS, Adobe ColdFusion, and options for both sides of the fence.

- Good meeting with some good research and R&D stuff. Good job Alan!

Merging and pushing up code with Eric. After the initial work, we spent some time talking about data modeling. Here are some of my notes.

- Eric would love to do some more data modeling and taking things into consideration and making a plan. He used to do this for other companies that he has worked with and for. Great resource. We could really use his help with adilas lite or fracture. This was like a mini database and data modeling lesson of sorts. I was loving it and scribbling down notes as quickly as I could. Fun stuff.

- We talked about flex grid tie-ins, flex attributes, and parent attributes. Basically, things that he sees that we do that might be built out into more efficient tools and features. Maybe rework some of this and/or combine some of the features.

- What really connects to other things (natural relationships) or what things are forced together (forced or special relationships)? We may want to look at use cases and try to pull out the natural relationships. Then build your application according to those natural relationships. You may still need to allow the forced or special relationships, but those become the edge cases vs the norm.

- If something happens over and over again, this should be part of the core system. Currently, we do use a lot of flex grid tie-ins to help with some of these special cases. As a side note, some of these one-off features are becoming more normal and should have their own logic and tables vs putting everything into the flex grid tie-ins. Great tool for getting things started but eventually, you may need to build out specific tables, logic, and pages. Make it more normalized and more efficient.

- As a note, what does the flex grid do? It allows for one-to-one connections, one-to-many connections, add log notes to anything, tying things together (main id's to sub id's or main id's to other main id's), and it also allows for up to 30 custom fields. Once again, it can be on a one-to-one basis or used and setup as a one-to-many relationship. Here is a help file that has more info on the flex grid tie-ins.

- As a note, the flex grid tie-ins have been the big brother to the things we are trying to build called flex attributes or real in-line database extensions or real in-line extensions for short. Here is a small, older graphic link, of what we are trying to do.

- We talked about the bus to motorcycle project (datasource project or world building project). We are headed to a new model where the corportion id numbers (corp_id) will be left out per database. Each company will have its own database and thus may not need the corp id number. This deals with table names, joins, and data that gets stored in the database.

- Back to the flex attributes and a possible option to build them right into the main entities or high level tables (for the 12 main players or wherever we see fit to put them). This option has some pros and cons. We'll have to work this out. Currently, I'm really leaning towards something similar to what we did for the current flex attributes or parent attributes. Let them build and setup any custom fields that they need. Dynamic relational model. Just for fun, here is the progression - flex grid tie-ins (2009), sub inventory attributes (2015), parent attributes (2016/2017), flex attributes (2020).

- Lots of talk about data modeling and being able to take off the corp_id. Including on the end of corp-specific tables - for example: invoices_53, invoice_payments_53, time_sub_inventory_53, and a slew of others.

- Maybe break the pili or po invoice line items into two different pieces. It was joined together to help with inventory counts over time and across multiple locations. Anyways, we may look at separating those tables into multiple pieces. Super important, make sure to remember and include locations. If just a single location, we could do the architecture differently. However, with multiple locations, it gets a little bit more complicated or tricky. There are tons of other possible options.

- The payee table should be broken up as well. Currently, if a person or entitiy is tied to an expense/receipt, a PO, an inventory item, it lives in the payee table. Payees consist of users, employees, vendors, and special customers that had to get paid out of the system (a copy and convert process). Anyways, we may want to break that table up into users, vendors, and special customers (something like that).

- We talked about a concept called "attribution" and data normalization levels. There are two main types of data models. You have the logical data model and the physical data model. Entities and entities have attributes. Eventually, those entities and attributes get translated into tables, columns, and fields in a database. Often, most attributes become their own database column or field.

- Attributes are different than types.

- We talked about fields like "flag_for_1099", "password", etc. Those are attributes for certain entities. However, does a vendor need a password field, most likely not. Each field or attribute needs to go with the entity that it belongs with. We, at adilas, tend to mix and blend some of the attributes between different entities. In some ways that is fine, but it requires explanations, instructions, and training. It's not as easy to follow without someone to guide you along. Anyways, some good conversations about data normalization stuff. What goes with what and why does it fit like that?

- Make the names readable and logical where possible. We do a pretty good job on that, but there is some randomness in there as well. Along with that, we jumped into talking about a section called special accounts. We are planning on using that for gift cards, loyalty points, in-store credit, vendor credits, punch cards, and other special account transactions where we almost need a bank account style with a rolling number and being able to add/subtract using individual transactions or actions. Anyways, we have a few fields in there called dev_flag_1, dev_flag_2, and dev_flag_3. We use those flexible fields to help with certain parts of the process. In a way, we didn't know what we were going to need, so we added in some flex fields. Well, now, those flex fields have rules and hold certain data that could be its own column or field. However, because we didn't know what would be needed, the fields are somewhat mixed, depending on what is stored there and what kind or type of transaction record is being stored (loyalty points vs gift cards or whatever).

- The conversion trickled over into human reference fields vs computer identifiers, ids, or computer reference fields. They are different and play different roles.

- As you think things out, eventually you have to transform or go through a transformation from logical models to physical models. Eric kept saying that we should be shooting for the third normal form (data modeling and database modeling). Figure out the whole business world (plan it out as best you can) and then build out what you need, based on what you see and/or know.

- We talked about aggregates and data warehousing. I mentioned that I would like to build out tables for yearly per location, quarterly per location, monthly per location, weekly per location, and daily per location. We would also have the underlying transactions or transactional database tables (raw data that holds all of the data). The other tables would be what we transform the transactions into (a form of aggregates or business intelligence).

- Along with aggregates, Eric was saying that sometimes you can watch the database and see what tables, queries, and reports cost the most (data, traffic, or processing time/energy/frequency). You then build out aggregates based on those findings and/or known needs. For us, we've been doing this for long enough, we know a few places that could really help with speed, server load, and provide great BI or business intelligence levels.

- Our system has to go clear out to the full accounting level. That changes how we do certain things. That is awesome! Our sort of end goal is perfect accounting, aggregates, per day, per location, and per category. Some of those (category levels) vary but they have mostly been defined in the current system. That is huge. We have a plan, we have a path. We just want to refine it. Eventually year over year reporting, monthly by month comparisons, real-time data - all data is live and searchable (adilas).

- Snapshots, aggregates, different preset and controlled data levels. We may need current data (tables without any dates - assumption of current counts, values, sums, totals, averages, maxes, mins, etc.) as well as dated or historical data (tables with dates to allow previous or prior lookups and date driven lookbacks).

- What about enterprise mappings and cross-corp stuff? We need to plan that out as well.

- We also need to consider servers, speed, reliability, backups, redundancies, and how deep we going?

- Lastly, Eric could help with a ground up data model. We could pick a topic, break it down, and do a number of smaller sessions vs a big push. That would be too much. Anyways, great meeting and Eric could be a great resource for planning, checking out our decisions, and planning out the best course of action. Good stuff!

Woke up this morning with thoughts of a virtual obstacle course going through my mind. I remember seeing a movie and the extras after the movie talked about how they put the digital characters through an obstacle course to test to see how well their modeling and simulations were doing (Pixar - Monsters Inc.). Once they could virtually run the whole obstacle course, without problem, they were able to go to the next step.

If we are building out the next level of adilas, code name fracture or adilas lite, I was thinking that we could come up with a good virtual obstacle course of sorts. I was thinking, simple database stuff, one-to-many relationships, users, permissions, roles, settings, validation (server-side and client side), add/edit options, getters, setters, reports, pagination, API sockets, coded using frameworks, etc. I know that sounds like a lot, but a mini version of the things that we do all the time.

This could include, form fields, toggle on/off switches, checkboxes, radio buttons, drop-downs, selectors or choosers, date picker, time fields, text fields, numeric fields, buttons, navigation, dynamic CSS (look and feel), mobile ready or mobile responsive designs, etc. Modals, dynamic help files, aliases, show/hide features, and the list keeps going.

This is just for fun but what about using customers and customer logs (simple CRM stuff - customer relationship management) for one of our virtual obstacle courses? Once again, just an idea. The features listed below are in no specific order. This is both funny and not so funny... We can already do all of this right now (using the current adilas ship A application). We want to rebuild this using our new ship B - fracture or adilas lite code and frameworks.

- Settings, navigation options, turn things on/off - do I want to use certain features or options
- Settings, what to call things (naming convention) - corp-wide settings or high level group settings
- Show/hide field level settings (toggle on/off, show/hide, aliases, rules, defaults, sort order, etc.) - data level settings
- Add/edit customer types - way of organizing and grouping customers
- Add/edit main customer functions and pages
- View single customer page (similar to the customer log page)
- Simple search, display, and drill-down into individual customer records
- Advanced search, pick and choose fields, filter, sort, export, and save reports
- Add/edit customer logs (notes and follow-ups per customer) - allow HTML - be able to sanitize as needed for display (say you had some bad or mal formatted HTML - still make it look good)
- Add/edit additional contacts
- Add/edit additional vehicle to customer assignments (currently being worked on for ship A)
- Aggregated data - log counts, contact counts, vehicle counts, total customer counts by type, individual customer info such as total invoices, quotes, elements of time, payments made, purchase history, items bought, etc.
- Full history of all actions - add, edit, modify, etc.
- Dynamic help files
- API sockets to do all of the functions listed above. Things like add/edit main, add/edit logs, add/edit additional contacts, add/edit additional vehicle assignments, view or get back data on all pieces (together and individually), search, show reports, even alter settings. The current API has a visual show and tell page, the real socket (live interface), and printable/searchable documentation.
- Rudimentary training per section - pages, sections, functionality
- Integrated unit testing
- Photo management
- Upload media/content (files)
- Gallery page - (images, scans, photos - up to 100 per customer with captions and show/hide settings)
- Remote login (ecommerce level) to allow a customer to login and update info, see histories invoice and quotes, be able to upload images from ecommerce, build your own statements, and view log notes out in ecommerce
- Quick search options
- Show log notes and follow-ups on a calendar type interface or view
- Search log notes
- Search additional contacts
- Flex grid tie-ins and limited flex grid tie-ins
- Customer flex attributes
- Doesn't have to be right now, but customer tie to invoices, quotes, and time (naturally).
- Barcode label options for simple customer information and customer id numbers
- Validation - server-side and client-side on all forms (add/edit forms and report filters). Base this off of a data dictionary type interface.
- Mobile ready and responsive web format and styling
- Customers can be tied to loyalty points, discounts, and gift cards
- Customer queues
- Email reports and special email options (custom email settings using corp email settings)
- More options on the customer homepage - tons of links and nav to other sections. Reports, management options, and core update and bulk tools.
- More options on the customer log page - including options for custom paperwork and numerous drill-downs to customer-specific searches and filtered reports.

Just being silly, but I'd like to record all of these pieces, in the old way and then compare them to what and how the new way works. Kinda a side by side view. Depending, it may end up being an old way, a semi-new way, and the actual new way. I'm not sure how fast we can jump from old to new. We may need an intermediate or middle ground step.

Went over big picture goals of Adilas Lite (fracture):

• Hide as much as possible
• Aggregated BI (business intelligence) level from the get-go
• Restructure queries and reports to use aggregates
• Charge based on usage
• Coding is simplified and efficient
• Usage is simplified and education methods are clear
• Look and feel is improved
• Custom label
• Make POS/cart/merchant processing less clunky
• Calendaring and scheduling
• Server stability and speed

Before my meeting with Aspen, I was still on the meeting with Byan. We took the last 15 minutes and talked about possible ways of modifying ship A into what we want for ship B. Bryan may explore that a little bit to see what that might take. I authorized him to spend 10 or so hours checking things out. He may also look into using a mix of React and ColdFusion. More R&D stuff.

Meeting with Aspen and going over notes from Alan and I's meeting from yesterday - see element of time #10267. Defining and explaining some the notes and ideas. I was doing some drawings, using my hands to explain things, and took a few more general notes. These are things dealing with fracture or adilas lite - where we are headed.

- On the size and pricing matrix, we need to include file storage (photos, scans, images, media/content, and general files). We also need to include database size (how much we are storing).

- On the choose corp page, be able to set the default corporation right from there.

- Look into modern payment solutions such as Google pay, PayPal, Venmo, apple pay, etc. We already do some of that, just make it even smoother.

- Aspen was pitching the adilas portal vs the adilas cafe - naming convention. She liked the word or phrase portal better.

- Education will be a huge part of the marketing and sales. We need to include it from the get go. This may be a person who has to be hired just to do that role. Some of our developers may not fit that mode correctly.

- Aspen's comments on education - We need to pitch education as optimizing the system to be more accessible.

- There is a need for market research and test runs.

- As we were reviewing the document and notes from yesterday, we came across one that talked about simple tax info for small users. That would be really cool if we could help people out and put all of the simple tax info in one place for them. Make it super easy and convenient.

- Along with the taxes stuff, we may want to add more tax and payroll forms to the current system. Make paperwork as easy as possible.

- AI (artificial intelligence) - What do you want to do? What do you want to see? What do you want to track? There are tons of other things that we could let people ask or do. Help them out and even tie in some of this the industry specific skins. Aspen and I were talking about AI a little bit.

- Aggregates and sums, counts, averages, totals, mins, and maxes - Almost a reverse or reversing the direction of the reports and gathering the information. Now that we know where and what we want, let's build that in from the get go. Also, this is for me... If there is a discrepancy, I really want a tool that will help rebuild those aggregated reports and aggregate values. I'd like to automate as much as we can, but if needed, we will have and/or provide manual recalc tools. That's important to me.

- A.D.I.L.A.S. - All data is live and searchable - What does that really mean? "All data", that means that we catch and store it all (the whole system and all of the parts and pieces). That's a pretty bold statement. We love it! "Is live", that means that we allow you to look, retrieve, view, and interact with your data based on permissions and settings. It is a living application, not just a digital archive tool. It's alive. The more you give it (virtually feeding it) the more you will get back (business intelligence and decision helping information). "And searchable", full visibility and full searchability. Every history, every detail, every record, every supporting piece or pieces. Filters, sorts, exports, save as options, you name it. It's your data, we just help you organize it, store it, retrieve it, and secure it.

- Above, is a light overview of what the name adilas can and does mean to us and to our clients. As a fun side note, the actual name "adilas" was proposed by Steve Berkenkotter, at a lunch meeting in the small mountain town of Salida, Colorado. If you look at adilas, it is Salida spelled backwards. The first nine years of the adilas business existence, the primary co-founders and partners lived in Salida, Colorado. Sort of a fun little fact.

- Aspen and I were talking... Are we too detailed (meaning our planning). Do we need to zoom out? That is a great question. It is very easy to get pulled in to the nitty-gritty details and happenings.

- Dealing with zooming out - Aspen asked me what my top few priorities would be right now - without any planning - This is a small list that we came up with. See element of time # 10270 for a small list of current priorities. After we made the list, we then talked about how each one related to the others on the list. That was a fun exercise.

- The first goal, we need to centralize the data. Make sure and catch all of the pieces. Once we have that, we can then worry about how it looks and how to get the data out or back out of the system.

Awesome session with Alan and I working on the plan for fracture and adilas light. We started out and I was showing Alan some of the R&D for the adilas cafe that Jonathan Wells did a few years back. I sent Alan some links to pull down the Adobe XD mock-up files. After that, we spent the rest of the session working on levels, tiers, user stories, and feature lists for adilas lite. See attached for our notes.

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.

Reading notes and making plans. Reread an email from Alan dealing with hours, teams, and roles. Printed out a small document dealing with a small overview of the book - The 6 Types of Working Genius. I got the little packet from Aaron Hill (his results from an assessment that he took). Good reading and insightful. It talked about working genius levels or types. It also talked about working competencies and working frustrations. The packet contained a small summary or summaries of each subset of the six types - Wonder, Invention, Discernment, Galvanizing, Enablement, and Tenacity.

I ended up calling and talking with Alan for a bit. We chatted and I scribbled some notes. See attached.

Here are a few of the notes:

- Stay a week or so ahead

- Let's plan and do some user experience studies and look into the some of the human factors of our fracture project. Human centered design stuff. Alan wanted to go into this as a career choice. He has some good stills and has taken a number of psychology classes dealing with page layout, flow, navigation, etc. Lots of usability stuff.

- Be agile with the planning - short sprints and focused planning - just in time deliverables vs a huge plan of a plan of a plan.

- It's ok to use hand drawings (at first). Eventually we'll make them tighter and more professional - like Adobe XD or live prototypes.

- Alan and I are planning on meeting a few times a week to get some of the initial planning kicked off and going.

After hours meeting with Wayne, Alan, John, Bryan, and I. Wayne pretty much drove and I took notes. It went for three hours. We have the first two hours recorded (see attached). The last hour, we thought that we were done and it kept going with ideas and more clarification stuff. It may be a lot to read, but I've got 5 pages of notes, all dealing with fracture and where we are heading with adilas lite. Some of these topics are deep, backend, and server and database related. Good meeting.

I have no problem saying this... I was definitely not the smartest person in the room. I've been doing this kind of stuff for over 20+ years and I was impressed. That makes me excited.

Once again, if you want to review the notes, there are a bunch of good things in there for our upcoming fracture or adilas lite project.

These are a few of my takeaways:

- We need to communicate and get some standards setup. This could be what we call things, what code to use and how it looks and acts, and other style guide level stuff.

- Our plan is to build the whole new parts and pieces into an open API socket connection level application. We could then use API sockets as well as let outside developers use the same API sockets. We talked a lot about this. This is where we want to head. The new adilas lite platform will be mostly run on API sockets.

- Rules and assignments - the concept of building the rules and then assigning who plays with those rules was a big part of the discussion. Follow a story-based design for logic, testing, etc. Make all of this data driven.

- Think generic - what is available - what do you want or need? Make everything configurable. Multiple levels of configuration. See notes.

- We will be building a very robust data dictionary and then using that in the rules, validation routines, etc. This is basically a database that shows columns, names, values, rules, defaults, and other information about those columns and/or fields. This is huge and will help us use a more data driven approach vs hardcoding all of the rules, values, and validation per column. We will have a generic set and then let each corp, location, and user tweak a copy, if they want to get that deep. If not, we will use the main master data dictionary list information. Only change and copy what is needed.

- Events and turning everything into small bite sized pieces. Very minimalistic approach. Make as much of this application asynchronous (nonlinear) as possible.

- Let's do the aggregates (data warehousing stuff) right off the bat and get those values in place and being used. We are very good at transactional data and data storage. Let's really make an effort to break into the aggregated or business intelligence (BI) levels. That is a huge goal of ours.

Went over to Bryan's house and we had a brainstorming session on his new upstairs patio. Beautiful view and good times. It rained on us but we were protected from most of it. See attached for a scan of my notes. Lots of ideas for fracture or adilas lite.

Here are a few notes:

- Mobile first - plan accordingly. Allow for mobile and desktop settings (show/hide for fields).

- Be able to setup your own data assembly line - based on what you care about. We will try to provide the pieces and modules and you can put it together how you want it and/or need it.

- Lots of talk about API sockets and small microservices.

- Lite or simple apps - for each layer - if you want more, just choose the next pieces. Play with aggregates (sums, counts, averages, maxes, mins, etc.) unless you need more details. If yes, just keep peeling back the layers.

- We have a friend that was pitching us on Deductr a long time ago (back in 2015 ish). It was a quick mobile app for simple expense tracking, simple mileage tracking, and simple categories and reports. Adilas can do so much more but we need to present it in a way that feels easy like Deductr (aka Hurdlr).

- Choose your own adventure or choose your own business process - similar concept. When I was a kid, I used to love reading the choose your own adventure books. As I grow up, what if I could do the same thing and put together my own business adventure (map it out based on needs, wants, and decisions).

- Talking about free versions of our software/web apps. We could also have or offer upgrades. If someone really wanted to play the reoccurring revenue game with us, we could allow them to sponsor and/or fund certain modules or sub modules and then pay them a reoccurring commission on clients who use those pieces. Bryan and I were talking about possible ideas and how that might work. Fun stuff!

- We talked about growth, slow and steady, and natural (organic) growth.

- At what point does the scale start tipping? What feature or add-on will really make it go? Or do we need to pull back some of the complexity and make it even more simple. If you want deeper, you just ask for it (layers) and then you get what you want vs having to have the whole thing every time.

- Lots of talk about pain points and how that tends to help with growth and being willing to pay for a solution to those pain points. If someone pays for an enhancement or feature, we tend to roll it into the mix. Kinda a piggy backing type system where one person pays for something, everyone gains (piggy backs) and then next person pays for the next enhancement. It has worked great for us. Sometimes we call it idea farming.

- Creativity is a chance - there is a possibility of failure with creative stuff - that doesn't mean don't do it - you just have to know there is a chance involved.

- It may be ok to use older code, if needed. Keep rolling forward and revamp, refactor, and rewrite as needed.

- Bryan and I also talked about API socket connections, simple website builders, easy payment solutions, dashboards, widgets, advanced reporting, and simple timeclocks. Tons of fun topics. See the attached notes for some other ideas.

Meeting with Bryan to push the flex attributes for PO's. The flex attributes allow for custom data endpoints per main group (12 main player groups). We currently only have flex attributes for customers, elements of time, and now PO's. Eventually, we want to add this same feature for each of the 12 main player groups. As a side note, originally, these flex attributes were going to be called real in-line database extensions and were going to be the big brother of the flex grid tie-ins. When we get everything out to the fracture level, we want to make sure that we have the flex attributes built out for each main player group. The main player groups are: Deposits, invoices, PO's, expense/receipts, balance sheet items, stock/units, customers, vendors, employee/users, parts/items, elements of time, and quotes.

Another thing that is really wanted, and we would like to build for fracture, is a granular level of both visibility and searchability. The clients want to be able to see everything and then be able to filter it down as well. That seems to be a reoccurring theme and request. Currently we have a number of prebuilt reports. That is great and all and needs to continue. However, to make it even better, we need to provide options on the advanced searches that show every field, every connection, allow for toggle on/off (show/hide) fields and columns, filters for each section, and options for both show and export. Once again, full visibility and full searchability. That's the goal. Adilas - all data is live and searchable.

Bryan and I got his code all merged in and pushed up to data 0 for testing.

Recording notes from 5/31/23. Lots of good stuff and some new changes and ideas were going on. That is right about the time that we started the transition between ship A (current adilas platform) and ship B (fracture and adilas lite). Lots of good stuff.

As a fun side note, as I was recording some ideas... I had the idea about - what if we build out features and modules and charge accordingly? That's where we want to go anyways. We could pay a commission on those modules to whomever helped up build and fund them. Just treat it (the reoccurring commission) as part of the cost of using a specific module. Almost like a sponsor or sponsorship of a certain part of the adilas platform. See element of time # 10244 in the shop for some other ideas.

Met with Eric to look at some code. We chatted about some time zone offset questions and date/time stamps that a 3rd party was asking about. We then got into a small discussion about better data modeling (see below). Eric has worked with numerous companies that have built and destroyed whole systems. We talked about some pros and cons and where we are heading for fracture as well as ship A and ship B stuff. We then flipped over to the enterprise vendor catalog changes that Eric was working on. We did a small code review, light clean-up, and merged in some code.

Eric and I – talking about the data model (database stuff)

- Problem with the unique id's – too much reliance on the existing primary keys – switch it to combo primary keys

- Any time you repeat things, you may want to look at the data model

- Cross-corp issues – for example – cross-corp loyalty points

- Po/Invoice lines – database table – breaking large datasets into corp-specific tables – that's how we solved the performance issues – there may be a better way to do that

- Better DB conventions vs table naming for corp-specific tables

- Enterprise level – aggregates and query data

- Shareable data models – associated tables

- Problems with text-based fields that combine records – for example: customer phone numbers

- Lots of talk about associations and setting up those relationships – master lists and who has access to that data, association, and/or relationships

- Refactoring things as we are in there working on things – smaller nibbles – iteration process – keeping chipping away at it along the way

- If we have a multi-page flow - make sure we use a common standard vs every page being different. A list of set standards.

- ETL - extract, transform, load - This is part of data warehousing and we would love to do it along the way vs just at the very end. Let's plan it into the fracture or adilas lite project.

Meeting with Aspen to go over parts of the plan. She ended up doing some research on fracture and I was recording notes and such.

Notes from Aspen - see below

Adilas Lite Weekly Objectives

6/12/2023–6/17/2023

1. Smooth over the relationship with Ship A

1.1. Propose prototype testing for Ship B components on Ship A

1.2. Win-win for all parties–helpful features that Ship A won't have to pay for directly, Ship B gets the assurance that their components work, Team harmony improves

2. Get Ship B Organized

2.1. Variety of Meetings, prepare documents for a more technical meeting with Wayne on the 14th

2.2. Project Management Document Summary, start on strategies

3.Complete Personal Hours, Etc.

4. Classification of Projects Under MVP and Non-MVP Categories

4.1. Helps focus efforts

4.2. Both need to be clear

4.3. MVP needs to be built with potential Non-MVP build-ins in mind

I met a friend and his wife for dessert. My wife was with me as well. My buddy is a high-end developer in the Salt Lake City area. I was telling him all about our plans to build out ship B (adilas lite or fracture). We had a great conversation, and he was a great sounding board. He was praising us, the current team, for making it happen and supporting our families for years and years.

One of my biggest takeaways from our meeting was dealing with the tech stack. Basically, what servers and technologies are you built on? Or how did you develop and deploy your code? What backend servers and frontend frameworks are you standing on? We talked about legacy systems, pros and cons, and quite a bit about perception (what people think - right off the bat). He kept saying that "the tech stack matters". Meaning, investors and others may have a say in what technologies are being used and developed. He didn't have one specifically that he recommended, but we did chat about a few options.

He was also asking questions about, maintenance, technical debt, dependencies, libraries, and who is going to build it, maintain it, and improve upon it? Great questions. He was basically recommending that we widen that piece as much as possible, especially if we are building from the ground up. Prep the field and make it as future proof as possible. Great ideas.

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.

Paying a few more bills and recording notes. Worked on notes and entries from 6/5/23 and 6/6/23. Lots of crazy days.

Also, as a side note, I ran across some entries on watchers and feeders and doing daily category sums, counts, and other data per location, per day, per category. That may be something that we look back into for fracture.

Group intro meeting for Ship A and Ship B - current adilas (ship A) and where we want to take adilas to create the next level (fracture or adilas lite - aka Ship B). We had 10 people on the call/meeting. I took a bunch of notes, Aspen took some notes, and we recorded it. See attached. After the main meeting, a few of us hung around expressing other ideas and then after everyone else left, Aspen and I had a small chat.

Notes from Aspen and Brandon talking after everyone had left:

- Start emphasizing what we are doing

- Fixing the scary things (rounding off corners and refining things)

- She (Aspen) would like to try to pitch it a bit (build it up and be able to help pitch it)

- Help Steve with a viable product and plan (MVP's) that he can sell. Help him to see that he can sell anything, including things that are poorly planned out. Imagine what he could do if we gave him something to work with (MVP's - minimal viable product, plan, person, etc.).

John and I had a great session working on a S.W.O.T. (swot) analysis - that stands for strengths, weaknesses, opportunities, and threats. You basically have a brainstorming session and list out different things under each category. We made some pretty good lists. Many of the same things could be viewed as both strengths and weaknesses. There was quite a bit of crossover between the different categories and topics.

John was working Adobe XD while I was listing things out. We had small conversations about each section. It was really fun. I took a small screenshot (not even a fraction of it). The document still needs some refining and work, but a great start.

Right at the end, we had the thought to do a SWOT analysis for smaller sub sections. Our first attempt was dealing with general adilas and the new fracture or adilas lite product that we are going to create. We could do a SWOT analysis for the main adilas (ship A), fracture (ship B or adilas lite), adilas university, adilas marketplace, our development team, etc. It might be nice to break things down a bit.

Phone call with Steve to go over hours and commitment for adilas (ship A stuff). I wanted to chat with him and ask permission to have a team meeting to discuss direction, options, and next steps. I've got a bunch of other notes... not sure if they were before the phone call with Steve, during, or after. I'm recording these notes on 6/24/23 from post-it notes that I made on 6/1/23. Anyways, here are some of my notes.

- Look for it - Seek and ye shall find - What are you looking for? Often, you find what you are looking for (good, bad, ill, faults, goodness, blessings, etc.).

- Ask for it - Knock and it shall be opened unto you.

- Bring what you can and throw it in the pot - We're making stone soup.

- Following a dream - The next phase or step of the journey

- Plans for adilas percentages - 20% of my percentages to go to help both teams A and B (normal adilas - ship A and fracture or ship B). 5% for getting the plan prepped and ready. 5% getting the funding. 5% for releasing an MVP (minimal viable product), and then 5% for ROI (return on investment). The ROI part was right from Steve during our conversation. I remember that much. That was brilliant.

- All of us would like to be able to fully turn all modules on/off at any time. That would be huge.

- I will give adilas (ship A) 10 hours a week. The rest of the time I will be working on ship B (fracture stuff).

- My biggest job is helping and dealing with people - the code and projects and products come later.

New transition today. I popped onto the morning meeting because that is what I normally did. I let the guys know that I wasn't going to be doing that any more. Sean was on the meeting and we chatted for a bit. By way of an update, he is doing great working with the dynamic adilas label builder. He is also willing to do some checking out of what our competitors are doing and providing me some competitive research. Nothing too huge.

John joined the meeting, and we were looking at some mock-ups. We would like to allow our users to interact with options to setup their own space, look and feel, etc. We would also like to do some early prototyping. Get it out and in their hands. Even things like settings for click vs hoover and other simple choices that affect their space (what they do and use - their space, their flow). We already have a bunch that we have paid for and haven't been able to use it yet. We have a ton of R&D stuff that Jonathan Wells did in Adobe XD for fracture, adilas cafe, and a new shopping cart.

A picture is worth a thousand words. Dramatize it, push up XD docs from Chuck on the content server. We have done tons of really cook R&D. Let's use that. This is how we are going to get fracture up and going and off the ground.

John and I talked about trying to centralize all of the data and assets. I have a bunch of it. We have pushed up a bunch to the adilas content server. We also still have quite a few assets and raw authoring files with the guys/gals who made them - Jonathan Wells, Chuck, Russell, Marisa, etc.

As part of our discussion, John was showing me some of the projects that he worked on for school. He's got business design docs, pitches, proposals, flow charts, etc. I'd like to tap into some of those planning and system scope documents. Not necessarily for his project, but more for what we could do for our projects. Once again, show them don't tell them. That is huge and reoccurring theme. Show them, don't tell them.

Here are some other notes from our meeting:

- We could make some awesome customizable dashboards

- Realtime data on what is going on (tables, graphs, charts, and quick aggregates), help them see everything without overwhelming them. Full visibility.

- "Show them" and then do it over and over again.

- Talking about dream salaries between John and I. Where would you like to be, salary wise?

- Keep idea farming - that's what we do

- Shari O. joined the meeting. She loves to do some gaming. I'd love for her to come up with some ideas on how to turn adilas and the daily work into a game of sorts (the game of business). Shari O. said that she could do some light research and maybe come up with some ideas. As we were talking, she said that she changes games based on moods. That's good information. We may want to come up with something similar - what mood are you in? Ok, let's play that way. This is just a dream right now. I'd like to see where it goes.

- Keep gathering things together. Eventually, we will make our own world.

- More ideas for the application and/or system - education mode, game mode, nuts and bolts mode (just get it done - speed mode).

- More talks with Shari O. about Facebook groups, other social groups, having meetings, setting up schedules, and giving people power to run what they want to do. Make the whole thing a team effort.

My mind was going nuts all day. Literally a whirlwind. I didn't write down the start and end time on this one. But from about 12 noon until 11 pm ish I was brainstorming, thinking, recording notes, talking to people, phone calls, texts, etc. It was super fun. Once again, these notes don't have any specific order, they were just what I recorded on small little post-it notes. I should have used a bigger notebook... :)

- We need a matrix and the ability to monitor every choice and setting. Full data driven and choice driven billing for our clients. This needs to be baked into the beginning design for fracture and where we are heading.

- What about possible open-source code and/or having our clients pay for their own accounts? That would take some of the hardware and server pressure off of us. Just a thought. Along with this, we could set it up to use any domain name, any site/server or hosting company. Whatever. Keep it super open, if we want it to be.

- As far as hosting and packages, we could have our own options as well. Things like simple home use, shared servers, semi dedicated servers, full dedicated servers, clusters, etc. Make some options and then make them available.

- List out your services that you offer and/or have available.

- Packages and bundles - tiny, small, medium, large, extra large (xl), double X (xxl) or whatever. Maybe set some limits for the different sizes or limits withing a certain range (keep it kinda flexible). Allow for variable billing.

- Stripe seems to have some awesome automated merchant processing features. It may be fun to plug into this. We could also use something like Datacap and then have access to even more merchant processing options. Just thinking along these lines. This could be for our clients as well as for us, as a company. Currently, we are using USAePay for our internal merchant processing stuff. I'd like to expand and really open that avenue up a bit.

- You (meaning me) may need to fully jump off. Earlier today I was giving Steve an analogy of jumping off of a moving train. The best place is either on or off, not somewhere in the middle. If I'm going to jump, do it and get clear. You don't want to be too close to that moving train. Once again, just an analogy.

-  Some of this stuff is for me, but was part of the brainstorming session. Anyways, I'm going to list it anyways.

- I know some bankers. I'd like to meet up with them and just pick their brains. Thinking of Mike Hall, Brent Wallis, Kevin Moser.

- I could use some of my percentage ownership of adilas as collateral, if I needed to get a loan.

- I have a buddy that helped me out, back in the day with my Learn To Freeride (LTF) project. His name is Gene Spaulding. He currently does a lot of stuff with nursing homes, memory care, and retirement homes. Good resource. Maybe even checking with him if he needs a product to help manage all of his beds (rooms for his clients - elderly folks). Regardless, he's an awesome resource.

- I know a guy by the name of Jud Eades who is an entrepreneur, a friend, and a total stud. He does all kinds of fun stuff. I could see if he has ideas and/or is interested in helping me build a reoccurring revenue based product.

- I know lots of other business people who have ideas and different know how. I would love to tap into their minds. Just being silly, but started thinking about too many people and decided to stop (for now).

- Use eye candy to show what we have done

- Talk with my wife Heather

- I have a full business plan that I did for the LTF project (older personal project dealing with teaching snowboard freestyle tricks and moves - early to mid 2000's). Look at the LTF binder, just to get some ideas.

- Recruit help. Think about all kinds of avenues, people, places, things, etc. Be creative!

- Include the Lord

- Sufficient - That goes a long ways

- Apply It! - Whatever you learn, keep applying it. That seems to be one of the secrets.

- We (adilas) hired a business consultant a few years back. Get back with him and review of what you learned from Jonathan Johnson and Epic Enterprises Consulting.

- Check in with Aspen, my daughter and see if she wants to help. She has a great gift for organizing and such. I could use the help.

- Talk with my mom and dad. I would like to ask my father for a father's blessing as well. That would help me out.

- Planning things out and then funding that development.

- Strategic funding based on needs and plans.

- Willing to listen and record notes. I love sharing what I have learned. Writing things down helps my memory. The old saying - The faintest scratch is better than the sharpest mind.

- I'm willing to let others play a role and add to or even take away as needed.

- Freedom from the adilas grind - that's worth a lot.

- I may be able to do more and help more by not being tied down.

- Make a list of pros and cons

- Include some prayers (lots of them) and some fasting - ask hard questions of God and of yourself

- A couple of books came to mind - Who Moved My Cheese, The Go Giver, How To Win Friends And Influence People, Rocket Fuel, etc. Read those books.

- Be willing to help and give. I enjoy that.

- Follow a dream

- There is a level of excitement that I'm feeling. This is kinda fun!

- I have a book called "Differentiate or Die" - I'd like to read that. It was given to me years ago and it has been in my office but I haven't gotten around to reading it yet.

- Get some training

- Work on some funding

- Be a cheerleader

- Help fix the existing foundation. Make this part of the plan.

- Be open... to... whatever...

- Bridgerland - It's a local technical college here in my town. There are lots of options there. I know a number of people, they have training resources, and they have even asked for a demo (multiple times) of our products. I'd like to explore some options there including offering to help them build something that they could resell and/or pitch to other technical colleges. Almost a white label type option.

- I had a dream the other night about including other businesses in our planning and roll out. Keep exploring those ideas and avenues.

- Leverage your percentage of ownership.

- Ask... What do you need? How can we help? What do you want? Where is your pain?

- Go back and do it again. Trystorming and being willing to circle back again.

- Talking with Heather, my wife, and going over what I was making, what I could make, and how to keep a good balance. I'm not going to lie, there are parts of it that are just plain scary.

- We may need to get back to doing a family budget. We used to do that a long time ago. It's been pretty smooth sailing and we haven't done that in quite some time. We may need to circle back around.

- I'm kinda scared to dip into savings. Super grateful that we have some.

- During the day, we talked (Heather and I) about existing expenses, promises, and upcoming expenses dealing with raising a family (vehicles, wisdom teeth, other doctor bills, etc.). We listed a few things out.

- From Heather - We don't want to relive LTF! - Understood and I agree. Lots of lessons learned. If someone has time, some time in the future, I'd love to tell them about that project and product. Huge building blocks of my career, part of my life, and part of the journey. It wasn't all bad... :)

- Look at the risk/benefit trade offs

- From Heather - She'll let me do this - new venture - if we don't take out a personal loan and don't clear out our savings.

- We have been super blessed.

- We can't see the future. We don't know what is coming.

- Keep adding to savings as part of the plan.

- Light fun with numbers. We started adilas in 2008 from a project that started in 2001. The first adilas deposit was for $100. As of 5/31/23, adilas has made over $7 million and growing. That's kinda fun.

- The current goal is the business plan. That may end up being more than just one document. It may be better to say plans (plural).

- Need to call our accountant and check on taxes (for me personally)

- We have a number of projects planned for around the house that will still need to be completed this summer (paint back porch, cut down the dead tree, etc.). Heather wants to make sure that I don't get too busy and that I can still help out and do the planned projects around the house.

- From my daughter Amber - We were on the back porch talking - Here are some random thoughts that I wrote down from our conversation. From Amber - Do what makes you happy! Question - wouldn't having more be more stressful (meaning another whole adilas product)? I told Amber that I was trying to work myself out of a job. She had a few questions about that. Foreign concept to her. We talked about - if you are enjoying the job, it's not work. Good fun!

- More notes from Amber - You could always find another job. For example, snowboarding or whatever. Something that you enjoy! Maybe something part time or something like that. You could teach an art class, spend more time with your hobbies, actually get a job where you have a window (you work in a cave), get out and get outside, something. She was having fun giving me advice.

- AI (artificial intelligence) - this may replace certain jobs. Creativity and interpersonal skills - you can't replace that (currently).

- I like helping people - do something along those lines.

- Aber was being super kind - She said - You should draw stuff. I love the t-shirts, cards, your life jacket (kayaking PFD), and other things that you have drawn. Go have fun! You could totally use your drawing talents.

- Next I talked to Aspen for a bit - she was very logical and had some great questions. For example: I wrote down - Do you feel comfortable dropping all of your responsibility on other people? Who is going to do what you were doing? What about family timing (meaning with our family and who is doing what - in general)? What about retirement? Who is going to help with marketing? Etc. Very logical questions. It was great.

- I told her that I was playing a small game, similar to the old fable called "stone soup". Bring what you've got, throw it in the pot, we are making stone soup. She thought that "a community effort" was a better way to say it than calling it stone soup. She is probably right.

- A few more questions and comments from Aspen - If you have a passion about something, we'll trust you. Prove yourself! Different question, how will this look for taxes?

- Both grandmas and grandpas (Heather and I's parents) are a great resource. I'd like to let them know what we are doing.

- Talking to my son Tanner about what was going on - He said, it sounds like Legos (little building blocks).

- This is totally random, but also came from Tanner - We were talking about trying to skip things that we didn't like or couldn't do. Just being silly. All of the sudden, Tanner tells this story about one of his friends. His friend is in a wheelchair and has some disabilities. Tanner was really sore from doing something and said, I think that I'll skip leg day today (dealing with weight lifting and going to the gym). His little friend chimed in and said, I skip leg day everyday. Tanner and his friend had a good laugh at that. Anyways, it was super funny and broke the tension around the dinner table. Good stuff!

- Talk with Steve about some ideas

- Aspen recommended that I talk with Kelly (adilas power user)

- Called and spoke with my mom and dad over the phone. I then went over to their house and spent an hour with them talking about things. Great little visit. They recommended that I do some fasting and praying. My dad will be willing to give me a father's blessing this coming Sunday. Pay your tithing, server the Lord, and pray for help.

- My dad gave me a scripture to look up: 1 Nephi 4:6 - Led by the spirit, not knowing beforehand the things which I should do.

- I told my mom and dad about a dream that I had on Monday night about including other business owners in this software re-write and that is exactly what my parents recommended for me to do. I thought that was very interesting and awesome!

Sean and I talking about the new pivot with adilas ship 1 (ship a) and ship 2 (ship b) - an email that we got from Steve this morning. Sean is going to be looking at some other business software packages and sending me ideas and screenshots (light research and getting ideas). We had a good little talk.

The rest of these notes were just thoughts, ideas, and notes after talking with Steve. My mind was just gushing with thoughts, emotions, ideas, worries, excitement, etc. The whole gamut or range of feelings.

- Operations has to lead the accounting. You can have operations without accounting, but you can't have good accounting without operations.

- Jumped on a call with Steve - Good chat - It felt like he was coaching me and giving me some great advice. Almost master to apprentice type talk.

- Keep heading north - that has been our general business plan - keep heading north!

- Steve was talking about a limited team (working on his house) and how effective that was - lessons learned

- This is an abundant model - we are not limited to just what we have and/or is right in front of us - tons of options

- Track everything - time, hours, plans, money, notes, etc. Track everything!

- Creating a super tight plan - almost a watertight level - As part of that, make sure and leave some flexibility into the mix. Things always keep changing.

- As of June 1st (6/1/23) no more adilas funding on ship B (adilas lite or fracture)

- Steve is going to be taking care of ship A (current adilas platform) and I'm going to be dreaming, building, and working on ship B (adilas lite and fracture).

- Going for dreams sometimes takes blood, sweat, and tears - be ready for that

- Lots of experimenting, playing, and messing around. It's all part of the game.

- Selling the sizzle - every restaurant that has steaks can sell the steaks. The one who really makes it sells the sizzle, not the steaks.

- Along with the blood, sweat, and tears - Steve was saying that there may be a lot of unpaid labor that needs to happen and go on before it really turns the corner. Keep tracking everything.

- So many pieces - we are in a complex industry - lots to do and coordinate

- You will always need customer service stuff. Customer care, support, deployment, etc. Remember the service piece.

- Steve has been a great salesperson - We are where we are because of him selling stuff - All kinds of stuff

- We would like to create a succession plan. Not necessarily an exit plan but more of a succession plan.

- We talked about ownership percentages and sub plans for distributing some of that equity and ownership percentages.

- Conflict of somebody spending money we didn't have - that causes stress

- Being mentally tough - easier said than done when it really comes down to it

- Suppressing things (good and bad) and letting the tiger out of the cage

- Removing a roadblock

- Being a participant - Get in there and play the game - Be there and participate

- "Icing" - That goes a long way - Easy, simple, pretty

- Not putting yourself in a box

- We need more than a business plan - Be willing to rewrite the business plan 3 or more times. That's ok!

- I gave Steve an analogy of him pushing me out of the train, at the same time, him saying good luck, and me saying thank you... Kinda funny!

- The plan will keep evolving

- Learning to fall down - That's part of many of the games we play - Get in there and learn to play!

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

This is mostly for me... but last night I couldn't sleep very well. I kept having the idea that I needed to include others and other business owners in the fracture project. This could be helping them build out their own systems and/or helping them get started on the white label journey. Anyways, meeting with them, helping them get things lined out, making plans, and getting their feedback, ideas, and suggestions. Group or community effort of sorts.

This is by no means official, but I was thinking about a six-month planning period, six months prototyping and getting funding, and then rolling things into a two-year build out. Once again, just putting things on paper. In reality, we'll need to check scope, project requirements, and who we have that can help. Lots of other variables. That's just what I was thinking.

I know some of the local business owners at the technical college, local ski resort, a bike shuttle company, a special race event, a high-tech manufacturing facility, and my dad (great resource to a number of other business owners). Anyways, just recording this as an idea for fracture.

This may not go here, but I was also thinking, if they commit to working on the white label projects (multiple versions) I could even cut them in on a small percentage of the main adilas system. Basically, a way to get them to help us push things forward. Once again, just thoughts and ideas.

After the server meeting, just Wayne, Alan, and I stayed on to go more in-depth on the framework stuff that Wayne is testing, trying, and pitching. Wayne has been spending tons of time looking into the ColdBox framework and experimenting with things. He's really going for it.

We talked about files, folders, and structure of how the application could and would work. The whole thing is setup in a rest type interface with specific paths, pages, and URL's (web addresses) to make it work. REST API or RESTful API architecture stands for representational state transfer. Basically, that deals with logical paths, files, and folders to create organization. You then place special code at each end point to do a specific task. That is part of the way it is organized. Our old site has tons of pages, all bunched into a couple of folders (all mixed together). When I say a ton of files, I'm talking thousands of files. This newer site will have like or similar pieces and pages in specific spots or places. It's all part of how it gets organized and managed. Interesting.

Alan and Wayne were talking about object-oriented coding with options for extending, inheriting, and sub classing functions, variables, and conditions. They both fully get it. I haven't had any formal training on this, but I'm picking up some of the pieces and concepts.

Next, they got into talking about limiting the handlers (receiving pages or virtual doors and windows). We covered a number of other topics such as nesting, sub classes, pre and post level page handlers, and how all deeper business logic needs to be over in the service models. Once again, it was mostly Wayne and Alan talking shop and I was listening. To translate, our existing site and pages have a bunch of things that we do every time to make sure that the page gets valid information. They are talking about doing all of that pre validation and logic as a simple handler and thus making each page smaller and not duplicating code (hundreds of lines per page).

After talking for a while, Wayne was showing us what it takes to rewrite things and pages using the new architecture and structure. We kept jumping off on tangents as Wayne was explaining and we were asking questions and making comments. Fun little interchange. At one point, Wayne had to either jump off and/or deal with something at his home. Alan and I were talking about options for permissions and limiting things even before we show them. Keeping things skinny and lite.

Here are some of my other notes. They don't really flow into nice paragraphs.

- Currently, our main pages, inside of adilas are kinda like handlers. We just don't call them that. Sometimes we call them the wrapper pages and string together some black box and/or special page includes to make it all work.

- All business logic would need to be in the services.

- Lots of talk about separating logic and views (pages).

- Using fracture (potentially more complicated) to show less (looks more simple - based on show/hide settings and configuration stuff).

- Creating rule books and using the database to help drive the pages, logic, rules, and procedures. Basically, the code gets stored in the database, where it could be updated, shared, or tweaked as needed. The pages just process the rules and/or instructions.

- Migrating data, seeding things (pre work and adding things for setup), checking for pending actions, and processing different actions. Small data assembly line stuff, for our own setup and configuration. That could be pretty cool!

- Wayne was saying, not really rewriting our code, more of moving it...

- Alan would love to help with this restructure project.

- We talked about options of how to integrate these things together.

- There are still some core changes that are needed. The key word was "core".

- Lots of talk about scale - how fast, how many, etc.

- Too many includes (code pages pulled into other code pages). This gets hard to trace down dependencies and variations if different pages are mixed together.

- We have some master copy and paste coders and developers. If that is the case, let's help them out so that they can copy and paste what we want them to do and use. If you can't beat them (some of our team may never change), then join them type attitude (give them good stuff to copy and paste).

- Tiny servlets and micro services. Everything is based off of time or events.

- We talked about budgets for both time and money. How quick can we do this? Time, money, resources?

- How long do we have if we don't do this? Not sure... meaning making changes and/or moving things over towards fracture (future plans and making the changes listed). Just part of our discussion.

- Wayne will reach out to Ortus Solutions (maker of the ColdBox framework) and see what options we have. Is there any way to use some of what they have and still keep some of our older existing stuff? We are looking for a middle ground, if possible. Basically, just a quick check to see if an option exists - mixing old code and new code and old structure and new structure. We may have to just choose one or the other, they may not cross or mingle very well (water and oil).

- Small story of how the Utah pioneers had to stop building a temple so that they could finish up the railroad. Once the railroad was done (lines completed) they were able to build their temple faster using the railroad to haul rock from the quarry to the temple site. Fun story.

- We talked about a new possible name for fracture (current code name for our future build out) and/or something that has a nice ring to it. We were thinking about "adilas lite" or something along those lines.

- What about building out a mini version, creating small modules and then charging for those pieces? Everything could be broken down into modules and sub modules.

- Originally, we were going to leave the existing adilas code alone and build something new, using the same database. As we were talking, it became apparent that we needed to build new. Meaning new code, new data, new database, new, new, new. The whole thing. As we were talking, we kept referring to ship A (existing adilas platform) and ship B (new or future adilas platform - aka fracture or adilas lite).

- Our first prototype, that Wayne is already working on, will be for payees. This is for vendors and users and will include a single sign-on option. Once again, just a prototype and proof of concept.

- Lots of great conversation about the adilas cafe and community. This is dealing with a global or master level list and access to the whole platform and/or adilas application. Imagine a single global login and then you could choose if you wanted to work (only show corporations where you have permissions and access), play (demo sites), buy things (marketplace), sell things (marketplace for goods and services - professional services), participate (community and social media stuff), and/or get some training (adilas university). Here is a link to more info and research on the adilas cafe from the developer's notebook.

- After Alan left, I talked with Wayne about percentage ownership stuff in adilas. Wayne would like to get some more ownership. He's doing a great job! We have many on our team that are really pulling the load very well. That is awesome!

- For me - adilas lite - make a simple play or plan. It could be a rough sketch or simple layout plan. Keep it simple.

Long meeting today. Started out talking to Wayne and Shari O. about emails, internal emails, external emails (outbound to different clients), and possible options. Wayne repointed the IP addresses yesterday back to the original way we had the email system setup. It was kinda wacky for a couple of days. Anyways, we put it back to what it was. We still need to look deeper into this, but it should be stable for now.

Steve was asking about the bus to motorcycle project - datasource or world building project. Wayne was reporting that some of his new code is trying to deal with this issue or these issues. We talked about the current state and where things are going. Briefly touched base on combo primary keys and removing major dependencies on existing standalone primary keys (database connection and relationship stuff). Along with the datasource topic (which database to talk to as a single time) the conversation also included our ever growing need to do cross corp stuff. We didn't talk about it, but some of this is very similar to the adilas cafe talks and discussions that we have had.

If we get majorly into cross corp stuff, and each corp has its own database or sandbox, we may end up doing cross corp stuff through API socket connections. That sounded like a good idea. We'll have to look at it, as we may do unions, API sockets, or other temp database tricks to show and/or report combined data.

We flipped over to the new framework that Wayne is working on. He did a small demo for us on what he is working on. These are just a few of my notes. See attached for a 1:39 - one hour and 39 minute video of of some of meeting.

- Our switch to a new framework is not just a time saver. It goes way deeper than that.

- Lots of conversation about supporting different frameworks, themes, and versions of code.

- The whole new framework is setup as an MVC framework or MVC model - model, view, controller

- We need to keep moving forward in order to stay valid

- Layouts and views

- Everything is event driven

- We have both raw input (info and data directly from a user or customer) and we also have cleaned up and formatted data (okayed, approved, combed, retrieved, or sanitized data).

- These are just some keywords and concepts - handlers, events, models, interceptors, layouts, views, classes, methods, etc.

- One of the goals is to get rid of all of the repetitive, ticky-tacky maintenance code. This is stuff like params, validation, permission checks, making sure that certain values have been set, etc. Basically, the prep work before the real meat of the page begins. Some of our pages may be hundreds of lines of code deep before we actually get to the meat of the page. The framework would help us simplify and standardize some of the prep work stuff.

- If we build this way, it could open up options for multiple layouts and/or views (what it looks like). Keeping a separation between the business logic and the view or presentation of that data.

- Events, watchers, and triggers that help us run clean-up and other processes and routines. Key everything off of certain events.

- Getters and setters - smaller mini functions for each class, object, and property within that class. All built-in and/or available. We really wanted to do this for the fracture project (future project for adilas).

- Options for self-documentation

- Debugging, tracer options, logging, and security stuff already built-in

- Lots of talk about the benefits of using a framework.

- Mementos and smaller sub sets of data, that may be pre-formatted and/or setup how we need it - saving time in conversions and retrieving available data.

- Defining things and then using them over and over again in other pages.

- This is huge, but the framework already has a ton of built-in documentation and samples. That takes a lot of work and preparation. Also, it is able to self-generate basic documentation based on how we code it (based off of keywords, hints, notes, and rules).

- If we build off a new framework, we could use either Adobe ColdFusion (current model) or we could use Lucee - open source CFML engine. The framework can flip flop pretty easily between the different backend engines. It's basically a config option.

- We do lots of things over and over again. Make that more simple, standardized, and compartmentalized.

- They offer a standard set of options and configurations. We can use that and/or pick and choose or customize whatever we want.

- Light talks about the pros and cons of an ORM model (object-relational mapping - mixing of objects and relational databases)

- Shooting for a more modern approach - use of code, technology, and a layered approach

- Wayne really wants to come up with a process of how to convert our current pages and code into the ColdBox framework. Think of a set of instructions (virtual recipe) and then allow other developers to help convert the pages. Basically, a road map to follow.

- Our customers really need and want us to be more stable and reliable, as a company, and as a software system. This includes how we develop code, release and deploy code, and manage systems and servers. In a nutshell, they want us to grow up, as a company and have a bit more of a standard structure and presence.

- We are heading more and more towards clustering, enterprise level stuff. We need to build towards that.

- As a side note, Wayne says we have way too many includes (files that get included and/or strung together to make the whole).

- One of our major focuses on switching the backend architecture is customer reliability.

- Wayne sees a need for radical changes to simplify, stabilize, and build things out for the future. It has to be sustainable and sustainability. Light talks about evolution vs revolution or changes over time vs drastic changes all at once. Things are smoother if software can evolve vs just being harshly changed. However, sometime things need to majorly change, hopefully for the better. There are some pros and cons to both approaches.

- Building new has a motivation factor to it - true story - what keeps us going?

- This is a chance to rebuild it like we want it - build to the dream

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

We switched subjects and were the guys were talking about hosting companies and how that scene is changing in the datacenters that we are using. We have seen a lack or lowing of the customer service levels. We may end up checking out some other hosting companies.

John and Cory were talking about other projects and timelines. They were also talking about uptime, downtime, and databases. We talked about coming up with new SOP (standard operating procedures) for pushing up code, code rollbacks, and deployment of new features. That got into talks about manual and automated database updates, scripts, auto processes.

That topic lead to a discussion on roles and responsibilities and who does what. There is a need to define some of the roles a little bit deeper and make it clearer who does what and in what order. More SOP stuff for the backend processes and procedures. There also needs to be good communication between the developers and the system admin persons. We have to keep up those communication channels. That is really important. Nobody can read minds.

Towards the end, John and Cory were going over projects and coordinating dates/times for testing, review, look and feel changes, and testing. Good stuff.

GoToMeeting brainstorming session with Steve to go over ideas and concepts for SG&A costs (sales, general and administrative costs). The whole first hour was talking and going over ideas. We were drawing and going through some fake scenarios. Here are some of my notes:

- Imagine a bucket with a relative fill line partway up the bucket. This would represent the bucket or holding account for SG&A costs that need to be distributed. As new sales happen, we would bleed off that bucket (lower the amount) based on the sales (percentage of average sales per month and what we thought was going to be the average monthly SG&A costs).

- Some of what we are doing would be considered smoke and mirrors. We have some known values and some unknown values. We have to mix and bled both, known and unknown. We also talked about flex and being able to flex at different times (image 1 and 2 how we see flex bubbles or data assembly line concepts).

- We talked about how we move monies for automotive vehicles (managers checkbook) and slush funds. Virtually padding things as needed to help offset costs, basis, and profit.

- We talked about using a fake number as an average and/or a fake burn number. These would be settings for average monthly sales and average monthly SG&A costs. Once we record these as settings, we can then base our math off of those values. If we want to run things harder or faster, we just change those values, which in turn would change the ratios.

- We talked about thinking on an invoice based model not on a daily basis model. That way, each invoice would carry its own weight and only happens as it really happens. For this first round, this was an easier tie-in to make.

- It keeps going, average SG&A and average sales per month. Constant fill and remove, fill and remove of those associated buckets.

- We talked a little bit about time. How many days to drain each tank or bucket? Monthly bills, annually bills, and other time variables.

- Here is the rough formula for our calculations: sg&a cost = invoice sub total * (average monthly SG&A costs / average monthly sales)

- Don't let SG&A go into the negative. We can't spread out or disperse more than we have available to spread. Adjust the buckets as needed. Being able to control the flow (gas and brakes) based on settings.

- We could show them (our users) the rough averages on the SG&A homepage. We could even do some forecasting or showing a "look ahead" view of what it should play out to look like. We could even show what things would look like under different circumstances and conditions. Almost a snapshot and/or predictive model.

- We will format our data in groups, drill-downs, and details. The goal is to seek the IRS's approval for this technique for tracking SG&A costs.

- Steve and I spent some time talking about systems vs trying to marry together multiple independent software packages. That can be a real nightmare. This topic lead to talks and discussions about systems, normalization of data, and even other outside 3rd party solutions using our data to show reports and statistics.

- Interpellation or Interpolation (not sure on the spelling) - good estimate and/or an educated guess

- Putting a white label over the top of our software. This would allow us to play a more build and supporting role vs the main point of contact and training. We may really want to look into this as we build out fracture (future project). We could be the Intel chip inside the computer or laptop vs being the actual computer (analogy with the Intel chip being inside various different computers and laptops). Being the underlying pieces of the system vs the top level or frontend piece.

- Steve was saying - selling what they want and how they want it - that's how you sell and market things.

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

After talking about SG&A costs for the first hour, Steve and I switched over to talking about our guys, hours, projects, and having our guys record their time and progress. I really enjoy the building and brainstorming part of the puzzle. The management portion is less fun. This has been a small pain in our rear. Too much babysitting. Nobody wants to document what they are doing. Steve and I talked about our burn rate (money wise) going forward and what are plans are. We need to be able to finish up projects in a timely manner. Sometimes all we can do is keep chipping away at it. Some of these things just take time and resources. We know that, but still, it's hard to swallow sometimes. We need to add in some levels of accountability. It's an abundant model and there are lots of players who could play along with us. Lots of options. There are some real challenges to running a software company from a distance. We will keep trying to help our guys and gals finish their projects. Sometimes all we can do is keep pushing forward as we are able. Here we go...

Met with Aspen to look over her world building presentation. We ended up getting into this little Q and A session and small virtual interview. It was kind of fun. Aspen took a bunch of notes on a Google doc. I won't share all of the info that we covered but I may pull out a few key pieces.

- Settings and speaking the client's language is a huge part of it - where it starts or where they (the client) gets some buy-in. Once you speak their language, they feel more comfortable.

- System configuration - I like this, I don't like that, can I hide this, can I make this show up here or there, etc.

- Using world building concepts in trainings and demos. Once the clients figure it out and catch the vision, they use world building terminology in describing what they are wanting or what they are hoping to achieve. Basically, if you can get the client to start thinking about the bigger picture, it really gets the juices flowing and the ideas rolling in. Virtually get the wheels spinning.

- Keep building what we know and then deal with other ideas and requests as they come. Custom code vs settings and toggle on/off features. A growing blossoming idea farm.

- We have outgrown a number of different models. For example: We started out with 5 different roles for permissions. Things like sales, mangers, accounting, admin, and backend/web. Now we have over 170 individual permissions that may be applied in any configuration vs the five simple roles that we started with. Also, our first round of corp-wide settings was to build out six corp-wide settings. We had to flip the model when we got up to the 400 ish level. We ran out of room. We ended up building vertically (variable/value pairs) and using custom setting objects (JSON objects and linking similar settings). Tons of ways that things have exploded, changed, and evolved over time. It's been a process. The other big challenge is adding in or taking away new stuff without affecting those who are already in there working (existing clients). You almost have to make the system a chameleon that can change its shape and color on the fly.

- Aspen and I talked about the potential of doing a white label approach. Kind of like the Intel chip inside of a computer. It could be branded however, but the chip is what the whole thing rides on. For example: You could have an HP, Dell, or some other brand of laptop but all of them use the Intel chip as the underlying microchip processor. We would like to do something similar. Whatever brand, powered by adilas.biz on the inside. We don't have to be the main company like HP or Dell or whatever. We could easily just help power those brands using our tech and underlying engine.

- Along the lines of a white label - It would take a potential competitor years and years and millions and millions of dollars to do what we can do right now. If they saw the value of a white label option, they would be smart to go in that direction (saving time and money). Just reskin it and start selling it vs building it from the ground up. There is already a market for what we do (based on our current clients and 20 years in the business and millions and millions in revenue - even though we aren't done yet).

- Aspen asked me about a couple of features that we are using right now and how they relate to world building. I mentioned elements of time and the flex grid tie-ins. Both are hugely customizable and fill gaps and needs, out the door. We talked about selling in bulk but tracking individual items, tracking processes of change (dealing with sub locations, sub phases, or steps of a process). One-to-many relationships, custom fields, preset settings, configuration, and being able to limit what is shown (even though behind the scenes it could be very complex). Tons of samples, examples, prototypes, and working models. We have nuts and bolts companies, bike shuttles, ski schools, and tons of other companies that use these pieces. This is just two pieces of the much bigger puzzle.

- Most of our progress is somewhat limited by outside funding, not ideas or needs. We have huge dreams; it just depends on where the funding for that comes from. This whole thing has been build on a garage type budget. We have ideas and projects that sometimes sit for weeks, months, and years before we can get to them. Our list for an MVP (minimal viable product) keeps revolving and growing. If there is funding, it moves to the top of the list. If not, we chip away at it little by little.

- Lots of analogies between our system (the adilas.biz system) and the body. Often, we start out talking about things like arms, legs, feet, etc. As we get deeper, we get into layers, joints, muscles, system, and clear down to the cellular or molecular levels. People keep wanting to be able to control and/or see the next layer, the next layer, etc. We haven't found the end or bottom yet.

- Aspen was asking what is the difference between world building and fracture? I tried to explain that the fracture project is more of list of lessons learned, ways to speed things up, ways of standardizing things, allowing for customized things, show/hide things, toggle on/off certain settings, full control over flow and display, and controlling things at a smaller detailed level. World building is what we are trying to do and/or accomplish (think bigger picture). We use fracture (aka the next generation of the system or application platform) to get to the bigger world building pieces. We talked about Legos and building blocks of different size, shape, and functionality. Sometimes you need to play in bulk (bigger or preset pieces), medium pieces, and super small pieces.

- We got into talking about the iceberg analogy (or ice berg analogy - different spelling) and how if we could have the whole mountain but only show the iceberg, it would sell better than something seeing the whole big mountain. It makes it look too intimidating (showing the whole mountain). The iceberg looks so much more approachable (be able to configure just what you want to see and use). That's where fracture and some of those ideas come in. You could still have the whole mountain (under the surface) but only have to show what is needed or wanted. Put the rest of the engine under the covers (under water) like the Intel chip inside of a computer. It's all perception and expectations.

- Ideas that don't get exposed (out to the public) can sometimes die in a hole. We talked about if a bigger company was pushing some of the world building concepts or data assembly line concepts, they would sell like hotcakes.

- Towards the end of the meeting, we were getting into costs, growth, and projections - numbers, costs, financials, etc. Fun stuff!

Anyways, a great meeting. Aspen has more notes in her Google doc where she was recording things from the small interview. I enjoyed the chat and the learning session. Sometimes you don't know what you have until you start trying to verbalize it. Good stuff!

We started out the server meeting and Cory wanted to check on the data 34 server. It was reported that it was running slow. Wayne logged in and looked around. They ordered some more RAM for the database server. Pretty cool to see how quickly they can jump on things.

Next, we started talking about a client and their balance sheet. I mentioned to Cory that we have on our wish list a report that would show known issues (bad dates, things done out of order, or other possible problems that we could detect and/or figure out). That would be so cool. As a side note, the page already exists, it just hasn't been built out yet. Definitely on our wish list for fracture. This could help all of us out and make things more transparent and visible.

Both Wayne and John are working on documenting things on the server level. It's far from done, but they showed up a 3 page document (just the start) of the outline or outline of the server layered architecture design document. Pretty cool. Starting to see that being worked on. I'm excited to see what they come up with.

The next major conversation was dealing with adilas phones, phone trees, and other forms of digital communication. We had some open discussion about do we want to keep it, who is going to support it, who is going to maintain it, and so forth. This piece is kinda flapping in the wind. We also talked about, if we want to, allocating both time and money and getting that code and/or process fully inhouse. Right now, it is a virtual 3rd party entity, even though we technically own it. The prior owner/developer is the only one who really knows what is going on inside there. We talked about different technologies that we could and would use if we brought it fully under our control or under our roof.

The reason that the adilas phones stuff got brought up was because of this document that they are building out for the system architecture and layered plans. Hopefully, we'll uncover other issues and/or dependencies that we need to look at and evaluate (spend/don't spend, maintain/don't maintain, market, pitch, let it die, etc.). We kept getting off on tangents. Cory did a great job keeping the discussion going in a good direction. Once setup, we will provide an open VPN (virtual private network) for our developers to be able to remote into the testing box to push code and make changes.

After that, we got into talking about the testing server and what our plans are for that. We have a client's data that we want to move off of a production server and put in the Amazon cold storage or Amazon Glacier. As we were talking about the testing server, Shari O. was sending questions and comments through the chat feature on the GoToMeeting account. We are making progress there and making headway.

We got into talking about insurance, coverage, errors and omissions, and general cyber security, and data breaches. We have a 3rd party integration that is pushing on us and wanting all kinds of certifications and proof of insurance coverage. Everybody but John and I had to leave to jump on other meetings or calls.

After that, John and I spent some time doing a code review on his recipe/build rework stuff. We talked about a new possible user-level setting for using the time-pickers vs an open entry time field. John likes the time-pickers. I had to take them out the other day due to a few clients complaining. That sounds like a perfect option for a user-level setting. We also went over new options for showing progress bars and helping the users know which step they are on and what is still needed to complete a certain task and/or process.

As a final comment for the meeting, John said - "The ROI (return on investment) for the testing server will be internal peace of mind." I liked that.

Sean, Shari O., Michael, John, and I were on the morning meeting. We all checked in and said what we were working on. After that, we all either left or went on mute and worked in the background. Shari O. had to take a tech support call and Sean was waiting to chat with her once she was finished. John had some flex grid tie-in questions. I was doing some research on MVP's and past data that we had recorded for what we wanted in some of our MVP (minimal viable product) stuff.

Here is a short MVP list that I'm thinking about - for the record, we already have some of this, we just need to refine it and make it watertight:

- Special accounts and in-store credit - We already have loyalty points, and round 1 for gift cards. Eventually, we would like to do in-store credit, vendor credits, punch cards, and other ones. The next biggest need is for the in-store credit stuff (in my opinion).

- Round 2 on gift cards - We've been gathering ideas and wants and needs

- Coupons and promotion codes - clear out and through ecommerce and internal shopping carts

- Take Calvin's adilas label builder to the next level - we've already done some planning and prep work there

- Standardize the merchant processing options - We have like 9 different integrations. Here's my next goal, pick one, make sure it flows from start to finish and is super simple. I want to do normal sales, pre-auths, captures, tips, refunds, voids, and reoccurring payments, etc. We have to be able to do manual key (like ecommerce mode), swipe, chip/EMV, and tap to pay hardware integrations. I want to do and offer all of the merchant processing functions. I was thinking that we could do a big push and try to get all hooked up with Datacap and then let them handle all of the different hardware pieces and different merchant gateways. That's my thoughts right now.

- Revamp the internal shopping cart, my cart favorite buttons, and general look and feel. I would love to head towards the fracture project - we have a bunch of R&D on where we want to go with that.

There are tons of other things on my list, but that is my quick MVP list for right now.

Sean and I started out the morning talking about deployment and how we need to keep offering that as a service. Certain clients are so busy, they really don't have time to deploy or devote time to training and setup. It's not that they don't need or want it, they are just spread too thin. Sean was talking about a current deployment that he is working on and I told him a story of us going into a kitchen ware store and helping to set them up. It took a couple of weeks with a few of us onsite to make it happen. At one point, the lady in charge of the kitchen store said, "If it wasn't for you guys helping us out, we never would have been able to make this transition." That is totally true.

Anyways, I wrote down in my notes that part of the fracture project that we are planning has to take into consideration training, deployment, setup, and other marketable services. We need the support staff to help support what we are trying to do, build, and accomplish. Taking the time to get it done and make sure that the parties that be are in the know and can function on their own. They need to know how to get help, but ideally, they have been trained sufficiently for the task(s) at hand. Another plug for the concept of "education mode" as a setting for helping people to get started.

Steve was on some phone calls and somewhat listening in the background. Sean and Shari O. were talking about merchant processing and where we want to go with that. I mentioned the company Datacap and let them know that we may want to look into doing a 3r party integration and solution with them, as it would open up a number possible merchant processing options. We can do merchant processing right now, but we have to spend time and resources integrating with each gateway, merchant, and/or device. We could really use something to help speed up that process.

As the meeting ended, I was doing emails and other small to do list tasks. I was thinking about small nursery rhymes and how we have used some of those same analogies and stories in our own story. Things like stone soup, the little ren hen, and many others. Kinda fun. We are daily building and hoping that someone will catch the vision and help us along the journey. Like the tortoise and the hair, slow and steady wins the race.

Started playing with elements of time and setting up the main pieces for the adilas master plan. Here is a quick breakdown of the time id's.

Master Adilas Plan

All time id's are inside of adilas

2283 - Main Index

2284 - Jellyfish Model

2285 - Value Add-On Core Model

2286 - Adilas University

2287 - Adilas Marketplace

2288 - Adilas Cafe & Community

2289 - Fracture - Future Project

2290 - Budgets & Finances

2291 - Marketing & Sales

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.

Looking over site design options inside of the thinkific site for the adilas university site. Making a few small changes to the site layout. Recording notes in both adilas and the adilas shop. Spent some time going over Shannon's videos from back in 2016 on adilas university - 12 main players. Good stuff. Here are a few notes for myself about some of her videos.

- It's ok to leave things for other videos. You don't have to go into crazy depth on every button, link, or option. For example: You could say something like, we will come back later - and then actually do it.

- Shannon would do a great orientation and quick overview. Then she went deeper and started showing usage, flow, and tips on the features.

- When we do some of the training for fracture, I would really like to go through each section, page, and function and list out all of the options. Then do quick little 1-2 minute videos on each of the sub functions, tips, and power user tools. This master list may take some time. As a side note, there is already a huge outline that we made for the presentation gallery. It may not have everything, but it could be a good starting place - start on page 5, under business functions.

- After the good overview and explanation, then go in and do it in speed mode or show a few reps so that they, the users, will see how fast and easy it is to do, once everything is all setup and prepped.

Steve and Sean were talking about how quickly you could setup a company and just sell and redeem gift cards. We may end up pushing this a little bit further. This could be a quick way to get our foot in the door with a company. We did some playing inside of the demo site and even made a few buttons, setup some quick settings and defaults, and ran a few things through the process.

As a note, we have a number of other quick standalone features that our clients can use that don't require a ton of other pieces. Things like the customer queue (even generic placeholders), timeclocks and timecards, quick calendar events, project tracking, ecommerce, etc. As you get into more and more things, the complexity level does go up, but some of those things could almost be sold or marketed as standalone products or pieces. Of course, they are all there (included), they are just smaller pieces of the whole that may be used independently or with minimal training or other setup.

Steve was asking about a possible option for showing buttons (my cart favorite buttons) with choices (like options on a menu - what options or side do you want with that?). We spent a little bit of time talking about how the buttons could include choices or whatever. At some point, we would like to do some buttons that tie right into time and scheduling as well (time buttons). The button is nothing special. The big advantage there is that it can hold the rules and assignments or special selections or settings. Basically, backend code and/or choices or presets get assigned to each button. That's what makes the button so useful.

After Steve left, to jump on a call with Mike, Sean was asking about quick setup options for things that we do all of the time. I mentioned that we could easily setup prep scripts or special code to help do certain things and/or configuration steps. Say you have a process that would require you to do a certain number of steps (say 10 or 50 or whatever). If you created a quick prep script, you could click one button and then have the system do all of those steps (5, 10, 50, 100 steps) all in the background. Especially if it is the same thing over and over again. It could really speed some things up. This would be a great addition for our fracture project, going forward. Quick settings, quick setups, quick default, and industry specific prep scripts. That would be really cool.

At the end of the meeting, John and I spent some time looking over a page to help split an expense/receipt between locations. This is something like an insurance bill or a bill that needs to be split by percentages between locations. John is working on taking older pages and updating the look and feel. It's looking good. He has permission to merge that page into the master code branch.

Notes and thoughts about an MVP (minimal viable product or minimal viable plan) for Fracture - future project for adilas:

- Dynamic yet standard CSS - allow for others to change their dynamic CSS (look and feel) - maybe hold some of this in settings and in the database somehow. That way, they could always change it and we could dynamically pull it in on the fly.

- Full API socket access with good documentation. Every feature, every function, super small getters and setters for each section.

- Funding options - real money, time, products, investments, selling percentages or shares, etc. Be open to lots of options. Multi million dollar stone soup type analogy.

- Along with funding the options, I would like to make a page that shows the time value of money based on total gross sales by Adilas, LLC. For example: If someone wanted to buy a percentage or share, they could see the total gross revenue (year over year sales totals) and then see what that value is multiplied by a factor, say 3. The standard is between 1-10 times of the total gross revenue as a general ballpark number. We could show them a price and then let them purchase that percentage or share (somehow contact us). Each day that the page is up, the price would go up daily, based on the total gross revenue. Just for fun, they could roll it backwards (view only), if they wanted to look at things based on past dates. Just playing with numbers. We may have to figure out some other things, just an idea.

- If we did seek some outside funding, we could put up 20-30% of adilas (shares or percentage for co-ownership). We could also open up options for funding as a loan or to lend or loan Adilas, LLC monies. That money could be put on the balance sheet with promissory notes plus interest.

- Just as a rough number, shooting for $10 million in funding for projects and future development. It very well could go beyond that. We could start on projects once we get a portion of that (seed monies). Technically, we could start with anything. Shooting for a smaller $2 million for a seed money level start. If further budgets were needed, they could contain things like marketing, sales material, training, education, documentation, look and feel, interface changes (UI/UX and GUI updates), new features, bulk tools, upgrades, maintenance, servers, team members, admin/management, developers, support staff, internal training, different roles and responsibilities, hourly wages/compensation, salaries, perks, plans, project management, R&D, AI (artificial intelligence), "Any" scheduler, design work, API sockets, consulting, white labeling, settings, permissions, templates, marketing, advertising, promotions, sales, certifications, merchant processing, external marketplace stuff, 3rd party solutions, and other areas. Just putting a number out there for a general goal.

- Another thing that we want to keep doing is creating content - written, verbal, visual, video, etc. Good, clean, data, and content.

- Make an MVP plan for where we are going - we already have lots of research and planning for fracture and other projects - just need to pull it all together. Pitch the pitch and review other notes. See the developer's notebook for other topics as needed. Most of the notes are stored there or are referenced there. Great resource.

It was just Steve and I on the morning meeting for the first 20 or so minutes. We were talking about getting people started and getting things going and helping them to get up and running. Here are a few other random notes from our meeting.

- At some point, we would like to circle back around and get back to the vendor logs or payee/vendor logs project. Basically, this would be similar to the customer logs but for both vendors and employees (users). Steve started this project but it got put on the shelf as other things came up. We need to circle back around, when possible.

- On the chooser page, what if we allowed every possible page. That could be really cool. This is where a user gets to choose what they want to use for their default homepage.

- Steve was asking about settings and how we wanted to organize things. I told him that we have at least four known levels for settings that we know of, right now. They are: corp-wide settings (at the world or corporation level), group level settings (any of the 12 main player groups or sections that we have a homepage for that section), page level settings (currently using the slide out drawer on the right of the snow owl themed pages to show page level settings), and user settings or personal settings. At some future point, we may want to build out a master settings page that showed where everything is and/or is located. We have things spread all around right now. This may be a project for fracture - future project.

- The whole thing of adilas seems to be a pyramid or stacked layered application. There are tons of different levels that build on top of each other.

- The magic seems to come from progress and ideas. We do something, someone else sees it, adds to it, requests something, we build it out and/or add to it, and it starts all over again. Like a giant snowball or idea farm.

- One of the huge foundations seems to be settings and permissions. We are also seeing that these two key foundational pieces tend to split, fracture, or break into subs. Almost an infinite level of control and customization. Very interesting.

- Sean and John popped in and gave us some updates and reports. Dustin and Kelly also joined for a little bit. Their general vibe or message was - that people need help (generally) and if we can help, we are able to slide into place. It could be data entry, tools, functionality, systems, normalizing data, sales tax, inventory management and controls, financials, etc.

- My observation from today's meeting - it seems like all of the team is playing well together and helping to get things done. No way, one person could get all of this stuff done and handled, as it is going along and happening. I'm super grateful!

- John was showing us an update on the chooser page to help users select, view, and setup their default homepages. He is making good progress there. More good changes coming in the look and feel department. Good stuff!

Working on three different projects. First, quick tweak to help with High Valley Bike Shuttle and setting up reports and shuttles for the next season. Second, sending files over to Beaver Mountain. These included some instructions, template files, and blank registration forms. I also sent an email to the client with information. Third, I worked on some new tool tips for the Beaver Mountain on their horizontal time view. The folks at the ski school have requested a few things. Playing around with ideas and options. Light research.

Going back to the idea of setting up custom verbiage and SOP's (standard operating procedures) for clients, we have a ton of great options in the top header and footer for the snow owl theme. Each person has 8 of their own custom navigation links and buttons. There are also over 40+ custom navigation links and buttons that may be setup per corporation. If used correctly, it would make access to simple SOP's and other custom training, education, or tips available to all users, right from the site, using the custom headers and footer links. That is pretty cool. We need to remember this when we are building out fracture and our next theme and framework. These custom links and buttons are huge. What do you need? Where do you want to go? What is important to you and your company? Let us help you out... Good stuff!

Sean and Danny were talking about demos and techniques. They are prepping an outline with hyperlinks to help them navigate and show things quickly vs having to navigate the whole system to get to the same pages. Good technique.

Steve joined the meeting, even though it was his day off. We got into talking about new time settings and my meeting yesterday with Beaver Mountain (local ski school). They have been using adilas for close to 7 years now. Most recently, they are looking to use it to help them with registration for their special mountain events and races. It was unintentional, but I ended up giving all of the guys on a meeting a full-on demo of what we are doing and where we are heading.

Steve was kind of challenging me on a few things - why did you do that? What about this or that? Maybe we could do this or that, etc. We talked about it and I took some notes. I still don't fully know what direction to go and what would be best, but I took some notes. Some of it was dealing with multiple systems vs a single system, settings, custom code vs building for the masses, and individual customer records vs quick flex grid to get super simple data into the system quickly. We talked about effort levels, timing, speed, data in/out, exports, and future flow. It was a good discussion, even though I felt like I was being challenged on every front.

As a side note, when we started this project, back in 2015, we didn't have what we have now (7 years later). If we had had what we have now, it would have been a different story. All things are possible and are options, it just depends on timing, resources, budgets, skills, and where the system is at (functionality wise).

As a part of fracture and going forward, we will be trying to turn in as much stuff to settings as we possibly can. We have 4 known levels for settings. They are corp-wide (world level), group-wide (12 main players), page-wide (per page per section), and user-wide (preferences and options per person). Things keep breaking down into smaller and smaller pieces another word for it is "subs". We even were talking about things like subs of corp-wide settings and almost location-wide settings. We don't want to go there yet, but it is starting to surface. Basically, the main goal is to turn everything into settings, where possible.

Along those same lines, if you have tons of settings, you will also need different levels of users - end users (lower levels of knowledge and skill), medium or middle users (knowledge of settings, options, and configurations). You will also need the admin users or backend/systems admin persons (who is making and building the settings for the others to use). It can get deep.

It is ok to re-think the processes or re-think these processes. Permission granted! Often, education leads to new ideas. We see it in our clients all the time. We add something or teach them how to do something and almost immediately they come up with something new, different, or that now seems possible based on the last known level. We call that taking the next logical step. It's huge and big part of what we do.

The last note for this session was this - everything is breaking into subs, sub settings, sub permissions, and sub configuration options. Everything!

Steve and some of the other guys were on a bigger demo this morning. It was just Danny, Sean, John, Michael, and I on the meeting. The guys were talking about demos and what they like to show and what they like to gloss over (speed of the demos and interest levels). Sean then showed some of the cultivation stuff that they are setting up for an upcoming demo.

It turned into a small sales meeting. Michael reported on what he was doing and up to. Sean and Danny were running the meeting. We went back and talked more about different bids, demos, and possible options. John showed us some of the dashboard stuff that he was working on for his school projects. We would love to grab some of that type of code and put some fun stuff into play inside of adilas. This deals with dashboards, quick counts, sums, totals, aggregates, charts, graphs, and other quick eye candy. We talked briefly about our desire to build out graphical homepages for each of the main players and sections. That would be really cool.

As we were talking about graphics, Danny, who is a pilot showed a screenshot of a modern navigation or heads-up panel from an airplane. The old was way was tons of different gages, the new way is a real time visual with all of the main important stuff, right at your fingertips. That's what adilas needs, a head-up panel for your business.

Danny then showed us a small video that he was working on. It's just a quick website overview. He is just playing with ideas, timing, and concepts. Anyways, here's the link to the video.

Our next major subject was talking about display and modern design stuff. We went over tabs, horizontal nav systems, vertical nav systems, cards, titles, buttons, sliding drawers, show/hide and toggle options. Lots of visuals. That lead us into a discussion on my cart favorite buttons and how we could keep pushing on those custom buttons and improve their look and feel as well as add additional functionality to them. We talked about smaller cards with other required settings on the individual cards. We also talked about time buttons and how that could really help for scheduling. Great idea going forward for internal scheduling and fracture level controls for custom interfaces.

To expand on the button concept and/or my cart favorites. What if the custom buttons weren't just for the cart? We have similar things on the snow owl theme and the individual payee buttons that can be mapped to different pages, URL's, reports, or sections within the site. What if we took all of those things (cart buttons, quick look-ups, jump or hyperlinks (URL's), navigation, and other options and made the whole interface something that you could setup, on the fly and be specific per user. As a side note, we allow for buttons to be copied right now, if they are set to public vs private. If a public button (aka some sort of nav type button) could be copied, that could be really cool and could allow a lesser user (skill wise) to be able to get awesome functionality without having to know the whole backend processes. Just a thought.

This conversation took us over to the shopping cart, split cart, and different cart types and styles. We talked about all kinds of visual and setting based improvements that we could do over in the shopping cart land. We briefly rolled through the classic cart, the kush cart, and the short and sweet cart (different existing cart styles). John was talking about adding in settings to help with flow controls (step 1 of 3) or crumb trails (you are here - in this process or step), etc. Ways of visually showing our users where they are and what else if still coming and/or needed to complete a certain process or procedure. My biggest takeaway from the entire meeting was - "Show people, don't just tell them!".

Wayne and I jumped in and did an hour and a half long meeting talking about the internal shopping cart. Wayne was showing me how he has to change things in order to run tests on certain pages. He is using an interesting combo of saving content and running included files inside of the saved content. Then it becomes a memory variable (big but still in memory) and he can test certain parts of the page that way. Interesting.

We went over some of his tests and how he has to virtually fake it, mock it up, and simulate certain flow and/or actions. He is working on removing an older code set that used a cfinvoke tag into more of an object model. We went over mocking the data, throwing errors, and catching the errors and exceptions. The discussion on testing got us into topics like: limiting the scope, only testing one page at a time (not the dependencies), testing without touching the database, keeping your data clean, simulating page redirects, as well as hard aborts or stops.

Part of the test is separating the data from the logic. The logic doesn't know if the data is real or not. It just knows what to do with certain types and kinds of data. By splitting things up, you could test the code logic without having full access to the actual data (live data) or being able to fake or mock the data (hardcoded or simulated data). The goal is to test the logical flow of the data through its process and/or routine. Ideally, the end goal is to make the processes more refined, bullet proof, while keeping the data nice and clean, and organizing the code to be reused and maintained by others (where does each process live and how is it organized). We briefly talked about putting supporting code closer to the usage of that code vs a more disjointed style.

After going over some of the testing, we switched over and started looking at the actual cart code and how it works. We did some demos, looked at code, and did some drawings. Some of the discussion was dealing with other developers and what assumptions that they are making. If the process is super complicated, the other guys who don't know, guess at where to make changes and where to start. That has bitten us in the butt a few times. Often, we play this crazy game of "add on". If the other person/developer doesn't know where it starts, they simply add on where they can and then go from there. Sometimes that is fine but as it gets more complex, it actually causes pain to the other developers.

To be honest, sometimes we don't know where things are going when they get built out (first time around or phase one). It just keeps organically growing through that add on game. Eventually things slow down and we can determine what is needed and wanted but we may make a mess getting there. That is totally normal. You just have to be willing and able to go back and do some maintenance and clean-up. That's the part that we have been missing. Currently, we just keep pushing forward without taking time to circle back around. That process of circling back around takes major work sometimes. Part of our fracture project (future project) will be going back and defining what we want (overarching scope and requirements) and what we need and then building accordingly. The bigger the picture that we can see (speaking hypothetically) the more we know what needs to be included and fully integrated - once you know the bigger picture, the path becomes clearer and you can plan accordingly.

Things get really crazy when there is a difference between testing and production environments. That could be settings, permissions, versions, data, usage, processes, scale, etc. It can get quite in-depth. The more ways to do things, the more things that need to be checked and maintained.

Wayne was saying, none of our customers have ever left our system because we don't do custom. They love that. Some of them really hate that as well as they have been burned and feel like testers vs clients. Most clients don't have a problem with what we charge, for what they get, we are way under the normal market prices. The biggest reason that some of our biggest clients leave is either the look and feel or consistency and scaling issues (they get too big for our product). The next step up is a big one (cost of other custom software solutions). Wayne and I were talking about helping our code not be fragile and be more bomber and scalable. That is a task, in and of itself. One of our biggest weaknesses is code reliability. Getting that dialed in and on speed dial, that's the goal.

Having said that, we have a viable working prototype (the adilas system or adilas platform). Not only are we constantly refining it, we have had paying customers who have paid hundreds of thousands of dollars per corporation to use our system, as is. That's millions and millions of dollars that we have generated on a working prototype of sorts. That is awesome. I'm excited to see where it goes.

Finished off our meeting and conversation about talking about how even automated testing still needs some hands on testing and virtually kicking the tires. Wayne and I also talked briefly about percentage ownerships stuff inside of the adilas company. We would like to invite Wayne to be a co-owner in the Adilas, LLC - multi member LLC company.

Danny and Sean popped into the meeting. Nothing major going on but just talking about sales, demos, and how to put our best foot forward. We talked about getting small quick screenshots and samples to help go along with our demos. Currently, we bounce inside of a demo site, show someone around and then bounce somewhere else. I use the word bounce, and we are fine with that, but to a new user, that seems like you have to know a lot, in order to jump or bounce around. They want to know that we have certain things and want to get their hands held for the first little bit.

Because we are so flexible, it sometimes intimidates people and new users. That might be a good thing to remember for fracture (future project). Maybe setup a super simple step 1, 2, 3 process that always work (for example, the normal front door entance) and then show them how they can change that if they want to (side doors, back doors, basement doors, garage doors, etc.). Dustin was calling it handrails. I might be nice to have different training modes or education modes. If you turn it on, meaning education mode, it virtually tells you what to do. If you turn it off, you can bounce wherever you want (like normal). Almost an analogy of training wheels vs freeride or normal bike riding (without training wheels).

As a small side note, my dad (Wayne Moore) was saying the same things yesterday. We were looking at the main adilas.biz website and he was saying, I like the verbage but I want to see it (super tiny clips or screenshots). For example: It says "real time visibility and control with inventory management". Ok, what does that mean and can you quickly show me (a picture is worth a 1,000 words type mentality)? Just some quick screen shots.

As a note, there may be different levels. We may need a quick overview, a quick this is that (demo style), and then a deeper how to or let's really learn and master this. I can totally see a need for different levels of screenshots, examples, tutorials, and step-by-step walk throughs. Good stuff.

Small demo for my day (Wayne Moore) and Harry (my dad's friend). They were pitching that we need some training courses. They want to go pitch adilas, but don't feel that they know what it can do. We talked a bunch about LinkedIn training courses. See attached for some of my notes. The first part was for the demo and then we started talking about all kinds of education type options.

- Wayne - training courses - in LinkedIn - people need to see it

- Adilas course that could be as deep as we would like... overview, beginner, intermediate, advanced, deep-dive

- Helping people know what is possible

- Get people where they need to go and then come out with a skill

- YouTube is another option

- We could get a lot of traction if we help train the public on what we have

- Putting the pieces together - where do you start and where can it go (easily) and with some work (more in-depth).

- The crazy things that we are doing - everybody needs.

- Global communities

- Tapping into other resources - including going into LinkedIn - allowing them to get all of the resources (course materials) so that they could do it on their own

- Helping show the adilas world - we have to show what we have

- Just in time learning and training - being able to move from step to step (building out the whole)

- We already have pieces - we need to string it all together - at the professional level - having our own plan of how to navigate the elephant

- Wayne was really pitching the training aspect of what we have and do

- Harry - you get what you pay for - If they pay for it, they become invested and involved - time, money, etc.

- Time - that is the tricky piece - sometimes we feel like we are so busy

- The digital world of learning - certificates, learning, etc.

- Adilas keeps changing... that is part of the game

- Steve was commenting on how we used to do videos - way back - we couldn’t even get things edited before they changed

- Wayne and Steve were talking about setting up new courses on LinkedIn - Wayne will see what it takes to add in new courses

- Steve was showing them some of Danny’s adilas quick tip videos

- Funding - getting enough to get that part of the puzzle going

- Talking about invoice reminders, online payments, etc.

- Steve was showing them the warranty registration stuff - video from Chuck

- Steve was explaining how our model has changed. We used to use outside reps and consultants. Now everything is done internally, using adilas trainers

- Steve was pitching ongoing training courses for our clients.

- Wayne has a degree in curriculum and training

- Steve was showing his older YouTube player - older stuff - but still valid - we need to update it and keep it fresh

- Speed and cadence of what we are going over - full outline and layout

- Just in time online courses

- People are pretty picky - we have to capture their attention pretty quick or maybe even faster

- Keeping up with the constant changes

- From Wayne - make the world our audience! Getting the information in front of the decision makers

- We can schedule more meetings, or we are on every morning at 9:00 am on the GoToMeeting channel

- From Steve - how do we make this go forward? Plans, compensation, ideas (even out of the box).

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

After the meeting, my head was swimming. I came up with a couple of other ideas, just for fun.

- What if for training we gave a new user 3 accounts vs just one account. Here is my thinking - One could be for the start of the lesson (work area), one could be for the finish of the lesson (what is expected or a finished product), and one could be for fun (we keep whatever, their own playground). All of the other systems could be reset to any stage by rolling back a database. Assuming that the training was planned out enough to roll things backwards and forwards as needed. This could all be scripted and rolled around as needed. It would really help with training and keeping things standard.

- What about making things plane Jane type interface or only as much as is needed. Keep it simple. Just a thought.

- Being able to reset the database at any time could be really cool.

- We aren't ready for this yet, but for fracture, it sure would be cool if we could have certain settings and defaults on speed dial. Basically, if someone wants a certain setup or package, the database (aka the backend scripts) could help us flip flop things in a hurry. Currently, we have to setup all of the pieces, settings, permissions, naming conventions, show/hide, sort order, and other aliases in a manual format or fashion. That takes quite a bit of knowledge. If we could get our settings and options dialed in, that would really help and speed things up. We could configure and virtually show/hide certain things in a click of the button vs hours of individual configuration. Lots of options here. It could be size wise (tiny, small, medium, large, extra large, huge) or it could be industry specific (this for that, and this other stuff for some other industry - tons of options). Preconfigure whatever we can. If they want to still tweak things out, it all exists, it just gives them a quicker starting point.

- Not sure where to take this... but I was thinking about books and choose your own adventure type style books. If you want to do this, go to page x or y. If you want to do this other thing go to page z. What if we helped setup our training in the same manner? If you want to put this on account, do this. If you want to pay for this, do this. You get the idea.

- Train the world

- Super easy setup and configuration, you could then tweak it if needed to get super custom

Added a new permission for some of the page level settings. We called it "Admin Level - Page Settings" permission. Cascaded the new permission to all servers and updated a number of files to watch for the new permission. The new permission id number is 176.

Side note for me - while syncing up all of the servers, I had to pull data from the data 0 box for multiple tables. Currently, the data sync grabs the entire table and its contents and syncs that data (inserts or updates). We really need to add a last modified date to those tables. Instead of pulling thousands and thousands of records, we would be pulling super small record sets. That would really help speed things up. Along with that, we could keep a history to help us know when the last pulls were made so that we could efficiently request and pull (sync up) the data.

The other thing that I was thinking about, while waiting for full tables to sync up, was daydreaming about using the web/API sockets to build the next generation of our software. I'm not sure if this is the fracture project or the next one beyond that. I think it would be really cool if we use our own API sockets and build some super cool pieces. They wouldn't have to follow any of the existing rules, look and feel, or whatever. We could build the whole app using the web/API sockets and host it on any server that we want. Just some thoughts. I think it would be really cool to do that. Even for the fracture project.

Along those same lines, if we build out the web/API socket interface, we could teach and train others to use the same thing (web interface or API level interface) to build all kinds of cool things. You could make it a way to teach other people and virtually invite other developers to build out cool add-on's, custom apps, or skinned down apps of what we currently have. Just some

Working with Danny, Sean, and Shari O. on the rafting site (demo site). They, especially Danny, were requesting and wanting some kind of SOP's (standard operating procedures) or some kind of a quick start guide. See attached for our notes. New notes are at the bottom. Mostly the session was just checking in and some light communications for today.

One of my observations is we have things all over the place. We have things inside elements of time, in physical notebooks, in emails, on adilas university, on YouTube, in help files, on different google drives, and the list goes on. We have a ton of resources, but they are not yet linked, cataloged, and organized for use. It's too spread out. That would be an awesome project to get all of that together and available to the public. That could be a future fracture type project. Training and education are huge spokes that we need in our wheel. There is a whole other side to this thing and it's on the education and training level.

Totally random, but a fun side note or thought - Think how cool it would be to go through the different system players (all 12), all of the different system business functions (12 of those as well), and the underlying core concepts. That would be awesome. Beginner, intermediate, advanced, and deep dive or backend levels. Show how things act, cause and effect relationships, where they show up for roll call, how things happened historically, how they effectually show up for roll call, and even how they financially affect inventories, banks, P&L's, balance sheets, and other financial relationships. That would be sooooo cool! I would love to work on that project.

I would love to get into the how, why, and what we are doing. The how and why really seem like fun topics. The "what" is pretty normal but allow us to do the other parts of the puzzle or passing the data along the virtual data assembly line. Getting into 3D world building and all kinds of cool stuff. So many things that we want to do and build. We just need help getting to that next level.

Looking over code for gift cards. Checking emails. Ended up pushing up some code and ran into a problem (crossing two code branches). Eric joined, Wayne joined, and we ended up rolling things backwards (back to the master branch). We talked about the need for unit testing as well as integration testing. Eric and Wayne were talking about software lifecycles and us maturing as a company. We are getting better and better but still need some improvements.

We could use some internal training on writing tests and how best to make sure that we have good coverage. We have so many different levels of coding skills (junior devs, senior devs, full stack devs, designers, etc.). We got into a big conversation about where certain logic needs to go and how best to handle errors and logic for checking for record counts.

That lead into a conversation about MVC (model, view, controllers) and how we are currently doing some of that but we are also mixing things. For example: We have some of the view and the controller in-line or on the same page. Some of our logic is intermixed with the display vs the business logic. Some of the code is older and some of it is newer. We need to make some plans and then go and head in that direction. Currently, we tend to go in a number of different directions. It gets done, but it looks more like patchwork vs tight, smooth, standardized code. Getting a plan and being united in that rollout, even if we have to do a little bit at a time, would be awesome for our fracture project and plans.

Good meeting this morning. Lots of talk about trends, needs, and client wants. Steve, Sean, John, and I were on the meeting. We were talking about software needs, trends, expectations and how those things keep changing. Steve was pitching the idea of a full white label type approach. This would be something like where we would license our software to a company, help them setup a standalone server(s), give them raw code and let them build and deploy whatever they want to do. This would be similar to open source in that we would give them a full copy, provide them updates, and let them tweak and use whatever they want to. Basically, let independent companies build out their own software solution based on our base code. In reality, that is still quite a ways out, but fun conversations.

Everything keeps changing, daily. Maybe let them (our clients) have it and do their own upkeep for their own systems. We could keep evolving the master branch and allow our clients to pull in new code, if they want it. It just needs to keep perpetually evolving. As a direct quote from John - "Our clients eat with their eyes." We need to keep working on a better look and feel. Also, this look and feel needs to keep changing every few years to keep it up to speed and up to snuff. If you want it to look modern, you need to have an update plan in place to keep it up.

Lots of talk about our competition and what level they are playing with. Because the whole world uses stuff like Amazon, eBay, and other giants, we are virtually competing with those entities and the expectations are similar because we play in the giant web world. Every has a smart phone and get to use mobile apps, nice interfaces, and other cool things every day. That is the expectation. That is really hard to keep up with and/or even play the game. Our users are expecting eye candy, graphs, charts, quick aggregates, slide in/out drawers, show/hide options, drop-down, slide-up, modal pop-ups, and cool one-pager type apps.

We just need to keep going. Eventually, even if it looks pretty, people really need functionality. However, if they can choose pretty and easy, they always will until it bites them due to lack of functionality. The old adage of form and function - which one do you or do our client value? It keeps changing as well.

Steve was talking with John about some future projects dealing with the look and feel. John is going to be taking over the adilas docs now that Chuck had to take another job. We talked about the use of a global style guide and keeping that up. Once again, every couple (2-4) years, we will need to keep upgrading the look and feel. It is part of the game.

As a side note, some of these things are good info for our future project of moving over to a project called fracture. Along those same lines, fracture may end up being a morphing process (using the old and making it become something new) vs a full re-build from the ground up. Both ways take a lot of work and there are pros and cons to both. Until we get more funding, our current goal is to capture the info, ideas, and data. We will then keep chipping away at the current infrastructure and virtually morph into the fracture model vs a full re-build. We would like to re-build, but that may not be practical. It all depends on needs, funds, timing, and goals.

Server meeting. The whole first part of the meeting was Dustin and Wayne going over some new things for cultivation. We talked about doing a new database field for locations and calling it a location type (normal, retail, warehouse, backend, vault, etc.). That almost sounded like sub locations, but we didn't end up going there. I've got a bunch of other notes on sub locations and sub phases.

Kelly ended up joining us and we found out that we thought was a coding error was just a data or user error. Great dialog back and forth between Cory, Kelly, Wayne, Dustin, and I. It was a great session. Here are a few other things that I thought were interesting:

- Being consistent - across the board

- Forcing some clean-up and maintenance

- Talking about reports and proper data drill-downs - getting to the underlying data quickly and correctly

- Mixing different vendors and locations (report settings and filters). If they weren't just right, the reports would return different data (filter stuff).

- When Kelly joined, you could literally hear and feel the difference between a power user and a backend developer. Kelly, as s power user, had so much more depth of knowledge of what went where and how it got there (using existing tools). The developers could look at the data and the logic, but it didn't make as much sense because they had no context for that data. Interesting!

- We are trying to smooth things out. Some of that will be through new interfaces, training, and education.

- Some of the challenges of being so dynamic (as a software system or application). It is both a blessing and a curse (how flexible we are).

- What does it cost to keep clean data and how do we main that clean data?

- We would love to add some trouble shooting pages and/or known error reports or pages. Basically, a quick way to find and fix data that may have an issue. Flag it and then allow them to change it so that it is correct. This would be awesome if we could add this for our fracture project.

- Manual tests and audits of the data - Is it a code issue or a data issue?

- We talked about switching over our email servers and how that project is coming

- Talking about getting system-wide aggregates and how best to get that data in place. This is huge, we just haven't done it yet. We have all of the transactional data records, we just need to virtually let the cream rise to the top.

- Kelly and Cory are going to be coming up with some standard testing forms (what to test and different scenarios for testing)

- Cory had a small list of other projects that we checked in on and got small updates.

- John and Cory were going over end of the year payroll projects, once everybody else left

Good conversation between Steve, Sean, Cory, and Brandon. We were going over ideas for sales, eye candy, graphs, charts, and system-wide aggregates. Here are some of our notes:

- We would like to create a MVP - minimal viable plan (product, person, whatever) - focusing on the plan part of it for fracture (future adilas project).

- Brandon pitched the value add-on core model with 5 levels – 1. Internal core (transactions), 2. Industry specific skins and functionality, 3. Custom code, 4. BI – Business Intelligence (aggregates), and 5. Enterprise level (multi corps and multi worlds). Part of our upcomming plan is to work on level 4 - BI or business intelligence (eye candy, graphs, charts, stats, counts, totals, etc.). Make it look good and be quick and easy to get to. Bury the transactional core a couple levels deep, so it is still there, just feeding quick information off of the upper levels (aggregates) vs all of the transactional pieces and records.

- We really want to work on the look and feel of the cart - less is more on the display on the cart

- For graphs and charts, we could use cfchart (code tags) or JSCharts (javascript charts).

- The reports homepage could use some loving

- Surface stuff to help with demos and sales

- Capture the daily, location, and category levels – basically, per day, per location, and per category (on the P&L and BS). As a note, we already have this info... we just need to grab and hold it. Also, we could go backwards on this one... there is already something that exists. We could pull it all in going backwards. There is already a path and a pattern.

- ETL – extract, transform, and load – this is how you get the aggregates = Brandon would be happy to build in this aggregate table or whatever -Steve would like us to talk and work with Eric about the backend triggers and deeper database stuff.

- Lots of talk about database triggers vs smaller microservices - pros, cons, visible, not visible, who has permissions, and best practices.

- We need to remember the API sockets and other ways of getting data both in and out. This needs to be part of our process.

- We tend to get pulled off of a project due to custom code, customer requests, and budgets (time, money, resources).

During the server meeting, Cory and Wayne were reporting on different issues, problem, questions, and talking about changes to sub inventory. Wayne is working on some new changes to help speed things up there. Wayne was also volunteering to help Alan with some elements of time (flow) stuff for production processes.

One of the big topics was the email server. It's kinda old and has been acting up lately. It's turning into one of our top priorities.

We spent some time talking about servers and specs. We have certain pages, like the balance sheet, that cause heavy loads. We really want to get into some preset sums, counts, maxes, mins, and averages - basically, we need aggregated data. We have great transactional data, we just need to keep moving up the chain and create the aggregated data that is date specific. That will allow us to go both forwards and backwards. That is very important, to be able to easily go backwards as well. Making this change to aggregated data will be huge for us in the future. We really need this as part of our fracture project.

We have a project called the inventory snapshot - mini aggregate project that Eric was working on. Once he finishes with his gift card project, we are going to have him jump back on the inventory snapshot project to help with quick inventory quantities.

The last thing that we went over was between John and I. We are working on a smooth hand-off of the discount engine project. Coordinating times and making plans. That is coming along well.

Adobe ColdFusion Summit 2022 - Digital Conference - Las Vegas

See attached for my full notes from the conference. Here are a few of them (not all).

- The future of ColdFusion, from Adobe's eyes, is going to be about performance, scale, security, and productivity.

- Everything needs a metric

- Moving more and more things over to smaller microservices

- Making things multi-tenant (able to handle multiple corporations or businesses without displaying any of the other's data). We already do a ton of this... keep going and keep pushing it further. One of the key words that the presenter was using was "data isolation".

- SaaS models (software as a service) - low-friction and focusing on the service side of the approach

- Building relationships not just selling software

- Quick onboarding and time to value ratios

- Creating a layered model

- Building change into the model and into the plans - how quick can you move? Are you locking yourself into something?

- Beware of technical debt - older code - it has to be updated, maintained, and even removed at times (ok to get rid of things)

- See image (photo of a slide) for some take aways from Monolith to SaaS - Focus on SaaS building blocks first, make identity and isolation an early priority, support multiple tenants on day one, don't defer automated onboarding, instrument for metrics - even if you only start with a few, tenant-aware management and monitoring should not be an afterthought, exercise all the moving parts with each iteration, continually ask yourself if you are meeting your agility goals. Many of these are great ideas for our fracture project (upcoming adilas project).

- If you are using tokens - maybe think about JSON web tokens (JWT's).

- Educating the younger generation - creating a training pipeline - re-invent yourself/ourselves from an educational angle.

- Most good jokes have a setup and then punch line. The setup is the expectations and the punch line is the twist. If you set things up correctly, it allows you to pivot or twist if needed. Thought that was kinda fun.

- There are benefits of bad ideas... is it ok to bounce something off of the party based on that idea - sometimes you get more ideas building off of the bad ideas - they tend to be seeds for the next idea or thought.

- It's ok to throw things away - it's ok to go down the wrong path - being creative is not efficient.

- Sometimes you can flip things on its head (180 degree flip) - what would that look like?

- Having a great idea and then having an even better idea of not using the great idea. Treat it like a giant pyramid of ideas. The base has all of the ideas, as you go up, you need to get rid of things to get to the best ideas. If you don't throw anything away, you go from a pyramid (filtered) to a square tank with no priorities or set level of applicability.

- Who is the filter? What ideas pass the test? That makes a difference.

- Find a way to connect with people and bring joy - think of something like a comfort food - consistent - same thing every time - make it loveable

- Most software packages have a 10-year average lifespan - plan for that and plan for change to keep it going

- A full rewrite often ends up in a financial disaster. If you do decide to do a full rewrite, do it for a business model reason not for an emotional reason. Morph through evolution not full revolution (total change). See photos.

- Sometimes it is easier to write code than it is to read code - thus the tendency to want to rewrite things.

- Keep pushing out new things and use permissions and settings to show/hide and make the new features or tools conditional. Base everything off of the permissions and settings.

- Small changes to microservices. Little by little, make the new stuff.

- Use the same (older) database

- 1. Make a case for what you are doing or wanting to do. 2. Set a boundary for what you are going to do - be careful. 3. Next you need a plan or a strategy.

- Same habits, same mistakes! Alter the habits...

- Things are tending to lean towards machine learning and artificial intelligence (AI). Be aware of those major trends.

- The 7 mistakes that developers tend to make - See actual notes for more info - 1. Fear of failure, 2. Shiny object syndrome, 3. Overengineering, 4. Going viral (most things don't happen that way), 5. Building more features, 6. Building for yourself and other developers, and 7. Burning out. Tons more notes in the actual scans of my notes.

- It is common for us (as developers) to think that everyone wants a full features multi tool (swiss army knife) when in reality, our clients want a simple butter knife.

- We love to solve problems and we love to build and create things

- Don't be afraid of competition in the space that you are working in.

- Offloading and running things asynchronously. Does the action need to be done right this second? If not, queue it up, offload it, and run those processes asynchronously. If you are offloading, outside services don't need to know your app permissions, they just do tasks based on queues or data.

- The value of your team over time - that is huge

- Find patterns that work

- Capacity - keep watching the downstream services - keep things flowing

- Minimal on batches of data and more on just in time or real-time transactions - smaller bites with more accurate results.

- Orchestrating and chaining workflows - step functions - ideally with visual maps of the logic

Good conference. Both Bryan Dayton and I went to the conference. Bryan has his own notes, but these were some of mine. For all of my notes, see the media/content upload for my full notes. Overall, I'd say that we are going in a good direction. Always things to learn and improve on but making progress and going down the right road. Good stuff!

As part of the server meeting, Wayne was reporting on progress and status of his wife - health issues. We spent quite a bit of time looking over a number of requests that Cory had. I sent Wayne a zip file for all of the existing email stuff (code and assets). The email server is being more of a topic lately. We will need to do something there soon.

We also spent some time talking about the content server and the disk size of what we are storing for clients. It is getting quite large. We talked about the accumulative sized and storage costs over time. Looking into other options, costs, prices, and other servers to help handle the current and future content loads.

We got into database stuff and talking about sub inventory stuff. Tons of bulk tools are wanted and needed. Another topic that we got into was dealing with training and lack of training. This was dealing with existing features inside of adilas and/or different 3rd party plugins and libraries. This topic led us into talking about maintenance and doing the right thing. That's a constant battle. Another huge vote for maintenance and education. Two huge concepts that may end up being better than new features. Something to remember as we keep heading towards the fracture model and project (maintenance and training/education).

I joined late. Steve was already on and Sean had already been on and left. When I got on, Steve and I were chatting about the Bear 100 mile race and some thoughts and ideas. Steve had the idea to put some kind of stats or leader board dashboard on the public runner portal pages. A quick 10,000' overview. For example: (pretend that the letters are numbers and that it looks cool) x signed up, y did not start, z started. We then could show where everybody is at... x at this aid station, y at this aid station, this many finishers, etc. Basically, a quick dashboard type overview and add some eye candy (stats and counts). Show the tip of the iceberg and then let them drill down as they get the data.

This led us into a conversation about transitioning into graphical homepages with quick snapshots, quick numbers, counts, maxes, mins, averages, and other quick aggregate values. We would love to add this in for our fracture project or fracture concepts. Do this on every page. Alan did some small graphs on the main invoice homepage. We want this spread throughout the entire site. All of the key player groups - (customers, invoices, quotes, items, stock/units, elements of time, balance sheet items, deposits, expenses, PO's, vendors, users, etc.).

Steve and Cory were talking about looking up projects in bit bucket (code repository stuff). Being able to check on commits and branches. They were then talking about different industries and how they are financing some of their developments. Lots of games that people play and how do we fit into that mix. While Steve was still on with us, Cory was reporting in on some meetings that she had had with Kelly dealing with the adilas label builder and sub inventory attributes. Both of those subjects seem to be heating up a bit.

Our current goal is to focus and try to get some small victories (projects being done and across the finish line). Cory and I spent some time going over projects. We talked about the need to test everything. Even small stuff. We have had it bite us before. Next, Cory and I looked into a possible bug in some settings. We looked and looked and couldn't see anything quickly. We may have to jump in deeper, when we get a chance.

Shari O. popped in and had some questions about getting a new internal email server. Our current solution has been giving us some problems lately. We don't change any code on our side and it works great, all of the sudden it will be down, and without any changes on our side, it all of the sudden starts working again. Kinda crazy. Shari O. calls it the gremlins or email gremlins. As a side note, later in the meeting she popped back in to let us know that it was working again. Random.

Wayne joined the meeting and got Cory and I up to speed on a few things that he is trying to work on. Performance tweaks.

Cory and I then started going over her list of possible projects, quotes, and estimates.

- Need quotes for inputting sub attribute data all at one time upon PO creation (start with build page)
- Bulk update sub attributes interface
- Mapping of EOT (elements of time) data to sub attributes (settings for cultivation and manufacturing)

Along the way, we were talking about options and settings that relate to the concepts of the data assembly line, recipe/builds, showing subs in the packaging and production pages, and managing recipe/build output better. Lot of talk about bulk edit tools for sub inventory attributes, batches, phasing, sub locations, and moving subs along a known path or virtual assembly line.

Dealing with the data assembly line concepts, I was telling Cory how we setup both rules and assignments for smart group buttons (tiered pricing buttons). I was mentioning that we could use something similar to help setup and do the mapping between elements of time, sub phases, sub locations, sub groups, and monitoring the progress of certain things. We need the rules (what or how to do things) and the assignments (who or what to connect or monitor). Using the two pieces in combo (rules and assignments) we could then have the computer and/or system help us monitor progression and progress. They are good at that, they just need instructions and the who, what, when, how, and why and they can do those jobs over and over again.

As we keep rolling more and more towards the concept of fracture (future adilas project) I would really like to keep working on the data assembly line concepts and using rules and assignments to get the correct flow and mapping in place. I see that as important as we keep going forward.

Looking into server page stats with Wayne and Cory. Small bugs and tracking down sources. Wayne has released his new monitoring services on data 0. We were looking at page views and what not. The top page was the view cart page with over 22,000 views in just the first 5 days of launching the monitoring service. This is just on data 0, not even that busy of a server. Our servers get hammered, daily!

Cory had a number of questions for Wayne from emails and other projects that are circling around. We spent some time talking about memory issues on both the server-side and the client-side. This is kinda new, but we are starting to see more client-side memory issues. A normal page, the server handles all of the memory stuff. We can mostly control all of those pieces. On some of the new and fancy heavy JavaScript pages, it gets to be a big client-side load in order to keep all of that data quickly at hand (data loaded on the client-side in the browser). We will keep working with stuff, but may have to break things down into smaller and smaller pieces.

Some of our pages may need to be refactored. They are doing too much and/or requiring the browser to work too hard or store too much info. This may be something that we need to be aware of for our future fracture project. We have to balance both client-side and server-side memory management stuff. Just because we can use AJAX and JavaScript and cool data tables, that may not always be the answer. At some point, even those things fail. We need a good mix of both and make it as smooth as possible.

Meeting with Chuck and going over layout and display options for the "working with time" page (part of the elements of time section). That page has tons of dynamics and was built as a mini prototype for what we want fracture to do and be. Basically, the page uses templates and then either hides, shows, uses dynamic naming, aliases, incorporates settings, permissions, and even eventually sort order and display order. This "working with time" page was built in 2011 but has pieces that we want to do and use throughout the whole system once we move to the fracture level. Ask Brandon for more info on the subject.

Chuck and I were going over design options. We brought up the current page in a simple mode, a medium mode (settings and data), and then in an advanced mode (more settings, more data, and more dynamics). We were drawing pictures and running things through fake mock-up ideas. The page has to be able to handle all of the different possible combinations of settings, templates, defaults, subs of time, flex grid tie-ins, and other dynamics. Each section will end up being in a container of sorts to help with web ready responsive design (mobile friendly). Lots of talk about nav, standards, and where we are heading. The other major variable is how much data is tied to a single element of time. It is just a quick virtual post-it note, an appointment, a project, a timecard, a vacation booking, or clear down to a dispatch level event? Elements of time are very diverse. The amount of data could be huge or super small per element of time, based on the template and the settings and the amounts of sub info or subs attached to the main element of time.

At the end of the meeting (last 10 minutes) we flipped and talked about a small bug that was found and reported to Chuck and also his new promo video for the adilas label builder.

We all jumped on the server meeting. Wayne was showing me his new monitoring services (watching for form submissions and URL values for internal pages per user per server). We went over some of the custom stuff, encryption, and ended up doing a huge asynchronous database update using AJAX and JavaScript. The update did a series of loops and reported back as things were happening. We are switching our database table engine from MyISAM tables to Innodb tables inside of the MySQL database. That was kinda a big internal switch.

Wayne spent some time and showed me around and went through the code with me. I know that we can use some of those same asynchronous techniques to speed up some of our long running reports or processes. Pretty cool.

Wayne was pretty creative how he blended session values, ColdFusion, method calls, AJAX, JavaScript, database updates, and reporting all into one small page flow. It was cool to see the pieces and then watch them work in real time. I enjoyed it.

After that, Steve has some questions with his VPN connection (VPN = virtual private network). Wayne helped him uninstall and reinstall the VPN software. They got it working again. Steve uses his VPN to push up code via FTP to all of the servers. We use that all of the time. If we don't FTP the files, we have to redeploy and pull master code branches on the different servers. Sometimes, the FTP route is much faster, and we can target single servers if we have to do some live testing that relies on certain data or certain sets of settings (data and configuration stuff).

Wayne left and Steve and John started going over timeclocks and internal timecards. Steve gave John a number of new permissions to be able to look around inside of adilas to check and look at numbers. John then gave Steve and I a small walk-through demo on the discount engine. Steve and John spent a bit of time talking about graphs, charts, and adding in eye candy to the system. Currently, it doesn't have much eye cand or sweet visuals to help show the data that we are holding. If truth be known, we are holding tons and tons of super awesome data, it is just hidden and only shown in a tabular format right now. Also, the users have to ask for the data right now, there is nothing that is pushing the important things up to the surface (push technology or using dashboard type utilities). It could really do some cool things if we got the right charts, graphs, sums, counts, and other business intelligence (BI) stats and values. That's where we are heading.

Steve and John were talking about the future fracture project and how each page will end up getting its own page level settings. Things like: What to show? What to hide? What tabs or sub sections will be displayed and what interfaces will be the default per person? More talk about settings, dashboards, and making the data sing and talk vs just holding it all. We really want to get it out into the business intelligence (BI) level. That will be so cool!

Poor Bryan - he was having major internet issues. He and I got to chat at the beginning and at the end. Steve came on and we got to hear from Steve for a while (I'll share some notes below). Part way through, Bryan's internet connection was going in and out and the poor guy kept trying to connect and then got booted, time and time again. I was on the whole time, Steve most of the time (while he was on the meeting), and poor Bryan in and out the whole way through. Finally, Bryan sent me a text message and said that he would hook up with me later on. He was making a great effort but some of that was out of his direct control.

Anyways, here are some of my notes:

- Bryan and I spent some time looking over Chuck's first round mock-ups. I was drawing and showing Bryan what we were thinking about. We got kinda techy and talking about flow, processes, settings, and ideas from the mock-ups. Good session.

- Steve popped in and he and Bryan were talking about videos and marketing. Lots of good back and forth. Bryan's brother is the one pushing the videos. Steve would be very interested if he (Bryan's brother) wanted to work on a commission basis - he does the videos and then gets a kickback from sales.

- We have tried a bunch of different things. Trying to figure out where we get the best bang for our buck - ROI (return on investment).

- Small section talking about our sales and marketing teams and how they have to deal with a level of client rejection. If they get too much, it tips them over the edge, and they start doubting their skills and confidence. Pretty natural but very much a real thing.

 - The costs (huge costs) of training someone to be high-level power user in adilas. You almost have to take an adilas power-user and then go from there vs trying to get a non adilas user and get them trained up. The costs are too high, and the skillsets need some in the trenches experience. Interesting!

- Steve was talking about allowing people to invest in marketing and then try to get some ROI on those efforts. It's really hard for us to do it internally, based on funds and available personnel who could really do what needs to be done.

- YouTube and YouTube influencers - that seems to be a very modern trend that is getting some results. That also takes someone fulltime who is pushing on things, knows what they are doing (adilas power user), has a following (other people like them and what they do), and they keep creating new content (daily, weekly, monthly, etc.). You need a mix of all of those pieces.

- Adilas has been a frontrunner and forward-thinking company since the get go. We just haven't been able to capture the full market. We were doing software as a service before SaaS became a buzzword. We were doing cloud, web-based software, paperless office type functions way before they were cool. Tons of other frontrunner type approaches. We have been pioneers and out on those front lines. We've been doing this for the past 20+ years. We started wtih modem speed internet connections and Microsoft Access Databases. We've come a long way. So, how do we market that? That seems to be the question of the day.

- Bryan was trying to reconnect to the meeting and Steve and I were just talking. I mentioned that Heather (my wife) said that we are too broad and trying to help too many people or do too many things. In the very next breath, I mentioned to Steve that I had a phone call with one of our clients (Drew at the bike shuttle and coffee shop) and they wanted all of these other things. Some of which were standard and some of which were custom. Steve was saying that we are caught somewhere in between those two realms. Some want it to be simplified and others want even more with choices, settings, permissions, and pick and choose functionality. It gets crazy deep.

- Seems like people want everything under one roof and they want it for free. That's a tough ticket (super powerful, low cost or free, looks great, and is easy to use). Sounds great! Sign me up! How do we get there?

- Just thinking about possible funding options - What if we were free (the whole adilas transactional core) and just charged a small cover fee? Credit card do it... everybody wants to use a credit card processor because it helps them make sales and run their business. We would also do something along the lines of the value add-on core model where we provide the main adilas core (full adilas account that takes care of all of the transactional data - what it is right now). We then could charge for any of the additional layers. We could even charge for the core and then add-on fees or charges for the higher levels. All kinds of options. Just as a quick review - Levels are: 1. Transactional core, 2. Industry specific skin/functions, 3. Custom code, 4. Business Intelligence (BI) (sums, counts, aggregates, stats), and level 5. Enterprise level (multiple corps in array and interconnected with roll-ups, roll-downs, controls, and full control over the flow of data.

- We can also sell other professional services, training, consulting, analytics, custom code development, design, marketing, hardware/software integration, etc. We are not limited as to possible avenues where we could monetize our efforts. Currently, our monthly application fees are our bread and butter (SaaS type levels of a monthly subscription or usage license). We could sell digital real estate (web hosting, database serves, mirrors, shared hosting servers, semi-dedicated servers, fully dedicated servers, and other special server configurations). We can sell storage (active and archived or cold storage - for data). We could flip our model so that is fully based off of usage, throughput, bandwidth, storage, counts, amounts, and transactions. Tons of options.

- We sure are gaining a lot of feedback and insights on what we can do with fracture (future adilas project). This is where we are headed. We just aren't sure how to fund that. We have an awesome testbed; we've done tons of little prototypes (they are working and in production), have tons of feedback from our users and other outside critics, we've been making plans, we have learned tons of lessons dealing with settings, permissions, interfaces, transactional data vs aggregate data, speed, servers, configuration options, look and feel, solving pain points, and bringing all of these pieces together. So.... what is our plan and what can we do to bring these pieces more fully to market? Where do we go from here?

- Switched gears and started talking about using some other video conferencing software packages. We've been using GoToMeeting but have been having some issues. Steve and I briefly talked about Google Meet, Discord, Zoom, or whatever. Just looking at options.

- Steve left and Bryan was able to rejoin for a few minutes. I told Bryan that Steve was very thankful and grateful that he, Bryan, is adding his timecards and time clocks to the adilas system. That is very helpful.

Long meeting between Steve, Cory, and I. Cory was reporting on tons of different projects and getting our input and suggestions. We covered tons of different topics. Here are some of my notes (from 10 pages of post-it notes - didn't know it/we would cover so much). The original meeting was only setup for an hour. It went a wee bit over... :)

- Talking about tons of custom label options. More talks about what to do with Calvin's custom label builder. We've spent a lot of money there and want to really get a return on that investment.

- We talked about bringing projects more internally with our guys and breaking things into smaller and smaller pieces.

- On labels, we had a request to be able to do serialized labels (up or modify counts and counters based on batches or packages).

- Using tons of our existing tools and refining those pieces. We have a ton of tools in the shed (virtually).

- Lots and lots of talks about breaking up the bigger projects into multiple smaller pieces. Along with that, we need to be able to charge money for bigger estimates. Everything takes time and effort. Either that or be able to recoup the amount within the bid or estimate.

- If we are doing real custom work, we need to charge for that. Often, we end up taking a hit.

- The trend seems to be (globally) transactions and details going into aggregates and summaries. We have had so many 3rd party analytical companies wanting to use our API sockets to harvest and use our great data sets. We would like to do a bunch of that analytical work inhouse vs farming it out to a 3rd party. All of these 3rd parties are just working for individual companies, but you can see the trend happening. Our clients are really wanting to get to the business intelligence level (BI) for viewing their data, snapshots, counts, summaries, and other aggregated data or stats.

- We went over some pros and cons of using the adilas API sockets. Back and forth on monetizing those channels and also making sure that they don't get abused or flooded.

- Lots of talks about the item catalog and the image catalog. As we use more and more API sockets, we could really use bigger and bigger bulk tools to help with data standardization and speed of deployment. Lots of positives. We, as a company, could also sell more systems if we brought in the enterprise level (way up - cascading info down to lower systems). Good stuff.

- More bulk standard tools. This just adds to the votes for building out the value add-on core model with different levels. Just as a recap - the value add-on core model deals with 5 known levels. They are: 1. Transaction core (current adilas system), 2. Industry specific skin, tools, and features. 3. Any custom code on top of the main system. 4. BI - Business Intelligence levels (stats, sums, counts, averages, mins, maxes, aggregates), and 5. Enterprise levels - connecting multiple worlds in a hierarchical type system (roll ups, roll downs, transaction corps/worlds, aggregates and sum corps/worlds - also dealing with permissions and access). We really want this type of a system for our future fracture project. We already have a number of pieces to this project (all kinds of prototypes spread all around the system), it just isn't all put together. That would be so awesome, clean, powerful, and hopefully pretty!

- We spent some time talking about our clients. Sometimes they get pretty creative. That is both good and bad. If they get creative, and find errors or break things, we just fix them and keep going. Other times, they totally use certain tools in ways we never would have imagined and/or foreseen. That can get interesting.

- There have been some requests for bulk tools for updating sub attributes and bulk sub inventory tools.

- Cory kept asking - Who are we? We tend to build generally but then we have all of these industry specific demands that keep coming at us. It makes it really hard to know where to focus. We really need to decide who we are and then hopefully that or those choices will help guide us.

- Dealing with Metrc (state compliance systems), we've had the request to build out more individual user type functions. This is dealing with more employee/user type permissions and settings. Currently, most of our Metrc transactions are done on a corporation or world level. The new requests are to do the exact same things but break it down on a per person basis. That sounds awesome, but that could be hundreds of thousands of dollars in development. We would have to create the one-to-many relationship, make sure that they were valid, then sync up users and permissions between systems in order to play. Then, to further make it kinda crazy, you would have to check user permissions (remotely) then attempt the connection, then if it failed, figure out if there was a global (higher up) option that you could do so that it wouldn't break all of our code and processes. It could be a huge project. Lots of unknowns. As part of this project, we would also have to add more history tables, who did what, who changed what, who has permission to do what, and making sure that each individual keeps their keys and tokens updated. It sounds like a small nightmare.

- We seem to build in general and then use it specifically as needed. Custom code on top of our own standard package, tool, or feature.

- Going over the cost of building and building. One you have to build it, then you have to maintain it, and upgrade and support it. The costs keep increasing. This topic lead us back to questions about who are we and where should we be focusing?

- There is a growing need to use asynchronous type loading like AJAX or some way of breaking huge datasets into smaller pieces. It is totally common for us to need to show or export 10,000+ or even 100,000+ records at a time. The current process tries to take that whole thing as a single bite or single attempt. It's just too large and slows things down.

- Some time was spent talking about loyalty points and keeping track of the total liability. More talk about other reports that show sums, grouped values, look-back capable reports, and using ACV (actual cash value) for recording loyalty points. We do a bunch of that, just refining the process and making it even smoother.

- Need for messaging or using the message marketing features that we have already built. There is a growing need for push notification and two-way communications outside of the main app or website. The client portal is growing in needs and options. More mobile ready or full mobile pieces are going to be coming down the pipeline. Everything seems to be trending in that direction.

- Question - do we fill in the gaps on functionality or try to update the look and feel? It sure would be awesome if we could virtually turn things on/off based on the UI (user interface) and settings. We would love to set things up super simply and then let the users add on or take away from our smaller base level. A new mini version of the shopping cart is in great need of these fracture type level settings. Start small and simple and then let the users build on or configure things as needed. Hide anything that we can unless asked for. Then when it is done (using the tool or feature), it can be hidden again. Every page needs show/hide options on a per page or per section level. Totally customized.

- Along with the show/hide options talked about above, it would be so cool to show all of the options and then say - what do you want? You tell us. More fracture stuff (where we are headed). Mountains and iceberg analogy stuff (it still needs to be there, but what is shown and/or exposed).

- We talked about extra costs and prices for some of the other add-on tools and functions. Some of our stuff (tools and features) takes a major amount of work and effort. We would love to sell more training, consulting, automation, and other professional services.

- News and updates and the importance of keeping our users up to date and informed. This seems to be a constant need and keeps evolving. Content and making and creating new content (creation and maintenance).

- Lots of talks about prioritizing efforts for different persons (parties). Diving out responsibilities and sharing info across departments and across people (users).

- Using videos - the value of education and training. Selling our other services. Scheduling and setting up ongoing training efforts. We would love to make lots of polished smaller videos. Laying it all out for our clients (on demand education or just in time education). We could really use our website to toot our stuff for different business verticals. For example: Revamping our manufacturing site and pages. We can handle... (fill in the blank) for manufacturing or whatever. That is a deep pool (manufacturing and production type businesses). The trend seems to be leading us more in that direction.

Chuck is currently working on the add/edit elements of time page. It is pretty big and pretty dynamic with lots of possible combos and show/hide scenarios based on time template settings. He is doing a snow owl (theme) facelift on the page. We also talked about a number of other fun topics.

- Chuck recommended, for fracture, what about preset color pallets vs full custom colors. We may need both options (presets and build your own custom look and feel color pallets). See a screenshot for a picture to see what WordPress does for preset color pallets. Trying to get ideas.

- As a side note, we currently are revamping things to show different visual displays for the snow owl and classic themes. Lots and lots of extra code and it may eventually effect load and run times. On average, Chuck was saying that we end up with almost triple the amount of code, going from an older original file (just classic) to showing both classic and snow owl theme options. That also translates to more code to maintain and keep updated. Lots of moving parts. When we do the fracture project, we want to make it standalone product. Basically, the old code will support classic and snow owl themes but fracture will only support the new fracture options. Simplify the code that needs to be maintained.

- We talked about using more content and page loaders - using asynchronous loading and asynchronous processes. We also talked about big reports and either using in-line asynchronous loading or doing some kind of build report to file type process. Especially for big or huge files (over 500+ records at a time - say 1,000, 10,000, or up into the 100,000+ records - we have some reports that could output millions of records). If we do a asynchronous process or build to file, we will also need notifiers, emails, text messages, or some other type of push/pull type communication. This may be a nice feature for fracture and future development.

- Going along with the huge reports and data tables, mentioned above - for fracture, we may want to build in the BI (business intelligence) levels and have sums, averages, counts, and other aggregate values right from the start. Sometimes we have users pull 10,000+ records, just to get counts and totals. Let's help that data (the BI level) rise to the top and be available so that we don't have to output and show all 10,000+ records. They may only want the aggregate values anyway. If they want more info, we could allow stepped drill-downs by month, week, day, items, categories, or some other grouping. That will help the record counts be much smaller unless they really want to see all of that data. Once again, we could do the asynchronous or build report to file type process for super huge reports.

- As long as we are talking counts, sums, averages, maxes, mins, and other aggregates for fracture - we really need to think about adding in visual homepages or graphical homepages with dashboards and other quick data references. The details are great, but that is only one of many possible views. We could use calendar views, timeslots views, horizontal grids, vertical grids, grouped reports, details, and other fun dashboard type interfaces. This could include charts, graphs, quick counts, trends, etc. Once again, at the BI level (business intelligence) on showing the data. Allow for drill-downs, filtering, exporting, saving reports, or refining a search if something different is needed. Quick access to the data.

- Push and pull communications - push notification is we (the system) pushed the notification out to the user or group of users (text, email, phone call, browser message or prompt). Pull notification is, you, as a user, requests or pulls certain types of information. Currently, our most common form of communication is pull notifications. When building out fracture, we would really like to be able to define more options for push and pull notification and communication channels.

- We circled back around and were talking about survey's, market research, and asking for feedback before we build the fracture project. As a side note, there really needs to be a plan and then help everybody build towards that plan.

- As part of the plan for fracture, we really want to build out a style guide and get the primary elements in place before anybody else builds the other pieces of the plan. We want it to be consistent, all the way through the build and deployment process. Everybody who then works on the fracture project would be expected to follow suite and follow those plans, guidelines, and style guides.

- Chuck and I talked about checking out competitors and their pricing and then building some marketing based on that research. As we were looking around, some of the other products out there have a smaller starting price but then you have to add on tons of modules or multiple by locations and by seats (active users). We want to pitch the whole thing as a package and then make it so configurable that it could appear small, medium, large, or extra-large. It's all done by settings, permissions, and configurations. Anyways, we really could use some more market information and data before building out fracture.

- Eventually, the fracture part of adilas will need to be its own mini app (fully mobile ready). We may have to scale things back, down, or allow custom configuration options. A full on adilas mini app would be super cool.

- One of our last topics for the day was dealing with costs. We will provide different levels and/or packages that all work and blend together (integrated solutions). If something else if wanted, it will cost and be built out as custom. We love custom and it's part of model. We need to keep that in mind for fracture. With custom, also needs to come cost. Just for fun, Chuck was saying... "I could hand out gold bars on the corner and still get complaints. If they want us to round it out, stamp it, or trim it to make it lighter - we get to keep the gold dust or shavings". We were just being silly but... it's real - custom needs to cost accordingly. That's important. I think that we are getting better at that and really trying to pass on costs and other services to our clients. It has been a learning process. We need our business to make enough money to keep it going. We offer some really great stuff. Our prices need to reflect that.

Great little discussion on fracture (future project - redoing the adilas interfaces and system). I had a bunch of post-it notes with notes on it after the meeting. Chuck really has some good ideas and is forming a vision of what he would like to see the fracture project become. He is great asset. I'm excited to see where it goes!

Good meeting - Going over the advanced time search page. Chuck is reworking that page. It is a huge form and has multiple smaller search forms all on one page. He is rearranging them into vertical tabs to show each one separately. That will really help. Here are some of my other notes.

- Chuck would really like to use drop-downs or predictive text drop-down selectors vs open text entry fields.

- Elements of time - very powerful but almost overkill - sooooo much data and sooooo many settings. How can we narrow that down? We talked about a couple of different analogies - cover the walls (imagine all the plumbing and wiring being shown vs a nice looking wall that is pained and has pictures on it), a hood covering the car's engine (style on top and complex and even dangerous below the surface), icebergs vs mountains (how much are you seeing at a time).

- Being able to pull data as needed using things like AJAX (asynchronous data being pulled in just in time, based on user inputs and requests).

- Sort of big and confusing - what does this do? How about that? How can we educate our users without making it look complicated?

- Make the whole thing (elements of time) more consumable - plans for fracture - break it down - Ask our clients and users, how do you use it? Offer preset settings or feature packages - such as: basic calendar, appointments, rentals, bookings, project time tracking, etc. Keep it small and tiny and lead the users along to get it setup correctly and not be intimidated by the number of options.

- Simple interfaces that are to the point and optimized for smart phones, mobile, and responsive layouts.

- Do some market research on how people use it and what they want.

- More dynamics and allow for the users (or preset settings) to change the naming and make it more dynamic. This would be from the top down - what do you call it? What does it do? What is shown, hidden, defaults, etc.? Allow for dynamic naming, layout configuration, and flow of data. At the highest level, almost the data assembly line type concept. If the preset options don't do enough, allow for a build your own layout system (super configurable).

- I mentioned to Chuck that we had some other plans for time templates and dynamic settings that we want to build into the next level (fracture project). See elements of time # 8004 for more details.

- Timing and budgets - sadly, it may take months and years to get all of this done. We have lots of changes that we would like to do. All in good time. Keep floating, watching timelines, budgets, and available funding. We'll get there.

- For fracture, we talked about some sort of education mode. This could be small popup walk through guides, wizards, tutorial helps, or whatever. Along with this, if we show little popup helpers, keep track of what has been viewed and what had not yet been reviewed. Be able to reset if needed.

- Chuck and I also talked about date pickers and time pickers. We looked at a few samples. Ideally, with the new UI/UX changes, we will be able to add both date pickers and time pickers to all pages that need that type of user input fields or selectors.

- The value of a team. We don't have anybody who can do everything to the fullest level. Plus, that would take way too long. That's where the team comes in. We've got backend guys, frontend guys, designers, database guys, coders/developers, project managers, dreamers, admin, and managers. Good stuff! Keep going in that direction.

Special client meeting on Cory's Zoom account. The goal was to cover and go over internal ways of monitoring and tracking quality control issues for a client. The user wasn't super familiar with adilas, but wanted a full-on system that could hold and track all of his pieces and processes. He works for a company that uses adilas but didn't know much about the existing tools. The underlying goal was a deep level of tracking for quality control within his processes. He's in the food and food production industry.

From what I was hearing, it sounded like a number of possible sub location or sub phases type stuff (data assembly line concepts). The need seems to be the ability to setup and manipulate the environment, setup standard and custom data points, and control the flow (start/stop/controls) of the processes. For our upcoming fracture project, I would really love to build in user controls that help people setup the sub systems, sub locations, sub phases, sub categories, and sub flow of data (forms, steps, or processes). The other important part of the data assembly line concept is the ability for the users (companies) to change, add, edit, remove, delete, and make their own processes more efficient. The concepts of the data assembly line have been on my mind quite a bit lately.

Kelly joined and was basically running most of the conversation. She just jumps in and sort of takes over. Some people really like that. She was talking about blending time, scheduling, inventory tracking, histories, and permissions. She really has a talent with consulting, talking, pitching ideas, show vision, and helping to make the sale or up-sale. Very interesting to watch and learn.

I also liked how she explained ERP (enterprise resource planning software). She said - "we track both money and goods, thus making it a light ERP system." I thought that was a good and simple definition. She also said, after the meeting, "The goal is moving the client from a problem based approach to a solution based approach. Get them excited about the possibilities." I enjoyed watching her work with the client. Kinda fun.

Morning meeting. Steve, Sean, and Shari O. were on and going other things. Quite a bit of talk about the internal email system and likes and dislikes. We are currently using an add on service from Newtek that we setup 12-15 years ago. We may need to look into beefing up that system and making it more a big part of our services. It works for me, but some of the folks are having issues with delays or not getting the emails.

Next, they switched over to sales, people, new recruits, and permissions. Steve is building a new way to capture hours and time spent on projects for the guys and gals. He is using and harnessing sub dates and times, as part of the bigger elements of time pieces.

Eventually, it was just Steve and I on the meeting. Steve and I were talking about the client portal and how that is heating up. The client portal is basically a mix of ecommerce, customer/client login, special features, message marketing, scheduling, online bill pay, submitting documents, uploading content, a message center and other things. We already have a bunch of this built, but we can also feel the water heating up there. This will be very important as we keep moving into fracture. The whole client side of the application will be huge. We'll use settings to show/hide and expose certain pieces. Then, our clients (the users and their companies) will be able to use the client portal to expose certain pieces of their business to their customers and clients. That piece is very important. Anyways, that whole piece and concept is really starting to heat up.

Lastly, Steve and I were touching base and talking about options for reselling merchant processing and being able to gain revenue from passive sources such as merchant fees and merchant processing. Basically, a client signs up with merchant processing for their business, then we help hook them up through adilas, because they are using adilas to run their business, we get a small kickback from the ongoing reoccurring revenue stream from the merchant processing fees. It's small, but we are hoping to get in there and let it add up over time. Anyways, we are looking in to being a reseller of some of those services. Good stuff! 

Talking with Steve about limited flex grid, status, and where things are headed. He is excited to expose some of the new tools that we are developing out to the rest of our clients. We are also trying to stay ahead of Chuck and what pages he is redoing and making them look better. That lead us into some discussions on layout and display options such as tabs, accordions, pop-ups, modals, and other modern display and layout styles.

Everything keeps going back to settings. We talked about 4 different level of settings, that we are seeing. They are: 1. Corporation level settings (corp level or world level), 2. Group or player group level settings (12 main players), 3. Page level settings, and 4. User level settings. As a side note, settings are awesome, but they can also make things feel like it is more complicated. You have to play the game of iceberg vs huge mountain. Hide what you can, only show what is needed, but still make it available if needed (like tools in the shed). We see more and more of this type of thing coming as we build out toward fracture and future development.

Another fun thing that we talked about was page views. We happened to be on the time homepage and going over different page views of the same data, but how cool would it be if we could build out reports that show up in calendar view, timeslot view, grouped or aggregated views, or normal details and tabular data type formats. So many options, including charts, graphs, and other layout options. Not to mention, export or save custom report settings. All available, we just need to keep bringing it all together. More stuff for fracture.

The next subject was dealing with getters and setters and how those pieces are so dynamic. Some of our entries have 30-40 fields or choices. We don't want to have to submit all of those pieces, every time, for a simple update. Getters help you get the data in smaller pieces, as needed. Setters help you set or update the data in small bitesize pieces. For example, say you have 30 records of flex grid, each with a possible 40 columns. If you do the math, that one bulk edit page could have over 1,000 fields. What if only 2 pieces of data actually change? Using a simple setter allows you to only alter smaller pieces of the whole without having to carry the whole load. Efficiency!

As we were talking, we can see the value of using small teams to push on projects together. That could really help with resources and giving everybody a buddy to work with. Along those lines, here are some other projects that we may give to Bryan or a small team of developers. Flex attributes for all of the main players (used to be called in-line database extensions), vendor/payee logs (modeled after the customer log section but for vendor/payees), and other projects that already have a small handrail or guide. Anything that has been done before seems to be easier, due to the example or handrail for the developer to follow.

Budget meeting with the admin crew. Steve wasn't able to make it, but Cory, Shari O. and I were there. We talked about the need for ice-down dates (per section) and how cool that would be. The ice down dates are part of our wish list for fracture (or whenever we can). It has been a goal and dream since 2008/2009 ish. Sometimes things take awhile to get back around to.

We went over budgets and did some calculations and look-ups to get actual values. We spent quite a bit of time talking about next projects for some of the guys. We also did a session dealing with naming conventions for expense types and how we want to classify thing on the P&L. This is mostly dealing with guaranteed payments and tracking how we are paying owners.

Part of the conversation went into some wish list items for Shari O. and ways that we could help her in accounts receivable (A/R's) and chasing down monies and payments. Brandon has both nots and spreadsheet documents from the meeting.

After the meeting was over, John jumped on and had some questions about timecards and timeclocks. We went over ideas, expectations, and where we are headed.

As part of our meeting, I was explaining to Chuck about our invoice due date project. He had a ton of good ideas and we talked about options to combine the invoice due date with automated reminder emails and what not. Great ideas. This is just for fun, but he said that he used a different product and it had automated reminders. He got more responses from the "nag" (automated emails) than he did by asking for money. As we were talking and joking around, he said, we should rename our automated email stuff "The Nagatha" (one-off from the nag). Just being silly.

Once we got back to normal work, we spent some time looking over the flex grid stuff. He is working on the add/edit flex grid tie-in page (rework and page facelift). We also spent some time talking about different questions, ideas, and styles. Those conversations included topics and discussions dealing with taking heat on making changes and adding a more modern look and feel (getting in trouble for making things look better). We have a lot of users who don't like change and we are constantly rolling out new changes, tweaks, and refinements. That's how we roll.

We spent some time talking about things that need to go in the adilas docs (internal snippets and style guide). We also went over some testing and talking about adding in tons of client-side validation (JavaScript) for fracture. We also talked about the value of doing small prototypes and how much we can learn by doing those little mini apps. As a side note, Chuck is really excited about fracture (future project in adilas) and has a number of great ideas and vision. Almost every time we talk, I hear him throw out a ping or a reference for planning and building out fracture. We'll get to it... it just takes time and resources, but the vision and dream are out there. Let's go get it!

Wayne, John, Bryan, Cory, and I were on the server meeting. We went over a number of projects throughout the meeting. We need to spin up a couple more boxes and the guys were working on a quote and a time estimate for one of our clients. This was really cool, but Cory asked Wayne what it would take to get this project done. Wayne flipped it on its head and was talking about working the whole thing backwards. Basically, you start with what they want (that wasn't super clear) and then you figure out what things you will need to do to get there. Wayne's approach quickly started to focus on what was wanted vs what could we do (the sky is the limit). I've known that and even used it, but it was fun to see it play out in the meeting. I really enjoyed it.

We went over options and questions that we could take back to the client. Are they looking for access to raw data, summarized data, a webpage or web-based report, a spreadsheet, or even open API socket access points? That makes a huge difference as to where you go and what you do. We also talked about certain projects and possible code that has already been written for other clients and how we could tweak that if needed. Wayne was recommending that we get with the client, open up a blank spreadsheet and see what data they were looking for (basically doing some consulting - instead of just quoting something). I took it as a form of listening and even helping to educate our clients. That method or process, of talking with our clients, will actually help our clients be even more happy and really get what they want.

We have so many possible options, sometimes it takes some time to figure out what is really wanted and/or needed. There is a big difference between value and cost. We were talking about that. Ideally, we focus more on the value vs the costs. As we were talking about this, I was thinking about some of the ideas of the value add-on core model that we have been dreaming up for fracture. Here is a rough recap that I grabbed from an older element of time.

The concept of the value add-on core model - with different rings to denote the other levels of add-on value pieces. We have determined at least 5 levels as of right now. Starting from the middle. 1. Core (adilas core - everything that exists right now - image the), 2. Business vertical or industry specific, 3. Custom level, 4. BI or Business Intelligence level, and 5. Enterprise or multiple corp(s) level. Each of those value rings has to be purchased and serviced. You have to have the transactional data core to get it started, but anything beyond that, is extra or a value add-on piece. Very configurable.

Eventually, everyone will want some of the (BI) Business Intelligence stuff. This will take the underlying transactional data and will help to summarize it, aggregate it, count it, condense it, and display it in a way that is easy to digest and fun to look at (aka eye candy but also eye candy with a purpose). I'm really excited to get to that part of the project. I want to make sure, when we build out the fracture project, that we include this Business Intelligence (BI) level into the main application.

As far as history, when we started, we didn't have clear picture of where we were going. The further we go along the path, you can see how the other pieces play into the mix. I'm excited to keep working on them prior to getting to fracture, but I really want to make sure we include them in the next round. In a way, it's like what Wayne was saying, work the project backwards - what do you want, then make sure that it fits and fills those needs. Make the plan.

Cory and I going over a list of questions. About halfway through, Steve and Chuck joined us. I think that they were going to meet and work on some look and feel, but Cory and I were on the meeting. Anyways, the question got brought up about doing down payments on stock/units and how to book that and keep everything straight. The real answer is using transitional invoices. Having said that, we went round and round talking about possible options. Towards the end, Chuck was saying that when we redo our fracture stuff, we may need to make it part of the system that a prepaid invoice, deposit on merchandise, in-store credit, and other things be put in place and education and training made available.

For the record, here is how you would do it right now... using a transitional invoice.

1. Stock in the item, even if you don't have it in stock. If it is in stock, use that item. Anything that is unknown, just make a note of that. For example: a serial number or VIN number - maybe use the customer's phone number or email address.
2. Go to the stock/unit and go through the invoice/sale process. Make sure and set it to a transitional invoice (that wording is dynamic - layaway, prepaid, etc.).
3. Do the sale for the full amount and then take the amount that is either pre-paid or deposited. That will start the journey of the stock/unit and the payments received. All of these transactions will auto flow over to the balance sheet (already built-in) if using a transitional invoice.
4. Keep the invoice in the transitional state until it comes in, gets delivered, or whatever. If needed, additional payments (deposits on merchandise) may be made along the journey.
5. When ready, flip the transition invoice over to a real customer invoice and finish out the rest of the info. Once flipped, it will show up for sales taxes, on the P&L, accounts receivable (if money is still owed), and will count against inventory values. Prior to that, the whole thing is held on the balance sheet as the work in progress, pre-paid invoice, layaway, deposit on merchandise, etc. (dynamic naming).

Anyways, the takeaway is for fracture, we really want to have a way to show our people how to do certain tasks (searchable education mode). We also want to have some of the special account stuff like in-store credit, vendor credits, gift certificates, coupons, punch cards, etc. all done and part of the system. Those features may be built-in prior but need to be there. As a note, a lot of those will be sub sections of what we call special accounts, just like the current loyalty points stuff.

Meeting with Chuck and going over the mini calendar pages. I had to bail out to go pick-up my daughter. We got back together after I got home and pushed up the mini calendar. We did some testing. Actual times were 10:00 to 10:15 and then 10:45 to 11:15 am - total of 45 minutes - with the break in between.

On a different note, I'm excited to see where Chuck goes with some of his other designs and web components that he is working on. He is working on a possible web component to make a custom date picker, that we could use, even for other projects like fracture. Ideally, the more we create our own little custom web components, the better. Less outside libraries and dependencies. We'll figure out a good mix. Good stuff.

Sean and I looking into the older code from the Leafly integration (back in 2019) done by Will Hudson. We were somewhat going through some of the pieces and virtually reverse engineering what we saw (looking at existing code and trying to figure it out). Basically, what was built by Will and what did it do?

John showed me some stuff on his discount engine. We were looking into a CSS (display) issue. We decided to wait for Chuck who would be popping in on the next meeting.

Just recording an idea, but what if we had Bryan help us out with some training and education stuff. We are really lacking there. Bryan could build it and then we could have Chuck make it look nice. Basically, Bryan could help with content and Chuck could help with presentation. There is a huge need for training, flow, processes, SOP's, etc. Also, just another idea... What if we put Bryan on a project to see if we could write a grant for building out fracture and where we would like to take it (huge future project in adilas and revamping the whole system). That might have some merit. We could really use some major funding to push that whole project forward. I know that Bryan has written other articles and/or research papers. Just a thought.

If needed, we could use the adilas developer's notebook to do more research on the whole fracture project. Lots of notes and ideas have been posted and pushed up to the developer's notebook over time. A great resource. A lot of it ties in with the adilas cafe and community that we are trying to build. We also have tons of R&D (research and development) on new UI/UX stuff from Jonathan Wells. Lots of great little ideas and such. Good starting point.

Steve and Sean were talking about ecommerce and what is needed to keep systems going. Lots of moving pieces. After that, it switched over to a sales meeting. Steve was asking questions about some dealerships and recent contacts that Sean and Marisa were making. We talked about how much custom code is needed per client or per industry vertical.

We got into a conversation about the client facing scheduler and how cool it will be, but also how much code it will take to make it fully functional. The subject then flipped over to automation, wizards, settings, training, and education needs. As things get more complex, there needs to be ways of letting people know what is needed and what needs to be done. If the education is not there, it actually makes it even harder to figure it out. We talked more about ways of helping to speed up the training and onboarding processes. We need a way for our client to figure things out and/or be educated on what is possible and what is needed. Steve was mentioning that we need a balance between sales and new development.

As a side note, in some of our design prototypes for the fracture project, we were working on a better UI/UX as well as a thing called education mode (toggle on/off for extra help and information). The goal was to make it available but hidden. If it was needed, it was there. If it wasn't needed, it was hidden but still avaiable. Also, a good UI/UX will help eliminate some of the education stuff (not all of it).

The final topic of the morning meeting was dealing with advertising and pushing that forward. We also talked about having the best team we have ever had. Good stuff!

Chuck and I were talking about using setup wizards and easy setup steps to virtually walk people through complex or involved processes. We covered a bunch of different topics today. One of them was MVC or model view controllers and how splitting things into different levels allows for more modular code. The thing that changes the most is the view model (display). The other pieces tend to stay fairly similar without huge changes between versions. Chuck would like me to speak with his wife about some of those different levels and some tips and tricks on keeping them separate. She worked with a client that does government work and they were setup with really good deafferentation between data layers, business logic layers, and view or display layers. She is also familiar with a number of different frameworks and possible options there.

As we were talking, Chuck said that one of his goals is going to be working on layouts, use of whitespace, and number of clicks to get something done and finished. Those sounded like good goals to look into and work on for adilas projects. Next, we chatted about navigation, layouts, and the concept of an artist with a pallet and being able to change the layout and control your space (work environment). Sometimes the word space is too deep for people to grasp. They think of stars and constellations. We are currently talking more about personal space and configuring your own environment or working space (homepages, nav options, preferences, dashboards, etc.). Chuck would love to help develop some really cool dashboards and such. That would be awesome.

More talk about wizards and easy bulk setup options. We would love to configure some almost hands-free setup options. Think of what a cost saving this would be. Basically, if we could make the setup easier, we could eliminate some large costs and time savings by letting the users set it up themselves. That is still a long way out, but a great goal. Along those lines, we were talking about how both settings and permissions really need to dictate displays, options, and work spaces. If we did it well enough, we could even offer a free trial or something along those lines. Right now, it takes too much to setup it all up and get someone trained. We can't do it for free because it takes someone who know the system to setup it up, configure it, and get the people trained on it.

If we could get things done in bulk or through simple handholding wizards, that would really help the process. Those handrails or wizards turn mountains into smaller icebergs (perception of what is there to take in or acknowledge). We talked about some possible mini apps or standalone modules for the current adilas platform. Timeclocks, timecards, uers, payroll, expense tracking, point of sale, CRM (customer relationship management), ecommerce, etc. All of the main 12 business functions. Fun little meeting and some good ideas. We would like to include and even start working on the fracture project with some of these ideas. That is and has been a big goal and driving force for what we are doing. What is the next step and how can we get there?

I woke up this morning dreaming about adilas and what value it brings to the table. I went downstairs to record a couple of thoughts and ended up staying down there for a quite a bit of time, just recording ideas as they came to me. I then took a small notepad of post-it notes upstairs and kept coming up with different ideas. These could be expanded upon, it was just a quick, record what thoughts are coming to your mind, type of thing. I had all of these little one-liners written on about 9 pages of post-it notes. Kinda funny.

- 20 years of experience

- 250 customers

- Working model

- Trained team

- Data like crazy - tons of it

- Usage patterns

- Able to handle multi-industries (business verticals)

- People use it - daily

- Success stories from some of our clients

- Database model and database schema (what rows, columns, tables, indexes, data types, records, values, etc.)

- Code repository (huge code base)

- 10 full versions with back-ups of each version (over time)

- Documentation (things written, recorded, and organized)

- Commercial product

- Developer's notebook - full story and all that we have learned

- Able to do custom out of the box

- All of the custom code (as an asset)

- Plans for fracture (upcoming and future project)

- Established billing and revenue

- R&D and prototyping

- Graphics, visuals, and other artwork (even sketches)

- Presentation gallery - Full presentation ready gallery for business functions, attributes, key players, and core concepts

- Concepts - these are worth more than our code

- Pioneering paths and ideas

- Over 6.5 million in sales

- Willing to push the limits and try new things

- We know the pit falls, the costs, the good, and the bad - we've been playing in this arena for quite some time

- No one else is doing what we are doing and how we do it. Our approach to bring operations and accounting together is unique.

- Our story is fully recorded

- Reoccurring model and reoccurring revenue

- Support a team of 15-20 individuals and their families

- Thousands of users that use it every day

- Refinement and bug fixes

- We've built and maintained this application - we know what it takes

- We are doing it - following a dream

- Tons of video recordings and trainings

- Knowledge and experience

- Minimal debt

- Generating revenue right now

- Plans and vision for the future

- 40+ servers

- Ok with being who we are right now

- We don't have to have every client - Ok with serving those who like what we do

- Relationships with clients, vendors, 3rd party solutions, users, and team members

- Tons of intangibles

- Ecosystem

- 12 main players, 12 business functions, 12 core concepts

- Data assembly line

- 3D World building concepts

- The concepts are worth more than the code - We are one of millions of possible options vs everybody will go down the main primary path that leads to what we are doing and trying to do. If they (any other company or software system) choose to follow us, they will come down the core paths that we have found and are exploring. These are the core concepts that we are built on. There is tons of room down here (like exploring a giant cavern with tons of off shooting tunnels and shoots).

- We keep taking the next little step and keeping linking things together

- The depth of what we do and what we cover

- High-end software as a service (online SaaS model), we cover anything to do with operations and accounting, we have a standard package and can built out custom on top of that.

Chuck joined Sean and Marisa on the last little bit of the other meeting. We were going over financials, accounts payable, and accounts receivable. Lots of fun showing numbers and some of their trends. Lots of drawing on the screen.

Both Sean and Marisa had to bail out and so just Chuck and I kept going. We switched gears and talked about the add/edit media/content pages that Chuck is working on (small page level facelift on certain pages). We also briefly talked about maybe using a JS framework (JavaScript) for the next version of adilas. Eventually, we really want to allocate some time, funds, energy, and resources to work on the fracture project. We are hoping that that could be part of our plans going forward. Even if it is a little bit here and there, we would take it and run with it. One of our first main goals is to create a plan and then be able to pitch the pitch. No new code, just mock-ups, requirements, prototypes, and proof of concept stuff. We really want a great plan and then to be able to do and build what we are hoping and dreaming about.

Along those same lines, Chuck was talking about making sure that our application has multiple layers. The database level (dao's - database access objects), the middle layer (business logic, models, and services - object oriented pieces), we then need an interchangeable display or show level (visual wrapper, themes, custom, or even white label options). If we build it out that way, the 2 lower levels could be almost untouched, even if we had to redo the upper or display level. Sometimes that is called the view level. It goes deeper than this, but an older acronym is MVC (model, view, controller). There are more modern versions of that now, but that is all that would come to my mind as I was recording this. Long story made short, keep the data, logic, and display levels as separate pieces and you are heading in a good direction.

The morning meeting started out normally and then sort of morphed into a multi hour long meeting with no real stop or start between the different topics and sections. We started out and Sean was checking in and lightly going over some of the BioTrack API socket questions. We got into a discussion on promises made and client and user expectations and how deep we want to go into those areas. Some of our clients expect an easy button for every possible wish or desire. It just doesn't work like that. Yet those expectations are real and valid based on user requirements and user demands. That puts tons of pressure on us as a software system. There just is no physical way to make it do everything, for every person.

Wayne joined the meeting and the conversation moved over to slow queries, database indexes, record counts, volume of data, and all kinds of other topics. We spent some major time going over potential problems with our flexible "LIKE" searches on the parts homepage (flexible wildcard searches across multiple database fields and columns). We need the flexibility, and we have trained our people to rely on that, but because it is so open, it is causing issues when put under a huge data load (not thousands but millions or multiple millions of records). We can handle quite a bit with no problem. When you really overload it, it starts groaning and squeaking under intense pressure. Technically, that is called scale.

The amount of data that some of our clients are generating and recording is causing a volume or scale issue. We got into deep logic and how we could speed things up if we were able to use indexes, exact searches, and get rid of huge list look-ups (using the SQL IN clause) or super flexible text searches using like commands (SQL LIKE clauses with wildcards). Basically, when doing some of these functions, the databases skip the indexes and end up looping over millions and millions of records. We spent some time talking about a number of possible solutions.

We had a break where Wayne had to go pick up his kid from school. In the meantime, John and I were talking about some of his projects. He was showing me a bunch of stuff that he has on a Jira board for the discount engine. I was kinda getting overwhelmed and depressed. So much stuff to do and manage. Sometimes it feels like it is all over the place and it never ends.

Wayne got back and we flipped back over to database queries possible options to help speed things up and handle a huge scale or a huge load of data. We talked about a combo type approach where we have to include tweaks to the database, code changes, UI and UX (user interface and user experience) changes, and other backend management changes. It may end up being a combo type package or approach to fix some of these problems.

That topic and discussion lead us to talk about prior or earlier decisions that were made years ago. We talked about why certain things were decided upon and implemented. It is very interesting and the story keeps rolling out in front of us. What we have now is a combination of history, situations, decisions, and even future wants and needs. It all mixes together and makes a complex solution. Some of the why and what we did is super important.

Having said that, things keep changing and morphing. We talked about building things for a non-static environment. Dealing with scale (up or down). That lead us to possible daily or real time mini aggregates on quantities and other key points and factors. Basically, ways of summarizing data and getting to more of a business intelligence type level - quick counts, sums, totals, averages, mins, maxes, etc.

Talking about the aggregation processes lead to talks about database triggers, update routines, scheduling, clean-ups, automation, manual checks and overrides, and the list goes on. Along the way, we kept talking about how important the inventory pipeline and tracking the ins and outs is so critical to these values, stats, and numbers. Steve joined us and we got into update functions, methods, table row locking, more manual updates, and reconciliation options to make sure all is well. You basically need the transactions (what happens and when - this is the details or the historical record). You also need the sums or totals (these are the running or current aggregates). These two pieces, transactions and aggregates play different roles.

As part of our discussion, we were looking at one-to-many database table and column relationships and how things are handled currently. It gets deep quickly. We then started talking about breaking shared tables into corp-specific tables and building smaller corp-specific aggregation type tables. This lead us to a small discussion on sizes of tables and when ones are already broken down into corp-specific tables and which ones may be up for review.

On the mini aggregate tables (quick sums, counts, and totals) we could go different ways. Do we want a historical record of the aggregates or do we just want to keep current (now) sums, counts, and totals? If you add historical, you start adding dates and get new records every day (assuming things are changing) or if you skip the dates, then there are less records, things may be quicker for the current but could take longer if going back in time. Maybe both... one to hold the historical aggregates over time and one to hold the quick and dirty (real-time current look or roll call report).

The deeper we got, the more that settings and database options came into play. We have a future project called fracture in the planning. We need to be able to have and use settings on what our users and corporations (worlds) want to see and use. We have tons of data and tons of records. Okay, great, what do you, as a user or end user, want to see, show, display, sort, etc.? How does that need to be organized? It goes deep and gets into advanced settings, display options, and being able to save layout and configuration options per person, per page, per corporation. That all needs to be included in the fracture stuff, along with the other transactional and mini aggregate database options listed on this page.

Once you know where you want to go... You can get there (hopefully). If you plan on being the only one to get there, the trail doesn't have to be very good. If you plan on repeating the journey, the trail needs to be even better. If you want a bunch of people and/or companies to complete the journey, you will need a road, not a trail. All part of the process.

Going back to tables, we talked about two big corp-specific tables in the system that will need a buddy mini aggregate table (or more). The big transactional tables are the po/invoice line items and the time sub inventory tables. Those two tables (that are already corp-specific) will need helper tables to keep track of both transactional aggregates per date (semi historical summaries) and also current non-historical mini aggregates for the quick and current view (no dates). Another way of putting this is making location specific pre math calculations vs having to go and re-sum things up or count things based on complex look-ups. You virtually do the known math per item, per package, and per location before it is needed. Then those numbers and values are quickly ready and available as mini aggregates. If you need more details or the blow by blow, you just go back to the transactional tables or records (different tables).

Some of our current pain is in the sales and POS (point of sale) systems such as carts and inventory tracking. We can do it, but if it gets into hundreds of thousands or millions upon millions of records, you run into the scale factor and issues.

Just for our notes, a couple key pieces are corporations and locations. If everybody just had a single location, some of this would be really easy. If you have more than one location, the solution needs to scale and keep track of mini aggregates based off of corporation and locations. That is a huge key that often gets overlooked. Plan for multiple (unlimited) locations. Here are some possible columns that may be needed for some of these mini aggregate tables for mini aggregate quantities - auto id, corp id, store id, part id, sub reference id (sub id), part count, and maybe a date if doing historical.

Switching subjects again, we need to charge more to clients for harder tasks and functions. I had a friend that was talking about software. He said, you tend to get two different types. You get cheap software or custom software. Hardly ever do you get cheap custom software. Custom does cost time and money. That is the way it is.

After Wayne left, Steve and I stayed on for a bit to go over some other things. We talked about gift cards, coupons, and other upcoming projects. I showed him a PO rounding demo and what I have done so far. The next question was... how deep are we going to dive per subject? Lots of options.

Chuck and I going over the custom error page that he is working on. We also talked about fracture and options of building new vs morphing existing into what we want. There are pros and cons of both choices. Just for fun, Chuck and I were saying that is would be really fun to get a small prototype team like Chuck, Russell, and I or something like that and let us work on fracture while others kept up the other system. Dreaming... :)

We also spent some time talking about different page views and where we are heading with scheduling, booking, rentals, and reservations. We really want to circle back and update elements of time to handle the things that we will need going forward. This entire section seems to be heating up and we want to stay on top of that. Good stuff. Dealing with views: We want to improve calendar views, horizontal time views, vertical time views, and other display views that will be fun and useful tools for people who schedule or deal with time as a resource (billing, selling, or booking time).

Chuck and I talked and went over budgets. We talked about global CSS changes and pros and cons of that approach. Ideally, we'd love to almost start over from scratch and build it up like we would like to, with a plan, a design guide, a style guide, and a bigger vision of the whole. Almost to the fracture level, when possible. Currently, we have a system that has been rewritten multiple times and we keep adding on to it. That isn't bad, it just could really use some more master architecting or bigger overarching planning and style guide type approach stuff. It would make it more cohesive as a whole. Build with the end in mind. We can see so much further down the road than we could when we started. We would love to translate some of that vision, pain, needs, and goals into what we build going forward. It's been quite the journey.

We looked at code and went over some feedback from users on the other branches that are still out and needing to be finished. We still have the parts homepage, the advanced parts search, the customer queue, the customer homepage, and other small pieces still hanging out there. Good discussion on raising monies and other ideas. Merged in some code and pushed it live. More email stuff at the end of the meeting.

Sean sent me a text and wanted to jump on the GoToMeeting channel to go over a possible problem with pagination on the parts homepage. It looks like adding in the new snow owl datatables, new updates and changes launched last night, that the pagination messes up bulk add to cart options on the other pages (beyond the first page of multiple pages of search results). Basically, the datatables allow you to change the sort order and even limit certain fields showing up. If they change anything, it can put a parent item on one page and the subs on the next page. The code looks for the parent item stuff, if a sub is selected. Basically, if both the parent and the subs were on the same page, it worked. If they, the users, through different searches, filters, or pagination (going to the next page) they could make it break if the parent and the sub items were not on the same page together. This also happened if there were so many subs that the package that they wanted was on a different page. Anyways, small little complication and small little bug. We found a number of work arounds, but that requires training and education or experimentation.

After I finished with Sean, I got a call from Cory and then we jumped on the GoToMeeting session. Cory was relating some of the tech support questions and complaints that she was receiving. They, our clients, wanted more info than what we were showing them. We tried to trim some of the reports down and make it easier on the eyes. Our clients, depending on what they were doing, really needed all of the data and sub attributes and RFID tag data. Kinda interesting.

Anyways, we may need to go back and provide more options. Long story made short, we really need real client feedback and input. It is invaluable and muchly needed. As a side note, it keeps coming back to settings and even settings at different levels. We need corp or world level decisions, category level decisions, and even user or page level decisions. It keeps coming up and would really help to provide a solution or multiple solutions where the users are in full control of what they want to see and use and even how things act and play through. That is one of the things that we want to add in on the fracture project - full control of what they see, what columns, show/hide, sort order, naming, aliases, etc. Almost to full custom without making everything fully custom. Just base it off of data driven decisions or layered settings, permissions, and templates. That would be awesome!

Meeting with Cory and Eric. We started out with a question that Cory had from an email from a client. Eric and Cory were following logic for wholesale carts and a bypass switch and logic for not sending wholesale data to the state compliance tracking system. Cory and Eric spent close to 45 minutes looking around, checking code, following variables, and comparing old and new code. Randomly enough, some of the changes were done by Eric, some by Wayne, and some by Alan. Also, to add to it, we couldn't tell if it was a user error or really a small bug in the code. We went over and talked a bout a number of possible scenarios, including users changing things after the fact.

We then switched over and went over some of the sales tax aggregate code and processes. Cory had a small list of questions and she and Eric were going through things and discussing options, flow, logic, and processes. It got pretty deep. Tons of moving pieces.

These were some of my observations while they were going over things:

- Possible problems with hidden database triggers. Hard to check the code you can't see. We talked about pros and cons for triggers and clean-up routines.

- Code and version control - branches - Possible problems with certain code branches overwriting other branches - who has the last cookie?

- Maybe make our own visual code based triggers, clean-up routines, and scheduled processes. We may even want to record histories of what happens, where, and when. If certain things need to go through a full process. Can we monitor and track it through the different pieces, phases, states, and statuses.

- One nice thing about a database trigger is watches for any change to the database record regardless of where it comes from. If we do our own, more visual and controllable version, we need to make sure and cover the different scenarios such as add, edit, delete, void, bulk updates, API sockets, backend updates (direct database activity), etc. Just make sure we cover all of the possible tweaks and scenarios.

- There seems to be a need for ways of doing a manual override and or a manual update. It may need to be flagged if updated manually or modified in any way, but sometimes the automated processes fail or have issues.

- Real-time vs a delayed type actions - Is the data being pulled in real-time or is there daily or nightly process that aggregates or cleans something up. Some outside schedule or routine. We have a lot of future aggregates that we want to build out for our fracture project. We may need ways of flagging and tagging the data and tracking it through phases and activity paths help us know where things are and what processes that they have gone through. Flags and tags (a flag and date or a checkbox and a date or phase and a date) are huge. they really help us track what is going on and what has already gone on. If the data is correct, let it pass. If not, correct it and then flag it. Once it is good, let it pass. The history part of it is important for what happened, when, how, and by whom. Basically, a roll call - where are you? What is your status? Where have you been? Who were you with? When did you finish? etc., etc.

At the end of the meeting, cory and I briefly went over some budgeting and funding values.

Cory and Chuck were going over some new changes and things that we needed Cory to test and give us the thumbs up on. The new changes have been pushed up to the developer's testing server and need to be reviewed. The biggest section on new code is dealing with the parts and general inventory items section. We have modified the parts homepage, the advanced parts search, add/edit parts page, view parts page, parts usage, parts history, and a number of other part/item related reports and pages. We also have two branches with some changes to the shopping cart on the dev testing server, ready for review.

As a great little side note, Cory mentioned that we have to give people time to update their SOP's (standard operating procedures) if we go changing things. Some of the companies really rely on those SOP's. I didn't even think about that. One other comment that Cory made was - "We need to manage the things that are in our control." There are tons of things that we can't control, but those that we can, we need to do it in such a way that we control the changes, updates, and releases. Ideally, we will test, plan, and even schedule the releases.

We got into a discussion on data tables and pros and cons. Chuck would really like to revisit this topic when we build out fracture (future adilas project). We would like to look at pros and cons, which plugins to use, or just build our own. We really like what the current ones do in concept (export, sort, filter, search, print). However, we would like to change the layout, the display, the amount of real estate that it takes, defaults, and pagination. The current data tables work really good up to 500-1,000 ish records. Anything more than that and they fall apart (due to pagination and how the JavaScript loads the tables). Chuck and I were talking about some possible hybrid type options where we use client-side and server-side code to help them be more effective. Including storing default settings, default sorts, default show/hide columns, and mixing AJAX and server-side logic. Basically, making custom data tables that work for what we do and how we want to play the game. Definitely a must have for the fracture project.

After Cory and Chuck left, I kept going and switched topics. I was checking banks and looking into bills and payments out to our guys and gals. I also wanted to record some notes from my morning hike with my hiking buddy this morning. We were talking about this while walking in the snow, up High Creek Canyon before work.

- Real costs - Build in ongoing maintenance costs - not just the original development

- Also dealing with costs - what about coving costs for admin, managing, planning, normal development, deploying, and future or ongoing maintenance. Many of these costs are being skipped right now in our quotes and invoices. We need to cover what it really costs. Currently, we are giving away a bunch of free work and labor.

- Maybe stopping custom work - I'm not sure how to take this one, but we were talking about it. Currently, custom work is a huge part of what we do. Having said that, a good 75 percent of my work and efforts are being used to help with 1x (one time) revenue gains vs general system enhancements that are on a reoccurring revenue gain or side of the fence. My efforts are being used in project management, planning, code sign-off's, heling on the projects, babysitting developers, and deploying those projects. I'm kinda torn here. I enjoy helping but is it efficient? It may not be... Hard to fully tell. Anyways, thought that I would at least make a note about it.

- Use data to make decisions to help figure out where your product or features are being used. The data will help you make certain decisions (supply/demand/usage). When is it being used, by who, how many times, and can I quickly get to aggregated or summed up data on the subject? It is an normal core usage or add-on piece? This may or may not go here, but our model gets more complicated by having tons and tons of different servers. We may need to identify different pieces of the application (core, extra functions, settings, features, add-on components, 3rd party solutions, industry specific pieces, custom code, etc.) and then setup flags and tags to who is using it, what are the costs, any add-on's, and make that information available from a single spot (aggregated data). This would be a great feature to add into our fracture project. We may have to create our own little master list and then report that data back to the main server through API sockets and what not. We really need to be able to get to that data (who is using what) quickly. We need a quick summary of how and what is being used or is turned on/off. We can see that data right now, but we have to go to multiple places and even run special queries to get that data back. It's not very quick right now. Anyways, a great idea. Let the data lead and help to tell the story.

- We may want to track other key decisions per corporation such as merchant processing, number of locations, number of users, numbers of vendors, number of invoices, expense/receipts, deposits, elements of time, etc. We also need to track data storage amount and also files, images, and other media/content. We already do this, but the numbers are not centralized. This would be another wonderful feature for the fracture project. Basically, system stats and aggregates based on data counts, numbers, values, etc. If we get this dialed in, we could really use this to help set prices and charge for what is being used and/or turned on. This is an eventual goal for us, when we can get to it.

Going over some of the origins doc that we just finished. Talking about adilas core concepts, plans, business plan, heading toward fracture, budgets, and small teams. We also talked about optimizing vs maximizing and pros and cons there. How do you implement change? What is the cost of transitions and switching gears?

Here are our current priorities (just for Shannon and I - where we are heading):
1. Budgets and getting cash flow under control
2. Plans - business plans, investment pitch stacks, and planning out fracture.
3. Back to the adilas core concepts and new content for articles, user guides, or other docs.

John and Steve working on some styling. Steve asking questions about old tech vs new tech. We really need to restyle everything. Steve was making an analogy of a pay phone and pager vs a modern cell phone or mobile device. Things change. We talked a little bit about fracture and the evolution of code and design. John really wants to start moving things to the next level. If we do that, there will need to be some internal training and making sure that all of our guys know where we are going and what we are shooting for.

Everything has a lifespan and a maintenance schedule. We have so much functionality, but it's kinda ugly. We need to work on that. Along with that, someone needs to keep up with the changes. We talked about a need for a deeper look into coding versions, functionality, custom exports, special print stuff, and more. This topic returned us to talking more about efficiency stuff and back talking about newer versions of some of the underlying code, libraries, plugins, and library dependencies.

It got into price increases based on our costs and reflecting that back out to our clients. Thing, costs, really have gone up and we haven't done anything about that. There is a disconnect there. Our current look and feel is virtually killing us. People dismiss us a viable option, because we look a little bit older. This seems to be the biggest factor where people judge our software. The value of having a good style guide and then sticking to it. We really need this in our site and app.

John, Cory, Chuck, and I were in a good discussion on versions, code dependencies, frameworks, and what the future may hold. This was a carryover conversation from an earlier meeting, but we ended up spending a bunch more time on it. I thought that it was interesting the mix that we had on the meeting. Both Chuck and John have been our biggest proponents (supporters) for a centralized style guide and the adilas docs project. They were both huge assets in this discussion on direction and upcoming future decisions.

I'm not sure I can put all of the topics that we discussed into nice sentence formats. I will just list them and make some bullet points. It will help me switch gears and subjects quicker.

- BATC or B-Tech (local technical college) and working with them in networking and possible intern training options.

- What technologies are needed and being called for - in the general marketplace?

- Focusing on UI and UX first. UI (user interface) and UX (user experience). It used to be called GUI (graphical user interface) but they have added in the user component and what the experience is like. That is great and really makes a difference.

- Once the UI and UX is nailed down, go back in and recode the backend based on the UI and UX decisions. We also want to use standards and frameworks.

- We talked a lot about critical components (things that we use or lean on). We talked about how we had to alter a number of things when Adobe Flash went through its end-of-life stages and what impact that had on our application and company. We talked about other things that are being deprecated or are entering an end-of-life range. Things like bootstrap 3, jQuery, and other code technologies that we use.

- Cost analysis - what do we gain and what do we lose if we change?

- Some of our customers don't care about mobile and the latest trends and fashions. Some of them really care about mobile and responsive interfaces.

- How can we show and expose the features, advantages, and benefits of what we are doing? If we get buy in, that helps us push things out to our clients vs trying to convince them that they want and need what we are doing. Pitching the pretty and sparkling things. Steve always says - sell the sizzle, not the steak.

- Changes in code and technology. Like using CSS variables vs a custom mix of server-side code and pages that we build on the fly, every time. Speed, consistency, and efficiencies by using newer tech.

- Lots of time talking about helping and optimizing things by making some of these changes and enhancements. Including validation plugins, JavaScript, and moving things to the client side of the application. Less touches on the servers. Let some of the things happen on the client side of the application.

- If we make a bunch of changes, we will have to do some training for our developers on the new techniques.

- Cory was asking, how do we protect ourselves from a crisis mode? Dealing with end-of-life and depreciated or deprecated code sets and libraries.

- Setting priorities and focus areas

- The whole discussion switched as we talked about moving to new technologies and when we should do this. We were talking about adilas as a ship (small analogy). We talked about options of having ship A (current adilas platform and application) and building ship B (new or fracture adilas platform). We talked about what that would look like, how we could do that, and what changes would be needed. We also talked about options for transforming or morphing between ship A and ship B (what we have now and where we are going). Pros and cons to both approaches.

- I did some drawing and showed the guys some ideas and options on how we could set things up and structure things. Tons of potential. As a note, if we did start building a ship B (new or fracture model), we would want to put it in a totally different folder/directory and start from the login process going forward. We have lots of brainstorming already done on what we have learned and what we could build if we went to the fracture model.

- We got into a discussion on prices, up sales, and pitching the dream. Talks about pricing lists for products and services that we offer and what our clients gain if we go in that direction.

- Along with prices, we also talked about really charging for data usage and storage. Right now, that is not really a part of our pricing model, but it can be a huge load to carry, depending on the client. Some price changes and price increases are very needed and are completely warranted. As a side note, we (adilas as a company) may need to listen to our guys and gals who are working with us. They are pitching higher prices. It is totally warranted and needed. We are really close to tipping over the point of not making it (costs are higher than revenue coming in) to being on the positive side of that line. Price increases could really help us do that without trying to wrangle in tons of new sales and other efforts.

- Keep making small changes - progress by degrees

- John is going to start creating a document with some prices for dedicated servers, semi-dedicated servers, shared environment, and other products. We already have some of this, but it is not in a central location. The end goal is not to have it on a separate document, but have a centralized spot, location, and even get it all into our POS system. Lots of possible variables. As another side note, we (Steve and I) have produced quite a few different pricing spreadsheets over the years. It gets tricky based on number of employees, number of invoices, number of customers, number of locations, amount of traffic and usage, data storage, media/content and image storage, and other features that our clients either use and/or don't use. That's where it gets tricky.

- Both Chuck and John expressed that they are grateful that we (as a company) listen to them and take the time to try to implement their thoughts and ideas. That makes a big difference, if you feel like you are being heard.

- I'm wondering if Steve and I should step back and let some of our guys and gals make some of the changes that they are pitching and proposing. We have to get to a good balance point of normal supply and demand economics and business logic. I would be interested to see what would happen. We could monitor it and help guide it, but I would be super curious to see where things ended up going (fresh outlook and fresh set of eyes on older or existing problems or issues).

At the end the meeting, Chuck had to bail out, but Cory and I kept going with John. He was reporting to Cory on his payroll updates, plans, and other projects. He is almost done with the year end tax and payroll form printing stuff. We keep getting better and better at the communication thing. It's tough to nail that down. Making progress.

Started off doing emails and recording notes from the earlier appointments and meetings. I then switched back over to Steve's projects for some new production, recipe/build, and elements of time code changes.

Future plans for fracture and maybe even before - we will need session values for recipe/builds and elements of time. These are the first new dynamic settings that are not tied directly into the normal corp-wide settings. They are more of a group or page level setting, but still needed to cascade through the quick search, homepages, verbage, links, buttons, error messages, and other places. This is a slight variation from the normal corp-wide settings, but they still play a similar role.

Pushed up some dynamic quick search and dynamic permission name changes (7 updated files). Let Steve know where I was at on the project. The next step is building in code to use time flex attributes to dynamically build recipe/build links if the correct settings are in place.

John and Sean were on the meeting. I did some checking on bills and payables. Eric jumped on and reported on his sales tax aggregation project. We talked about force adds and logic lines and channels. There are times that we need to make sure that certain things are in place vs giving all of the power over to the users.

John and I talked about how to get the Adobe XD files for fracture up on the content server. We may need to convert them to .zip files.

Cory joined and I reported in and showed her what I was working on with the new element of time settings and new time template settings. We did a small over view, I recorded some notes, and I showed her around the printouts, marker/highlighter stuff, and Excel spreadsheets. I did some drawing and tried to explain where we are going and heading. We also talked about planning projects and being able to turn those projects over to other developers.

As a part of our conversation, Cory was mentioning that Steve is working with a client that is paying for some new time settings that they want. We talked about options to control settings on a world (corporation) level and also on a per time template level. Steve is working with his client on some global or world level settings. I am going to be tackling some of the time template level settings. We will work together to make it all flow and happen. I'm seeing that Steve's settings will be considered global and will feed into the template level settings. The the template level settings will control the elements of time that are added under each time template.

Random side note, Chuck did a rework on the time template homepage yesterday and we pushed it up to the server. It looks great (night and day difference). I'm seeing that our future plan - called "fracture" may end up being a refinement of what we are currently doing. I was explaining to Cory how I always envisioned two totally separated projects (old adilas or ship 1 and new adilas or fracture or ship 2). Even though I would really love to do that... (old ship and new ship). We may have to build on what we have. If we get the funds and resources, I'd still like to rewrite the whole thing. If not, we may need to keep tweaking, refining, polishing, and working with the older version to make it become what we are looking for. Anyways, just recording some ideas, thoughts, and feelings.

John joined the meeting first today. He, Cory, and I went over some of his projects and where he is at. He has pushed up a number of smaller branches in the past few days. One of them had a number of JavaScript changes to the discount engine. He reported on that and then we switched over to servers and system admin stuff. John wants to document things but he is concerned with security keeping the procedures and processes out of the hands of those who shouldn't have them. We talked about some options for distributing and securing those documents.

John also reported on chasing other smaller bugs and putting out small fires. Going back to the key person, systems admin docs, currently, lots of things are hinging on certain key players and their knowledge. We need to capture that knowledge and put it in writing, as best we can. We also need to keep those documents in the high admin's hands vs public knowledge. Anyways, we will start going through things and collecting what we can, while having the security thoughts in front of us. We'll find a good mix.

After John finished, Alan checked in and let us know where he is at with his projects. He is still working on the new sub inventory object model code out in ecommerce land. He still has a few things left with that project. It's been a big lift. Also, he was saying that he currently can't pull that new code inside adilas (out of ecommerce land and into the main secure adilas platform) due to some legacy issues. Not insurmountable, but at least a decent amount of work.

One of the blockades is the number of black boxes and custom code that exist out there. We need to figure out a way to bring in the new code into the legacy system. Alan has a few ideas, but we may end up having modes (new and old) and being able to flip flop between those modes.

Some of the new stuff is more object oriented vs in-line code that runs from page to page but requires a certain step by step process or chain of events. Some of Alan's new stuff deals with objects and inheritance, less hits to the database, and all around more efficient code. It's all part of the process. You have to start somewhere and eventually, things tend to morph and/or mature, in logic and processes. It's all part of the game.

Alan was showing us and talking about some crazy tax calcs and recalcs and how the models and objects handle those changes. One of Alan's goals in this project is to stabilize some of the pieces and isolate the variables. In the new models, he watches and monitors things like quantities, target prices, costs, price per, rounding errors, taxes, etc. Pretty deep.

I thought that it was interesting to hear Alan say that one of the barriers to him finishing the project was the number of black boxes or custom code pieces that are out there. We love doing custom code and it really helps our users, however, there is a cost to that and it tends to hit our developers and how easily they can roll out those new changes. Basically, easier for the users, but potentially harder for our developers. Lots of moving pieces.

Cory and Alan were talking about MVP models for the new sub inventory pieces. We could jump off into super deep waters, but we need to get the project done. We can always circle back around.

After talking about sub inventory for awhile, the topic switched to Metrc (state tracking and compliance system). That 3rd party integration is more than a fulltime job. Anyways, they were talking about importing inventory, comparing inventories between systems, and other required interactions. Lots of moving pieces, plus you have two separate systems that work completely independent and we are trying to keep them synced up together. It can be very challenging. If they change something, we have to follow suite and/or create a bridge to what new requirements are needed. If we make a change, we have to make sure that we aren't breaking anything that already exists.

After Alan was done talking to Cory, he left and just Cory and I were left on the meeting. We started talking about how long certain projects take, how deep they are, and how they tend to morph from what was originally created into something completely new and different. This lead to some discussions on the complexity of being a public or publicly demanded company (our clients have a say in what we do, when, how much, why, etc.). Sometimes I wish that we were just developing our own little software solution and then we could just sell it to the public. Instead, we are building, changing, refining, and trying to please our clients along the way. That is ideal, but it also adds all kinds of pressure and other variables.

Cory and I got talking about real costs and what it takes to please people. We had a client that came up with an idea, it sounded easy, but has turned into a huge 4 month project and has cost us over $30,000. Sure they want it, but did they pay for it? Sadly, no, we are stuck with the bill. We tend to do that a lot. That hurts and especially if you keep doing it. We love to build and can get sucked into that very easily. Having said that, we are getting better at asking for seed monies, billing out the clients, and sharing the load. Sometimes we just need to vent a little bit.

As we were talking, my mind started to think about how hard it would be to fully rewrite the entire application that we are building. Don't get me wrong, I'd love to and I think we could come away with some huge benefits but there is a cost. Some of those costs are real costs with money, resources, talent, time, etc. What about the things that are harder to see like stress, pressure, demands, wear and tear, burnout, changes in physical ability, mental ability, and other unseen costs. What if we just try to build on what we have? That's what we are doing right now. What if we just kept going and didn't try to redo everything? Just keep refining, polishing, and tweaking things as needed. Still a lot of work, but it may be a better solution (at least right now). I was thinking about fracture (future project) and where we want to go with that project and those pieces.

Phone call with Steve. We started out talking about some of our current projects and where things are at. Lots of moving pieces both in business and in life in general. Here are a few of the topics that we talked about. I filled up a couple of post-it notes while we were on the phone.

- We briefly talked about sales and reoccurring invoices (reoccurring revenue steam). Looking at trends and where things are at with the reoccurring invoices. That is our bread and butter. We also do custom code, deployment, training, and other things, but the reoccurring invoices are our primary source of income.

- We talked about the MVP (minimal viable product). To some people and some industries, we are there. To others, we are still not there, even through it's been years and years. As we were talking, we also mentioned, that adilas is so deep and complete, maybe we are just now even getting to an MVP type level. Real digital storytelling and world building requires deep waters.

- Timelines - Sometimes it takes a long time for certain things to happen. That is just true, no mater what. You almost have to adjust to the longer play (for certain things).

- Get out there and rattle the bushes a bit. If we need more custom code or client funded work, get out there and ask people if they need anything done. We could get them a quote and then get a developer on it. All of our guys are busy, but not all of them are on funded projects. That means that we are picking up the bulk of it (the virtual tab), for the new development.

- Pitch things as they are. If needed, we could customize and we can bill for that.

- We need to do some immediate fixes. We have some payables that are stacking up that we need to get out. We also have tons of receivables that we need to collect on. If we had that, we would be fine, but it's hard to get the money out of our clients some times. Always this little game of sorts.

- We talked about some short term funding and cash flow options.

- We are going for the full system or fully integrated system - that's where we want to head. This allows for the ability to record and track things end-to-end, through the entire process.

- We will still allow 3rd party solution but we really want to focus on what we do. There has to be a balance.

- Steve was talking about calling some of our best clients and seeing if they want anything? Development at $100/hour or training at $65/hour. Couldn't hurt to ask. This could be custom development or filling their needs in some other way.

- As Steve and I were talking, it is amazing how functionality and needs for functionality keep bubbling to the surface. We don't even try and it just comes up... Kinda like the ongoing idea farm type mentality... it literally just keeps coming and we end up taking the next step.

- We are a serious solution - those who get it, love it! Those who don't, go elsewhere.

- Harvesting some of our R&D and building out some of the fracture type pieces. We really want to build where we want it to go vs being pulled in certain directions. There needs to be a balance, but right now, we feel like we are just being yanked and pulled in every direction (spreading us thin). It would be great to be able to focus and really go where we feel the bang for the buck would be best for us as a company.

- Dedicate time and resources to those pieces. Work the plan! Carve out some time and push on some of our pieces.

- At some point, you kinda have to keep faking it until you make it. That sounds shallow, but it is true. Fake it till you make it!

John and I were on a meeting. I ended up doing a little bit more research and looking at the file from Jonathan Wells and his Adobe XD mock-ups and prototypes. I FTPed  the files up to the content server. John asked me to explain the content server and how that whole thing works. We did a lot of drawing and bouncing to different pages to explain the processes. Some of the highlights were talking about why and how we allow for 3 different sources for media/content (files). We allow for local paths (where are things stored on the local computer or drive), remote references (where are files stored on outside or other servers such as google drive, drop box, skydrive, etc.), and finally, physical upload (files that you push up to our servers for storage and security). Great questions.

John really wants to help out with some visual flow charts and graphical user interfaces, including graphical homepages and layouts. That would really help - for people to get their heads around what is out there, possible, built-in, and available. Each section needs a small visual and/or virtual map of the area. As we get into fracture, I really want to include some maps of the sections so that people could follow along, know what is there, and also be able to customize their own workspace and data flow (digital assembly line with phases, sub locations, date/time stamps, checkpoints, etc.). Make the whole thing a visual delight to work with and organize your space or work environment.

John asked me for some file over email. I knew that we had them, but I hadn't been able to get back to them and review them. The files in question were tons of great R&D files on fracture done by Jonathan Wells. I started to review the files and got completely sucked in and inspired by the level of detail, the work and research that was done, and the possibilities. Great stuff. Anybody who is researching the fracture project, needs to review those Adobe XD files. Wonder full. The originals were done between 2019 and 2020. There are numerous screenshots that have been posted, but the real value is in the raw files, including the clickable desktop previews (mini click through slides and links on the actual documents).

Towards the end of this session, Heather (my wife) came down to talk with me. I showed her some of the things that I was playing with and learning about. Great enhancements and much easier to consume and digest. I loved working with Jonathan Wells, sad that it had to end (time and budgets), but we got a lot of great stuff (R&D, research, mock-ups, ideas, and direction) from the efforts.

See attached for a small list of XD files that I was looking at.

Steve and I going over ideas and options. Steve was just going off (in a good way) and I was scribbling things down as fast as I could. Fun little session!

- Using adilas to run adilas - so many things are available - discover what is out there that we already have - harvesting elements of time - Steve is working on forward looking inventory planning - demand, work orders, recipes, supply, ending inventory

- We have lots of great developers, maybe tap into them and help us all learn some new skills - JSON, AJAX, Bootstrap, jQuery, etc.

- We have a great team all around - Sales and deployment is getting better and better

- More predictive stuff is coming - What to order, What to get rid of, finding that balance point

- Keep building the foundation

- The value of templates - Steve sees those concepts (templates) being used for invoices and employees - Maybe add template id to the flex attributes table.

- SaaS (software as a service) is developing, people are starting to trust the cloud more and more - Netflix, Google, etc. - They have taken the edge off a bit.

- Predictive loading and just in time events based on settings

- Fracture is already starting to morph (what we think it to be) - Helping users predict what they want - Break it all down into smaller and smaller predictive outcomes

- Simple pages that allow a customer to preset or only use what they need - like an artist pallet - pick and choose and put the pieces that you need, where you want it - All based on settings and permissions.

- We are seeing three (3) levels of users or programmers - They are full backend, middle end users, and frontend users - You will need all three as it gets more complex.

- The reality of the constant state of improvement(s) - It just keeps going! New tech (new technology) and new services are needed and wanted - All the time!

- Helping our clients succeed - That's the main goal!

- Minimal load but allow them to add weight and depth as they need - Helping to match price with what our clients are getting.

- I was showing Steve some screenshots from Chuck's presentation gallery project - super cool stuff. That (the presentation gallery) will be a great sales tool! So much potential!

Recording some more ideas for time settings. got into database field settings and custom verbage (names and aliases and instructions) planning.

These notes were added as of 9/3/21 - Original date was 7/24/21. All of them are dealing with elements of time and new time settings

- We need validation on the add/edit time action page to reflect the new template settings and verbage settings

- If a frequency is selected, help it automatically show in the add/edit page for adding time (all settings and verbage settings). It may also be nice to do the same thing for the sub dates and times and sub flags and tags. For example: Say I mostly deal in hours, if that is selected, i'd like to see hours preselected in the frequency drop-down. As a side note, we will use a new setting to take care of this.

- Some pieces of elements of time get pulled into the shopping cart. We may need to check settings and template values there as well.

- With all of these changes to names and defaults, we will need to update a number of help files.

- List of subs
Action Status Logs & Changes
Additional Date/Times
Additional Categories and Special Flags
Additional Comments/Notes
Additional Sign-Off's
Additional GPS or RFID Tag Tracking
Additional Payroll/Time Sheets
Additional Notification/Reminders
Additional Tie-In's/Assignments/Pools ("any" person, place, or thing)

- On sub sign-off's - Take off the under construction note on the template page.

- Add a date/time frequency id for general dates - this will be a new template setting - use it for start dates, end dates, and target dates - make sure it replaces the total time frequency id and also populate things in the edit mode for flipping dates quickly.

- On the time templates, add a budget frequency preselect, including a custom one. Currently, you can just turn on budget stuff but can't set anything.

- There is an awesome function called buildCustomFieldSettings in cfc/basics_3.cfc - We may need to add an alternate table name to allow for time templates to be pulled, as they are different then the main defaults. Once done, make sure and search other usages and update them with an alternate table name as well (for customers and such).

- Took a small break and went outside and walked around my house. Came up with a couple of things for me... 7/24/21

- Create a whole excel spreadsheet with the new verbage changes that are needed. Include a usage column to remind me or whoever where these changes need to go or show up. Very important, so that we don't miss anything.

- On horizontal time views (and vertical time views) make sure and show conflicts or double, triple bookings - expand as needed.

- Keep planning it out... it may be faster in the long run, including options to delegate parts and pieces.

- Figure out the dynamics - say $$custName$$ or $$locName$$ for the corp-wide settings for customers and locations. just an idea.

- Not worried about time or money to do and finish this. Do it right and build as if for years. Part of this is showing that fracture (future project) is possible. Small exercise and experiment. I know that it is possible.

- My current job is focusing on project management and planning

- Sell and pitch the vision

- It doesn't have to be done to pitch it

- Keep prepping things and be your own style

- On the db_field_settings (custom field names and aliases), we may need to update the db_field_rules_min from unsigned to signed (allow negatives).

- On the new db_field_settings... do a check to make sure that _display and _short_display values all match up. Check excel before doing a final commit. Maybe add some temp columns to the spreadsheet to see what is where.

- We had the idea to make the advanced search be template specific. What about being able to make the main time homepage be template specific. That would be really cool!

- Speak their language. Everywhere that is possible. Make it easy. Less training will be needed later on, that way.

I've got a project coming up that needs some new settings for elements of time (calendar, scheduling, and events). I woke up this morning and couldn't stop thinking about some ideas for some new settings. I scribbled them down on a 3x5 card (front and back). I was saying a prayer and the ideas kept coming. Kinda fun. Also, the other fun thing was almost being able to see how to do some of these things and the potential that they could unlock. Really fun.

Anyways, here are the ideas. After I got them all scribbled down, I texted Steve to see if he would want to meet for a bit to go over the new settings and ideas. We jumped on a GoToMeeting session and he and I had a good 45 minute chat, with drawings, proposals, pitches, and lots of ideas going back and forth. Good session. Here is an expanded version of some of my little notes and scribbles.

- Dealing with time templates - what if we allowed for a basic mode and an advanced mode? Some people may not want to see all of the pieces. The basic mode would be what currently exits and/or something pared down from that. The new advanced mode would allow for all kinds of other settings, verbage changes, field name aliases, special instructions, sort order (where the fields show up), settings, required options, etc. The time templates page would have a toggle switch to go between the basic mode and the advanced mode. There would also be links directly to the advanced and basic modes from the list of time templates page. Same permission, just a toggle switch between the page modes. As a side note, Chuck recommended that we maybe have a "custom" mode.

- We already do this with customer database field names (allow for field names to be controlled). We want to do the same thing for elements of time. We will use the db_field_settings table to store specific info (field name options) for each time template, if the users wish to. If not, we will use a default set of data stored in the db_field_settings table for basic time_templates. We will use the field called db_table_name to store the value "time_templates" to store the default values assigned to corp 1. Just like the customers stuff. For each time template, we will change the name from "time_templates" to "time_templates_[555]" where the number will be the corp specific time template id number. Tons of sweet options there already. Aliases, defaults, placeholders, build your own drop-downs, required yes/no, max, min, show/hide, sort order, etc. As a side note, we currently let the main time templates handle the show/hide options. Somehow we may need to sync those up and/or figure out which one is the master. For right now, I'm still leaning on the time template being the master and the db_field_settings table holding the naming, aliases, special directions, defaults, etc. I hope that makes sense.

- On the advanced time search page. I would really like to add a master template switch at the top of the page. This would be a drop-down form field that shows all of the time templates. If a time template is selected (or preselected through a URL.template value), at the top, and submitted, then the page would be able to virtually slim down based on the settings, naming, and custom pieces per time template. The current advanced time search has everything plus the kitchen sink. If a template is selected, then the page could only show those pieces that are turned on, the correct naming, the correct filters and search criteria, and hide all unused sub searches as well. The time template settings would also affect the sub time searches and use the correct verbage, info, naming, show/hide, filters, etc. Basically, be able to dynamically convert the advanced time search page into a time template specific search form or page. That would be super cool. Also, if a template is selected, the search results could also translate and show the correct fields, verbage, settings, and make it feel round trip (search, results, and details). Higher in this entry, it is alluded to the fact that we could control the page with a URL value (URL.template) and then we could link to it, store quick buttons, etc. That would be really handy. As a side note, Chuck recommended that we look into a tab or tabs based page for all of the different searches - make it more digestible vs all in-line down the page. We could still have the template switch, but show the different searches in a vertical or horizontal tab display. Great idea.

- On the sub flags and tags, we need some more template settings. You can turn 5 different sections on with this sub (one of the bigger subs). A section within the sub tags and flags, was one that that was added later on (for phase tracking and location moving) it deals with possible sub tie-ins (PO's, invoices, quotes, etc.). Currently, we can't control that piece through settings. It just kinda got added out of necessity vs through the normal development process (planning). All we need to do is go in and add those settings, flip some of the old values (existing data) and make it more straight forward as people set those things up in the future. Along those same lines, the sub flags and tags may need some help on the output and display and the add/edit process. All of those pieces were altered and got the sub tie-in hardcoded to them. We may need to remove or make that more settings based.

- On sub flags and tags, I would like to be able to show the last flag or fag on the main. It holds the data right now, but doesn't show the entry. Light tweak to make it show up on the working with time page and the printable time page. Also, check the searchability of the last known flag or tag on the main, through the advanced search.

- There are two pieces of the main elements of time that we can't control via settings yet... they are the make private and admin only checkboxes. We need to be able to turn those two settings on and off. Currently, every element of time automatically gets those. They are not used that often and need to become settings so that we can show/hide those options. As a side note, those two settings do have some hardcoded text values like "private" or "admin only" that show up on other reports and report types if someone searches for something that is marked as private or admin only. Just a heads up. We may want to limit the verbage on these settings.

- The general amount field on the main elements of time is currently locked to showing dollars. I would love to add some settings to allow that field to be named and formatted. I was thinking of dollars and cents, decimals, plain (no formatting), and integers (remove the decimals). That would make it more useful. For example: I have a time template called mileage and I use the general amount field to hold the number of miles. It holds the correct value but when I pull the report, it always shows the miles in dollars and cents vs just a plain or decimal number. Anyways, I think that could help. Also, along those lines, there are some budget and estimate settings (different settings but still tied to the main element of time)  that could use similar number formatting options. See notes at the bottom for some other mileage ideas.

- What about allowing for the sort order of the fields? This is more complex, but it would be cool. You could put whatever makes sense to you first and move other fields around (up and down or sorted). We may have to circle back around to make sure this is possible.

- Recently we added a thing called flex attributes to the customer section or player group within the system. The flex attributes are virtually real in-line database extensions. We allow for new fields to be configured, added in, able to search, able to show-up, etc. These flex attributes are datatype specific (dates, times, strings, numbers, decimals) vs just plain text fields like the flex grid tie-ins. We eventually want to add these flex attributes to all 12 main system wide player groups (customers - already, invoices, quotes, parts and items, stock/units, elements of time - coming soon, I hope, employee/users, vendors, PO's, expense/receipts, deposits, and balance sheet items). One more thought on this topic of flex attributes. We may need some flex attributes on a global scale (able to cross time templates) and we may need time template specific flex attributes. We may want to do the global ones first, then limit or tighten things down for the time template specific flex attributes after the global flex attributes are added and stable.

- Horizontal grids - show time blocks with main categories or values going down the left and time across the top. We would love to allow for saving settings, allowing for special homepages, and custom buttons, just like my cart favorite buttons. See element of time 6967 for more info on horizontal grids. This is a form of blocking out times and who or what is scheduled, called for, or booked. Ideally, we want to be able to configure these horizontal and vertical time views, so that we could have and use more of them. That would be really cool. Once again, see element of time 6967 to get more details and information on horizontal grids. We used a custom horizontal time view for the Beaver Mountain Ski School. They have been using it for 5-6 years now. We would love to keep building off of that type of a model and make it even more configurable and savable without tons of custom code. Make it a tool for all of our users.

- Visual blocking of time... both horizontal and vertical blocking or showing bars or blocks of time. This is a visual way of showing what is booked and what is not booked or called for. Both directions, horizontal (side to side) and vertical (up and down). We need them both. We currently have the time slot view which is close to vertical blocking, but it still needs to be more bold and handle the blocking in a better way. The logic seems to be there, but it still needs a little visual help to really bock and virtually claim those slots or segments of time. It might be nice to ask for certain visual blocking right from the advanced time search - kinda like a report type. We already have a calendar view, time slot view, grouped view, and detailed view. Maybe add horizontal block view, and vertical block view. That would be cool.

- We would like to add in some dynamic dates. These special dates would allow reports to be saved with the dynamic dates vs a physical date range or custom fixed date rage. The dynamic dates would and could be things like: current day, current week, current month, current quarter, current year,  yesterday (prior day), last week, (prior week), last month (prior month), last quarter (prior quarter), last year (prior year), tomorrow (next day), next week (future week), next month (future month), next quarter (future quarter), next year (future year), etc. These would be really handy, so that saved reports could just pull relative info (based off of the current or today's date value), without having to worry about updating or flipping date ranges. Anyways, I think this will be awesome and we could use it all over the system on other reports and pages. Especially, wherever we are saving reports and pulling up saved data. These dynamic dates may make it super awesome and powerful.

- Be able to use the calendar view and calendar overlay for tons of new reports. Be able to save almost anything in an calendar type view. That would be awesome. Once again, the dynamic dates, mentioned above, would be really cool with this. Maybe even have an advanced search page that could save and filter the data and then show it on a calendar type report view. Great visual for what is happening on what day over time. We could call it the advanced calendar page or report. It would also be super cool if we could point subs of time to some sort of calendar type report or other visual time blocking type report. Currently, most of the subs only show up in detail view (normal tables with rows and columns). Being able to see the subs in other report formats (calendar, time slots, time blocking, horizontal, vertical, groups, etc.) would be sweet.

- On the template settings (techy stuff behind the scenes), currently, when adding and editing a main element of time, you have to pass in the template settings when adding or editing the main element of time. I would like to automate this process. It would make it easier for the developers. This is more of a behind the scenes switch on the methods and method calls. Most of those template settings don't change very often. We should have the methods themselves do the look-ups and make the changes (adds and updates to the fields on the elements of time table). This would really simplify the add and edit main elements of time processes.

- Being able to control the names and settings on the subs is going to be huge. This means what they are called (like sub dates and times, sub comments, sub sign-off's, sub flags and tags, sub payroll, etc.) and what fields they hold. Be able to change that on a per template basis. It also includes the sub fields and what they are called. For example: Say the default sub section is called "Sub Dates & Times". We may want to rename that "Amenities" or "Sub Bookings" or "Project Timecards". We could also control the field names with the sub section. Say the origianl or default field name is "Sub Title or Caption". Say you wanted to change it to "Extra Booking" or "Follow-up Reason" or "Sub Event" or whatever. Being able to change what the main things are called and also what the sub fields, within each sub of time are called and how they act. That will be a game changer. Here is a list of the current subs of time.

- On the working with time page, make the add/edit subs easier. Add in buttons to help with the add new process. The current way is just a simple link. It kind of gets hidden. Make it a little bit more bold and obvious.

- Some of these settings and concepts would be super cool for the fracture project. We really want to hide whatever we can, show what we need to, and allow for the whole thing to be dynamically (through data vs code) controlled and configured. That would be a super cool piece for fracture. See the above entries for some ideas.

- Futuristically, we would love to be able to switch elements of time between time templates. Currently, you get one time template and that is it. We don't allow an element of time to switch templates due to all of the background settings that are being held, monitored, and used.

- We may also need to add in some settings to deal with the general name for elements of time. That is very broad. Each time template can be named individually, but we have had clients that want it called the calendar, scheduling, etc. We may need some bigger corp-wide settings that control the main name and smaller abbreviations. For example: The defaults may be "Elements of Time" and "Time" for short. However, they could be set to Calendar, Lessons, Schedules, Reservations, Rentals, Bookings, Assignments, Tasks, To Do's, etc. The more that people can call it what they want, the less they end up fussing later on. That key piece of speaking their language is huge.

- It's not all code, some of this is just planning and dreaming

- It may be nice to use a spreadsheet to help with some of the planning. We have lots of rows, columns, and complex data that is needed for the planning portion.

- As a side note, it was so tempting to see a need, and then jump and try to fill that need. I on purpose spent some additional time (hours and hours), trying to get ideas and thoughts out of my head and on to paper (virtually) so that all of the pieces became public knowledge. My normal urge was to figure out a portion of it and then just do it vs writing all of these things down for the benefit of others (and myself).

///////

On 8/10/21 added some ideas for advanced job costing.

- Mini P&L per element of time. If we can tell that an invoice or expense or PO was tied to the element of time, have it automatically show up in a mini P&L (profit and loss) statement. This may be done with flex grid tie-ins right now (currently - but somewhat manual). We would love to automate it and build it into the mix. That would be really cool. Maybe do some searching for "job costing" to get other ideas.

///////

On 9/2/21 added some ideas from Chuck Swann

- Chuck read through these ideas and gave Brandon some feedback. Some of the ideas have been listed above with Chuck's name (search above). Here are some of the highlights - What about adding in some custom CSS (cascading style sheets) or custom display options? Maybe think about using a tabs based display for the advanced time search. The word or mode of "custom" may be better than "advanced" - technically, the advanced mode could be the custom mode, it just sounds better and more fitting to what we are really doing - dealing with time templates. Lots of the existing pages need an update to work better with the snow owl theme (style and face lift for pages). Make elements of time easier to use, in general.

///////

On 9/2/21 added ideas and projects from Cory

- Build out the online and customer facing scheduling options - this is a big project, all by itself. There are more details on other pages. We have a bike shuttle company that needs online scheduling (from ecommerce) and there are many others who are looking for this. Any business could use customer facing, online scheduling.

///////

On 8/21/23 added some ideas from a buddy - Josh Hanks

- On mileage. Maybe add a sub of a sub to do mileage. We may also need a standalone option (list way up higher using the general amount field) or adding it to a sub date and time entry. Not all entries would need mileage, thus a one to many off of the subs (sub off of sub dates and times). Imagine template settings under sub dates and times to say something like: Need mileage? If yes, do you want to enter a simple number (x number of miles) or use start/stop odometer readings (then we automate and do the math when submitted). Anyways, I had a great meeting with Josh Hanks on 8/21/23. He's a water master, ditches and irrigation stuff, he has a need for these things mixed together - projects, hours, notes, and mileage. The other benefits would be reports, exports, and math that is done for you. We may also add in photo galleries, document management stuff (media/content), etc. We have all of the pieces, we would just need to mix it together better and make it a small industry specific skin. Eventually, when we build out fracture or adilas lite, we want to include some industry specific skins as part of that project or platform (part of the value add-on core model). This may be a fun little venture into that world.

Meeting with Chuck. We haven't been able to meet the past few weeks due to training conferences, vacations, and crazy summer stuff. Chuck is wanting to get going on some new website status and analytics. I told him to coordinate it with Danny, Marisa, and John. He has the full go ahead other than coordinating with the others on the web site team.

We jumped into the presentation gallery project. Chuck is starting to code more of the pages in web code vs just being mock-ups inside of Adobe XD. We went over some questions that he had regarding certain pages, layouts, and content. It is fun to see it starting to come into real code vs just graphics.

We also talked about that we have a number of Adobe XD files from other R&D projects in the past few years. We are not going to be doing anything with those files right this minute, but we have tons of stuff dealing with fracture, click through mapping, and virtually what is in the closet. Tons of potential there. Brandon has the original XD files.

Chuck would like to get a few new Adi (blue adilas dog) images from the artist. We chatted and Chuck is going to follow-up with the rest of the web team on ideas and choices. The last topic of the day was other projects and reworking existing pages.

Lots of guys checking in. John M. checked in on his payroll project. Dustin was showing and talking about AJAX stuff on his new cultivation pages. AJAX stands for Asynchronous JavaScript and XML (asynchronous data going back and forth). The new AJAX stuff helps with quick loading of pages and data. Dustin was looking into an error  message from Metrc. Sean checked in on the SAR custom gun registration stuff. Steve was talking with the guys and checking in on server speeds and stats.

Steve and Dustin were talking about companies growing and dealing with load times and more and more data. Part of the game. Steve and Dustin were then talking about allowing the user to control what loads first, second, third, etc. This is part of what we want to do for fracture - allowing settings and presets to show what needs to load first, second, etc. Help the customers get their data quickly and in the correct order. What is your flow?

Meeting with Steve McNew and Steve Berkenkotter. Both Steve's were on for a bit. Then Steve Berkenkotter had to bail out and just Steve McNew and I chatted and went over some things together.

Here are some rough notes:

- Trying to push more on sales

- Ideas on prospecting with customers and doing demos

- We will need to keep building out the info graphics - a good image speaks a thousand words

- Refining the installation plans and deploying new clients - getting them going well and properly

- Steve Berkenkotter's top 3 on the tick list, as of right now - 1. Sales, 2. Work on earn and burn ratios, and 3. Servers (being able to split up databases - datasources and/or world building project - bus to motorcycles transition)

- Top 5 things from the conference that we just had from Steve McNew - see attached - 1. Helping Kelly with an installation plan, 2. Working with Sean on deployment processes, 3. Bug tracking and getting things tighter, 4. Communications and collaboration within our team, and 5. Projects and planning pieces (heading toward fracture).

Danny and some of the crew on the morning meeting this morning. There was a small sales theme going on in the meeting. Danny was commenting about sales and getting good communications between sales and the developers. The developers, me included, build and build, but don't let anybody know. Constant moving platform. Good communication is key. We talked about ways of improving those communication lines.

I ended up showing those on the meetings some of the Adobe XD files that I got from Jonathan Wells, just the other day. It was like Christmas. I was showing them stuff, zooming in, panning out, scrolling, drawing, and pitching some of the ideas and concepts for fracture, new shopping carts, and the adilas café. For the record, Brandon has a whole folder that has tons and tons of Adobe XD files that were done in 2019/2020 by Jonathan Wells. All of it was graphic R&D and research. Very much a little treasure box. Here is the file path (www_adilas/extras/jonathan_wells/xd_from_jonathan)

Marisa  was on the meeting this morning as well. She was getting excited to see some of the prototypes and mock-ups. We want to start harvesting some of those R&D projects. Lots of work and efforts have gone in there and some of the mock-ups look great and make us (and our clients) excited. As a small side note, we somewhat switched gears and talked about outside investors and seeking outside funding sources. I pointed them to a document that we made a couple of weeks/months ago that talked about some of our plans. We called it the questionnaire summary report from an internal questionnaire. Here is a link to the doc (pdf) - questionnaire summary. Light talk about investors and seeking funding. Danny, Marisa, Sean, and Steve were chiming in. Good meeting!

Chuck joined the meeting and gave me a report on what he is working on. He has done a great job. Here are a few of the things that he is working on.

- New live chat feature for our main website

- Changes to the adilas docs project. Added a new training page, videos, new components and code, and working on some new education mode or bigger dynamic show/hide tool tips. We want to use some of those education mode pieces as we transition over into the fracture project (future project or future release).

- He showed me some progress on the presentation gallery and some alternate layouts. See attached for some screenshots.

- We finished up by talking about the WordPress back-ups and some light direction there.

Steve and Cory were on for a bit talking about finances, plans, billing, and other options. After Cory left, Steve and talked about harnessing user clicks as a way to get things done. We keep coming back to that as a possible option for getting big migration tasks done without us (our internal team) doing all of the clicking and migration of the data. A way of harnessing what is already happening with small side tasks that need to be done. We've considered this and thought about this before. Somehow, we keep coming back to it. I'd love to see it get put into play.

Once Shannon and I got on our part of the meeting, we did a little bit of review and then split up to work on our own part of the info graphic harnessing project (picking up the pieces from years of doing the developer's notebook and other concepts and drawings). Shannon was doing some research. I was going through folders with screenshots for R&D on the adilas café and our future project called fracture. Going through screenshots from Jonathan Wells. As a side note, I made a small folder on my local box to pull the best shots into one place. Eventually, they will be part of the R&D photo gallery. Part of this page (we'll add a new section).

Great little work session - going over the questionnaire summaries and proofreading our responses. See attached for our progress. There was some mention of "Fracture" in the questions that we were working on today. We can't wait to get to that project.

Working with Shannon on vision statements and general goals for the next 1 year, 5 years, upto 10 years. See attached for our progress. Here is a list of some of our semi-short term goals that we will be adding to our business plan and vision plan:

Without going into too many details here are some elements that will be included in our plan:

- Keep tweaking on the transactional core

- Move client services more internal to Adilas 

- Expand into other verticals

- Allow for custom code where needed

- Get into aggregated and/or business intelligence (BI) type levels

- Grow the platform into an enterprise level app/system

- Along the way there are plans to do a full re-write under the code name “Fracture”

- Revamp the look and feel - improve user experience 

- Create and facilitate the Adilas Café and community

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

We also talked about using the key word "core" for different starting spots or base level options. This could be core transactional systems, core database columns or fields, core or main pieces. An example may be something like: Using the word or phase core values vs parent attributes, sub attributes, flex attributes, etc. Hopefully that makes sense.

Prepping things and doing some pioneering. All part of the game.

At the end of the meeting, I ended up pushing up some code for Danny and his custom labels.

Meeting with Craig and Steve to go over finances, bills, ideas, and direction. The meeting started out with just Craig and I. We went over a bunch of things and then Steve joined us later on. Craig brought a fun flavor to the meeting. Steve and I have hashed over some of these things so many times, we kinda get jaded or set in our ways. It was nice to have a fresh view and someone who would pose hard or uncomfortable questions. I really enjoyed the meeting.

All of the meeting notes are on Brandon's computer. Here is a small portion of them.

- We need to find the balance point - not running faster than we are able but still pushing it

- We have been spending some monies on certain projects - we really need to get a return. For example: Research on AWS (amazon), R&D for fracture, WanderWays, SEO

- Funding options -  The main 3 are: sales, borrow, investments

- Steve was saying, we have two main choices - steer towards deployment and fully funded projects - sell stuff or pull back and just do what we can - head back into smaller waters - slim down and tighter budgets. As a side note, we even talked about cause and effect if we were to actually gain from a small dip... lose some weight.

- Failure to launch - this is a problem if you never get off the launch pad.

- Picking our battles

- There is need for what we do

- Dealing with charging for our services - $65-100/hour

- Trying to sell a new car but it keeps having issues - makes it hard to sell - people are willing to pay more for certain products if they are reliable

- Fixing the servers - question: do we need more money or what to help make it better. On the positive side, people really use our products and they hit it hard, we really push the servers that we have. It's not like nobody uses it, the opposite is true - people throw everything that they have at them... we still need more.

- Maybe stop development - we need to sell things - harder done than said... - try to switch gears - cross training - maybe change the word or phase sales into networking... connecting the dots - get some more hunters out in the field - swap people around - focus on the deployment and setup process - focus on funded projects - on the dev side

- Being able to say "STOP"

- Learning when to put our foot down - limits and levels

- Selling the current 2021 model

- Switch who we are targeting - trailer dealers, bowling pro shops, etc. - sell what we have to offer

- It's just a $100/hour - managing expectations - sometime people want a perfect number or a nicely wrapped quote or project cost. It's just $100/hour. Otherwise, we lose our shorts.

- We get pulled off on tons of outside distractions - external distractions, custom projects, and outside 3rd party solutions

- The code is splitting - new school, old school, high tech, low tech, etc. scripts, tags, functions, includes, different styles

- Having a real game plan - we really need this - a full plan and then let everybody know about it

- Fracture is a real word - a life style - part of where we live and breath - keep heading in that direction. As far as we can see, things will keep fracturing. Plan on it and build accordingly.

- Like race car driving - we need a good driver, but maybe not the best driver, especially with an attitude, they may need to go

- You can always fill a spot... (even in management) - like a bucket of water, if you put your hand in, then pull it out, it will fill back in - finding that range that fits

- There are multiple battles - in front of us

- Using a talent scout, like my dad - maybe look around at the college (talent just getting out of school) or for people who have the skills - draft

- Find and gather up the low hanging fruit

Great little session on the look and feel and where we are headed. See attached. Also, here is a small copy of the verbage for the summary we did today.

-- from the attached file under a question about the look and feel and user interface.

Summary: When we started Adilas we decided that we wanted to get functionality done first, followed by look and feel. We know it is time to bring that pretty, modern look and feel into play. Some of these aspects are already being approached and more are on the horizon. 

We have chosen to let the clients lead with their ideas, suggestions, priorities, and funding. This has directed our development and our growth thus far. We recognize that many people would like us to just spend the money and make everything pretty, but then you still may not make the goal or hit the mark, which is continually changing. We feel it is important to keep following the client's lead and this will still be our main approach. 

Having said that, we are definitely planning on extending more services, continuing to evolve and refine the interface, and keep following what is working. This will include getting a master plan in place. Many people have heard us talk about this concept called "fracture" - which is a name for a future project which will be a configurable, dynamic interface that will only turn on whatever pieces you want to see. Fracture will include countless ideas, lessons learned thus far, ways to improve efficiency, and breaking things into smaller modules and pieces. This will include more efficient navigation, dashboards, and user friendly features. 

It's beyond the scope of this summary to fully explain here but this will be incredibly powerful to be able to configure Adilas to whatever level of complexity or simplicity you want. This is like an iceberg mountain analogy. You still have the whole mountain but you only expose what you want to see - just the iceberg portion on top. It can make it feel easier, simpler, and more manageable. 

The current model is composed of numerous, smaller prototypes that have been linked and wired together. Our eventual goal with fracture is to make all of those prototypes have the same look, feel, and flavor. This will be selecting the best of class from over the years and standardizing it across the platform/system.

Even though we are talking about look and feel, taking a team approach, helps us move forward in every aspect of furthering the application and model. People who work together are able to achieve more and that is how we are trending and changing our operations even further. More good stuff to come.

If you type the word "fracture" into the developer's notebook you will begin to see how big our plans and dreams are for what we want to accomplish when we build to this "fracture" plan.

Wayne and I started working on the WordPress stuff and getting the adilas news and updates section tested and deployed. All was going well and we pushed up some new code. For about half an hour, no problems... all of the sudden, we had alarms going off right and left. We had flooded the new WordPress server and it was totally maxed out. We quickly tried to remove the WordPress API socket connections to restore our servers. We don't know if it was just our own traffic or if it was under attack, but we buried that poor server. We got things recovered as quickly as possible. We are going to build in some better error handling and enforce better timeouts and number of attempts. Crazy stuff.

On a totally different note, while everything was going good and smooth... Wayne was showing Steve and others some of the home automation and fun things that he (Wayne) does when he is not working for adilas. Some really fun stuff.

As part of Wayne's demo and virtual show and tell, they were talking about 3D layouts, gaming, 3D printers, house plans, electrical circuits, etc. As they were talking, I was having this fun vision of using adilas to virtually layout and organize a business... just like a 3D layout program or a circuit schematic, what if you could layout out your business or business flow in such a fun visual manner... this talks to this, that flows over to that, these processes get done here, and these things get connected with these other things (very general but image real instruction and flow processes). I think it would be so cool if eventually, you could virtually setup a business to help map, layout, and illustrate the full flow of data and processes. It would be so cool to virtually watch as each piece of data went through the process. You could see the data, you could tweak and change it, you could correct it, you could approve it, you could allow it to move on, recycle, add options, or whatever. Think how cool that would be... almost a 3D virtual game (data assembly line) for the game of business.

That concept of a virtual game type layout and interface may be fun and could be part of the fracture project (future version of adilas). Build your own mock-up, build your own interface, custom configure just what you want and need, tailored to your business. See above.

Going over projects and progress. Cory, Steve, and I all working together. Cory schedules these meetings and runs things past Steve and I. We bounce around a lot but get things going. Kinda fun.

One of the topics up for discussion today was a client that wanted a complete copy or clone of their entire production (live) environment. We talked about logistics of what would be needed, expected, and how to do and service those requests.

We also talked a lot about moving into aggregated totals and aggregated data (sums, averages, counts, totals, and stats). Some times these bigger projects need a plan, seed monies, and then time and resources pushed at them to really make them work. Along those same lines, we spent a good portion of our meeting today talking about what is needed to help these projects get off the ground. We talked about some basics for aggregated data and data warehousing such as - ETL - Extract, Transform, and Load - dealing with processes to work with large amounts of data. The extract option means get the raw data from the transactional database. The transform means take that data and change it or manipulate it into what you want it to be. You then load it or store it in it's transformed state. This helps make it faster for the next stage and you can get at the info quicker. This whole process is coming into play and will be part of where we are headed. We will for sure need it for our future fracture project. Good stuff.

Our plan is start with sales and inventory tracking. We will then get into aggregated data for the other main player groups (all twelve - expense/receipts, deposits, invoice, quotes, stock/units, inventory/parts, elements of time, customers, vendors, users, balance sheet items, and PO's). Some examples of where we are going are taking transactions or transactional data and going up to daily records and sums, weekly records, monthly records, quarterly records, and even annual records. All of these time based tables would get and hold sums, totals, and counts from the transactional data. It is almost like a reverse pyramid with transactional data on the bottom, then up to daily, weekly, monthly, quarterly, and annually. This starts getting into data warehousing and doing the basics of extracting, transforming, and loading into the data warehouse the data that we want. Almost the business intelligence level (BI) once you can display it in consumable manner. We will keep heading in that direction.