There were still a few people on the call, but most of this meeting was between Steve, Cory, and Brandon. We went over a number of projects, got some updates, and reports on other projects. We then had a pretty long discussion about 3rd party solutions and them either using the public API sockets or having to have a private 3rd party API socket. There are pros and cons to both. We decided, if they really are a 3rd party, they need to play in the private API sockets so that we can track their requests and activity better. Otherwise, they are just one of the public requests (harder to pin point who or what company is making the calls).

Cory asked for a report on the Flash to HTML conversion project. I reported on that and showed them what I had, as of right now. As the conversation progressed, Steve was talking about a number of industry specific pages and functions that he is working on. Good stuff and I'm glad that he is in there pushing around on things.

The subject switched over to servers and some of the struggles that we are having there. We are working to get things more and more stable, but we keep running into small little things that shake us up. We've made a ton of progress, but it is frustrating because it doesn't seem to get fully fixed. Here are a few of the things that we were talking about:

- We don't seem to fit into a normal out of the box solution - we are a software as a service, but we have tons of custom code, and our setup and flow are very custom. It feels like we don't exactly fit into a certain box.

- As we build, we keep adding on a number of new technologies. That's not bad, but we don't know how all of those pieces play together and where the bottle necks are. It's great if someone else builds the complex pieces and we just use them (like libraries or other outside resources or products). The problem is, if anything goes wrong, you can't always directly fix it. You end up patching or adding other things on top on one an other to get the job done. Too many outside services and dependencies. It creates weaknesses and possible vulnerabilities.

- We've been having issues with Cloud Flare... not that Cloud Flare is the problem, but maybe it's not a good fit for what we have and how we roll. Anyways, quite a few minutes talking about Cloud Flare. Eventually, it comes down to security and efficiency for the IT guys or a more open model but better for the clients (so they think, because they are not as restricted or don't get hard set timeouts). The age old questions... security or customer service... we know that we need a mix, but both parties are screaming at us.