My Coda 'Makers Festival' entry

I’ve been using Coda in my startup HR Partner for the past year or so, and love the fact that I can create custom dashboards to share and manage data with my team. This week, I noticed that Coda and ProductHunt were having a Makers Festival (No Code Edition) that was pretty cool, and so I thought I would whip up a little mini project in a couple of hours.

The choice of project was a little tricky, but then I remembered that I always wanted to build a mini app to track my liquid intake throughout the day. I have a terrible habit of not drinking enough to keep myself hydrated, and I promised myself that this year, I would improve upon that. What better way that to build a dashboard that would objectively show my how well (or badly) I was doing.

To that end, I decided to build this ‘Waterboard’ app in Coda:

This is a very simple app that shows me how I am tracking as far as liquid intake for the day, plus show my trends over the past week.

Here is a breakdown of the app:

At the top of the dashboard, I can set my target goals that I want, meaning the total quantity of liquid that I want to drink every day, plus the time interval between when I take drinks.

Using Coda’s slider widget to set my goals.

If I am below my target quota for the day, the dashboard will prompt me to keep going, and when I exceed the quota, I will get a ‘well done’ message. Similarly, if I go over the time interval set, then the system will warn me that I am overdue for a drink, otherwise I get a thumbs up. Here is what those displays look like in the middle of the page:

Not so good, I am behind in my target quota and it has been a long time between drinks!

And here is the display when I am doing well:

Everything is just ticketyboo!

Notice also that in this section, I am using Coda’s Rectangle() function do draw in a progressive bar chart which visually shows me my current liquid intake vs the target goal. Makes it easier to see how I am progressing versus trying to do mental maths when I am dehydrated.

The table in the middle of the screen is the actual Coda data table that holds the information on my liquid intake. A really simple table with 4 fields in it:

Really, all I am doing is collecting the time of the log entry, the type of liquid (which is a customisable drop down list) and the quantity in ml. The last column is an auto calculated icon that shows me whether the entry was pure water, or a compound liquid like coffee/tea etc. We all know that pure water is best!

Oh, and this table only shows the entries for today. All previous entries are filtered out using Coda’s filter capability in order to reduce clutter.

But seeing as I am a programmer, I hate doing long form data entry. And seeing that my daily liquid intake is usually from one of about three or four different containers, I thought to make up some ‘Quick Hits’ buttons just above the table:

All my favourites. (except Coke - I don’t drink Coke!)

So now just one click will populate the table data with the most popular beverages I drink on a daily basis.

Setting the button action.

You can see above how easy it is to set an action to the buttons - I simply nominated that I wanted a click to Add a row to the data table, and I specified the two critical fields that relate to this button (Note that the entry date and time are auto populated using calculated fields within the table itself).

Voila! That is it.

Last on the page is a graph of the past week’s liquid intake, so I can see how I am trending over time:

A veritable roller coaster.

That is it. Perhaps about two hours work to put this together, and most of that time was spent looking up the formula syntax for Coda’s date/time and string manipulation.

One downside of Coda is that all timestamps (such as those returned by the Now() function) are in Pacific Time, rather than UTC or local time. Date functions however seem to be in UTC which is strange. Nevertheless, Coda has the concept of Named Functions, so I created a custom function called NowLocal() which converted the returned timestamps from Pacific Time to Australian Central Standard Time.

Coda’s named functions make reusing repeated long formulas so easy.

Where does the 0.6875 come from? Well, Pacific Time is 16.5 hours different from Australian Central Standard Time, so 16.5/24 gives you 0.6875 which is the amount we have to add to the datum to correct the time to my local timezone.

I also created a function called DateLocal() which is basically:

Chaining named functions.

which corrects the Today() function in Coda and returns the correct date for today once adjusted for ACST. See how simple it is to use Named Functions to save typing out the same formulas repeatedly all over the dashboard? In fact, I used several named functions in this dashboard to save time.

Here is an example of using DateLocal() in the graph filter:

Coda supports some quite complex formulas, including IF statements etc. The following formula picks out the last drink time of the day (and returns a sad face emoji if there are no entries for the day). Note copious use of Named Functions to avoid long winded formulae:

Waterboard running in the Coda app in iOS.

