Talking about creating a smaller sub theme in adilas and called it "fracture". This would end up being an adilas fracture account. We would like to rebuild things from the virtual ground up and add in all of the subs of subs and database field level control. This would be a full on internal white label and/or internal theme that goes down to the micro level. This deals with database field names, settings, permissions, and all of the sub settings and sub permissions that are needed. It could also deal and use smaller getters and setters as well as individual databases, custom API access levels, etc.

This is kind of a dream, but it would be so cool if we took the time to virtually rebuild the entire thing from the ground up and use and apply all of the ideas and lessons that we have learned getting to this point. That would be really exciting. It would really be cool if we had the money, funding, plan, and people and talent assets ready to play the game as well. That would be a huge but awesome project. Just an idea and/or a dream at this point in the game.

Talking about scalability and how to manage up and down swings without shooting ourselves in the foot. We were talking about load balancing and monitoring usage, storage, and bandwidth.

We have been seeing some light push back on price from the consultants. Basically, they are charging a certain amount and then promising that our services are and/or will be a certain rate for life.

We are also seeing that some of our clients are growing as they come on to our systems. That is hard to know what is going to happen when they first start up.

Technology keeps changing and pushing things forward. This is a crazy world and we need to build on the dynamic changing environments that happen all the time. This is not a static model.

Traditionally, software companies build versions and then release that version. They then build in the background and make the next version and then plan the release of the next version. Our model is literally build and deploy on a daily, weekly basis. Alan was saying that our clients are paying for what the current adilas system does and can do... they are not paying for the future developments. However, some of the client demands are almost all speed, bulk, and future related.

Tons of cause and effect relationships, pros and cons, and maintenance things... lots of talk about concepts, styles, and preferences.

After our discussions, we all went back and worked on our own projects. I was working on adding in the customer type id filter for sales tax reports and advanced invoice searches. Steve and Dustin were working on Metrc API pieces and bulk QR code labels. We also had both Wayne, Alan, and Calvin pop in and help with different questions and projects. Busy work section. Also some light phone calls and tech support stuff.

Checking in on the morning meeting. I have been out of the office most of the week. Steve and I chatted this morning about the need for new independent developers and getting people into the mix and into the family. There is a real need there. We then merged in some code from his branches and pushed up files to all servers.

Looking over ideas for loyalty points. Lots of good info on element of time # 3778 in the adilas shop.

What is a liability? What are the differences between real and phantom values? We need the values recorded for both real and phantom, the difference is how firm and/or fixed the liability is. Steve mentioned a term called a "shadow account" (that exists, but may not be fully tangible). We also talked about how it is the actual company that is creating these phantom and/or shadow type liabilities. That kinda changes things... it is the company creating their own liability based off of a point system to encourage customer loyalty.

There seems to be two main part of the puzzle. How many points (ins and outs) and what is the value of those points? Lots of balance sheet transactions.

Simple to more complex transactions... simple gift cards or simple gift certificates, basic loyalty points, punch cards, in-store credits, coupons. As a fun side note, some of these transactions are subs of the balance sheet. Kinda like sub inventory but on the balance sheet side. Maybe we need to think about how the transaction takes place. Is there already cash on hand (paid in advance)? or is it just lowering the total owed, like a form of a discount? Who pays for what? What about coupons that a manufacture pays for or pays a part of?

On the main balance sheet items, we may need another switch to help us know if this is a main account and/or a sub account. We may also need to know if the asset, liability, and/or equity account is real or phantom (shadow). This is kinda fun, but we are seeing a fracture that is needed in order to record the balance sheet items. Everything is breaking into sub accounts.

Going back to discounts and special discounts... do we apply the discount to the cart/invoice on a whole or do we have to re-distribute that discount back through the system?

On a different note, we had a request from a client to be able to permission and/or fully turn off standalone discounts. Also, we are seeing that taxes make the discounts more complicated. We have options to do both in-line discounts and/or standalone discounts. Things get really fuzzy as you try to tax, especially with excise taxes and taxing things at the different levels (per item category, per customer type, per inventory type, etc.).

We had a great talk about "bad debt" payments. Don't worry about the words (verbage), think about the concept. That helps to satisfy the invoice (monies owed to us), the taxes are fully correct,  but it is then showed as an adjustment to revenue (rewards, coupons, loyalty points, etc.) on the income statement. Both coupons and loyalty points are similar. It is the internal company basically saying "I'm going to cover that part of the invoice". We claim that that invoice and/or ticket is x dollars and has y amounts of tax. We then cover the invoice by real monies and/or monies that mean something, but no real money changed hands. Look deeper in this. The main difference is the verbage between bad debt vs rewards or loyalty points.

Maybe we should add some new standard payment types such as: Rewards, Loyalty Points, Coupon, In-Store Credit, Gift Card/Gift Certificate, etc.

We are seeing the need for a good mix of user-maintained pieces, system-maintained pieces, and possibly some mixed-maintained pieces (user and system). We are seeing this in the watchers, feeders, standalone declarations, time templates, settings, etc. We need to let them play where they can and need to, but also make sure they have the tools and pieces to get the job done, even if we control the pieces behind the scenes.

Eric would like to check in on loyalty points around 11 am for a couple of hours. He texted me and said that he was unable to meet today due to some things that came up. So, in the meantime, Steve and I had a great discussion and made some good breakthroughs. Good stuff.

9009 E Arapahoe Road, Greenwood Village, CO 80112
Phone: (303) 799-4555

See attached for notes, scans, files, and GoToMeeting recordings (videos)

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

Day 1

We did some intros and then got started. Danny Shuford did a demo and did a great job. See attached for some notes. Here are a couple of the highlights from what I took away from it.

- Solution for solution minded people

- It can be molded to fit your industry

- Changes keep happening

- Big open view of the whole system - it wasn't made for just one industry

- Brief overview of the framework

- Based on user permissions and valid logins

- All web-based and cloud-based

- Features and benefits - focusing on the benefits

- CRM - log notes, additional contacts, photos, and other media

- We all deal with money, but in the end... we are all dealing with people

- Note to me... Danny went into the customer table and doing the custom page settings on the customer fields. This is for things like the name, aliases, sort value, show/hide, etc. We really need to keep pushing that idea and concept forward. People really want that level of control. It just takes a ton of work to cascade that through the full system.

- He talked about news and updates

- "Our Interface" - what do you want? We don't have a single set interface, we let you choose

- Customer queue

- Lots of moving parts

- Drea - "Adilas is play dough"

- Inventory tracking

- Reporting and building your own reports

- Labels and changes to the requirements

- ecommerce

- Payroll

- Accounts payable and accounts receivable

- Print checks

- emails

- Customize and working with the developers

- Security and back-ups

- Steve - Showing some hidden gems

- Small demo on flex grid

Next, I gave a small section on the adilas model - core concepts - and intro to world building. I will upload my outline. I'm also hoping to upload the video as well. I don't have any notes because I was the presenter, but here is my rough outline:

- We will be bouncing around

- Start with a guy holding tons of stuff

- Talk about the needs and how to organize things

- Go over different tools... head and mind, paper and pencil, word processing, spreadsheets, databases, software packages, web or hosted solutions

- Go over systems and how things start to inter-relate

- Cover the 12 main players

- Cover the 12 business functions

- Cover the 12 main world building concepts

- Mix and blend to get the desired results

After lunch, Alan Williams did a presentation on highlighting and exploring new features. He started out with a fun group activity and a game of sorts. Minimal communication and we had to figure out a path through a virtual mine (bomb) field. It ended up having forward steps, side steps, back steps, etc. We eventually, as a group, got through the mine field. Really fun exercise and it opened up some conversations. Here are some notes from Alan's presentation:

- Little active - mine field - group activity - finding their way

- How does this relate to the adilas process?

- He then showed some of the steps that we have taken to build the application

- Side steps, back steps, and forward steps

- Going into advanced add to cart and sub functions

- Request from the group - no standalone discounts - Make that a permission and/or a setting. Standalone discounts can and do cause tax problems.

Next, Steve Berkenkotter lead an open Q & A section. The first question was asking about any updates with the Metrc (state compliance and tracking system for Colorado). That got pretty deep but exposed some of the challenges that exist between connecting and maintaining dual systems (adilas and Metrc). Here are a few notes:

- Questions on Metrc

- Some new tables and new limits from Metrc

- Auto processors - running nightly stuff to help sync data between systems

- API and server to server connections

- Challenges that exist

- Mixing old and new functionality

- Transfers

- Sales

- Using elements of time to track states, status, phases, and groupings

- Getting back at the data - reporting

- High level vision

- Question from Pat - 280E - new tax and accounting rules - what can we write off as cost of goods? What about unitizing expenses?

- Steve - How the IRS is looking at things and expecting things

- Steve - loves numbers and how he brings his skills to the table

- Work in progress - attributing a value as part of the accounting

- The progression of building and breaking

- The system is able to store the data (huge piece of the puzzle)

- The system may be customized to get the data back out and/or to get the data in (another huge piece of the puzzle)

- Template building

- A consultant spending time and configuring a system before it is released to the end users

- Small questions on CSS and changing certain page colors

The last section of the day was a presentation on historical stepping stones - what have we learned and why do we do what we do? I did this presentation so I will add my outline. Once again, we are hoping to get some videos uploaded to this element of time incase someone wants to watch the videos. Here was my outline:

- Where did we start? Spreadsheets, static web sites, zip disks and sending inventory around from place to place

- Fixing current business problems

- Where is your pain? Start there

- Letting operations lead - Use the adilas interactive map to help show flow

- At some point, accounting will need to follow

- Checkpoints and flowing data

- Gap between operations and accounting - drawing the gap, horses and carts, and old school T accounts - light history of accounting

- How does time play into the mix

- Comparing operations and accounting in a static environment

- Comparing operations and accounting in a dynamic environment

- Progression - drawings of the data assembly line and how it ended up at a 3D data assembly line

- 3D world building - x=time, y=resources, z=space or depth - draw out the box or cube

- Black boxes & white label options

- The whole deal

We didn't quite make it all the way through the whole outline, but we covered a good portion of it. Towards the end, we went around the room and got some feedback. Those documents and notes will also be uploaded. The final request from the class was to have adilas allow the "adilas version" spreadsheet to be shared with the world. It was originally created in order to get a bank loan, but Steve said to release it to the world. Great meeting and good energy on day 1. Good stuff.

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

Day 2

We spent most of the day working on and going over inventory tracking and point of sale (POS) features. See the attached videos. We also had some great demos from Calvin Chipman on building custom labels and one from Dustin Siegel on some new code and features that help with plant phases and cultivation. Here are a couple of notes from some of their presentations. For a more complete version, you may need to watch some of the videos from day 2.

- Calvin and the adilas label wizard - He gave a slide show and then started to interact with the label builder. After he was done, we asked him to show some of the behind the scenes pieces of his label builder. Good stuff.

- Vaporware - the product doesn't fully exist (yet) - part concept, part actual, not yet fully functional

- User designs the label (step 1)

- User selects the label from inside of adilas (step 2)

- The label(s) are created and displayed on the fly, based on stored instructions, mappings, and special code. (step 3)

- Part of the demo was showing sheet labels with a data merge, labels with barcodes and QR codes, static text, dynamic text (user can interact and change things), data mappings, graphics, etc. Pretty cool.

- Small talk about PDF's, Flash, & HTML and CSS - printing options from the web - Our choice is PDF currently

- Interacting with printers, browsers, and other hardware pieces

- PDF - actual size vs shrink to fit size

- Questions about font point size and possible limitations for compliance reasons - We will leave that up to the users, that way we don't have to chase all of the compliance rules and regulations.

- We talked about settings and maybe limits that could be stored and looked up on the fly.

- Possible template options

- Be careful saying a compliant label

- A good disclaimer to keep things legal according to the local and/or state requirements - put the liability back on the companies and/or users.

- Small story of a company and internal programming wars and war stories - Different places that Calvin has worked.

- It may take a hybrid solution of both software and web

- Small demo of the actual builder - Calvin is going to be taking that and putting it more into a wizard-type format. Currently, you have to be pretty techy to use it. Round 1 - prototype.

Dustin gave a presentation on some new cultivation processes and some dynamic mapping. We had some technology issues, the demo was going slow (Internet) but the concepts were awesome. Imagine going from a manual one-by-one process, to a bulk streamlined process. Huge time saver, plus tons more data points, capturing the whole story clear down to minutes, seconds, locations, phases, etc. Pretty cool.

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

Day 3

Busy day today. We got into sub inventory, why we do sub inventory, customer relationships, elements of time, flex grid, ecommerce, custom emails, group mass texting (GMext Pro), and a presentation by Kelly Whyman (super power user from the Denver area). We are going to be posting the videos and the notes from the day. Good sessions. Here are some of the notes that I took while others were presenting. Once again, see the attached media/content files for videos and other digital notes.

These are some notes from Shari O.'s presentation on CRM functionality

- CRM - The real acronym stands for Customer Relationship Management - Shari O.'s acronym for CRM is - Can't Remember Much - pretty funny

- Good data in = good data out - Fill things out completely and make sure you get good data in

- The client log and how to use it

- Leaving personal footprints in the sand - using the log

- Addin gin a user-maintained history... internal communication

- Cover you own rear-end

- Being business appropriate - have good manners when recording details and data points

- Custom emails

Drea did a demo on how to show/hide transfer packages inside of the adilas/Metrc inventory pages. Here are some notes from that:

- Transfers in and out and how to hide things

- Everything in adilas is flexible

- This new functionality is only a week old

- Talking about manual clean-up and automatic clean-up - doing side-by-side comparisons

- Using the data tables and being able to sort and search data - almost on the fly - re-writing the page based on the data.

- Some of the new CSS cards, tabs, and such - really look super cool and it seems more intuitive - it also makes it look more modern.

- We would love to keep adding new data tables and more options

- As we keep going, we may need more clean-up options

Calvin game a PowerPoint presentation on GMext Pro - This is his group mass texting solution. He did a great job and I think that people really liked it. Here a few notes that I wrote down.

- Pretend like you are a client

- Communicating to a large group or large groups (plural)

- Pitching GMext Pro - great demo and presentation

- Some of the stories of huge companies and how changes have happened and how those big companies weren't able to keep up. WordPerfect and Blockbuster were some of them. Major game changers entered the market and could do things better, faster, and cheaper. People gravitated to those new options.

- Technology happens... embrace it and thrive

- Mass texting and single text notifications - similarities and differences

- Phones and phone numbers - with mass texting, you are basically buying phone numbers so that you can send more texts at a time. Each phone number can only send 1 text per second. So you may need 5, 10, 15, 20, 25 phone numbers to get all of your texts sent out.

- Problems with people giving out the wrong phone numbers (bogus numbers or wrong numbers) - that can break your marketing campaigns - too many wrong numbers and you get reported as a spammer.

- Ways of opting in and out

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

Day 4

Final day of training for this go around. We started out day 4 with a group session on tips, tricks, and best practices. We spent quite a bit of time going over settings, permissions, and parent attributes for items. Steve then did a whole session on the three main parts of the balance sheet (assets, liabilities, and equity). The topic was intro to adilas backend office and functions. Steve took the words backend office and tried to flip it to - let's put the owners in the driver seat vs trying to drive from the back of the plane (pretend they are trying to fly the plane from back in the bathroom with the doors closed). Great session.

The afternoon session was talking about BI - Business Intelligence & Big Data. The group talked about databases, data, and how to both get data in and out of the databases. Lots of fun examples. We then has some other Denver power users jump in and do demos on tiered pricing and smart group buttons, and another one on the process of doing a full inventory reconciliation and full inventory count. Great info and good sessions.

The final session was supposed to be on the adilas model - vision, future, and wrap-up. We were all too tired, so we just chatted and went over a bunch of the things that we learned from the training session. We got some great notes and tried to clarify a few items, topics, and concepts. Pretty casual ending. Great people, wonderful ideas, excellent participation, and memories made. A great training session. Here are some of the notes that were taken while others were presenting:

