twitMate

This is very different from the pre-launch roadmap which was heavily focused on development of the service.

For the next periid we'll be focusing on marketing, SEO and content creation

I've retired the waitlist for new sign-ups - those already on the waitlist still have a few days to get their accounts but I am moving to live sign-ups today.

Early-bird discount will be 70% off for life - not quite as much as the waitlist discount. When I get ten early-bird sign-ups this will go down again.

I am sending out invites gradually as each new user takes a bit of work to set up and I don't want too long a delay if I sent them all out at once and get a lot of uptake.

Wait time is mostly due to getting the Twitter developer account OK'd by Twitter for each user. This can be just a few hours or occasionally up to a few days and several emails as Twitter is fairly thorough with their checking for new API users. Even though this is a pain I understand why they have to check.

I could cut this out by running everything through one Twitter App under twitMate but there are advantages to each user having their own app. Users aren't associated with each other in any way and each user is totally isolated from all others. In my opinion it's more work but higher quality.

There is a little manual work required to set up each new account: set up a Twitter App to connect with the Twitter API is the first job.

This involved a bit more setup than you might think as the codes for each product changes when you do this in Stripe so a few changes necessary in the DB.

Getting closer!

This was to test customer onboarding and although it wasn't as thorough as I would like (a couple of people I had lined up to test dropped out) overall it went OK and I found and fixed a small bug.

Next up - sending invites to the waitlist members. I know there are a few from here on the waitlist so not long now till you get your invite!

Still a couple of places on the waitlist if anyone likes the look of it 🚀

and we're on to public beta testing!

I made some progress today, working on the last onboarding section.

Here new users pass us details for posting their tweets and URLs of their landing pages (these will be linked from tweets to drive traffic to their website/blog posts etc)

Nearly done - just image uploads to go!

Today I had some productive time where I built the 'audience management' section of customer onboarding.

This is a series of short webforms where we get the information needed to target the correct audience for the customer.

I used 5 short webforms with simple choices (1 click) or a single text input field and 'next' / 'back' navigation. I prefer this to one more complex form as it walks th euser through the information.

So far I have completed the flow for the most common scenario - where a customer has a Twitter account and they want us to set up their Twitter App (which connects to the Twitter API).

For this they need to provide us with their login details (we're not using OAuth so each customer gets their own personal app which means they are isolated from other customers).

To do this well meant using encryption to store the login details securely. After we set up the app we delete them completely from our database.

The entry point is where a new customer has signed-up and purchased a plan.

At this stage the aim is to get all the information that we need to set up their Twitter App which connects to the Official Twitter API, to manage their audience and to tweet for them.

...and to make it as easy as possible for the customer to complete.

Here's a pic of the flow:

The last job with payments integration...

Customise the dashboard pages so that if a user is logged in but hasn't purchased a plan yet, they are prompted to choose a plan.

I considered redirecting straight to the plans page but figure this is better as people get to see what they are missing and can still do things like edit their profile or change their email address.

This involved more Stripe integration but this time it was easier. It's the first time I've used their new 'customer portal' and I was pretty impressed.

It saved a lot of time - the only tricky bit was catching the webhooks and updating things at our end when customers make updates to their subscription.

This afternoons job was to add a sign-up page for #twitMate

I want sign-up to be as easy as possible so I built the plans page to create a session in case the user comes to sign-up from the plans page.

If they do, once they complete signup they are automatically logged in and go to checkout for the plan they already selected.

If they come from somewhere else, once they complete signup they are automatically logged in and then go to the plans page to make the choice.

Just spent an hour battling with Stripe docs again to integrate discount coupons on twitMate.

Hopefully it will save me time in the long-run as I should now just be able to change the coupon to change prices across the board. I'm starting with 75% for waitlist members with stepped increases working towards full price after launch.

I have completed the tricky part of customer payment with Stripe integration of checkout completed.

I know Stripe is considered the best payment processor on the market (and I have yet to find anything easier to use myself) but I always struggle with their docs and find there is a lot of figuring out to do.

The crux was passing crucial variables to Stripe from the frontend using JavaScript via stripe.js (this is required by Stripe, I assume for security) while my website forms are processed in the backend using PHP (for my own site's validation and security).

I always find using multiple languages for a single task tricky and try to avoid it as it can get messy but I got there in the end.

I'm old school when it comes to planning and prefer pen and paper.

Here is the user flow from plan choice, to payment, through email verification and on-boarding to the dashboard: