On the morning meeting with the guys. Talking about progression on servers, technology, needs for planning, programming, sign-off, technical writing, user interface, graphics and design, performance tuning, server tuning, hardware, etc. There is a huge progression that is taking place. It doesn't stand still. It always keeps going and pushing things from one level to the next.

Bryan Dayton jumped on and had a question about a custom page that he is doing. We started out and only had 3-4 black boxes for the same page. Now he has 12+ for the same page. He was asking what the plan was and how do we start handling all of the black box requests. We talked about building and breaking and how that helps all parties keep progressing. I told him to push what he has and then talk to the client the next time to see if they are interested in adding in page level settings that will make the whole thing easier for them and for future clients.

Bryan's next question was dealing with sub domains. Most of the adilas servers use a "www" sub domain such as https://www.adilas.biz or https://data7.adilas.biz - The question comes in... what about custom URL's and domain names that use sub domain names such as https://order.swcarizona.com/ and others. We have to go back in and add a variable for the sub domain. Once again, the ball is progressing down the field. More and more settings and permissions.

The next conversation was dealing with an outside code developer (3rd party solution - developer) and them wanting to play with us inside of the code arena. Once again, new territory. Good stuff. We invited him into the GoToMeeting and talked with him. Bryan lead the discussion. We setup some basic guidelines such as a non compete and non disclosure, safe code, clean and top level sign-off, no direct FTP access, a new bit bucket account.

Notes from Hamilton from Full Circle - They are a 3rd party solution that has been involved with adilas for quite a good time (text messages, email blasts, marketing and promotion stuff). They are looking to work with another 3rd party solution called eXPO (a financial solution and payment solution). They want to mix their products with our products to create a super mixed product. Kind of a touchscreen simple ordering area. This is a mix of ecommerce, sales, payments, and texting options. One of the main goals is getting the ecommerce process onto the customer's phones (mobile app). Shooting for a flawless experience that is super easy to use. Currently, they are going through our API sockets but want to build a more native application.

We were talking about proof of concept and getting it into the hands of certain key players (existing clients). They also wanted to show some custom reporting dashboards. This would help with the sales and campaign tracking pieces. How many texts were sent, what was the response, what sales resulted, etc. Getting into the sales analytics and marketing of their different campaigns. Where are we getting the most traction (sales and dollars per sale). If you know your customers well enough, you can then really market them for upcoming events, sales, and campaigns. This is really getting into marketing, sales, and promotions.

Dealing with multiple layers... lots of moving parts. 3rd parties working with other 3rd parties and those 3rd parties working with other outside parties. It gets deep very quickly.

We had some discussions on full API socket access (play at the wall) vs building natively. It comes does to access. Is it from adilas to Full Circle to an outside party or is it Full Circle to adilas and Full Cirlce to the outside development shop. Hamilton with Full Circle is working as a go between and a project manager of sorts. One of the end goals is scalability and who will help us get to that level. The conversation trended toward ideas on white labels and what we have to offer. It doesn't matter who offers it (name and skinning the app), as long as the clients can get to their functionality, they may not care who does what. Lots of possible different levels and phases. We will end up with both long term and short term goals.

Bryan chimed in and was saying that maybe we put the Full Circle stuff on to the adilas servers and we basically use their functionality as a marketing arm for adilas. Fun ideas. It may just be a sub folder on the adilas servers. So instead of pulling things through the existing API sockets, we move their code more inside, and then run native to native vs full API socket access. In a way, Full Circle wants to offer a targeting marketing platform and custom dashboard. They would love to move that functionality inside of adilas vs being an outside 3rd party. Basically, an integrated marketing arm.

The complexity of who has the master database (say more than two databases with somewhat similar data)... if it is local or native, you take out the duplicated data and who is the master.

Steve was mentioning watchers, feeders, triggers, etc. Some of those pieces (backend code watching and feeding in totals and analytics - summing up data and getting stats) will end up playing into the bigger puzzle. It is all part of the marketing and/or targeted marketing efforts. If we combine forces, it could allow multiple companies to gain from mixing technologies. In a way, it comes down to what services are available and how do you offer that to the marketplace? It also comes down to scalability and how things scale (how many pieces are playing and where the data comes from).

One of the problems with API sockets is the ability to control the other parties that are playing into the mix. Steve's analogy was - you need to pick one girl to marry. Basically, as many pieces that you could have under one roof and one code set, the better. That becomes the "system". It is all of the pieces that combine to create the whole.

Going deeper and deeper, we need to focus on the different aspects of a business. Who is going to market, develop, deploy, engineer, manage, maintain, etc.? Each of us, the different parties, could benefit by utilizing the other parties and who does what best. Combining to be more.

I have been tagged to get the non compete and non disclosure ready for both sides. It will be sharing code between companies and needs to cover both sides. It also needs to say some verbage about non exclusive promises (there will be others). One of the big benefits of being first is they will gain traction and the adilas reps will help sale their services. Good plans are developing. Bryan is going to be the point guy on this multi 3rd party mix and match (mini mash up or combo project).

As a side note, we were talking about creating a full custom 3rd party dashboard for Full Circle. We could tie it to their 3rd party solution selection (turning things on/off). We also talked about being able to do some reverse marketing and showing potential, even though full functionality is not turned on.

From Steve - Finding our stride... we are looking for solution minded companies wanting a full solution.

Going back to the railroad analogy. Once the tracks are put down and running... we are hoping that clients will see that potential and basically want to jump on board and go for the ride, using our tracks (the train - look and feel  - may change). If needed, we could build more tracks and get more trains (engines and motors). See this link for some more info on the railroad track analogy. https://data0.adilas.biz/top_secret/time_web_gallery.cfm?corp=371&id=3933

Steve was saying, that some of these outside parties are trying to setup real estate around our tracks and are even paying for what is needed to make it look and feel like what they want. That is pretty cool. We are hoping that others will do the same thing.

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

Different subject - long running queries and tables locking themselves... Alan and Steve were talking about chaining and locking of tables  (both manual and automatic). Basically, the customer queue was locking the customers table. Both of those tables and sections deal with invoices and invoice data. One thing was locking the next, which was locking the next, etc. Chain reaction of sorts. This gets further into the rabbit hole by allowing 3rd party reporting based off of invoices (like a Metrc or other state tracking system). If they are slow to reply, it could cause problems going back up the chain. Basically, a data traffic jam.

There is a deeper and deeper need to be able to fully watch and do traffic control on the actual servers. Basically a monitoring system with stats, graphs, and notifications.

We had some other talks about splitting up tables and databases. Breaking up things, including data and databases, into subs of subs.

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

The last part of the morning session was chasing and following a bug in a custom cart for a client. We had Drea jump on the GoToMeeting session and show us where the bug was happening. No other clients were complaining, so we thought that it might be custom code. Upon looking, that client has 10 custom pages (black box code). We started looking into some code. Alan ended up saying that he would look deeper. Never a dull moment.