And yep, it even works in the Coda app to look just like a native iOS app (If you look at the image on the right). I realise that I still need to do some rejigging of a few of the widgets and buttons to make the ‘sit’ properly on the smaller form display, but overall, it is a useful way to use the dashboard and logging too.

TODO: I’d probably add some automation so that a Slack message or notification is sent whenever a drink entry is made. However what I would really like is for a notification to be sent when I am overdue for my next drink, but I don’t think Coda has the ability to send a notification on a formula at this stage.

I am happy to share this dashboard with anyone else out there who is interested in learning how it is built. Feel free to poke around the formulas and functions, and improve/customise it to your liking. Drop me a line if you want a Share link to this dashboard.

The first programming trick I learned

Most programmers I know experience a moment in early in their code writing careers where they are shocked by a profound moment of discovery & realisation about their craft. I’d like to think that this moment helps to crystallise their love of writing line after line of instructions designed to manipulate a pile of silicon and electrons into doing their bidding.

For a large number of those that attended some form of computer science class, or coding school, it was probably when you first saw a recursive function in action:

“WHAT? That function can’t keep calling itself… can it?? Wait…”

I said the same thing above that probably 99% of Programming 101 students said when they saw such a mind twisting piece of code. But no, for me, my major discovery about the beauty and subtlety of the art of programming that lurked a layer beneath the monospaced text on my screen happened way before that.

You see, I was a self taught programmer, and cut my teeth on the very early versions of Turbo Pascal back in the 80’s. I was lucky enough to score a job with a local IBM dealership as a support technician, and also managed to do some small bits of coding on the side for their clients.

One day, a senior IBM System/360 programmer in the company casually asked me: “Devan, do you know how to swap two variables around in RAM?”.

“Sure!” I replied, brimming with 18 year old confidence, “You just create a third variable to hold one of the values temporarily, then you do a reassignment and copy the temporary back into one of the original two…”.

I had fallen into his trap. The same trap that most junior programmers make:

The ‘old fashioned’ way of swapping two variables, using a third.

I remember him shaking his head sagely. “Nope - did you know that you can do it without using a third variable?? We often have to swap over entire blocks of memory on the S/360, and often, we don’t have any extra memory to spare to hold a temporary value.”

I frowned in consternation. This was impossible, wasn’t it? You couldn’t ever swap two variables without using a third placeholder. The first assignment would corrupt one of the values immediately, or so I thought. I asked him if it took longer, or used more steps than the simple answer above. “Nope” he replied again. “It takes the same number of steps, and on some systems, like the S/360, it is actually faster than your example”.

I pondered this problem for most of the day, but in the end had to admit defeat to him. Surely this was just another hazing of a junior employee that he was dishing out here?

Wordlessly, he write the solution down on a whiteboard in the conference room:

Using XOR to swap values in memory.

I stared at what he had written with the same utter confusion that I did much later when looking at my first recursive function. Surely this was impossible. There must be a mistake here. This shouldn’t work. This can’t work.

But it does. Try it.

For those that are curious about the ‘exclusive or’ or XOR function, here is an explanation about it. And our veteran was right, on some CPUs, the XOR operation actually takes less cycles than a PUSH or MOV operation.

What was the ‘moment’ that made you fall in love with programming?

The increasing third party costs of running a SaaS business

Photo by Émile Perron on Unsplash

There is no doubt that in recent time, the barrier to entry to building your own SaaS (software as a service) product has been lowered to the extent that almost anyone can jump in and build a solution to solve a problem.

However, an immediate after effect of this surge in SaaS offerings out there means that your average customer is completely spoilt for choice, and differentiating your offering from those of your competitors has become the problem du jour.

How to work on the ‘edge cases’ that can make or break your startup? It means you have to focus on things like customer retention and strategies/tools that can record massive amounts of data about how your customers come to you, and then what they do once they start poking around your system. This myriad of metrics and information usually means that you need to invest in a host of third party tools in order to get these capabilities into your own app.

Now, I am a believer in the old adage of “don’t build it yourself if you can buy it off someone has who has already done the hard work”. Our friends over at Baremetrics have already done the homework and designed a tool that will tell you whether it is more economical to build a solution you need in house, or pay a third party provider for it.

But over time, while talking to several marketing experts about how we could improve growth in my own SaaS product by increasing user retention and satisfaction, I kept hearing that we needed to provide things like:

