Texts, emails, and started recording notes from the end of May. I'm a little bit behind, but there is some good stuff there. I want to get it all recorded.

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.

Checking in on the next couple of projects. One is a repair job, another is a new build out. I've also got to get with some of the guys to push code. None of that stuff was really ready. Left a voicemail with Cory asking for priorities.

More recording notes from 5/31/23. Fun to relive some of those memories and ideas. Lots of good stuff on that day.

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.

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

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

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

These are a few of my takeaways:

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

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

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

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

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

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

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