Bolt on Community
I wanted to develop a community for mortgage professionals around the downpayment.gift product. I did not want to run that community in a Facebook Group. I wanted them to return to the app to participate in the community or consume the content posted by us or other users. …so after some consideration, looking at options like Discourse, Tribe.so, Circle.so, and other custom Rails frameworks that would embed a message board, in-app… I decided to implement a new, single page app called Peerboard. The reasoning was around it’s simplicity and support for integrations like SSO, JWT authentication and full, evolving API and Zapier support.
Peerboard can be found at https://community.downpayment.gift. It mostly public except for groups that are secured by login. To login… well here is the beauty… you have to login to the downpayment.gift registry app as a partner. If you click Login from the Community site, it redirects you back and forth.
The goal in the short term for the Community is to post content here, marketing content, templates, ideas for marketing down payment registries, video ideas, slide decks and more. Think like a bit of a dumping grounds for marketing ideas and we’ll see want takes off. I expect we will be direct linking from emails, social posts and ads, directly to the community posts. I expect to be blogging to clients and consumers on the main site, downpayment.gift. …however, I expect we’ll “blog” on the community site for partners instead of posting on a traditional blog. We may spin up a few “tent-pole” partner blog posts… the sky-scraper technique… for partners but that it is.
Being a bolt on to the app, we can simply move it to the next version of our platform and re-integrate it. Due the JWT authentication, we have a simple SSO solution path our app is the authentication server. The new version only needs to carring forward that implementation to maintain the integration. The categories might narrow and then expand. Right now we have the ‘ghost-town’ problem for a forum software.
Okay… the update… this week I added to the PeerboardController a method to add_user_to_pb(user). The JWT authentication would “auto-create” the user at first login. I noticed during a presentation that Categories in the community forum were not showing up to a Partner while logged in. I realized later that I failed to add the user to the Partner group at all!! Something that never popped up in testing and was overlooked in hacking away at this months ago.
The new add_user_to_pb(user) method adds them to key groups in our instance at Partner signup.
They also get a cool welcome email from the community that is preset by us.
Cookies blocked caused strange result
Fixed a bug in Ruby code as side effect of JS client side cookie code for assigning a client account to a specific partner lender account. Basically it was assigned them to an unexpected partner account… a bit unexplained… almost like there was an uninitialized value that resulted in a missing parameter on the Ruby side. I was able to block my cookies and duplicate it and test it after making a few lines of code fix.
This JS cookie code will need minifying and refactoring in the near future. It meant to enforce the click attribution policy.
I also need to test this no Cookie on the legacy external form sign ups. Those forms will work, calling via webhook, but it’s a user flow that I wanted to move away from once I found Product Led Growth religion.
Force Cookies required
Separate from this missing parameter issue above, we are forcing users to allow Cookies to use the app. The idea is to fail gracefully.
I still need to implement a test against third-party client side ad-blockers that block cookies but the server side may not know it until a refresh. Botton line is that Browser Sessions require cookies to function.
Move Sessions to DB
In the process of testing blocked Cookies, I realized that we were still storing Sessions on the Client side, browser. …default from development. Given the nature of our app, we don’t want to be using the client side strategy. It is more performant, but is more suspectible to security attacks on specific users from the client side or cross-site attacks.
We moved from sessions in cookies to active_record_store for sessions… effectively creating a giant table for all the sessions in our Postgres DB. The core advantage of sessions in the DB is that we essentially invalidate sessions more easily without changing the secret key. The app still creates session cookies, but the it’s encoded reference to the data stored on the server side.
I wrote a first stab at a monthly investor / stakeholder update. Head to investors.downpayment.io to check it out. So far we are publishing past updates, but we might lock that down in the future.
Edit Pitch video
I edited a recorded run through of the investor centric pitch into transcribed, bite sized videos.
Here is the first half (Part 1 of 2) as a square video with headers and subtitles:
This was not done as a “timed” pitch. It was a 15-18 min paced format.
I’ll be putting some of these short ones on the Investor updates and on DPP social media feeds as content.
Feature flagged Coassemble LMS
Long story. The short story is that broke my Coassemble API key by testing the Key with a sub-admin user id. It put me in the penalty box for a day. Support at Coassemble in Australia was able to get me back alive. Later I circled back and just changed the super-admin user from loren @ homeloangeeks to loren @ downpayment io. A workaround until they roll out API keys for all workspace admins.
Still need to record some courses here for Client users and for Partner users.
In fact, the learn.downpayment.gift is not linked from the client app yet. We add users to the LMS and groups only… awaiting the right time for this.
I do this this “Course” featurette will be a great lead generator. “Sign up” for a FREE Course is a great call to action to education users (and partners).
Outbound push for webinar content
I have configured this app before. This time for real. This is basically a cold email automation tool.
CSV lead data and MySQL
I have a huge MySQL database with 100k plus rows of data for Loan Officers and mortgage industry folks. This was hand culled, cleaned and de-duped a few months back using Easy Data Transform desktop app and Clearout for email checking.
I kinda lost track of this effort as I was not ready to begin outbound efforts to promote content.
I spent the better part of a day trying to remember what I did not document and where I left off on cleaning and importing data.
Ultimately this database is a key asset for our growth plans, but I need to take baby steps and just start warming up emails and sending outbound emails. I don’t have sequences built and will worry about that later. I’m hoping we can get some word of mouth going.
I did brush up on my multi-table SQL JOIN syntax. ;)
Money for Ads vs Cold Outreadh
I originally felt I would jumpstart this content, webinar strategy with ads. I just don’t have the spare funds that I had a year plus ago to due this on a broad scale.
I plan to test a few webinar ads and setup retargeting. I literally feel like I’m stuck on these steps for the past several months. I remember wanting to setup retargeting ads back in September!!! …was not ready yet. Now we are!
Given this… I need to make the cold outreach method and automation and group preso (webinars) work. Cold email is not free. It takes a ton of time. I am pressed for time but will have more time that money (for ads) through a certain lense.
Bootstrapping without Ads
The benefit of emphasizing cold outreach to webinar content to product trial flow…. is that I cn prove this method works and could scale with more juice. Investors don’t like the idea of pouring investor money to Facebook Ads. Neither do I… in fact, back in Octover, I came to the conclusion that we wanted to kickstart campaigns with FB Ads… but that we would rather run viral giveaways and contests and give that money to prospective home buyers instead of Facebook. More on this key insight later.
Gotta run! Thanks for reading this weeks update.