• Detailed user onboarding workflow

• Screen recording to track behaviour and movement through your app

• Knowledgebase of help articles

• Video based training via an online academy

• Automation tools for importing/exporting and linking data

• In app chat for instant support response

• CRM (customer relationship management) tool for drip email campaigns and “central point of truth” for all your customer data

• Mailing list management software

• Blog site with relevant articles plus hints and tips for your customers

• Analytics and data warehousing tools

This is of course on top of a bunch of other tools that you need in order to build and host your offering in the first place, such as:

• Hosting with AWS/Google Cloud/Azure etc.

• Landing pages for marketing campaigns

• Prototyping tools

• Bug tracking and CI (continuous integration) & build tools

• Source code repository hosting

• Security infrastructure

• NPS (net promoter score) measurement tools

• Billing management systems

• Financial accounting/payroll systems

and much more.

We recently did an audit of the cost of third party tools that we use here at my own SaaS business, and we worked out that all of our monthly tools that we used to track the above was around the $3000 per month mark (and that is with about half of our tools on free or discounted plans!). Now, given that our base pricing for our SaaS is $100 per month, it means that 30 of our customers are basically there just to pay for our third party toolset. None of those 30 customer’s revenue can go towards paying for general marketing costs, or to pay wages for our team.

Because we are still a fairly small and growing company, 30 customers is quite a sizeable percentage of our total base. I know what you are thinking - “Meh, that won’t be a problem once you have a million customers!”, but then it still will, because a lot of these third party tools pricing are based on the size of your customer base, so our hosting and support tool costs will increase linearly along with the size of our customer base at a constant rate.

To this end, I am now revisiting the idea of swapping a lot of these third party tools back ‘in house’ again. For instance, we recently explored a variety of customer onboarding tools, but given the fact that most of these tools run to around $200/month on their basic plan (that’s another 2 customers we have to find and keep just to pay for that tool), we decided to go back to writing our own onboarding sequences for new customers.

Sure this took some time to do, but at the end of the day, we could incorporate steps into our onboarding that third party tools could not hope to replicate - for example, studies have shown that the sooner you can make the customer feel that they “own” your tool, the better the chances they will stick around and explore. So, the second step of our onboarding process encourages the customer to upload their company logo to their trial company. This way, they see their company logo and name at the top of every app screen they visit during their exploration. We have seen trials to paid subscription conversions improve as a result of just this one change alone!

One of our ‘self rolled’ onboarding screens within our app.

Same with our billing system backend. At a recent conference I attended, I was bombarded by third party payment processing handlers who promised they could handle things like bounced payments and expired credit cards for us - all for a monthly fee plus percentage commissions.

I am sure they were great and all, but I ended up writing our own Dunning routines and processes for handling expired cards all within our own codebase, which gives us far better flexibility as to how we can handle them.

The other thing I have been exploring is the consolidating of multiple services all into one. We recently signed up for HubSpot’s sales and marketing toolchest, and it appears that we can now stop subscribing to about 5 other vendors (in app support chat, support knowledgebase, newsletter manager, drip campaign system, landing page hosting) and do it all within the one system. HubSpot isn’t cheap, but we can reduce our monthly third party service bill by around $1000/month, so that certainly helps to offset the cost, especially while we are on their ‘startup’ plan initiative.

While we are talking about startup initiatives, I do love that a lot of companies out there provide deeply discounted pricing plans for new SaaS businesses, I am a little perturbed that most companies (such as Amazon) only provide them to funded companies. In my view, a company who has just received millions in funding can certainly afford to pay for Amazon assets to host their MVP, whereas a bootstrapped startup that is running on the smell of an oily rag could certainly do with a discounted (or free) temporary offering so there is no negative impact on their cashflow while they are building their customer base.

Most of these startup initiatives also expire after a specific timeframe (e.g. after one year). That also seems a little strange, as some startups can boast a meteoric rise within a few short weeks, whereas others may take years to break profitability. Far better to peg the discounts or free tiers to measurable metrics such as number of paying customers, or monthly revenue, in my opinion.

I am thinking that as the ancillary costs of running and promoting a SaaS business continues to rise as it is now, we will see more and more startups going back ‘in house’ for their analytics, onboarding and support tools, and we will see a consolidation (and pricing reduction) in the number of third party offerings.

