Well, it’s still probably just 24 hours, but I have a few more things to do and I’m not sure I’ll be able to get them done in the next 5.5 hours to officially be finished on Monday. It might even be more like Wednesday, but I’m trying for less than a 24 hour slip in launching.

That said, this process was absolutely the right thing to do. Since last Tuesday I have been continually cutting down on what features I absolutely have to have to launch my site and service, and as the days have gone by it’s gone from a general list for 6 days, to a 4-day list, to a 1-day list to a short list. Each time dropping lots of things I want to do, but aren’t 100% necessary to launch.

Without this arbitrary Fortune Cookie Deadline to spur this slashing of to-do items, Id still be working on a much larger list than my original 6-day plan. I might even still be adding more features. All those things still need to get done, but they don’t need to be done while I’m not advertising the site and seeing if I can find Early Adopter customers and doing any customer interviews I can wrangle up.

Since I’m getting close I’ve started to do searches myself on “monitoring” and “alerting” for how Google searches will work, and have found both of those words are used frequently in news articles, so there’s going to be an art about picking the right search terms to get any converting AdWords traffic.

Current I have 1 big item to do, and 7 small items to do before I can really launch. Launching before that would not be a good idea, as these things need to work. Here’s a summary of my to-do items with some techno descriptions.

The Big Item

I currently have 5 servers running in 3 regions (Virginia, Northern California and Oregon) to distribute where monitoring is performed from. All of them also accept web traffic, so they are monitoring nodes and website display nodes.

The way I work my data systems to be reliable, only 1 machine for a particular type of data handles particular types of activities. The rest report changes to that machine, and collect updates from that machine. Normally this is handled by a Database Server, but I am taking a slightly different approach which I’ll expand upon on a later date. This method avoids a problem where 2 machines decide to do something that conflict with each other, as for any given type of work there is only 1 machine that handles the tricky parts.

I call this machine the Mother. Knowing which machine is the Mother of a particular problem is the job of the Mother Mother, or Grand Mother. At some point my infrastructure may get large enough that even this needs a Mother, and a Great (Grand) Mother will be created to tell all the Grand Mothers whats up.

To keep things simple for launch, I’m starting with just a single Mother to do all this work. This will make saving data a little slower, but changes aren’t that frequent with this kind of service, as it’s infrastructure and not a social network. Consistency and having distributed results is more important.

The real benefit of this system is that if the Mother machine dies for some reason (it’s a cloud instance, plus computers break and networks go down), there is already a prioritized list of the next candidates for Mothers, and all machines know this list and will just go to the next one in the list.

This means that my system is extremely resilient to individual nodes failing, or even all the nodes failing. If all nodes fail, a machine will still be promoted to Mother, just by being the first in the list, and all requests will go to it until more things can be sorted out.

I’ve already done all the research work on this and implemented it dozens of times, so it sounds like a big deal, but it’s not that much work. But obviously needs to be done before launch, as something as simple as being logged in fails to work when you are log to to one machine, but then due to Amazon routing you to another machine, you end up on a machine that didn’t know about your previous login and now you’re logged out.

The 7 Smaller Items

Related to the Mother system, I have to create a “shim” data module that proxies any data changes to the Mother, instead of working with local data. Local data is used for reads, and gets updated by polling the Mother for changes. Not a big deal, and completes my data model. I’ll go into this in more depth sometimes as there are a lot of interesting choices I’ve made here and they open up a lot of more interesting possibilities for the future because I made them and did the work to ensure they functioned well enough before launch. Doing a lot of this after launching would have been incredibly difficult as they are tied into how absolutely everything in the system works. Most people just take this for granted to do it Standard Way X, and that’s a good idea unless you have more detailed plans with Standard Way X doesn’t account for.

Sending emails. I really want to provide many contact methods, but to launch faster I’m cutting all of those and just sending emails. I’d like to use Amazon’s Simple Email Service to help avoid going into the Spam folder, but they haven’t finished processing my Production Access request I made yesterday, so I’ll just have to send directly from my servers and tell people to check their Spam folder for the registration confirmation.

Registration is currently broken, because it uses an older data model that I replaced last week. I have to update that, and plug it in with the email registration and verification. Currently verification isn’t required, but I want to enable this before launching too. Obviously, registration has to work to launch the site.

Front page has broken features. I have 2 main attractions on the front page besides explanatory copy and login/register Calls To Action. The first are some real-time 5 second graphs of major companies, right now I’m using Google and Twitter. The second is the ability to enter your own company and see a real-time 5 second graph of that. The first 2 broke with the data change last week, like registration. The latter also broke that way, but also needs to be hooked up with the Mother data process, like the login problem.

Security. I know people say to cut everything you don’t have to when launching your company, but I can’t let obvious security problems go, so I have to do some testing and add in some extra assurance so that customers can’t access each other’s data. It’s just disrespectful of your customers to not make a initial and continued effort and ensuring their data is secure.

Outages and alerts. Kinda the point of the whole website. Once email has been set up on my production servers, I need to test sends on error conditions. I allow creating Test Outages so you can get alerts without actually having to take your services down. I want the actual outages to send emails as well.

Correctness of monitor configurations. I need to go through all the options of my monitor’s configuration and make sure all the options still do what I think they should. I have just been doing basic things for a while, and so it’ll be good to make sure all the features either work, or hide them until I have time to fix them. Either is good enough for launching and things the general cases are already very solid.

So these are my must-haves before I launch, and I think all of them are very reasonable for a Minimum Viable Product in the online infrastructure space.

I woke up at about 4:30PM today from a long night, and I was feeling a bit tired still as of an hour ago, but I’m feeling a lot more energetic as I finish writing this. Probably why I started writing it…

Even the longest Monday ever recorded has to end eventually, and when it does I will launch my startup without much fan fare, but with a lot of satisfaction that I’ve taken the first real step in starting a business I really believe in and can recommend people check out.