Today marks another step along my journey as a co-founder (chief bottle washer?) of a FinTech start-up – we are ready to announce our WolkeWerks Alpha Launch! It was been an interesting and rewarding experience to say the least. My co-founder, Scott Scazafavo, and I have spent most week days with at least one video meeting as we hash through the details of our product and the problems it solves for our consumers. Only two people in the company, and yet we still have multiple locations and a two hour timezone gap. Flexibility is a key to success.
To me, we have too much polish and too many features for an Alpha. For Scott, he no longer “cringes” when showing the product to his friends and family. The joys of being co-founders.
We are really fast, er, not that fast
As usual, things always take longer than one would like or even optimistically estimate. After Scott and I determined the initial high-level plan, we selected a data provider and I was able to produce a proof-of-concept / prototype in one week. WE are REALLY fast we thought. Within a day later, I had skinned the “consumer” version in Bootsrap 3. OMG we are SUPER fast! The prototype made it clear we had all of the building blocks we would need (aside from an army of software engineers, designers, research assistants, etc).
If I was able to write a fully functioning, Bootstrap-skinned prototype that was based upon a data service REST API in under two weeks, surely we could get our Alpha product live by April? May at the very latest.
Where did it all go Blanche?
Hmmm. Oddly, as we launch today, on July 5th, it is interesting to see where the time went. Figuring out the features for Alpha took longer than expected as we scoped the ideas down to the bare essentials. There was over a month spent on looking at technologies and products that we eventually realized would not be used until the MVP phase. A huge help was the book “The Lean Startup” by Eric Ries. It helped us focus on much less and testing our way into changes incrementally (and thus an Alpha, Beta, MVP and the major releases).
Of course there is also the fact that we only have one software engineer (me). I like to think I can code fairly quickly, but in fact, I am also the AWS systems administrator, the Apache and Tomcat administrator, the MySQL DBA, as well as the front-end web developer (JavaScript, jQuery, Bootstrap 4, HTML5, CSS, JSP) and the core services developer (Java). Oddly, as is the case during my whole career, product management was able to generate more ideas and features than engineering was able to produce at the same pace. I was doing some product management along with Scott – but again only I was doing any coding or system administration. Clearly I learned to stop making my own backlog bigger fairly quickly. 😉
In the beginning…
In the early phases we needed to agree on the basic functionality. We knew the long term product would use distributed processing, AI and machine learning. These are of great interest to me and so I poured myself into learning them more deeply (and getting them working in my lab) as fast as possible. This was going to be a super cool product and possibly even more fun to build!
A dollop of Hadoop and a sprinkle of Spark
What a dream job! I was a full-time student again. One of our product’s main goals is to help a consumer manage their online subscriptions. My quest for building a Hadoop based AI engine allowed me to add at least five more online subscriptions to my credit cards! I was a super-user and the product was not even built yet. Courses from Udemy, Lynda.com, Coursera, Pluralsight were great! I quickly outpaced the top courses in Treehouse but had fun looking at them. These paid services were in addition to my regular free sites of w3schools.com and others. I was suddenly an online training expert. Visions of blogging about the various online training sites and their relative merits sadly danced in my brain.
I took courses about Eclipse, Docker containers, AWS S3, Hadoop, MapReduce, Spark, and stuff I cannot even recall at this point. All of this while building out and upgrading my Hadoop and Cassandra clusters and testing my various theories on how to make the product sing. Then a dose of reality hit as I was working my way through “The Lean Startup” book. Oops. I had gone way too far down that path when we were not even sure of the core viability of our product. There were MUCH simpler ways to achieve the product viability testing we would need without the AI engine working day one. Well that was at least one month of “fun” research that was pointless to our Alpha. Ouch. That was a big chunk of time lost – regardless of how much fun it was.
Time for a road trip
Once I realized I had lost my way according to the “start-up bible”, I quickly re-focused my interactions with Scott. We decided we needed to spend some time in the same city (with a real whiteboard) to flush out the phases of the product roadmap. Scott and I chose Denver as it was in between Seattle and Minneapolis. We used Trello (for free) and carved out what the Alpha, Beta, and MVP versions of the product needed to be (knowing even Alpha would shift as we continued to determine feasibility).
Real collaboration – at the code level
The next issues was linking Scott’s product features and design to my coding. Sounds simple, but we needed to agree on simple things such as a front-end framework and possibly a tool that would allow Scott to design mock-ups that could be implemented with relative ease inside the chosen framework. With much angst and encouragement, we agreed Scott would learn a little Bootstrap and select a Bootstrap tool to make the “unauthenticated” portion of the Alpha site, since my version was a white page with a login form (I thought it looked great!)
Since Bootstrap 4 was available, Scott picked a tool that generated Bootstrap 4 code. No worries, Bootstrap 4 is backwards compatible to the Bootstrap 3 code used in the prototype – right? Um, no. 🙁
I made the mistake of a 5 minutes hack of the consumer site (integrating the authenticated prototype and the new unauthenticated code from Scott). It produced a hybrid Bootstrap 3/4-ish site that I showed to Scott. I think I almost killed the company. It looked OK-ish (to me). Scott was so depressed at how bad it looked he was on LinkedIn looking at Junior Product Manager roles.
Staying positive and building momentum
I realized that incremental crap-ism might not be the way to encourage Scott along the Bootstrap 3 to 4 migration journey. I quickly researched all the issues with making the site fully Bootstrap 4 and re-coding the prototype so it looked proper in both the authenticated and non-authenticated states. Slowly I coaxed Scott back off the ledge when he saw his designs working pixel-by-pixel as he had designed them.
Moving from Bootstrap 3 to 4, creating a working rhythm with Scott as he generated pages and updates to the prototype pages took some time, but the pages started looking better and better. Eventually Scott learned how to use GitHub and started making some UI changes directly himself. Now we had put down our rocks and sticks and began cooking with gas.
There were some data service issues that we needed to address. Then some AWS issues we needed to investigate and correct, plus redirects, SSL certs, password standards, and a lot of other things that were correctly deemed important into a FinTech Alpha.
Then the real fun began. The product was getting close enough, but there were some key features that we felt would make the product more useful and pleasing to our consumers, and there was an issues with “the browser wars” that was likely to cause confusion with our Alpha users. Should we add the features and try to fix the browser wars issue? In the end we decided yes. The additional features required about a day of coding. Well worth it.
FireFox, FireFox, why, why, why?
We decided we needed to make a valiant effort to correct an issue where browsers were auto-populating our site’s credentials into a third-party access credentials form. We allow our consumers to access their own data through our product, but they need to securely pass their credentials onto their banking service. If the browser auto-populated these fields with our site’s login credentials , the user would likely pass the wrong credentials to the back-end banking service and the connection would fail. It should be easy to stop a browser from auto-populating a form field you would think. Unfortunately, again, no.
Here is where the “browser wars” come into play again. The HTML5 specification says that there is a attribute that can be used on the <form> and <input> tags called “autocomplete”. By setting autocomplete=”off” the browser should know not to populate that password field with the current site credentials. Perfect. Except none of the browsers honor it!
Protecting the installed base – of course!
There is a significant hurdle browser companies implement so users are less likely to consider switching browsers. Many users allow the browser to remember all of their passwords to the many banking, media, and merchant sites they use. Smart users do not use the same password for their favorite recipe site as their investment or banking sites. Who can remember all of those passwords? Let Chrome, Firefox and Edge remember them for you! But once a user has done that, it is way too much work to start over again with a new browser and migrate all of those passwords (that they really don’t remember) along with them. Great product management by the Chrome, Firefox and Edge teams in protecting their installed bases.
This is all fine and dandy, until a site needs to be sure the consumer is not confused when a different set of credentials are being requested. Auto-populating credentials (especially when they should be different than the site they are on) may cause less sophisticated users to submit the wrong credentials. This further confounds the user experience and frustration levels.
A partial fix for now – and full fix in Beta
Interesting enough, on a blog from the Mozilla Developer Network, there is an article that explains a simple way to stop the browser from auto populating the forms fields. And guess what? It works for the latest versions of Chrome and Edge – but NOT FIREFOX!? Mozilla explained how to correct the issue (autocomplete=”new-password”) – but then explains they ignore that as well.
Why would Mozilla do this? Because they have been losing market share to Chrome for years – and they need to be more aggressive in their product design to capture and keep new users by storing their password at all costs. Sad.
So we launch with Firefox users having some confusion when we (securely) need their credentials to their bank services. There is a complex JavaScript fix that we will eventually implement that randomizes the field names on load, but changes them to “password” and “username” just prior to form submit. Sad we need to resort to that. But we will make that part of the Beta and just pre-warn our Firefox Alpha users. After all, it is Alpha, and we decide who signs up and what issues we are asking them to avoid.
A curvy roadmap – and then a right turn
So after a month’s travel down a wrong road along the course of developing our roadmap, we have finally gotten to the day of our Alpha release. We need to remind ourselves it is not an MVP or a Beta – it is just an Alpha. But to me, an Alpha that is pretty slick and does a lot of what we will need it to do as we roll towards Beta and the MVP.
There are many features left for Beta and the MVP as well as dusting off the machine learning and AI code – but we are on our way!
Ted Cahall