What are your thoughts? Does it make it more cost effective to move some of these functions back ‘in house’ again for your startup?

The problems of selling a 'modular' software system

Modularity comes at a cost…

For years, a lot of software has been sold on a ‘modular’ basis, with the view that customers can buy only the critical functions that they need now, at a lower cost, then add on extra functionality and capabilities as their needs (and their budget) grows.

For over 25 years, I sold a legacy accounting system that was completely modular based. This system had over 20 modules and we had customers using as little as 3 modules, right up to the full suite. At the outset, this seemed like a great idea - after all, a smaller business that was just starting out and had a couple of employees didn’t need full inventory and warehousing. Just the basic debtors and creditors control, and perhaps a general ledger with bank reconciliations. As their product lines (and their cashflow) grew, we could add inventory control, and perhaps purchasing.

However, we repeatedly came across situations where customers would actually refuse to upgrade, even though they needed the extra modules because they were struggling to cope with just a subset of features. We also had customers who would purchase the extra modules, receive training and implementation assistance, then a year later we’d go on site and realise that they simply weren’t using them any more.

This always bugged me and I couldn’t understand their rationale behind this. To me, it was counter productive and wasteful.

Then it happened to me.

We have been using HubSpot’s free CRM offering here at my startup HR Partner for a few months now. Our very small team loves the software, and I like how it integrates with our support system, our G-Suite emails and other services we use. It was a great contact management tool, however we were starting to push against the edges of the capabilities, so two weeks ago, seeing as we were growing and increasing our cashflow, I decided to bite the bullet and sign up for HubSpot’s full sales and marketing professional suites - a not insignificant investment in terms of time and money.

After the first week of training and setting up configurations and being excited about things, I noticed after a few days that my team members, and myself, were reverting back to just using the contact management functionality. I mean, we had these great tools for capturing form information, setting up automated email reply sequences, automatically scheduling demo bookings etc. all with a press of a single button (and sometimes not even that), but we were going back to typing long hand repeated emails and booking demos the ‘old way’.

This process made me realise that sheer working habits and ‘muscle memory’ dictates a lot of the ways that a team will work. Old habits die hard.

The other thing I realised is that we probably tried to change too much too quickly. Had I rolled out the new features piecemeal over a few weeks, it might have been easier for the team to get completely familiar with one feature before having to learn another one. To that end, I am still rolling out all the fabulous automation that HubSpot has, but slower, and with a little more discipline. I am also listening to the feedback from team members during the rollout, to hear what their thoughts are on each little feature, plus seeing if they have any suggestions for improvement, rather than just setting everything up myself and telling them to go use it.

One last thing I’ve noticed is that if a software system has a lot of features, and most of those features are hidden away out of sight (because the customer has never activated those modules), then it is much, much harder to lead the customer on the path of discovery towards those new modules. We came across this scenario time and time again with the legacy accounting system I spoke about earlier. Our customers would simply have no clue that they could do ‘x’ in that software because they had never seen anything in the system that even hinted at it. It was only during regular on site consulting calls that we would have to talk to the customer about it whenever we discovered there was a need for it.

Even with HubSpot, I am astounded every day when I see what added functionality there is within the system. I would have completely redesigned some of our business practices and processes differently had I known what we would have unlocked by signing up for the full plan. To change them now is much more difficult than setting them up a certain way at the outset.

Taking all this into consideration, I am glad that we designed our flagship SaaS app HR Partner differently. We considered having a ‘modular’ structure at one stage (and indeed, at one stage we even hid the extra modules on the menu that we thought our customers would not use yet), but eschewed that path to provide an ‘all in the box’ solution. The only thing we charge extra for is the Timesheet module, but only about 10% of our customers actually use that, and it is not really an ‘optional’ thing anyhow, but rather something that you would need straight away.

So if you sign up for HR Partner, you get everything available to you at the same monthly subscription price. Users who are curious can click around and self discover new functionality, and they can ask us about it if they need a hand setting it up - or else they can simply play and experiment at their own pace. No need to talk to a consultant or support person and get roped into paying extra. Also, by knowing that the functionality is there, they can better plan to implement it in the future, or set up processes now which will accommodate the extra features down the track.

Do you sell modular software systems? I would love to hear your thoughts on the pros and cons of this methodology.