- Molly presented on parent attributes for items - think of tag or ways to categorize things

- On parent attributes - for example: say you have an item but want to show different brand names or characteristics - Say you are selling shoes... You may want Nike, Converse, Adidas, etc. Or running, walking, hiking, trail running, etc. These would be good parent attributes or tags.

- Parent attributes are huge for ecommerce searching and creating tags for different items

- Russell did a great job on so many different features - we would love him to keep building more features

- Easy setup

- Building your own little shortcuts

- Parent attributes are used for labels, sales, ecommerce, searching, filtering, etc.

- Treat parent attributes like a way to build your own database... eight use the flex grid and the custom fields or use parent and sub attributes.

- Both parent and sub attributes are unlimited and they have a proper data type such numeric, dates, text, toggles, and drop-down lists. That really helps when putting data in and also when querying the data to get certain results back.

- As an idea... what if we build out both parent attributes and sub attributes to all 12 main player groups, inside of adilas. You literally could build your own one-to-many database relationships. The main 12 player groups are deposits, invoices, users, vendors, customers, stock/units, expense/receipts, balance sheet items, elements of time, quotes, PO's, and general inventory items. Currently, parent attributes and sub attributes are only available for parts or general inventory items. Think how cool that would be if we pushed it to the next level...

///////////

- Small note from a meeting during one of the breaks... what is the internal adilas funnel to report an error or a bug? Who gets put on that project? We need to figure out our own process and communication funnel.

- Bryan and Molly and others... funding some of the consultant projects - what is the short list and then where are things at. Basically, what do we have to work on and what are the priorities of those pieces?

- Shannon may be part of this funnel that we are trying to build out

//////////

Back to the main training even... The next session was Steve Berkenkotter and Shari Olin - going over financials and adilas backend office functions. Steve pretty much ran with this subject and did an hour long power session on the three main parts of the balance sheet (assets, liabilities, and equity).

- CPA homepage interface

- Inspecting what we expect - you have got to look at what is being delivered as a final product (actual items and/or tasks or services)

- Going back to the beginning - balance sheet homepage

- When you get a new system, we setup a default bank and default location

- Problem with batching... Say trying to remember 30 days back and/or not getting data and information for a long period of time. It kinda leaves you guessing and/or missing some of the details

- Steve - Think of flying a plain... try to be ahead of the plane... where is it going - often pilots try to think 3 tasks ahead of what they are doing

- Views of the balance sheet - a trial balance - working and checking mode

- Assets, liabilities, and equity

- We covered the difference between the income statement (P&L - profit and loss statement) & the balance sheet

- Values and tax laws

- Depreciation and schedules

- Life cycle - length of the life of an object and/or an entity - time and a schedule to lower a value (usage & wear & tear)

- The IRS has setup the tax game... They want you to play and even play up to the lines that have been setup - think of a game - play to the line

- Where you put things in very important

- Small discussion on double entry accounting - history and pros and cons

- Skate to where the puck (hockey) will be

- The formula is the most important part of it

- Passing things like a hot potato... basically moving things along the data assembly line - roll call accounting

- A balance sheet is a snap shot in time

- Talking about the profit margin and where does that come in to play

- Small holes in the ice - things that are either gotcha's or thin ice (not all the way done)

- Some of the guys and gals were saying that we need - big dumb animal pictures - super simple instructions

- Accounts receivables - Think of that as they have your inventory or they have your endeavor (a promise to pay for something) - basically, they owe you money

- You have to know the story - sometimes the numbers tell the story but sometimes the story tells the numbers what they mean

- Liabilities and hidden liabilities - be careful there

- Hidden costs

- Triggers

- Payroll and payroll taxes - this is a huge sink hole

- Sometimes we can't do things due to the technology - as that opens up, we have more options

- Auto processing and calculating needed values in non-peak times that could then be available for other reports

- Fall backs, redundancy, auto-syncs, and re-syncs

- Turtle up, sometimes the servers will shut down and pull in their legs - kinda like a turtle protecting itself

- We need an all encompassing system to help steer the ship - think platform or system

- Owners - who holds the liability

- Steve - analogy of the tail wagging the dog vs the dog wagging the tail - who is in charge & which way do things flow?

- The owner needs someone who is a decision maker and/or gate keeper

- What is the game plan and do you have buy in?

- The POS (point of sales and inventory tracking part) is only a small part of the puzzle. Very small compared to the whole business realm (world).

- Abundant model - you have to imagine a line of people wanting your services and standing in line - next, next, next

- The backend - really, this is the pilot's cockpit and/or the driver's seat

- Absorption (in take) model & attributing sub costs over time

- Dustin - I want "this" (meaning adilas & underlying data) to argue with my boss, not me.

- I need a business tool & now I can run faster & better - thank you

- Equity

- Net Profit - it comes from the P&L - one of the only connections between the income statements (P&L) and the balance sheet.

- Investment - how was this company funded and/or formed?

- Fracture - just having fun - it keeps doing it (fracturing) on its own... maybe let it keep going and play accordingly

- Change "backend office" verbage to the cockpit or balance sheet.

Towards the end of the day on day 4, we had a couple of power users show some demos and such. We had Josh do a presentation on my cart favorites and smart group buttons (tiered pricing). Drea made a suggestion that you make the pricing tiers as dummy proof as possible. They even pushed the ending values clear out to show a visual warning to the person using the buttons. The other major request was for this feature (buttons and tiered pricing) was dealing with allowing these buttons to be time sensitive for sales and promotions.

We also had Drea go through and show an inventory update and how she does a physical count and then an inventory clean-up. She would pull reports, export data, show/hide columns, add columns, print things out, and have her people go work. Then she showed how the system would take those over and short values and push them through an update PO (internal tool for updating inventory counts). Pretty cool. As we go along, we will need more clean-up tools.  Clean-up tools make things look better and help to give users a peace of mind. We also talked about trust issues and how sometimes it is tough to trust and/or trust people. All of that plays into the mix.

My final note about the training sessions is that those who played with us, live and online, really had a good time and we all learned a lot. Good times, great food, and wonderful people. Inspiring sessions. If you want more details, check out the media/content pieces (notes, excel docs, scans, and videos for more info).

Alan and I had a small meeting after hours in our hotel room. The general topic was were are going and how are we going to get there. This is mostly ideas... but some of it is real and may come in to play as we go down the road.

- Alan noticed that there are special headers in the old AFB settings pages. We may need to swap those out. These are the snow owl theme settings page, the ecommerce settings page, and the custom email settings page.

- We might need a new level between black box (custom), bulk black box (them), and the classic. Sometimes we need an option but we don't really want to go to a black box per corp - Kinda like the shopping cart view... we have multiple options to choose from and that is tied to the personal settings.

- Maybe hire a designer to help with CSS and user interface stuff

- What about an adilas fracture account

- Are we in the race, out of the race, or working on something else?

- Where is the puck going to be?

- What are our goals?

- What are our defined roles & how does that play out? Currently, things are pretty loose and multiple people play through the different roles.

- Who is going to do custom?

- Goals and roles - those are big subjects.

- We really want to get back to the custom database fields (show/hide, sort, name, alias, require, custom instructions) like we did for customers.

- We really want to do a similar things with the reports. Imagine a way to select what fields show up, what order, what base or starting filters or criteria, pagination defaults, etc. That would be really cool. We already have some of that in the save your own reports pages, but it would be cool to make that happen on a page setting level. Basically, here is what is available, what would you like to see and how would you like to see it? Great idea.

- Just a thought... what if we stopped custom coding for a while? It sure would be nice to be able to use all hands on deck for certain internal projects. As a side note, custom code has become part of our model.

- Maybe try teams

- There will be growing pains

- The view cart page mixes black box technology and corp-wide settings and personal settings. We may end up with more hybrid type options like that.

- In general... we have really taken on a lot... people want us to keep building both out and up... question for us, is the core strong enough to support that?

- What would it take to stabilize certain parts of adilas? Some of the pieces haven't been touched in years and very stable. Other parts still have virtual wet paint and are still changing. The goal is to get some of those morphing pieces to become more stabilized and steady.

- Education and maintenance may be more important than new features

- Some of the reps are getting sick of training the same things over and over again

- Go through the whole system and black boxing pages and adding icon menus

- What if we went back to the web_page_id. That field was originally designed to be a page specific id number. We could then tie-in in help files, videos, page level settings, etc. Every page in the system would have its own id number.

- Working in strategic teams. Say teams of 3 like Alan, Wayne, and Brandon. Or Bryan, Wayne, and Alan. You get the idea.

- Balances...moving balances - We have seen problems with planning too much and planning too little - there needs to be a balance.

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

Fast forward to the next morning... Friday, 9/14/18

- Just keep going and don't do anything crazy - let it keep cooking and growing.

- Maybe have a contest to see where we are going and what ideas we have.

Need to take tri-storming approach. Taking smaller steps toward larger vision. More success with taking smaller steps instead of the A-Z approach.

https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=fracture this is the future to do list

Currently, the adilas.biz master plan is held in the minds of a few of its founders. It has never been fully funded and written out. We think that would be a great project and could help our existing users, current clients, and even future clients. It would also possibly allow us to get more funding if there was a firm and written plan of what is needed, in the works, and where we are headed.

As of right now, the only written business plan is very general - such as: "We are heading North" (meaning up :))

Random notes from the day. Brian Stewart is a friend and 30+ year computer guy and programmer. He works for a different company but we go walking and hiking together in the mornings. We talk business and code while we walk. Here are a couple of gems from today.

- There is a difference between working in your business or working on your business - Brian Stewart on a morning hike.

- Create systems... Instead of setting pass/fail goals... create a small system and then start playing the game. Success is playing the game and working the system. The results will usually end up following. - Brian Stewart on a morning hike.

- Brian and I spent quite a bit of time talking about good cop, bad cop, and helping to setup the community and environment that you want for your company. A lot of the discussion was dealing with finding that balance point between speed, function, stability, and beauty. Not everybody has the same personality and/or skill sets. Lots of mixing and blending. Some of the conversation was how to mix senior developers and junior developers and to help them play well together. Sometimes that mixing becomes an issue and also a who gets credit for what and who gets paid for what. Sometimes a tough mix.

On the morning meeting with Steve, Dustin, Alan, and Josh. We started out and got things going. Dustin is going on a trip soon and was reporting about some areas in the North East that he will be visiting. Sounds fun. Here are some other things that happened on the meeting.

- Helping Dustin with some FORM logic. He has a ton of form field data that needs to be dynamic, grouped, and passed over to an action page and still be able to maintain its complex data format and maintain its special groupings. We went through a number of scenarios and he took a number of screen shots. We talked strategy and I showed him some similar code that is used for duplicating PO's and passing dynamic data from page to page.

- Talking with Alan about the idea of on purpose allowing the view of the pages to fracture and be more controllable. We did a small graphic (drawing) and talked about how we have known form field values. We also have a known database table that could hold the data field settings such as show/hide, defaults, data types, special instructions, sort values, field name aliases, etc. We then talked about how we could potentially use ColdFusion custom tags to hold the logic to dynamically populate and/or build the HTML (web format) pages based on the custom tags. The custom tags are a combo between a function and an include. Anyways, we had a good discussion on that. Alan was saying that this plays in perfectly to the MVC (model view controller) type scenario that we would like to use. See attached for a small drawing.

- We had two other outside parties come into the meeting. We had Molly (an adilas consultant) and a guy by the name of Ryan McCorvey (a user for McCorvey's Pro Shop - Bowling). They both had similar requests. They have different pages and reports (or functions) that are hitting time outs. Both companies have tons of data and Alan and I were taking notes and looking for possible bottlenecks and either slow queries and/or slow database tables. They could do the same reports and actions with small amounts of data, the system just choked and/or timed out when trying to process too much data. Kinda like getting a huge mouth full and not being able to chew and/or swallow. Anyways, we worked with both individuals and took some notes. Alan started looking into some research on what causes those table level slow-downs and what not.

- As we get into bigger and bigger datasets, we have to play well with scalability, indexing, and being able to play the big data game. Interesting how things keep progressing.

On the morning meeting with Steve. As we were going through emails, we had more requests for custom homepages and even some users wanting to go back to the classic invoice homepage vs the newer graphical invoice homepage. We then started talking about all of the different levels of custom...

We went into corp-wide settings, group settings (12 main player groups), page level settings (page control - how does it look and what does it contains and how does it work), and clear down to personal settings.  That got us into a small talk and conversation about an adilas "fracture" account. This is a concept of breaking everything down into mini pieces that could be stringed and/or put together in any combination. This could include pre-sets, pre-built options, special skinning, etc. It could also get into real in-line database extensions, themes, core black box options, etc.

What we are really selling is... We have tons of things pre-built and have a viable solution that has tons of functionality. This is ready and out of the box. We then offer people the chance to build their own application and virtually extend the functionality to what they really want. Basically, Steve was talking on a sales level, and was thinking about having a number of checkboxes... when meeting with a company, you could virtually check the boxes of what we have, we could also allow them to then pick and choose what they want to add on. Basically, we, as adilas, could tweak out our own product and create all kind of custom wire jobs.

We need to apply our own client filters and see who wants to play. We don't want to get over our heads, but we have a great number of guys who can do and handle certain pieces. We have a solution that is usable, right out of the box. We also have a platform that is customizable and moldable (like clay). Steve was also talking about selective selling and really selling our model vs just the system. Not everybody is a fit for what we do and/or offer.

Idea from Steve... Run the system for 6 months and get good at the system. Then come back and tell us what you want to tweak out and/or change.

People want major functionality... however, they also want it to look a certain way (how pretty is it), they also want a level of control (what can they tweak and change).

Function, form, and control - Alan was mentioning the word "Control" - that gets clear down into that fracture type level. We could have preset templates, show/hide settings, toggle on/off settings, permissions and sub permissions, main pieces, sub pieces, and even show/hide of the different modules. Currently, we have everything available... we may actually want to look at module level controls. For example: do you use payroll? do you use stock/units? do you use x or y?

Idea from Alan... What if we did some testing on new users and had them do certain tasks. We then see how intuitive the process are. This would be a refining process and then work from there. As a side note, we have been adding on for years and years. That is our current model. Maybe we need to rework our inter core and make it more module based and then be able to show/hide and/or be able to toggle things (full sections and/or pieces) to an on/off level.

We also talked about packaging and limited packaging of the system... For example: The limited package, the standard package, the deluxe package, and the mother load... package. Not sure what to call things... but it could be really cool. Basically, it all exists, we just show it (smoke and mirrors) in certain ways. Based on the package style and/or level, we could show/hide other pieces and/or features. Another analogy is a race car engine and then we offer the body styles like cars, motorcycles, vans, trucks, semi trucks, or even UFO's (see attached for an older image).

Adilas has a lot to offer... but what if I only need it for this or that? It sometimes feels like taking an army tank out to hunt birds, say something like pheasant hunting or duck hunting. Almost an over kill. What if we could dumb it way down and make it more approachable. Make it into smaller bite size pieces and then let them get deeper if they want. As a side note, like the ice berg analogy, we only show the most basic pieces. Then, if they want more, we allow them to get to it. Maybe either offer certain packages and/or hide everything by default and make them turn it on (at a corp-wide or world level and also at a payee/user level).

Steve - how do people want to buy things? We then need to cater to that level. See the photo gallery for an inverted funnel analogy. Currently, we have people enter with all options (like the top side of the a funnel) and then have them select what they want to get to the smaller level. What if we flipped that model and started out super small and basic... then they could either buy and/or turn of additional modules and/or features as they need them. So, basically, we start super small (like the bottom of the funnel) and work outward (getting bigger like the top of a funnel).

Alan - would like to do a cognitive walk through... What path do they take to do a task? Where did we want them to go and/or do? Where are their eyes on the page and where are they spending the most time? How easy was it for them to follow the path that is wanted? The cognitive walk through would include a small user group, and then the persons being tasked with the tasks would have to explain (verbal and/or written) what and why they are doing what they are doing. Basically, getting into the minds of the users and what they are seeing, focusing on, and/or actually doing.

Wire frames (interactive outlines) and getting to the basic decisions and taking that research back to the coding project. What is the phycology behind the decisions. What are the human levels that we might be missing and/or could really enhance just by display, menus, and structure. In Dustin's words... "putting rails on things".

We also talked about doing different cognitive walk through groups (users not familiar with the system) and how they would do their own different tasks. If they get stuck, why? What were they looking for and what were they expecting? This is more of a cognitive (brain activity) exercise to see what the thought process is and/or could be. One of the challenges for us might be - so many different business verticals and so many different choices... we might need to get a sample and make sure that we aren't hitting just one niche and/or personality type. Lots of different flares and possibilities. We would like to match who would be using the program with what we would be asking them to do. This testing also has some down-sides, such as preconceived notions, using other existing and/or older products, and actually testing people who would be using it.

Alan and I were talking about who we knew and what resources we could tap into to get some basic testing. Just throwing around some ideas. We added in a new community funded project to get in there and do some research and some of the cognitive walk trough's.

After that, Alan and I were reporting on our different projects. We love the options of having black box code, but there are teeth to that as well. We are starting to see the black box section as a huge time sink for the developers if they are making core changes. We have code that is not in master (in the main code repository), it could be changed at any time, and no one knows who has the last cookie. The developers work directly with the clients, and thus, they think that they have the latest code, but a new change could have been cascaded through to the other pages. We definitely need the black box code options and framework, but we need to eliminate as much duplicate code as possible. It is becoming an issue. It is not on fire, but it becoming a thing that needs to be addressed.

Wayne popped in and reported on the database migration project. He is planning on running some new tests tonight. He went backwards and did some major back testing and going back to a test driven design philosophy. He said that he got a great reminder on why we need to stick with a test driven design philosophy (watching out for the little things). The data migration process is super deep... it is basically allowing two different servers to run as they are... then in the background it takes data and tries to re-sync the data to get a perfect match, even though they are different databases with different auto id numbers. That is advanced mixing and blending.

We got into a bigger discussion about standardizing data and using special tables such as flex grid tie-ins and custom dates, numeric, and custom text fields. Some of those tables are great double agents and/or chameleon type tables (they switch as needed). Good stuff and it really seems like Wayne is trying to think beyond the current project.

We are constantly chasing a moving target... part of the fun... :)

On the morning meeting with the guys. One of the first topics of the day was a client's system stats and how to monitor who is big, small, or somewhere in between? We have a few small reports, but we really need to beef that area up and make it more available and visible. We would love to do some visual stats, like the new invoice homepage that Alan made. The difference would be that instead of just invoice and sales data, it would be corporation (world) or location level stats and data. That would be really cool. We went into one of the servers and checked around. The data 0 box had over 1,000+ unique logins yesterday. The corporation in question had over 55 unique users yesterday make and/or modify an invoice. That same company had over 110 unique users affect an invoice in the month of October. We would like to make those kind of stats available and ready for viewing. It helps with decisions and what not.

As we were talking about shared hosting plans, we had the idea of creating an in-depth news and update with information about shared hosting plans (standard adilas accounts), semi-dedicated plans (limited number per server), and fully or full dedicated plans (private server boxes or cluster). We also made a note that some of that info may go well in our ecommerce pages and section. Basically, let the companies decide if they want to upgrade and what not. Show the features, advantages, and benefits of what we have to offer.

Along with that discussion, we had some talks about how fast things are changing all around us... think of technology in general, software packages, servers, hardware, and even versions of existing products. Everything keeps advancing. It becomes a maintenance balance to keep up with things.

Steve wanted to be fair and look at upgrades and maintenance from both sides. What are the clients wanting and/or expecting (their side)? What are we wanting and/or expecting (from our side)? Where do we meet in the middle and who pays for what? Great questions.

We also talked about the fear of selling and making the sale. Sometimes it is scary to virtually rock the boat. This was mostly on my part, but I was expressing that sometimes my angle and strategy is very open and doesn't commit and/or over commit on certain things. Each person needs to be their own style. Later in the day, I was challenged to write a big email to open the door to a client about getting on their own box. It made me think of a quote from Spencer Johnson's, "Who Moved My Cheese" book about dealing with change. It says - "What would I do if I weren't afraid?" That is a good question to ask. It is even more fun to ask yourself that question and then actually go do it. Difficult but fun.

Historically speaking, we are seeing things such as the data 0 server. It was setup in 2011 or 2012, it is on a 2008 server, it uses older versions of ColdFusion (coding environment) and older versions of the MySQL database. That conversation moved us to talk about older technology like fax numbers and other older hold-overs and such. It is amazing as it comes down to a form of maintenance and upkeep. Lots of the new things are going to faster processors, solid state drives, and up to date versions of both software and hardware.

A quote from Steve - "Lessons in time". It is amazing what we have learned over time and by trial and error. We keep learning as we go.

Towards the end of the session, I helped merge in some new code from Bryan. His code was dealing with show/hide option for 2nd vendor/payee tied to PO's. After merging code and pushing things up, he went in and did some live testing. After that, I helped get Steve's latest code branch merged into the master code repository. His code is currently all in custom pages and mostly dealing with the cannabis vertical. He's got some good things going. On that note, he would love to turn over his code work and swap it out for more sales work. He is really good at that.

I worked on some feedback for Dave Forbis and a new graphic that he sent to me. See attached for a copy of the new graphics.

Eric popped in and we setup some bigger blocks of time to work on his special account tracking projects. As we were talking, Eric was talking about project management and the "risk factor" within project management and risk management. He is excited that our current project will help other pieces and clients, but it not dependent upon other pieces in the system. Our goal is to get that section finished and launched by end of the year. That would be awesome.

This is an observation, but there is a growing need to keep breaking things into smaller and smaller pieces. Eric had questions, just today, about how to show/hide fields, change names and aliases, etc. We have a mini project that was done and created for the customers add/edit page, but it doesn't go any further than that. We really need to break each section into smaller pieces and have group settings, page settings, and personal settings. That seems to be a growing need. Along with that, we also see a future need to sub divide the permissions into virtual functions within the functions themselves. It is crazy to see how deep those fractures are and will be heading in the future. Crazy customizable levels.

- Tons of emails and light tech support from things over the Thanksgiving weekend.

- Brandon and Steve talking about updates on people - we were talking about Shannon, Russell, and Dave Forbis.

- Alan popped in and had some questions about his new projects. He is working on discounts on my cart favorite buttons.

- We lightly talked about vertical (business verticals or industry-specific) templates and settings. Make it easy to cater to specific verticals.

- Talking about system stats and storing that info in a daily watcher or feeder type table. We also talked about queued back end services that run on daily routines. We also talked about pulling reports and monitoring growth and changes.

- We were also talking about "rules" or standards per vertical (industry). Each industry is different, and thus may need some general rules based on the type of industry that they are. Basing the pricing off of processing and storage vs charging for the code. Some users may or may not be using certain features and/or modules. This discussion ended up going into questions about what do we want to do with the adilas databases (make it bigger and better or break it up into small faster pieces). This is still an active discussion and we are trying to gather pros and cons of both.

- Alan was talking about vertical and horizontal scaling - add more and more servers (distributed or cluster model) vs single server and up the capacity and resources. This lead into a small discussion on back-ups, redundancy, and disaster recovery options. Currently, we are doing somewhat of a modified horizontal scaling method.

- Steve had some questions about the API socket level and what that load may be and/or take?

- Alan had some ideas on risk mitigation and how to help our clients even do their own risk mitigation processes. Lots of talk about what are the vulnerabilities and how do you treat, track, and deal with those vulnerabilities. It always tends to come back to an analysis of what is the threat and how much do I care, need, want, and/or require? Talks about server up time and reliability. What maters most and what are we willing to pay for and/or spend?

- We would love to show all of the corporations (virtual worlds) what their stats are and what we (as adilas) are carrying and helping them out with. That helps us show a benefit and advantage for those who use adilas.

- We lightly talked about an offline adilas mode and allowing a user to use the main web system, if a problem, they could use a local copy, and then sync up things later on. This sounds awesome, but it could be a huge project and could be riddled with loop holes and gotcha's. Possible, but hard to tell what the real costs are and/or would be.

- The technology wave and what is here, coming, and already gone (outdated). We are constantly riding those waves and making decisions. Alan lives down there in Arizona and could maybe pop in and check things out with the actual server farm. We could even branch out and spread out our exposure to other server farms.

- We could update older servers to help with stability and up time. We could upgrade to using solid state drives, bigger processors, more RAM memory, and updated server and software packages. That could be a great upgrade for the time being. We also talked about optimizing our existing servers by tweaking settings and such (performance tuning).

- We may end up needing some new training on how to configure and upgrade the things that we need. This is just a possibility, but there is an upcoming ColdFusion summit convention coming up in April 9-10, in Washington, DC. Just looking at ideas and options. Our goal is to get the most out of what we can by either upgrading to the newest models and/or versions and getting the proper training needed to make it dance and sing. ColdFusion is allowing more and more scripting languages and is gaining some momentum.

- There was some small talk about upgrading from Windows servers to Linux servers. Wayne is the one that knows a lot there. Lots of possibilities.

