So I started off my ISV journey 7 years ago. Just an innocent attempt to get people to my events by sending them a Calendar Invite. If they accepted, I knew that they were coming. Or at least had a better chance of showing up to my events. Along the way I had a Web based Calendar engine built by a local contractor on an old Cold Fusion stack. It worked and we were off on many use cases on how I thought it should work. Some 2200 hours of personal time in testing, UI design, and disastrous blunders on my part as a weekend and after work project I needed break. If this was going to be bigger idea I needed help. Enter a friend named Arnie. Arnie came into the calendar “Thunder Dome” 2.5 years ago. Or about 1800 hrs ago. It has been a part time project for him and he caught the bug as indicated that those hours are after work and weekends.
He helped with so many things – testing , coding , web site, blogging and overall front end animal. I voted him to Co-Founder last year. He is a true inspiration. Then we decided to blow up the old site and start over -literally scrap all the code some – $80K in custom contract coding down the drain.. Not easy. We were both at a loss for 60 days. We knew after talking with several large test customers we needed to get to scale on AWS with SES.
We then started our Pizza Journey into AWS in August 0f 2017. About 3 months ago in February of 2018 we were fortunate to recruit Jonn , who is our lead developer and CTO. We have been iterating using Slack, and brain storming on how to use SES, Python SDK, SNS, Lambda and Arnie’s Vue front end with his run time engine. We have the prototype running now in AWS. Pretty exciting to see the Pizza project running! The test site will be up and running in a few weeks. www.calendarsnack.com. More to come as we attempt to give every marketeer in the world their own calendar server for sending and tracking of Calendar invites!
To be completely honest, the last (almost) year has been tough. We had a working version of 31Events – that accomplished the goal of sending a very well formatted iCal/ICS file, that could be “consumed” by all the major email & calendar clients on the market.
So we had a decision to make – Either make the existing platform work or to completely re-invent/code to work within an ecosystem we knew would both (1) scale and (2) be around for a very long time.
So we decided to burn it down, and start over.
What we’ve learned in the process of moving from a Coldfusion/MSSQL environment, is that AWS Serverless Architecture gives us both flexibility with the ability to scale – without us having to manage any servers, storage, or infrastructure. It’s been an interesting 9 months of learning for us — first, it’s a complete mindshift from our backgrounds (both Greg and I have spent our professional lives within “infrastructure” and services for large companies) in that we didn’t need to worry about the “backend”, that it would just work – regardless of what we wanted to do.
Second, it forced us to really think through what 31Events does – and start breaking it down into smaller and smaller pieces, because serverless architecture is about “micro” services and functions – no longer did we need to think from an end-to-end standpoint and create functions to handle it. We now shifted to smaller functions.
Third, it forced us to re-think the front-end (user interface), and what we wanted to accomplish – first as we roll out Version 1, but also what we could do as we proceeded down the enhancement and development path.
I like to talk in analogies, it helps me put things into some sort of context and understand complex “things”. To wrap my mind around the direction we had planned to take, I started thinking of our new AWS Serverless backend as setting up a dominos. Our dominos can start off as a simple line … knock over the first one, and it just knocks over the next. But as we learn and grown, we can add complex patterns, or create side tracks that go simultaneously. And each “domino” is a fraction of the whole, and if it breaks, we can go back to the specific place and fix it. It really is a great way to create an application (which is what 31Events is) and have it work right from the beginning.
Right now, we are still working through creating our micro services, and we’ve made some significant progress in doing that. Although the concepts are “easy” to understand, the implimentation is always going to much harder than originally thought.
The other problem faced, as you march down this brave new world of serverless, is finding people who really (and I mean really) understand it – and can make it work. We’ve been through a few people along the way, but hopefully have found the right team to help us going forward.
We all have “day” jobs at the moment – so 31Events is a sideline project. That doesn’t mean it’s not important (because it is, Greg and I both see examples every day where we could help people), what it means is that we can’t necessarily publish a roadmap with dates. Our first priority is to ensure we have the same functionality we had a year ago. After that, we will re-launch. Because we know, once it works, it will just work regardless of how many users we have creating and managing events & invitations.
We hope to be back with Version 1 by July – that would market a one-year absence of 31Events – but I’m not putting a timeline on it. So, stay ready, because once we re-launch, it will just work – and you will then be able to send a calendar invitation to anyone, and will just work.
Because we are here to change the world of “Add to Calendar”.