- Some new shortcuts and getting up to speed. Alan was showing us some coding shortcuts. Params, is defined, and quick conditional processing. Things like a turnary operator (one line true or false if statement - switch), elvis operator (reference something and it is able to self-define if it doesn't exist but will use a real value if it exists - less breaking code for things that are undefined).

- There are many paths that we could take and would work. Let's make a plan and then work that plan.

- What we do is not easy. There are so many moving parts and pieces. As we build, we keep finding that it comes back down to more and more permissions and settings. Subs of subs. Eventually, it could become simple if you get enough sub pieces built into the mix. Kinda crazy.

- We are also seeing more and more needs for bulk tools and such.

- We are also seeing that people are really looking for a system that could do almost everything with both global tweaks (per business vertical) and also granular control (permissions, settings, etc.). Almost a wish list of sorts.

- As we get out, in the field, we may end up adding some icing here and there. Maybe even some icing per business vertical.

- On black box stuff - what if we had a list of what happens and/or what black box code is running? We may need to use some kind of technology to help us monitor and/or use what black box code that is out there. Maybe a way to notify our developers, consultants, and even our users what code they are using.

- Small concepts - creating an adilas fracture account - future concept once we get a few of the other pieces in place. This was an idea from Steve, clear back in 6/22/17. We would basically, allow the normal or classic adilas to keep going, and then start building out the adilas fracture accounts. Everything would be broken up into tiny modular controls but would also have bulk tools, templates, and industry specific defaults to help play the game. This subject could take up volumes, as far as other ideas and concepts that we would like to include. Super cool idea and future project.

- Steve would like to see us work on breaking out users from the systems... They, the user pools, exist and can interact as needed but they become their own entity - Imagine pools of professional (adilas community members and power users) users that could work for other companies as needed. Separate users and systems, even more than what they currently are. Steve has some good ideas on that. Kinda like a marketplace for features and functions as well as power users, employees, and people talent. Fun ideas.

On the morning meeting with Steve. We merged in some of his code and then made a few new changes. Alan popped in and gave us a small report. Dustin was also on the meeting and working on his own stuff.

Eric popped in towards the end of the main morning meeting. He and Steve were talking about category level rules on expiration dates and how to track and process items as they age over time. Basically, keeping track of expiration dates and helping to flag and move inventory to help keep things fresh and moving.

There was also some discussion about part/item categories and parent attributes. Both tools are well used and there is some cross over between them. The difference is how many things may be applied per item. Only a single item category may be assigned per item, but an unlimited number of parent attributes may be applied. Sometimes, the clients and users, and doing some mixing and blending. We may need to keep looking at that and maybe even allow for some rules, flow processes, etc. What we are hearing is the need for high level rules and then applying those rules to the items that are cascaded under that category. Basically, grouping and sub grouping, even inside the categories. Steve and Eric would like some other filter options for the main categories. Almost a mix and blend of categories and attributes.

There is still a growing need for sub categories within the main part/item categories. It is amazing how many new feature requests keep coming in on a daily basis. Pretty crazy.

This is just a side note... but we are getting more and more requests for some of the subs of elements of time to be applied to other pieces of the system (other 12 main player groups). We would love to push that out and allow for it to happen, but it just hasn't been built out yet. These are things like: color codes, sub dates/times, sub flags and tags, sub locations, sub phases, sub grouping, sub notes and comments, and sub sign-off's, and such. We have tons of ideas on this (virtual adoption process between elements of time, subs of time, and other system players). I'm excited to see where these things go. As a side note, we could create daily elements of time for certain things and/or tasks (this almost creates its own group) and then you move things or flip things from there.

We are also seeing a problem with some companies that use adilas for just one or two processes, but they don't use adilas for the whole thing. That creates problems because things can't flow from phase to phase and state to state. They are kinda wanting things to flow to a certain level and then just magically appear over in some other section. That gets tough to automate that because it is basically skipping steps.

Steve was showing Eric how to setup custom page settings and storing those values in JSON. As another side note, our original goal for the custom page settings was to give every page an id number (web_page_id from the web_pages table). We also wanted to give every CFC method or virtual API socket connection a similar web_page_id number. That way we could track what is being used and how often (behind the scenes stats). We started that process, but got pulled off due to other projects that needed attention. This is a huge piece of the puzzle and would really help if we go to the full adilas fracture account level. Dealing with page level id's, we also need to figure out what is needed for black box takeovers and extended settings of settings and/or conditional settings. It gets pretty deep fairly quickly.

Steve was just dreaming, but he would love to see the adilas application as an artist pallet where you could pick and choose your widgets and where to place them. Basically a build your own dashboard and build your own layout. Steve would also love to see a configurable shopping cart, where users could pick and choose what they wanted to see. Just some dreams.

Another huge observation today... Steve was showing Eric (who has done tons of development for us) around the system. This was huge for Eric and he could see and catch the vision. Sometimes you don't even know what you do not know. One of the down sides to adilas is the current size of the application. It is huge and has tons to offer, because of that, some people never venture into certain areas, even though they could really use the functionality offered. Maintenance and training are huge concepts that need to be pushed and available to our users.

Steve - Question - Is that even a tree you want to cut down? Steve was cutting trees as a winter job, just out of High School, and was talking to a old sawyer (tree cutter) and the older guy was telling Steve to leave a certain tree alone because it wasn't worth it. Steve was young and wanted to conquer and do a good job. The tree had some old barbed wire embedded in the bottom of the trunk. The old sawyer was telling him to leave it alone because it would be a ton of work and may end up ruining your chainsaw. Business is like that, you may not want to cut down every tree in the forest. Abundant model - next! Great advice.

Spencer and I got on the GoToMeeting session. We have a small project that we would like to work on together. Because this is the first real project that we are doing together, I took him on a whirlwind tour of all kinds of stuff. We went over some of the current adilas billing, trending, etc. We went over look and feel, preset CSS options, themes, classic, snow owl, etc. We went over current shopping carts, views, and options. The small mini custom project that we want to work on is a new shopping cart called "short and sweet" - it will basically be a responsive design (mobile ready) and will have a place to scan an item and/or type a item name. It will be a one-pager application that allows for line items to be added, displayed, and other cart/POS functionality either in accordion style options and/or hidden menus.

We also briefly talked about building things from the ground up and using a base structure to create a new theme called "Fracture" or the start of the adilas fracture accounts. The goal there is full modular control over settings from a world or corporation level, a group level, page level, and individual level. Good stuff.

Alan popped in and we got Spencer setup in adilas repository with Git and Bitbucket. Alan also went over a light file structure overview with Spencer to help get him started. While they were doing that, I was working on a small document to help spec out a short and sweet mini cart interface. See attached for the document that I sent to Spencer.

Steve and Dustin were on the morning meeting. Steve had a quick question about a custom report for owners. We talked about some security hashes that could help the report be more secure. The admin report needs to be outside the secured environment and kinda a quick access link to a quick breakdown report for admin users. Steve has the report built, he is just adding some security and then going to add an access point from inside the secured environment.

I got a call from Russell. We talked for quite a bit about some custom client needs and how best to proceed with those requests. We also spent some time talking about using Bridgerland or BTech to help build out some of the fracture type pieces. The term "Fracture" comes from an idea that Steve had back in June of 2017. Everything in adilas seems to be fracturing and breaking into smaller and smaller pieces. Just discussions at this point, but basically a centralized brain (backend engine) and then a deployable front end that could be hosted on any client server or through a commercial web host. No special setup and a fully customizable frontend interface. The whole thing would talk and/or communicate through API socket connections and back and forth API traffic. We talked about ideas, options, etc.

If I were to put together a small fracture tick list, it would be something like this: (just ideas)

- Customizable look and feel (corp-level, department level, user level, and whatever in between)

- Preset defaults with ability to tweak out the defaults and settings (good starting spot and/or basic structure - starting templates)

- Permissioned out and/or micro permissioned (down to the functions per section)

- Settings for layout, settings for display (show/hide, sort order, aliases, instructions, required yes/no, validation rules, etc.) - As of right now, we are seeing settings on 4 different levels. They are world (corporation or business entity), groups or system player level (customers, invoices, deposits, expense/receipts, PO's, parts/items, vendors, users, stock/units, balance sheet items, quotes, elements of time, etc.), page level settings (what will show/hide, sort order, placement, flow, etc.), and finally, user level settings and defaults. How do I want to play the game (at a personal level)?

- Existing structure and flow, but it could be modified. Basically, a template of the starting procedure and/or process but make it able to be modular (build mini data assembly line type options per procedure/task). Think of our model with the mini bubbles and/or pods. These interface with flow, permissions, time, flex, and mapping clear out to the accounting levels.

- Real in-line database extensions. This allows us to provide a basic starting point (database tables and template flow) but also allows for things to be expanded and/or contracted (lessened) based off of configuration. These database extensions could be data types and allow for numeric, decimals, text, dates, on/off toggles, and even long text or JSON storage.

- Be able to save and build any kinda of report or data export - using existing tools

- graphics, charts, graphs, and other summary type options

- Support of both transactional data (what happens day to day) as well as aggregated (summed or pre-calculated values)

- Digital story telling, using characters, relationships, cause/effect choices, consequences, etc. World building concepts.

- Configurable interfaces and functionality per business vertical - click of button to switch layouts and/or processes.

- Customizable (data or logic hooks or black box technology) on client side, server side, and display and logic sides.

- Responsive and/or mobile ready

- Tons of flags, tags, and special callouts

- Be able to tie everything to time or elements of time. This could allow for groups, categories, types, sub locations, sub phases, sub status, etc.

- The list goes on... Most of the ideas have been recorded somewhere in the adilas developer's notebook pages. A great resource, it just may take some time to review and categorize. 

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

Back to other topics, Eric popped in and we made a few more notes and decisions on the sub special account tracking stuff (gift cards, loyalty points, in-store credit, etc.). After that, Wayne jumped on and we talked a little bit about email servers and what is needed there. I spent the rest of the time recording notes and reviewing to do lists. Busy times.

Working with Steve on some JavaScript to help with a new production build (internal builds) page. Lots of dynamic notation. Steve has been working on main flow and carving out some basic pages. He is then pushing things off to Dustin to help shine it up and make it look pretty. Steve wires it up (round 1.0) and then Dustin takes it to the next level (2.0). Good plan.

Eric popped in and had some questions on how to assign his sub special account tracking things to customers, payee/users, etc. After that, he and Steve were talking about future and upcoming projects. Steve was asking Eric about his backend skill sets vs his frontend design skills. We even got into some project management talks as well as backend database architecture. Eric has quite a few skills that are very marketable. We also talked about internal core projects as well as outside custom projects. Good conversation.

Steve and I were talking, briefly, about our direction for the future and near future. Good stuff. Our goal is to keep working on the system, building new pieces, refining some of the older things, putting a new coat of paint on the application (look and feel stuff), and figuring out the master plan of where we want to go. We have so many ideas out in the developer's notebook area... it would be so cool to gather all of that up and really make a plan.

The master plan could include things such as: database structure stuff (world building), graphical homepages, server structure stuff (universe level), fracture account ideas (things that we have learned and ways to break things into smaller and smaller pieces and settings), API socket access points, custom look and feel stuff, 4 different setting levels (corp/world, player/group, page/section, user settings), as well as additional rounds on balance sheet, elements of time, and subs of subs. This could also include all kinds of system stuff such as watchers, feeders, triggers and other ideas that are out there. That would be really fun, a huge project, but really fun.

Eot 4427 in developers notebook

https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=748&id=4427

At some point, we want to circle back around and rebuild a bunch of the pieces and how they act and interact. We would like to call this new rebuild "fracture" or something to that effect. Anyways, here are some brainstorming ideas on the fracture pieces that we would like to sew together. No specific order:

- object oriented approach (objects and data over time)

- use teams and different talent pools

- ice berg vs mountain type analogy (what is being exposed and what are the perceptions - visual exposure)

- settings and different setting levels (corp, group, page, user)

- subs... of sub (everything is fracturing into smaller and smaller pieces) - plan for it and embrace it

- API socket connections and external work flow options

- database scaling (corp-specific databases or corp-specific database tables)

- real in-line database extensions (add/edit/remove database fields and help them flow through the whole system)

- 3D world building - keep going and building out these ideas and concepts - one step at a time

- data assembly line(s) - concepts of tracking phases, grouping, sub locations, allowing flex and checkpoints, permissions, mapping to financials, etc.

- using time or elements of time as a base level and then mix, blend, and share sub functionality and tracking options (more objects and data over time stuff)

- funding and making sure we can fund the planning, design, and development of our game plan

- help files, videos, and SOP (standard operating procedures) - standard and custom

- black box and ways to customize the pages, verbage, logic, and process flow

- summarized data (aggregated data) vs transactional data (all the steps and transactions) - we need both - watchers, feeders, and triggers

- following and dreaming the dream - it may sound way out there... but following that dream is huge

- make a visual plan

- include general testing, unit testing, validation (local and serer-side), and standardizing requirements

- version control and deployment

- going back and doing research and review of older notes - tons of mini gold nuggets to harvest from doing this over the years (make sure and harvest some of our own ideas)

- use of sub homepages and graphical hubs of sort - also use graphics, charts, graphs, and other elements

- summed up data with drill-downs or searches available (basic or advanced) - approach all most everything from a summed up version into a more expansive (expanded) view and/or format

- be able to export any data to CSV, Excel, PDF, and general web format

- smaller mini functions - getters and setters - for miniature database access and updates

- use sub flags, tags, and other similar features - lots of ideas about sub phases, sub groups, sub locations, sub flags, sub tags, sub progress, etc. Lots of prior documentation on elements of time and subs of time, including how to virtually adopt functionality between main player groups (invoices, deposits, expense/receipts, PO's, customers, parts/items, stock/units, vendors, employee/users, quotes, elements of time, balance sheet items, etc.)

- custom look and feel - able to match moving trends

- responsive (able to change size and layout based on device or screen size) - mobile development

- sales - how are we going to market and/or sell our products and services - how are we going to set things up for correct billing and tracking (usage, storage, bandwidth, queries, connections, data, files, images, etc.)

- communications, push/pull notifications, automated things, queues and scheduling tasks, bulk and individual communications

- good project management

- sub permissions - almost down to the function type level (as needed)

- dynamic verbage, custom layout(s), dynamic link builder (favorites), and simple look and feel

If you are looking for other ideas for the fracture account stuff. See this URL or web address: https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=fracture

On a GoToMeeting session with Russell. He was showing us some new and modern concepts of MVC (model view controller), object oriented pieces, full API access, getters and setters, custom skins, GUI interface, and tons of cool JSON storage stuff. Russell also had a number of ideas for the adilas fracture site and what we could do, be, show, and even become. Kinda fun. I recorded the session.

Russell would like to take adilas to a new level. Putting in standards and testing to help the process. We want to standardize without cutting off the custom code arm that we love and are used to. Adilas would be the safeguard of the data and files and content storage, we then allow, through the API sockets, the ability to sew things up and put things in any way they want. We become the major backend app and allow for customized frontend options. Dream it up, we'll wire it up.

Steve and Russell had some early conversations about custom dashboards and being able to build things with small widgets, modules, cards, windows, panels, tabs, etc. Be able to show/hide different things, be able to drag and drop features, make it super cool.

Beautiful, powerful, easy!

If you had to start all over again (virtually burn things down), what would you do different? What would you do the same? Where would you take things? Fun questions.

Steve is seeing huge needs of a integrated system out in ecommerce land. Currently, there are tons of small companies trying to build their own little piece of the puzzle, but nothing interacts and fully connects. He is also seeing a need for a single system that could be good at all of the different pieces.

Brief talks about the current adilas Snow Owl theme and where things could go with new CSS variables. Lots of JavaScript and web components. The look and feel is super important. Light talks about heading more and more towards open source code and projects. Good talk and discussion.

After the meeting, Eric jumped in and had some questions on showing some of the discount stuff. We talked about who on our team could do some more CSS stuff and finish up some of the Snow Owl functionality. We also talked about Spencer and maybe having him help with some raw CSS stuff. Maybe we could make some CSS snippets and then build from that or from there. That would be really cool. Good page or resources of the CSS and styling changes (over time). The existing CSS stuff (minus Snow Owl) exists out in https://data0.adilas.biz/css/index.cfm - It would be super cool to keep expanding some of those options... :)

Meeting between Russell Moore, Steve, and Brandon.

- From Steve - "Russell, we have missed you".

- Russell - Drawn back to the dream

- Like a beehive, everybody gets to play and the combined effort makes a difference

- All core adilas projects are going through our new gateway. Cory Warden is the gatekeeper for those projects.

- We have some snow owl CSS questions for Russell. We need the master back in the mix.

- Timeline views and other modern look and feel (flavor of the sites). These are things that we want to get back to.

- We want to focus on the Snow Owl Theme and get it all stabilized.

- Russell and Steve have had multiple conversations on the widget, app, pallet type interface - mix and blend different widgets and mini apps to help the users get their "space" setup. This is somewhat of a custom mini dashboard concept with lots of options and configurability.

Russell - wanted to pitch some ideas and things towards the adilas fracture project (future adilas project and plan). Making it a true core with an expandable platform type interface.

We started out in Postman (PHP based - API socket tool) and using Russell's auto generated API documentation - Tools with custom extensions for functionality, API sockets, classes, and view models. Core pieces all get add, edit, and view options for the data. Frameworks and then building on top of those. Russell was talking about core, custom core, themes, custom code, etc. These are ways that he could build on and virtually extend the core tool without hurting the main core logic.

Some of the concepts were dealing with the pallet type view (multi mini windows or widgets). They were talking about how to use tons of mini widgets, apps, views, and even third party tools - all mixed together in one app. We started talking beyond screen, and screen size, and going more to a canvas type view. A canvas is a layout design that may be bigger than a screen. They would like to be able to navigate to different sections, zoom in/out, call something into focus, and the background pieces would connect with both internal and external API sockets. Once the data structure is known, the building out of things becomes very quick. The goal is to create a robust back end engine that could be built out and modified on the frontend very quickly. Getting back to cores (internal core) and plug-ins or add-on's.

Both frontend and backend developer widgets and backend components - Russell was proposing a table component (just like the data tables, but more robust and configurable). Components are able to worry about their size vs screen size. Basically, you could make the components smart (know its own parameters). As you start mixing different components, make each one smart enough to mix and interface with other widgets without being overwritten and/or altered. Tons of self-contained mini apps all working together.

I was asking Russell about some of things that he is working on. One of them was what he was calling "Headless CMS (content management systems)" - All API socket connections but no real structure. Virtually a brain without a face. The face becomes the view model. We talked about how adilas uses a similar concept called "play at the wall" type concepts - All API socket connections without having a required view of that data. Russell was getting back to classes and specific tools and object oriented programming. If we use a tool too much (say elements of time), it can make the water muddy. That is both good and bad. In some ways, it makes it very flexible. In other ways, it may actually get abused because it may be used in so many different ways.

Lots of separation between database, views, logic, uses, tools, and data. Some of the new pieces (on the view model) could be scrolled, slid, collapsed, expanded, shrinks, etc. Kinda like the old Adobe Flash Rich Interface Environments but without the Flash wrapper. Beautiful interfaces with just in time data, fun navigation, built-in validation, etc.

At some point, we would love to allow our uses to use what pieces and features that they want and then working on charging based on what they are really using. Maybe thinking of being out on the AWS stuff for this. Still just ideas and concepts.

We also talked about running with two ships vs just one (different applications) - see screenshots (build on both apps and eventually have two separate products). Ideally, the new ship (say adilas fracture) would end up being a more powerful tool and a full remake of the original adilas model. Little by little, chipping away at the new system and new structure.

Steve was talking about getting a designer to help us with the Bear 100. He would like to take it out to Google maps, GPS, mobile friendly, and even allow for people to use our site to do sign-ups and other pieces. We could have the site tied out to ecommerce and allow for tons of other options. That could be fun.

Eric came into the meeting and had a couple of questions about customizing the invoice and quote process. We talked about parent inventory, sub inventory, parent attributes, flex grid tie-ins, and even black box custom tables. We also talked about adding in some blank or generic flex fields in the quote line items and the invoice line items. They want some custom fields per line item. Steve was saying, don't tell me what you want... show me. That way we know what tool to use and where to put it into play. Steve was also talking about maybe going up steam and setting those moving variables up higher on the customer level. In a way, the over arching question was I want to extend the existing options and functions per invoice and quote line item. We then have to help, how do we figure that out and what solution could we use to solve that problem? Good stuff.

This doesn't play in quite yet, but at some point we would love to get into real in-line database extensions. That is somewhat of the bigger brother to the flex grid tie-ins. Being able to add and subtract data points and data fields per section. As a side note, we have tons of companies that virtually commandeer (take over - like a pirate ship) any field that they can to get the job and/or task at hand done or finished. Kinda interesting.

Steve wants to get more information, from the source. He would like to get a real world scenario and then make a plan from there. Not just a quick band-aid, he wants to help develop the solution. What are the processes, what are the needs, what already exists, and what else is still needed? It keeps getting deeper and deeper (4 and 5 levels deep).

There was an analogy of a "part changer" - think of mechanic that just swaps out part after part in order to fix something. We really need the mechanic that gets in there and looks at the problem and then makes a decision. From Steve - It's not how fast you go, it's how well you go fast - older Porche commercial.

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

Switching gears, we started talking with Wayne about servers.

We were talking about virtual machines, physical servers, load balancing, and the difference between hardware problems and software problems. We were talking about clusters and getting redundancy and depth of options. If we stay with Newtek, we need to build in some of our own pieces. If we go more with AWS, we get to just use some the existing pieces. There is a trade off - AWS has more options but it also a deeper pool. Newtek is not as deep, but in some ways easier. We were also talking about rollover, fail safe modes, mirrors, etc.

We spent quite a bit of time talking about the Adobe ColdFusion engine and how we could potentially configure cluster type environment. When you get out of a single machine environment, what do you do with the database. On a single machine (server or dedicated box), it is simple. On a cluster, you have to keep things moved and/or separated. We would love to break some of the system down into their own databases. The idea here is making each database corporation specific vs server (whole box) specific. We have talked about this for years (since 2012 ish) and have called it world building and other project names. We really want to do this, but we also know that we have tons of code changes that are needed. We could separate out the shared tables in the existing database schema but we would have to do it table by table. As a side note, we have already done this very process for invoices, invoice payments, po/invoice line items, customer queues, sub inventory, etc.

One solution would be to create a corporation specific datasource (pointer to a specific database) and then help that get migrated and pushed around. We also talked about loading in objects per user that has all of their corporation specific settings and values. Eventually, we will still need to break out the payee/users so that we have a master list and then allow them to be merged and virtually bridged to any corporation and even any system. We still have all kinds of exceptions, such as be in corp x but pretend like you are in corp y (look and feel and settings). It gets kinda crazy.

The subject started to switch to more and more object oriented programming, storing values in session objects, and other objects that are server based. We also talked about database server clustering and moving all databases (per corporation) to a dedicated database cluster that only served up data and content. Lots of possible configurations and options. Both Alan and Wayne were talking about cross-schema queries and all kinds of advanced things. As another side to this equation, we are seeing more and more of a need for aggregated totals, auto processing, daily task management, etc. All of these things play into the mix. We are seeing certain tables that are great as shared tables and other tables that really need to be independent and corporation specific.

As we move forward, even towards a fracture type model, we will need to separate databases, logic, move more towards object oriented programming, API socket calls, etc. Just for fun, Wayne and Alan were talking about different levels and using bigger teams - backend guys, database guys, middleware guys, frontend and UI (user interface) guys, etc. We aren't that big.

Steve's idea... Alan, Steve, Dustin, and Brandon are all going to be at a convention. Let's use that time to do some planning and take it to the next level. That's a great idea.

- Light overview of our vision - overarching adilas design vs individual business vertical designs and mini white label options.

- Talking about the reports homepage... where can we go from there? Currently, there are reports for invoices, sales by, items, parent/child items, vendor stuff, and customer based reports. Jonathan was wondering about all of the other reports. In a way, all that adilas is a giant reporting application. Data comes in, then our users want to pull that data back in some way. That would be super awesome.

- Going to some graphics and screenshots - Comparing old and new report settings and pages. One was on an older code set, new code sets, and even permissions and settings. Jonathan was noticing small differences based off of those vars (old, new, permissions, and settings). Lots of moving pieces.

- What to expect... We talked about how the adilas core graphic was divided into main system players, then sub homepage based on that player group, each player group also had searches, reports, and other data or group specific output. Each section (main player group) will also have tons and tons of data associated with them.

- The interactive map has a button for history and reports up in the top right hand corner. That is a pivotal piece (corner piece).

- What do we do? We store data, we show data, etc.

- Jonathan was listing out pages and then sorting them based on names, pages, sections, etc.

- So much redundancy (in the design and in the navigation) ... new users can get lost. Does this button mean the same thing that I already saw or is this a different section? Because there are so many ways around the horn... it somewhat makes it hard to find your way around.

- The shed and tool box analogy - You will need a lot of different tools. Most of them you keep in the shed and/or toolbox. However, each time you do a task, you want certain tools for the task at hand. How can we help them get to the tools that they need and still keep it super simple. A similar analogy is an artist and a pallet of paints. They need them all but they only are usually dealing with certain ones per painting.

- The deeper we get, the more we get the comments... How can I go faster? How can I do more? How can I see more? How can I mix this and that? How can I (fill in the blank)?

- Jonathan asked... Do you think people use your system more for viewing data or for entering data? We answered, both. It totally depends on which side of the fence you are on. Are you a salesperson at the counter do a sale or are you a manager looking at financial? It all depends.

- We lightly talked about custom links, custom buttons, and custom icon navigation.

- Some of the upper management users are wanting things quicker, faster, easier - things are going to mobile apps, quick reports, dashboards, etc.

- Screenshots of searches on the sides, data is in the middle, and add new is at the top. Simple layout and then keep it standard on all group level areas (customer, deposits, invoices, PO's, expense/receipts, parts/items, stock/units, vendors, users, etc.) See the screen shots.

- Being able to use settings (using the gear icon) to get rid of certain columns, sort values, pre-set setttings, page level settings, users settings, group settings, show/hide columns, custom naming conventions, etc. Super cool fracture type ideas and tech. This would be awesome for the upcoming fracture type system.

- Standard of here is how you enter data, here is how you view your data, here is how you get to certain areas quickly.

- A lot of the system is built out in tons of standalone URL or pages. That allows us to jump and interact with whatever page/tool that we want. As a technical side note, some of the pages do have required flow and pages but some of that is negotiable and/or programable.

- Jumping back to the mind map type overview. We also talked about the interactive map and how we could use it to drill-down into more details from there. Being able to flip flop the view. Allowing for multiple different views of the same things (what is your style).

- Being able to flip into an education mode and then be able to show simple videos, walk around tours, and step-by-step directions. This could show/hide extra verbiage, show/hide quick images, show/hide quick video tours, etc. Education is a huge key.

- We are seeing that every page is going to need an id number for saving settings on a per page level. This is feature already exists. We just need some data entry to get all of the id numbers. Jonathan would even love to store possible CSS settings and such on a per page level. Lots of roads leading in this direction, page level controls and settings.

- See attached for image uploads of concept art, icon boxes, magic 4 square, search and results options, mind maps, etc.

On the morning meeting with Dustin, Steve, and Alan. We were touching base on all of the things going on. Steve needed a merge into master for his current code branch. We did that and both Alan and Steve have plans to take some of the pages a little bit further. Most of the meeting was just touching base on different projects and who is doing what.

I spent quite a bit of time working on emails and doing some follow-ups with different people.

One of the follow-ups was with Russell. I called him and we chatted and then jumped online for a 2 hour meeting with both Steve and I. Great meeting. See below for a number of ideas, concepts, direction, and notes from our meeting:

- Need to focus on Snow Owl theme settings (overall look and feel of adilas pages, reports, headers, footers, and data tables).

- On the data tables (fancy tables that allow exports, sub filtering and sub searching, and sorting of columns) - we talked about the need to get a better handle on these data tables, make them more standard, and deal with the possible weaknesses and/or bottle necks with going with these new fancy table structures. By way of a note, we have a number of these data tables throughout the entire system. We need more of them and we also need to refine some of them to make things faster and smoother.

- We talked about what would be involved with the process if we created our own data tables, specific for adilas, and our client's needs. We talked about creating our own custom tags, our own we components, and then using that throughout the whole system.

- We spent a good amount of time talking about how the need to show aggregated data could remove some of the existing load from showing transactional data with the data tables. Those data tables are really good at showing smaller number of records vs tables with thousands and thousands of records. They really work better for things in the hundreds of records vs the thousands of records (and up). Aggregated data would be things like quick counts, totals, sums, averages, maxes, mins, groups, and other overview type data and numbers. That would also be great if we could show that data in charts, graphs, quick numbers, easy to use mini dashboards, and even graphical sub homepages or graphical homepages per section (system main player groups and/or subsets of specific tools and features).

- If we start showing graphical homepage and aggregated data, it would virtually allow us to pull back a level and push the transactional data deeper. It still needs to exist, but it may be a better option if we could get them quick details and data and then allow for drill-downs as needed. Quick, easy, simple, and then more details as needed.

- On the data tables, do we know what people/users are using and wanting? Is it the exporting, the sub searching, filtering, sortable columns, or quick pagination?

- Maybe work on and do some concepting and proof of concept on the adilas data tables. Take it to the fracture level.

- Russell is going to get with Brandon to do some training on the existing and current data tables. We plan on recording the training session. The goal is to start standardizing the implementation of those tools and features (data tables) in the system.

- We (Steve and I) are really trying to focus on better project management, planning, and helping everybody get small victories. Some of this may involve virtually protecting our guys so that they don't get pulled in every direction.

- Lots of talk about MVP's (minimal viable product) and shooting for that type of approach.

- Breaking things (projects and processes) into smaller projects and pieces.

- Asynchronous data loading for big record sets.

- API sockets and loading in bite sized pieces, data, and logic as the application backbone (main source of both raw and formatted data).

- Russell was talking about a need for more developer training, requirements, snippets, CSS and code samples, standards, validation, and other dev tools.

- Steve and I would like Russell to lead the way and lead out on what is new and what is going on. Nothing too huge, but basically, what is the next logical step?

- Having Russell and Chuck work together. More coordination and small teams. Getting involved with all of the other players and pieces. Different talks about teams and collaborating with each other.

- Easy, pretty, simple, and powerful

- White labeling our own product on a per business vertical type model.

- Russell would really like something that he could be involved with and have some kind of stake, claim, and or ownership. We talked about both adilas and adilas fracture type options.

- Steve would like to come up with a new business type model - who owns what, a perpetual trust type entity, open invitations, rules, regulations, standards and options. Reformatting our existing business structure.

- The concept of how "fracture" keeps happening. The deeper we look, the deeper it goes. Everything is sub dividing and splitting into smaller and smaller pieces or subs. Along with that, where are we headed? Ok, then let's build that.

- The whole thing keeps unwinding and new ideas keep coming and falling into place. We just keep taking the next logical step forward.

- We are seeing more and more needs and wants to be mobile ready, responsive, and modern design needs. This could be mobile apps, phone ready options, different screen sizes, multiple screens at the same time, virtual environments, and where are things headed? Keep pushing forward. Skate to where the puck is going to be (proactive approach).

- We are really wanting to jump into some other verticals (business entities and business categories).

- Steve used to look for a single rep or consultant. Not marital status, but size wise (just one person at a time). Now, he is trying harder and harder to find super consultants who want a group of like clients, outsourced compliance, oversite, over viewers, and other vertical specific services. He would love to tie into different CPA firms or groups. The goal there is to turn over the training, setup, oversite, and support to these super consultant groups or white label entities. They run with the needs per business vertical.

- Reoccurring revenue models and how to work with it and mange it along the way. SaaS (software as a service) and what and where is that headed? Good stuff.

- Let's make it happen. We can check off the checkboxes. Let's do it.

- We even want to move our leads over to the correct white label suppliers. We will act as the industry specific point of contact until a suitable entity and/or third party white labeler is in place and/or available.

- Let others focus on each vertical, we will focus on the core and our software package and the offerings.

- Even the core keeps fracturing. That sounds bad, but we are really excited about it. This is the new direction, small, multi pointed, configurable, flexible, software options and packages.

Jonathan, Steve, and I were all on the meeting. We started out and jumped into some general world building concepts. Just trying to keep Jonathan in the loop and seeing where we are going or where new development is happening. After that, we turned the presentation over to him and he showed us what he has been working on. Still lots of mapping, gathering, and what not. We have him on a big project - cleaning out the garage and helping us to organize things... :)

Here are some notes from the day:

- 3 main navigation buttons or area that people want to be in - they are where do you want to go? What do you want to do? How can I show you or let you pull the reports you want? In a nutshell - go, do, reports

- The Go section would be broken down into different navigation type or screens. We were thinking of cards with icons, a zoomed in map, the core layout (radial fan), and a build your own section. The Do section would be somewhat a mini search engine built into the system. They user would type a word and we would bring back results for them to click on. For example: they type discount and we show different discounts options, reports, help files, videos, etc. Super simple search with built-in navigation. The other section would be the reports or what you want to see (show me) section. We spent quite a bit of time on this section, but the main gist was categories, sub reports under those categories, and settings to allow for the page to be customized and organized as needed.

- Going back to the zoomed out map idea with icons. Jonathan took the existing interactive map, added some icons and simplified the design a bit. Great starting point.

- The action or do section could be setup like a mini google area or search engine within the system. Make it fun and light but able to jump to assets that deal with the task at hand.

- 3 different type of tools - Tools for entering data, tools for searching data, and tools for showing the results of the searches (reports).

- Lots of talk about settings. What different types of settings are there? World level (corporation wide settings), Industry specific settings, main 12 player group settings, page level settings, and individual user settings.

- Splitting up the settings into the different player groups and even allowing for page level drill-downs as needed. For example: Say we were dealing with settings for invoices. We have all of those and we also show all pages inside the invoice section that also have settings. Be able to do all different kinds of settings from one spot (corp-wide, group level, page level, and user settings).

- We got into lots of talks and discussions about build your own navigation systems. Be able to set icons, colors, naming convention, sort order, tool tips, custom URL or pick from a list, and other individual button/nab type settings.

- It would be super cool if you could turn things on/off and then drag and drop into a placeholder or a grid of sorts

- As we were talking about custom built navigation systems, I started to think about the my cart favorite buttons. We allow general buttons, photo buttons, nested or group buttons (be able to stack things), colors, custom names, add/edit custom categories (ways of organizing and grouping like buttons), custom sort options, copy or use other user's buttons, etc. Lots of fun ideas. Instead of just POS (point of sale) buttons, be able to do something similar for custom navigation. Anyways, use my cart favorite buttons or that idea to build out custom navigation systems. This could be a cool addition for the fracture stuff.

- Going along with the custom navigation buttons, we may also want to allow for colors, icons, categories, custom sort options, special placement options, etc. Turn it into a virtual pallet of sorts (pull and organize your space like an artist using a pallet for a painting). Super flexible.

- The term cohesiveness came out a number of times. Making the site cohesive through tools, apps, pages, sites, products, and even marketing.

- As a company matures, it often tries to use a designed system approach. This included style guides, requirements, code snippents, cascading CSS, components, and style assets that could be used over and over again (one to many relationship between a component and what it does and/or looks like or functions like).

Great meeting and fun conversation. Towards the end, Steve was encouraging Jonathan to keep dreaming and refining as we go. We are trying to catch the over all vision. As we keep going, we may even need to circle back around and see how the new ideas could relate to the rest of the system. Trying to get to that cohesive type design level. See attached for some screenshots.

Met with Jonathan and went over our own version of a spec list. What is needed? We talked about his latest video walk through and the impact that it is having on different key adilas players. Good stuff and fun to see the reactions. Lots of positive feedback. Here is a link to the video from a couple of days ago - https://adobe.ly/2PEhYI4

Below are some new notes from our meeting today.

- The value of the page and what is really important? Focusing on the task at hand. Sometimes we can get distracted by the tiny details.

- Spec sheets - what does that mean and what are we really looking for? Sometimes that spec sheet develops over time through meetings, feedback, and decisions. Currently, we are somewhat in the mode of just in time spec sheets vs big long lists that have been prepped and formatted. We may lose some efficiencies but we gain in a real way by talking about real ideas and subjects. Not everybody likes it this way.

- Timing and what is needed and when. Timing is huge.

- Talking about adding colors and backgrounds. See attached for a few screen samples with some background colors and background images. Just playing around.

- Meet, change, meet, change - R&D format (research and development) - This is somewhat how we are managing the projects right now.

- Delightful (key word) - We want it to look good and be fun to work with (delightful).

- Global nav searches and pushing that further (new quick search option). This could be huge. Being able to search the app for anything that matches a few specific key words. We could show navigation, buttons, links, help files, videos, tutorials, tours, tips, etc. Fun options to think about.

- We spent a little bit of time talking about what the "education mode" means and what and how that would look like. We decided that if we turned it on, it would show all kinds of helpful info and tips to help orient a user. If they want, they could turn it off and the tips and hits would go away. They could turn it on/off as often as needed (the help options would change based on where they were in the app).

- Making custom software easy - that's what we are trying to do.

- Sent Jonathan a link to some research on fracture - https://data0.adilas.biz/top_secret/developers_notebook_home.cfm?q=fracture&sort=asc - as a note, fracture is somewhat of our code name for some of the ideas of where we want to go (future project). Things keep breaking and sub dividing (fracturing) right underneath us. We are trying to embrace the changes and roll with the changing landscape.

- Going forward, we are planning more screenshots with more customizable options, real data layouts (fake data but simulating real pages), being able to drag and drop to help with sorting, and building up to CSS style guide stuff. As we go further, we may end up adding graphs, charts, and other eye candy type stuff. Just trying to fill out the navigational app with mock-up data.

Emails and other to list stuff.

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

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

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

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

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

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

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

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

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

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

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

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

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

Steve, Russell, and I met to talk about some business options. Russell has been working on some prototype code that he wanted to pitch to Steve and I. The new code is really cool, but not all the way finished. We talked about a number of the concepts and they will be great additions and could be the base for some of the fracture stuff that we are planning. Here are some of my notes.

- Russell really wants to take what we have and restructure it into a more cohesive core. We build and build and stack and stack. Some of what Russell wants to do is take all of that, and re-make it in such a way that it becomes more mobile and modular. Same type functions, just change the backend core pieces to work better in the future. See attached for a small diagram (drawing) to help illustrate the concept.

- Russell really wants to fix and patch the current ship as well as start building a new and faster ship on the side. Enlarge our fleet, in a way.

- We build and break, build and break. That's how we keep learning and growing.

- We want the adilas core to be 80% of what people need and use all the time. The other percentage will be industry specific code and custom code per corporation and/or business.

- At some point, we bump up against a few tougher obstacles such as volume (quantity of records or quantity of choices) and up against evolving tech. Those two things seem to be a common thread.

- Lots of talk about using web components. This is where we make a small mini widget and then use it over and over again. The little widget holds the code and the logic, we just pass data to it and it knows what to do. Some places where we want to do web components or something like that are: Movable pieces to set up your own flow or virtual data assembly line (think of the cards on a Trello board). Media/content libraries - be able to upload items and then use for multiple places vs just uploading the same thing over and over. We also want to add drag-n-drop functionality and our own version of the data tables. Russell has more info and ideas. There are things that will end up playing in the fracture interface.

- We talked about the value of being in the know and having experience to go along with that. Huge key.

- One-to-many and using shared libraries and media/content galleries and libraries. We already have some of that (media/content remote references) but we want to make it more visual and spread it out more across the system.

- Building and using some tech and pieces from other companies like WordPress and Trello (cards, boards, and that type of interface). WordPress is a pretty deep CMS (content management system). Lots of good ideas. We'll end up with our own flavor of sorts.

- We want to keep making the tool better, prettier, faster, and more powerful. In Russell's words - Easy, Pretty, Powerful.

- As a side note, I wanted to record a saying that Russell said back in 2016. "Adilas is a great companion software package for any business." (4/13/16)

Meeting with Jonathan to go over some progress. We haven't met in a few weeks due to holidays and what not. The meeting went well. Jonathan and I were on the whole meeting. Steve joined us in the middle for a part of it. Here are a few of the things that we did and covered:

- Review of the education mode - see the screenshots. The education mode allows a user to turn on/off additional helps, tips, help files, verbiage, videos, graphics, etc. The user can turn things on/off to keep the interface more clean and streamlined. If they need more help, it is available at the touch of a button. Side note, added this link to a small video on the education mode on 8/14/23.

- Review of the invoice interface with some fake data. Jonathan is working on showing mock-up data and how it may look and flow, as the user interacts with the system.

- Talking about style guides and standards - design systems - This is how we will end up standardizing the look and feel over multiple pages, components, reports, and features.

- Components and using consistent assets (visual and code resources). Both in the design and in the code - design/code once, use many.

- Talking about mobile development and more needs for mobile ready pages.

- We also talked about the placement of certain eye candy pieces such as graphs, charts, and other stats. Leaning towards the reports pages and/or section.

- We briefly talked about Jonathan's research on fracture and breaking up the system into smaller pieces. Being able to have the mountain of tools and options (features and benefits - current adilas system) but only showing what is needed (turned on/off and properly configured) and streamlined per industry and per company within that industry (making custom software easy). Basically, the ice-burg model. As we got into this, we ended up talking about the core product (the main adilas platform) and how we could allow for industry specific interfaces and settings to play over the top of the skeletal type model.

- The skeletal type model deals with the underlying systems... imagine a person with just a skeleton structure. You could then put normal clothes on that skeleton structure. Pretend this is core adilas (plain jane vanilla). Then you could dress that person with industry specific clothing to get all types of different outputs. Every industry has a different look and feel, verbiage, style, flow, etc. That is like putting on specific clothing on the skeletal system.

- Towards the end, Jonathan and I were talking about the shopping cart and how that part of the system really needs some loving. So many pieces converge on the shopping cart and point of sale interface (POS). It is pretty awesome. Here is a small help file on the shopping cart - click here. We talked about some of the known pieces that converge inside of the cart such as smart cart logic, customer loyalty points, tiered pricing structures, discounts and discount engine stuff, inventory tracking, sub inventory, mini conversions, labeling, coupons, payment solutions, sales and promotions, etc. Once it hits the cart, it gets put into the database and starts its life cycle. We talked about how the shopping cart and things that flow into it and out of it are kinda like the heart of the application.

Meeting with an outside developer who is setting up a custom VPS with some data for a company to run his own analytics. This developer was hired by the company to run some other reports and such through his own environment. Our job is to supply the VPS with a copy of the live data so that the developer has a working model and environment that he can play with. Awesome idea and concept.

Anyways, we went over some database stuff, mappings, key fields, data relationships, and how things tie in together. We did some drawings and other tech talk stuff. As a fun side note, it would be really cool if we have some of this same stuff (what makes it tick) really documented out so that other developers (ours and outside developers) could tap in and play. That would be super cool. Future project. As an idea, maybe a tech mode (similar to the education mode or data mode or permission mode) for the fracture stuff. In tech mode, we could get into the nitty gritty details of how things flow, connections, data relationships, decision trees, conditions and conditional logic, switches, validation, keys, etc. Super techy stuff. The tech mode would talk to the developers, programmers, and/or the curious persons who want to see the backend logic and design.

Recording notes and adding documentation to the different entries and elements of time. Lots of fun screenshots in the past couple of days. Here are some fun entries:

https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=22&id=1532 - WanderWays - camp adilas project

https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=748&id=5530 - WanderWays website prototype project

https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=748&id=5864 - internal adilas mock-ups - fracture project

We invited a couple of the guys to meet with Jonathan today. The main topic was the shopping cart or internal cart. So many things go on inside of the cart. It really is a heart or very viable piece of the equation. On the meeting today we had Chuck, Alan, Steve, Jonathan, and myself. Chuck started out by showing a few shopping carts and point of sale (POS) options from his WanderWays - camp adilas project.

Jonathan then showed us around some of the things that he is prototyping, including the custom navigation options, settings, and custom configuration pieces. We also went over things like the education mode, simplified searches (hide search form fields until needed and/or wanted), and combined searches. Lots of stacking, tabs, and just in time access menus.

After that, I did a small demo on how the cart works and how things get configured and used inside of the internal shopping cart. We switched carts, we did discounts, assigned customers, restored quotes to cart, added notes, payments, and all kinds of options. See attached for a small video recording of the walk through.

The last part of the meeting was dealing with some critiques and ideas from the different guys on the meeting. Good stuff and making progress.

Updated - as of 2/3/20, two new video links were added (see attached) for concepts of the invoice mode (mock-up for fake data) and also a proposal for the education mode and how adilas fracture interface could inter connect with the adilas café project. See the attached videos for some overviews.

Emails, follow-ups, and watching some new videos passed over to me from one of our designers. See this element of time to see the new videos. They are concept art and mock-ups for our future navigation system - code named fracture.

https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=748&id=5868 - see the attached videos for a sample of the interface we are designing.

Working with some of the domain names that we own. Pointing them to the main www.adilas.biz website.

Steve and I were going to be meeting with Kelly, but she ended up getting delayed while traveling and security in the airport. We ended up having our own little meeting. Good stuff. Here are a few of the notes from what we were talking about:

- Businesses need all of the deep functionality, they just want it as hidden as possible. Smooth and pretty just feels better, even if it does do as much.

- What if we keep flipping our model? What we mean here is... as a client or a rep keeps asking for more and more, what if we help direct them in such a way that we can get it done? This could be done by meeting with them, planning out what needs to be changed, offering solutions, listening, and taking down notes. Lots of possible options and then we gain from the source vs being pushed away from the source.

- Steve and I talked about the concepts that we are built on vs the code we are built on. Straight up, the concepts that we have built on are 100 times more valuable than the code that we have built on. Our code set is 1 of 1,000's of possible solutions. However, the main core concepts, those will need to be used every single time that someone does what we are doing. Even though you can touch some of the concepts, there is huge value there.

- We were talking about ways to get funding and the down sides to that. We talked about getting overextended and having huge amounts of debt. That is no fun either. Other talks about possible funding sources such as: grants, selling our services, getting partners, investors, loans, venture capital, donations, and leveraging other assets.

- MVP - minimal viable plan (the p could be plan, product, etc.) - I like the plan option for what we are doing and working on.

- What about the adilas marketplace (adilas world)? Lots of options out there as well.

- Everything that we see is fracturing into smaller and smaller pieces. Development process, permissions, settings, servers, API sockets, single tools vs bulk tools, tracking needs, etc. Fracture is the key word. Kinda like "Legos". We may need some blue ones, red ones, and some yellow ones. It just keeps going and breaking down into smaller and smaller pieces.

- Business management and who will take care of what

- Pain and virtual bleeding sometimes help to drive us towards change

- Somewhat of an open source type model

- What is our direction and our pace? Pick a direction and then let it grow. In some ways, it feels like we pick a direction and then plant the seeds, then in a day or so, we dig it up to see how it is doing. I think we need to pick a direction and let it grow a bit.

- Our model has always been slow and steady...

- We are only able to move forward as we get funding - we get funding from...
>> Reoccurring revenue
>> One time services
>> Seed money
>> Donations and other sources

- We are stable currently

- 3 things...
>> Look at what we have - deep, deep
>> We are building daily - progression
>> We help you by bringing value - multiple ways
-->> Low cost for what you want
-->> You are able to move the system in the way that you want it - allow custom

- Maybe make it known what we are spending on new functionality and R&D

- This is who we are... we are who we are and we plan on maintaining that

- We need to take things with a grain of salt

- Our current direction is directing projects over to one main source (Cory) and then diving things out from there - a director of development operations - Steve and I have decided that we will let this play out for awhile before making a major change or shift.

- Walls and helping to sterilizing things - getting some separation

- Like an essay - tell them what you are going to tell them (prep), then tell them (main content), and tell them what you told them (conclusion)

- You can do that? or You can do that! - We love it!

- We have a team that helps and supports us... that is huge

- We, as a company, need to have our clients get in line. Sometimes we give preferences and special treatment. We need to help standardize things.

- As a skill, we have people saying that they are proficient in adilas as a skill set. Pretty cool.

- Constant development and pushing the ball forward. We are building and refining every day. Keep it going!

Tons of email. Also working through some new 2020 payroll changes and new calculations.

I got an email from Jonathan dealing with some cart ideas and concepts for fracture. See the link below for some of his ideas and thoughts.

https://adobe.ly/33DwR4i - cart ideas and permission/roles ideas and sub dividing into smaller and smaller pieces.

Back working with Russell on the cart and flow that is needed. We spent quite a bit of time today talking about barcodes and how we are currently doing that process. The idea came up that maybe we could create an aggregate (summation of sorts) for barcodes. We currently have 5 main tables where barcode are stored. That may seem random, but it's true. We may want to combine those value into one table vs doing a full text search on thousands and thousands of rows within those other tables. As a side note, barcode may be on parent items, sub inventory, my cart favorite buttons (preset code), recipe/builds (kits and groups), and even flex grid (custom tie-ins). It gets pretty deep, pretty quick.

We spent quite a bit of time talking about aggregation of data, efficiency for searches, and even down to the fracture level (future project for adilas). We talked about our current goal to fix up and update the current system, while still looking ahead to the full fracture type interface and layout. As we go forward, some of new projects will be prepping the way for where we are headed in the future. Good stuff.

Great little meeting with Jonathan Wells. We had Steve, Cory, Jonathan, and myself on the meeting. Cory was only able to stay for the first little bit. The main subject was dealing with a dashboard of sorts and mock-ups and samples in the fracture interface (future project for adilas).

Super cool mock-ups, tons of potential. We are going to be pitching some of these mock-ups to current and perspective clients. See attached for a number of screenshots.

Some other topics that we discussed are: investments, prototypes, reverse shopping carts (brining products into the system), global master lists, virtual catalogs and being able to copy values from the catalogs, predictive buying and selling trends, thresholds with maxes and mins, and other topics. Good stuff.

Today is Memorial Day. Pretty quite on this front today. Steve and I were the only ones on the meeting this morning. We ended up chatting about enterprise and aggregated systems. We need to make sure that the traffic and flow of data can go in both directions - up and down (to master and from master). We also talked about tons of other topics and lessons learned. We are constantly refining our model, what we offer, and how we do things. Just part of the game.

Some of the topics that we were chatting about were things like:

- Flex bubbles and concepts of the data assembly line - trying to keep operations and accounting running parallel and allowing flex to enter the equation as needed. Bring things back together with checkpoints, permissions, dates, and known phases. 3D depth, stacking, and layering to record and let the story play out. Lots of data assembly line concepts.

- Helping our developers move from the snow owl theme towards fracture. We are currently working on a look and feel them of snow owl (just a name for the current version and look and feel). What we really want to do is keep building in such a way as to get to a future project called fracture. This is where everything starts breaking into smaller and smaller pieces that may be configurable and controllable. The whole thing keeps sub dividing. So, we plan on accepting that and are planning on capitalizing on that natural occurrence of things splitting into smaller and smaller pieces. Everything is headed into sub level of controls.

- As we move forward, what would that take and how does it roll out (current to future projects)? Trying to get our minds about how this whole thing will unfold.

- As part of the conversation, we were talking about how accounting and CPA's help keep things together, once operations have taken place. Eventually, everything ends up as accounting. If we can help in that process (from operations to accounting), that helps companies become more sticky (wanting and needing our products and services) through their accounting and CPA's.

- A big part of our job is pioneering the vision and bringing both operations and accounting together. It takes a lot of hard work, ideas, good data, and lots of dreams. Steve and I love the dreaming and brainstorming and problem solving parts of the puzzle. Good stuff.

- Once you get some motion and momentum, it seems to be easier to go in certain directions. Part of Steve and I's job is to help get things started and get that motion and/or momentum going in a good direction.

- We need to give Wayne some more power in order to do everything that he needs to. He is doing a great job.

- This is silly, but we went to the corp administrator page and talked about some older pricing and verbiage that was on that page. Here is some text from there. Just for fun...

Submitting Ideas, Custom Code & Developer Rates

The adilas staff are constantly adding to and improving our business platform. We love your feedback and ideas! Just email us or let one of our reps know if you have any needs or suggestions. Many of your ideas may be incorporated for free and then passed on to all other users and companies free of charge. This is how we share the love and give back to the community. A huge portion of the adilas platform has evolved from great ideas from different users like yourself.

When you submit an idea or suggestion it will go into the general adilas "to do list". We then pull from this list according to priority, time, and needs. There are no promises as to the specific timelines or release dates for when or if ideas will be used. All changes we make that come from our general to do list are completely free to everyone.

Entering the "custom" or "priority" level...

If you have a specific idea that needs priority or needs to be custom-built, just let us know! At this level, we do charge for these changes.

Here is how things work in the custom code arena... Adilas, LLC. retains all rights and possession of code, assets, functions, and features (including custom-built code). Your data is yours, but all of the code assets and code libraries belong to Adilas, LLC. As much as possible, it is adilas's goal to reuse, resell, and permission out new projects and features to other adilas users. This becomes part of the free upgrade process that all adilas users benefit from.

We use the following as our general guideline on rates and fees:

• Submitting An Idea or Suggestion - Absolutely Free! :)

• Hourly College Intern Time - Quote or $35 to $50/hour. This could be for either design or development work. This is great option that both saves you money and helps one or more college interns get the skills to pay the bills. Adilas interns work directly with the main adilas staff to get the work and projects done.

• Hourly Adilas Development Time - Quote or $100/hour.

• Custom Interfaces - Quote or $100 and up. A simple page with 10-15 buttons will run about $100. If it gets more involved, we'll give you a quote that fits your needs. We also allow you to literally "dream it up, and we'll help you wire it up!" We are happy to work with paper and pencil mock-ups, sketches, digital diagrams, or schematics, and even designs from 3rd party designers. No problem, we'll help you wire it up!

• Custom Data Imports (parts, inventory items, customers, vendors, etc.)
Quote or $100/hour. Most imports, from Microsoft Excel, come in between $100 and $200. You provide the data file.

• Simple Custom Documents or Forms
This could be any simple Adobe PDF file, custom report, MS Excel document, or CSV file. - Quote or $100/document. Advanced documents or processes are by quote only.

• Full Day of Development Time
Block of Time (at least 6 hours and up to a max of 8 hours) - Quote or $500/day. Must schedule with developers and get approval.

• Full Week of Development Time
Block of Time - 35-50 Hours - Quote or $3,000/week. Must schedule with developers and get approval.

• Full Week with a Developer Onsite
Up to 6 days at a time - Monday/Saturday - Quote Required - $5,000/week. Must schedule with developers and get approval. This option may also include a place to stay and airfare if needed.

• Full Project Match
Quote Only - We figure out a project together and Adilas, LLC. will match and/or exceed what you and/or others put into the project (possible group effort). We, at adilas, need to see a pretty good value in the projects or features that take this route. :)

These rates and fees are "ballpark" only... They are provided to help you get an idea of what is possible and to help you determine rough budgets. If you can dream it up, we'll give it a go and see what kind of magic we can do... We love this kinda stuff! Yee Haw! :)

As a reminder, the only required fees and costs to use adilas.biz are your normal monthly fees to use the system. All other costs are done at your consent to play in the custom code or priority arena.

Copyright © 2020 powered by adilas.biz

Shannon and I had a good session and talked about where we are going next. We've been working on the presentation gallery for weeks and months now. We are getting close to finishing that up, at least for this round. We determined that we will start planning and preparing for an important project for us called "fracture". This is the next level we want to take adilas to. It included concepts like: 3D building blocks, world building, data assembly lines, beautiful and configurable user interfaces, permissions & settings, and dynamic paring. Super cool stuff.

See the bottom of the attached document for some of our concepting and brainstorming. We want to present the vision of where we are headed. We want to start tapping into the raw potential of what we are doing. The potential of what we are working on is far greater than all of the code and pieces put together to date. The sum of the whole and where that could go... It's good, I want more... Good stuff.

https://data0.adilas.biz/top_secret/help.cfm?id=483&pwd=building - help file that talks about world building concepts

Kelly, Steve, and Wayne were talking about test driven design. There ended up being 7 people on the morning meeting call. The first 45 minutes were mostly Kelly, Wayne, Steve, Cory, and myself. The other guys waited until the end. Here are a few of the topics:

- What is important to the clients in their interfaces? Small disconnect between what is possible, what is available, and how hard/easy is it to use. Also, what if the client doesn't know that a certain function and/or feature is even an option? Education, user interfaces, configuration, training, speed, and tasks at hand.

- Light talked about some of the fracture concepts such as being able to turn everything fully on/off, show/hide interface pieces, mass settings (corp-specific settings and/or industry-specific settings), make sure those on/off toggle switches cascade through the whole system. The iceberg approach vs the mountain approach. Same amount of data, just the approach and perception changes.

- SOP's for adilas developers, adilas reps, adilas consultants, adilas setup people, etc. SOP is short for standard operating procedures. Getting things more standardized and organized. Be able to scale and do it with style.

- On the cart, currently we have some corp-wide settings that help the user determine what they are searching for (items, flex grid tie-ins, recipe/builds, cart favorite buttons, barcodes (mixed sources), and sub barcodes. As we were talking... Steve had the idea of allowing the corporations to check what they search for and in what order to do the search. Currently, they have to chose one of our drop-down cart quick search settings and we then do the search. Steve was thinking that maybe we let them tell us what to search and in what order to do that search. Great idea. Just wanted to record it. Currently, the corp-wide settings is #37, but that may change. Search for it by looking for "mixed sources".

- Along the same lines as above (cart search and scan options)... what if the corporations could set up what they want and then each user could tweak that on a per user basis, if needed. Just another thought. More preferences and helping the system be more effective in the searches.

- Dustin is interested in doing some of the test driven design stuff. He jumped on and was talking to Wayne and Steve about his interest level.

- Two reoccurring themes keep coming up... They are structure and getting more organized. Interesting.

Shannon and I were texting back and forth and she couldn't get on to the GoToMeeting session. In the meantime, Wayne and I going through things on servers and Git and bit bucket (code repository stuff). Shannon and I did end up jumping on a Zoom meeting to touch base. Our plans for Thursday are to finish up the presentation gallery outline, break it up into smaller pieces, turn some of it into smaller elements of time, and then to start working more and more on the future plan for what we are calling fracture. More info will be coming as we move forward.

Shannon and I had a good pre-planning session for doing some planning. Asking ourselves questions and just recording to do list stuff while we are actually doing the planning. Basically, planning the planning - if that makes sense. See attached for a bunch of random notes - no special order - just dumping at this point. Heading toward fracture stuff.

Fun concepts of a million dollar dreams and concepts of a stone soup approach to get there (million dollar stone soup). Lots of things need to be mixed and blended to make this happen. Let's get a big scoop out and start mixing... :)

Met with Russell over a Zoom session. We started out talking about settings. Those are awesome, but sometimes we need to ask ourselves, just because we can doesn't mean we should. There is a point when too many settings becomes too much and it actually becomes a burden. For example, super small settings for preferences between icons or spelled out words for invoice payment status (fully paid, not paid, partially paid). Does that matter or would that be a good setting? The debate continues.

We got into talking about the fracture project and where we are headed. He has a ton of ideas on this subject. We went over his dev tools, prototypes, and other mock-ups that he has. We spent the whole rest of the time talking about fracture and what we would like to do there. We could have gone longer, but ran out of time. It may be worth it to get in there and record some of those ideas and mock-ups that already exists. I was impressed just watching what he was showing me.

Zoom meeting with Russell. We were talking about the dual ship model (older adilas system and newer adilas system - where we are headed). We spent some time talking about plans, needs, and requirements. Part of our plan needs to go through each section of the application and decide what is needed. Good planning on these sections will be awesome and will hopefully help us take inventory of what we have and what we want to keep, get rid of, and even upgrade to new functionality.

We talked a lot about the progression and natural growth of systems and applications. We were drawing diagrams of a circle - core and then add-on or bolt-on additions. Pretty soon, as soon as you get out a ways, the circle or core model starts looking like a flower vs a circle or core. We talked about how, you have to let it grow naturally and then eventually you rewrite it and then start over on the same progression cycles. That seems to be how things develop.

Russell and I jumped into some code review on the new corp-wide settings and defaults. We merged in some files and pushed up the new files to all servers. The new section looked great and hopefully will be accepted - sometimes we have people who can handle change and complain if we change anything.

After that, we jumped on a different project and I got my first look at the new add/edit payee/user permissions and saved roles (preset permissions and saved settings).

We talked about smaller micro processes that could play both ways between old and new. Some of these things were full on structural changes. The more we can play at the source, the better. This discussion got into talks about stateless services, language independent decisions, and even potentially looking at other coding languages. Currently, we have been using Adobe ColdFusion and that has worked great. There are times and seasons but we are being encouraged to keep looking around.

As the discussion continued, we started talking about planning "what" we want vs "how" you want it. I think our end goal is what we want... and it may not mater as much on the how we get there. Some of this comes down to research, preference, and skills. Those are not the only things, but we need to keep this door open right now.

At the end of the day, I kept recording some new ideas on my random tick list for fracture stuff. See attached.

Russell and I merged in some code and then talked about projects. We also spent some time talking about fracture stuff (where we are headed). Russell has a lot of good information there and has a dream and a vision already in his head. I'd love to capitalize on that see if we can get those ideas out of his head and on paper and/or recorded somewhere. Here are just a few things...

- Russell really wants to organize the core with specific sections. He has a drawing that he does to explain some of the pieces. Basically, imagine a center core that is round. On the top and both sides, there is a known slot where something may be inserted into it. Imagine a slot for special logic and/or a controller. Another for classes and/or a model (structure of the objects and pieces). And yet another for the visual or view portion. Somewhat of an MVC (model, view, controller) type model.

- Relating to the core with special insert points, each of the insert pieces (logic, view, what) would allow for both industry specific code and custom code. Basically, You set the core up so that it can and is able to handle things (code, views, logic, other objects) that change the core without hurting the core.

- Along those same lines, for fracture, Russell would like to have two different types of API's - One would be a rest (URL or path based) API. The other API socket would be for things like graph QL or some other type of API socket.

- One of the goals of this new interface and/or application would be to have the ability to reach out to other industries and be able to swap out the pieces to virtually make the application or platform switch clothes or be able to change as if the application was switching clothes and/or modes of operation. Dynamic core, known plug-ins per industry, and ability to flip/flop without affecting the core. On purpose built that way.

- What if we could... be able to... handle all custom needs? Be able to handle all industry specific needs and all core needs? That would be a very flexible and dynamic architecture and/or design. We want to head in that direction.

- We used to say something like... You dream it up, we'll help you wire it up. What if you could say, Dream it up, you wire it up? Basically, give the power to wire it up to the persons who are using it... That would be so cool. Real live world building and/or setting up their own data assembly lines. That would be super cool.

- Headless CMS (content management systems) - Headless CMS storage for your data. We offer a huge and configurable database and backend app or toolset. You get to decide how you want to use it and what you want to do with it.

- Along those same lines... if we want to reskin the app for a different industry, we do the same thing that our users do, we just do it in bulk to accommodate more than just one company at a time (think bulk setting changes and/or industry specific themes or modules). It is still a headless CMS storage system for your data and your business flow. It just deals with are we configuring it or are you (as a company or user) configuring it. We both use the same tools.

11/11/2020: Paused due to cost and lack of funding.
7/28/2020: Jonathan and Kelly working on ways to innovate- pushing fracture forward, etc.

Met with Russell and did some code review, pushed up the new payee/user homepage code, and also went over a number of other projects in different phases of development. We looked at mock-ups, code, and finished products. Lots of good stuff coming down the pipeline.

Small notes about fracture and building a reusable platform. Imagine - any developer can succeed using this platform. When they succeed, we succeed. Russell was giving some analogies about a platform with a virtual city on top of the platform. The platform would be held up by a core or core engine (backend database, code, and software package). Developers could then build on to or off of that core. As they do, they have to help and support that core (a way to give back). 

Along those lines, we were talking about open source vs non open source. This is just a what if... what if the core was open source. We could then build out the adilas fracture core as a non open source project. Basically, stacking models on top of the core. It might be worth exploring those ideas.

If we share the load and help others to succeed, then we have less enemies and they, the other developers, help to support the core. Interesting ideas. See this link for other notes from today, dealing with backend offerings and structure.

There were 4 to 5 of us on the morning meeting. Wayne and Steve were talking about storage solutions and options there for client-specific storage (potentially even in different places per client). Apparently, they had been on a meeting since 8 am. As a fun side note, we need to make sure that each system could be configured to both store and retrieve stored content from different places. Currently, we push all images and scans to the local box on a per server basis. We also push all bigger files, graphics, PDF's, and other document out to the content server. What if we could configure both of those pieces per client? That would be super cool.

Along those lines, we could specify a location say on AWS where there images and content could be stored. We would then directly charge those clients for the storage of those files and assets. Currently, it is all part of the monthly fee but no one has been watching or monitoring how much storage space that really is. We have one client that has well over 200+ gigs of outside files that we are storing for them. To put this in perspective, google drive allows for 15 gig for free and then you have to pay. They are at 200+ gig. They add to it daily as well. We have other clients that have thousands and thousands of scans and images. Once again, unmonitored. We need to be able to configure the systems to handle those changes as well as pass those file storage and hosting fees on to the client. It's their data, they need to pay to store it (within reason). Also, some of the storage is stored over years and years.

There was also some talk about having active and inactive content and files (levels within the storage solution). For example, new files, images, scans, and media could stay active for a month (or whatever time range). Then they (the files) could be moved a little bit deeper but still exist. Think more of cold storage vs active or hot storage. This is all just a dream right now, but it may play into some of the configuration needs for fracture (upcoming adilas project).

Danny and Steve were talking with Wayne about labels and what not. We need to get Calvin's label tool fully online and working over the web. Currently, the adilas label builder is a custom Window's app. Things keep changing (for labels) on a constant basis. Danny wanted to make sure that Wayne knew about some of the label changes so that we didn't overwhelm him with tons of files and merge requests.

The guys were talking about adding in a fee for those clients who use Metrc - a state level 3rd party solution for sales and compliance. That would be great as it literally costs us around $20K per month to keep up with Metrc and their changes alone. Pretty crazy.

Sean is going to be reaching out to some of our current clients. Steve and Sean talked about some current and future plans to reach out to different clients to see what they need and how we can help them. Steve was talking about small custom homepages, or small dashboard type interfaces to help them get around and move around in the system efficiently.

There was also some great talks and ideas about doing live or on-sight training by our clients for new clients in the same or similar industries. Basically, instead of having an adilas rep train someone, have an active client in that same industry or line of work train the persons. That allows our clients to get the training, from the source, and our clients could make some money by charging to show and train the clients using their existing systems. Some cool ideas there. Use the client's facility and train other people in your same industry by charging them to train them.

The last main topic of the morning was dealing with servers, IT help, and server resets. Wayne and Steve are going to be looking into options of using the existing IT staff of our commercial web hosting companies to help with extended server and support issues. They already have full access to the servers and know the infrastructure at the hosting company. It would be so cool if we could sub some of that maintenance and hot fixes out to them. Both Steve and Wayne will be making calls and setting up meetings to advance that ball forward.

When I got on the call, Steve and Sean were already talking about sales. Sean said that as he was calling some our clients, they wanted an easy way to add multiple things at once to a PO. Basically an add bulk option. For example: Say you were adding in bowling balls and you entered the main bowling ball product name. It may show you the 6 pound balls, the 8 pound balls, and the 10 pound balls. Currently, you have to click on one and say - I got 3 of these. You then have to do the search again and click on the next ball and add those. They would like to be able to add multiple values at once.

As a side note, there has been mentioned earlier, options for PO's to be like a reverse shopping cart for PO's. Currently, the shopping cart allows for a simple search and multiple items may be added to the cart at once. We would love to make something similar for PO's. Just another request for such a feature.

The guys were talking about internal funding options and even selling some of the code and development for certain business verticals. Say for instance WanderWays (camp adilas). We have already put in $60K+ on that project. If we wanted to, we could virtually sell all of that prep work and R&D and then let someone else run with it. Basically, a way of pioneering ideas and concepts and then finding good owners for those pieces. All part of an adilas core platform and virtual ecosystem that rides on top of the business platform. Fun ideas and exploring.

As a side note, we keep talking about "fracture" as an upcoming project for adilas. In a way, it is already happening. Maybe we just need to keep letting it happen and help it along the way with some loving guidance with little tweaks here and there to make sure it fractures like we want it to. Just for fun, I have a post-it note on my desk with a date of 6/22/17 with a statement from Steve about fracture. He said that it might be a fun business name. Over three years later... it is already starting to happen. I'm also excited about the other ideas that we've been gathering up over the past months and years that go along with that. Good stuff.

Later on in the conversation, we started talking about checks and balances. We drew out a model with the US government and the three branches (legislative, judiciary, and executive) and talked about how they help to run checks and balances on each other. We, at adilas, would love to have some pieces in place that did similar things. They could run independently of each other but could also provide some checks and balances to each other. That would be really cool. Just for fun, see attached for a quick screenshot. We are still figuring out the adilas side of things, but we liked the concept.

We also talked about core pieces, outside 3rd party solutions, and inside 3rd party solutions (hybrids). Lots of options. Eventually everything that we have has to interact with the core or main platform. That's where we need to focus and put the correct checks and balances in place.

Dealing with sales, Steve and Sean were talking about Danny wanting to get CPA's (certified public accountants) on board and pitching our services. If a company gets help from their CPA, gets tax help, tax prep, and other consulting, it makes our product more sticky (in a good way). Fun discussion and conversation.

Going back to the adilas checks and balances, we offer a ton of different services. In a way, all of those services could fit under the adilas marketplace. That's not a for sure, but we wanted to record the idea.

The last concept we were talking about was the system core and platform and how we could virtually design what verticals go on that platform. As they get developed and designed out, we could find people (other businesses) that wanted to run those business verticals. If anything went wrong or whatever, we could always buy them back and run them from our internal teams. Lots of options. In a way, we help people and companies to build and run their own white labels. We have developers, a huge dynamic platform, and tons of other services. We also allow others to build their dreams and run it on our platform. Lots of options to mix and blend.

Shannon and I jumped on our normal Tuesday meeting. Right as we started, we got a call from Russell and he wanted to show someone the things he was working on. Basically, a small breakthrough on his current project and just wanted an audience to bounce ideas off of. So, we invited him in to our meeting. As a side note, Shannon, Russell, and I are all brothers and sisters.

Anyways, Russell started showing us some of the new help file options that he is working on. The older system had one help file per page as a whole. Nothing super special and very much a set static page. Some of the new code that Russell is working on is a way to break the help files up into sections and dynamically make them popup and be more consumable. It also offers new options to put in business vertical, industry, or even corporation specific help options. All of the new stuff is there, hidden, but showable on demand without much effort. Light approach on the education mode that Jonathan Wells introduced in some of his prototype demos for the fracture project. Great stuff.

We ended up bouncing all over the place with Shannon, Russell, and I for the meeting. Here are some other notes:

- Help files can seem like a mountain of info... what if we could take those mountains and break them up in to smaller ice bergs of information. Once again, make it more consumable and a nicer presentation.

- Help files could be expanded into courses, videos, quick ticks, settings, and other help or education material. Don't limit yourself to just a plain old help file.

- Russell is prepping and paving the road for where we want to go and who we want to be. Some of that prep work will need others to help fill in the gaps but the virtual roads and ways will already be built. That's fun to think about.

- After Russell was done with his demo on new help files and options for helper sections, we switched and I pitched a few of the concepts that Steve, Sean, and I were talking about earlier today. See this element of time for those notes.

- Switching over to the adilas core platform concept (pretend that you have a floating platform that is supported by the adilas core - different businesses, industry specific options, modules, tools, features, and a virtual city with different buildings and structures resides on the floating platform)... Russell had a number of comments on this subject. He was going so fast that I couldn't catch everything. I should have recorded it. He has some great insight on this topic. Here is what I caught.

- If playing on the platform, what are my boundaries? What are the rules? How do I play? and What will all of this cost? These were questions that Russell wants to know and others who want to play will also want to know. A good starting place.

- Are there maintenance fees? commissions (possibly both ways), license fees, server fees, etc.? Put out and post all the specs that you can - help to sell it as a service. SaaS - software as a services and PaaS - platform as a service type models and mixing the two of them.

- If someone makes their own module, we would love them to be able resale it and/or offer it to others. Once again, what are the rules?

- Imagine being able to quickly choose from modules to build a custom or industry specific tool very easily. That would be awesome.

- What about getting a portion or percent of earnings for using the adilas platform? Just a thought.

- We need to charge based off the components that we offer and what they use. Be able to pass on certain client costs directly to our clients.

- What if there was a certain fee to get in there and play? This could be a service type contract or whatever. Just spitting out ideas right now.

- Back to rules and costs for certain things... servers, domain names, databases, storage, files, images, scans, documents and files, throughput, API socket calls, different modules, components, other pass along charges, 3rd party prices, etc. List it out.

- We could make it profitable by building it, supporting it, selling it, or even pitching it. Lots of options.

- We could also offer other services (virtual marketplace of services). One of which could be consulting for other companies.

- This is a side note, but we have said over and over again, that the services that are needed are more than 10 times the value of the actual product (adilas software). Whoever owns and/or participates in that part of the puzzle will be doing well. Just a small side note.

- If we build it correctly and publicize it correctly, people will come to us and say... Can I do this or that? I want to play.

- It came back to being able to make the application into quick plug and play modules that could interconnect, interact, and turned on/off very easily.

- We talked about pitching ideas... in multiple directions. People pitching us ideas and we, as a company, pitching ideas their way.

- We want really generic tools that may be mixed and blended as needed. Yet, being generic, you could also put a spin or small tweak on it to make it custom in a heartbeat. Quick and dirty changes.

- Help others realize their dreams. Have the ecosystem ready for those dreams to be built and realized. Russell kept saying, people will come to us, once they realize what they can do.

- Speaking about frameworks, conventions, and prepping for growth in different areas. Make it easy, pretty, and powerful. Prep the way...

- Endless possibilities, being able to mix and match to get the perfect flow or perfect mix of tech, ease, and power.

- If we open up our model, we could potentially even buy some of our clients products and pieces if we see merit, need, or wants. Open model.

- Both internal and external modules need to be able to play together.

- We did talk some about IP (intellectual property) and who owns what. It all needs to be spelled out in the rules and how you play the game.

- Think of Legos (kid's (big and small) building blocks - that interconnect) - We may need to make certain things opensource and standard plug-and-play type technology.

- Small talks about limiting and protecting our clients. We may certain limits in order to protect all parties. No limits sounds awesome, but that usually means that someone will abuse things and possibly harm other players. We also talked about ownership and other intellectual property stuff here as well.

- Just some ideas for core pieces that we, as a company, may want to bring up... adilas core, adilas platform, adilas shop (development), adilas services, adilas market, adilas university, etc. "See a need, fill a need" - Robots the animated movie.

As a funny side note... Russell was talking and I was scribbling notes as fast as I could. Front and back of multiple post-it notes. We may want to record the next session, Russell has some great ideas along these lines. Fun.

Cory jumped in and was checking in and asking some questions. Danny had some questions on sub inventory and we went over things and even did some backend database stuff to do some show and tell on the subject. Steve and Sean were talking about sales stuff.

After everybody else left, Steve and Sean and I were talking about sales.

- Where is the sweet spot? If you find that, that could make all of the difference. Steve is seeing the sweet spot a little bit above mom and pop shops and even up into multiple locations or multiple corporations. That seems to be our niche (what we we can tell right now).

- The other major needs are in the high level operations and high level accounting. As a side note, Steve and Cory are working with a CPA firm and they are actively funding a number of projects - meaning the CPA firm.

- We currently have a small internal audit going on for code, processes, and procedures. We are excited to see what that turns over. We are hoping nothing too crazy but hopefully a focus point and/or a way to make things better and better.

- Lots of talks about figuring things out and being your own style.

- We are where we are, size wise, and will keep growing, as naturally as possible.

- Using that old notion to use other people's money to fund your business. We would like to keep working on getting other clients to keep putting in money to help pay for our development efforts. They get what they want and we keep pushing things forward.

- Steve would like to keep expanding our model like we have the custom code and development side. We have made some great strides there in the last six months. For the record, it has taken about 5 years to get here but things are really starting to click and lightbulbs are starting to go off (ideas and comprehension).

- Being able to offer a robust solution and allowing for our customers to customize and add customization seems to be a good mix for us.

- There was some talk about being able to show our current clients what we have to offer. Sometimes we or they get so busy, they may not even know that new features are available and may help them in their business and/or solve a current need. It comes down to communication and being able to help and show those things. It gets pretty deep some times.

- Steve and Sean were talking about menu boards and other tech stuff. It just keeps going. There was also some talks on hardware/software bundles and what not.

- Pain is a good indicator of where we need to focus.

- One of the things that we do well is trying to figure things out and tweaking what we've got to make that happen. We also try to tweak and figure things out based on what our users are saying and what we are finding out.

- Steve is making business decisions. Our top three priorities have been: 1. Servers and stability, 2. Cash flow and sales, and 3. Look and feel. Not done yet, but the servers are getting close to being done. That is awesome. The next one, cash flow and sales, is starting to move up the priority list.

- Aggregation and talking about where we want to go... Right now, we lean very heavily on the transactional data structure. We would love to add different levels of aggregation and moving out of the current dependence on the transactional data level. As a thought... think about daily transactional data being aggregated into daily records, weekly records, monthly records, and then annual records. Think how fast some of that data could be searched vs millions of transactional data with table joins, indexes, and crazy deep stacking and logic. Get those numbers out on their own and become quick and searchable. That would save tons of horsepower and server usage. Currently, we have a virtual super highway built directly to the transactional data. It works, but that is not the long-term solution. The long-term solution is to get into aggregation.

- Things are already fracturing (fracture) by us cutting things into smaller and smaller pieces. We want to keep that going. We are working hard to figure out our model and where best to focus.

- Our mission statement, from Steve, is to help our customers succeed. That is pretty simple.

- If a project is part of accounting or operations, cool, we are interested and open to discussion.

- We are just a big toolset.

- Dealing with tools, JSON (javascript object notation) is a tool but somewhat of a lightweight tool for retrieval and searching. It is great to store things but not so easy to use in high availability type models where everything needs to be edited, searched, and tied together. Make sure and only use it where it makes sense. We've been burned there before. JSON works great if you need to store something and then you only need it on a 1 to 1 ratio (no joins, no cross ties, and/or no dynamic searching). There are other tools that have performance and built-in options that are better.

- Predictive use of data - The more we can prep and get things ready, what is close at hand, the quicker we could make things. This almost gets into AI (artificial intelligence) and guessing what the user or client will need next. Prep with a purpose. Think of an artist and their working pallet, they surely have tons of supplies, brushes, paint, rules, pencils, etc. However, they know what project they are currently doing and thus adjust their virtual artist's pallet to match that job. As the job/tasks changes, they may need to alter what their pallet contains. That is totally ok.

- How do we help solve some of these needs... We aggregate, we split, we divide, we are trying to move into predictive realms, etc. Things are fracturing right under us but that is part of what we are trying to do and/or capitalize on.

- Our current model is very heavy on the transactional side or transaction based level. Eventually, we want to keep pushing into aggregate or enterprise type levels. Think of master lists, master catalogs, summing up data, quick stats (totals, counts, graphs, etc.), normalizing data, and being more effective at higher levels. 

- Our model seems to be moving more into a customizable reoccurring monthly platform as a service (PaaS) with all of the underlying services that help and support that model. We have dished things off for years to outside 3rd parties and independent contractors. We are seeing that we could provide both, the dynamic business platform as well as the supportive services that go along with that. This is funny side note, but Brandon has often said that whoever controls the service side of the business will be 10 times (10x) more value than the actual platform itself. The business platform is the catalyst and keeps things linked together, but the services help keep it going, building, and create the level of satisfaction that is needed. In Steve's words, it makes companies sticky - meaning they want and rely on our products, services, and business platform.

- People play in these areas... a reason, a season, and a life time.

- Growth and progression over time.

- Super glad for the water that went under the bridge - aka lessons learned.

- Delegation and association - In an employee model, they use delegation a lot. In an independent type model, you may end up using association more than direct delegation. Small but interesting word play.

Steve and Sean going over sales stuff. They were talking about the Apple Model and how someone greats you when you come in and then you could be helped by someone else by going through some sort of simple queue type process. Danny checked in. After that, we helped Steve with his local environment. Both Dustin and John Maestas checked in. Some small intros were made and what not. John is Dustin's friend. John is just getting going with us on some development projects.

They then started to talk about different versions and generations, for example: generation 3 or generation 4, etc. Dustin has been responsible for some of the new versions out in cultivation land and what not. It is fun to see the progress and the changes over time.

After these guys left, we went into a sub meeting of sorts and worked through some things. Sometimes, our clients, want industry specific processes that are fully built out and completely industry specific (super narrow focus and/or paths to choose). As we were talking, we ended up talking about drawing out the processes, pretending to do simulations and different use cases. We also talked about being proactive vs reactive  and/or passive. We really want to help our users out and then let them help us refine it vs waiting completely on the client's input. Sometimes they don't know what is possible, they tend to stick with what is set in front of them.

Often, our clients don't realize that we can customize it (tweak or refine the processes). That seems really trivial to us, but thinking in custom code (what is possible) is a skill. The deeper we go, the more we are seeing that all of our layouts need to be fully customized or customizable and based on settings. That sounds awesome, but that adds a whole other level of complexity. Small and skinny yet totally data driven.

We need to get back to the limited flex grid pages. Make it slick and skinny. We are already using it for Beaver Mountain, but want to make it good to go for all of our clients. This would be so cool, but it will take some more work. Having said that, we really really want to get back to this. The limited flex grid is a way of setting up custom fields and dynamically populating a really small add/edit form that only shows what they want or need vs all of the possible fields.

As a side note, the flex grid table has over 40+ different fields that we can and do use for different things. Imagine is you could setup a simple form that only had 5-6 of those custom values. It then becomes really simple vs too big or too overwhelming. The goal is user defined simplicity, yet still being fully connected and powerful. If needed, we could always flip over to a full or more extended mode if some other field or value is needed. It is almost like layering the interface and the data. Super simple on the surface, but deeper or more rich as needed (layering).

We got off into communications and dealing with outbound messages, communication options, and getting people connected to the correct sub or special pages (combo of communication and navigation options).

Next, we got talking about building out custom skins (wrappers of the logic and data) and how that plays into the mix. We did some light pitching and talking about different packaging and marketing options. Some of the subjects that we chatted about were things like ski area, gun shooting lanes, classes, and then working with people in those industries to build and test out products and services. Basically, have or get a dream, build it, and then use people who are in that industry to test and give feedback on interface, navigation, user experience, flow, and functionality requirements.

On the marketing and sales side, if we have someone who is using our product in a specific industry, that testimonial does tons for helping others in that industry to be willing to jump on board. We have also found that if we find someone who is in an industry and they are willing to help, provide feedback, beta test, and give ideas... that is like gold and helps the process get smoother and smoother. It is amazing how a little bit of icing makes the cake look that much better.

Expanding into other horizons, we really want to do this. Our conversation circled back around to the dream it up, push on it, and we'll help you wire that up type model. You dream it up, we'll wire it up. Making things simple, powerful, and easy. Awesome words/phrases, harder to do, but possible. We also talked about opening our eyes and minds to what is possible. Being able to see and/or imagine is sometimes harder than you think. Once we can see it, the next phase is letting our users and clients catch that vision. Once you can transfer the vision, others start helping to beat that drum and making it happen. Share the vision!

As we look at the MVP (minimal viable product or minimal viable plan) type approach, we get pulled out of the dream land and back into - what are the next step or steps that need to happen. You can't lose sight of the goal, but you also have to make it work (along the way) vs just the dream at the end of the tunnel. Having said that... one thing that has been very successful for us is... get them hooked on one aspect and then letting them go and start dreaming. They'll start putting the pieces together. You just have to get that process started. Sometimes with an MVP type approach and then let it grow from there.

Here are a couple of other topics that were discussed: saved reports and connecting to them, other future projects (fracture), reviewing topics listed above, automated and predictive logic, aggregates and quick starts, templates, build your own processes (data assembly line and flex bubbles or flex pods), and other topics. Good meeting. Lots of new ideas and also firming up some of the older ones that keep circling around.

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.

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.

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.

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

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.

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.

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).

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.

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!

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).

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 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.

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.

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.

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!

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.

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.

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 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.

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 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.

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, 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.

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.

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.

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.

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.

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!

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.

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).

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 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.

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 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?

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!

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.

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.

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.

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.

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!

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.

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.

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! 

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.

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.

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!

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.

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.

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!

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.

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.

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.

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.).

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).

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!

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.

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).

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 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.

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.

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.

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

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

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.

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.

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!".

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!

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!

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!

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.

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.

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.

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.

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

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.

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.

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.

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!

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...

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.

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.

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.

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

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!

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!

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.

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.

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.

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.).

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.

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.

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.

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

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.

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.

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.

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.