October was a month of tepid gains.

Income wise, I earned $1,022.07, down just $72 from September. The difference appears to be that October’s revenue remained consistent at the lower, post second-week-in-September rate, whereas September had one good week before income dropped. I’m still disappointed that revenue dropped in the first place, but the good news is that revenue isn’t dropping further.

In terms of engagement, users were up 8.6% in October. October’s gains, combined with September’s and August’s were enough to finally overcome the loss of audience size that started back in May. Comparing comparable time periods (both starting the same day of the week, and counting the same number of days), Audience size in October is just four tenths of a percent down from April, which is within the noise.

It’s not all good news when looking at audience size, however. While October and April’s overall audience sizes were comparable, per day rates were not. On average there were fewer users per day in October than per day in April, which could indicate a lower retention rate in October. Diving in with Google analytics it appears April users were more likely to return quickly, within 0-4 days. I’d really like to investigate this further, and get a sense of why users might not be coming back as frequently as they once were. It looks like a different breakdown in app popularity could explain the difference, but I’d like to be sure there isn’t some larger issue lurking.

This month I’ve been working on bug fixes, interface design and user experience.

At the end of September I was alerted that mobile-first indexing was now enabled for datayze. I knew it was coming, and was already pretty pleased with my current approach to mobile. One area of concern still is browser resizing. Each app interface is great if you’re on a mobile screen, or a desktop screen, but if you grow from the former to the later, or shrink from the later to the former, sometimes things can get a little wonky. It’s not a common case, but one that should be addressed just the same.

September looked like it was going to be another explosive month. One week in and revenue was up high enough to put my business on track for the $2,000 per month milestone I was aiming for. But just as suddenly (and unexpectedly) as the increased revenue came, it vanished. Despite users being up 4% for the month, revenue dropped to only $1,128.36. Publisher coverage was down 20%, and adclicks were down nearly in half.

Despite spending most of the month trying to root out the cause of the revenue drop, I couldn’t identify the source. The drop occurred around the time I pushed an update, but it really doesn’t make sense for that particular change to effect revenue. It didn’t change either page content or user interface in a meaningful way – just replaced one text link with a button. If anything, users appeared more engaged afterwards. Time on site was up 19%, and the bounce rate down 63%. As far as I could tell, everything should be good on my end.

That’s not to say Datayze was error free in September. There was a nasty time zone bug effecting my time management apps for some users. I was finally able to identify the root cause after some user feedback. It appears the bug was introduce at the end of August. Since the bug was effecting my most popular apps I had some hope that it might have been effecting revenue in some round about way, but revenue remained largely unchanged after the fix.

Aside from interface improvements and bug fixes, I also launched a new app, Days Until/Since. Days Until gives you a total count, as well as the number of each type of weekday. It also precomputes the date of many popular holidays a user might not know of off the top of their head, like Thanksgiving.

While it’s hard not to be disappointed in the revenue drop, I’m trying to remain focused on the positive: $1,128 is still twice the revenue from June and May. Users are up, and we are heading into the most lucrative part of the year.

I’m always nervous when something unexplained happens. When I couldn’t pinpoint why July’s revenue was way up I braced for the possibility that it might drop just as suddenly. Well, income rose to 1,406.88 in August, and users are up 4.7%. I’m now feeling confident this change may be permanent, and since my numbers tend to go even higher leading into the final quarter, I’m daring to hope $2,000/month may be a possibility by the end of 2018.

This month I continued to focus on user experience.

The Apache server log parsing script ended being so useful at uncovering hidden issues last month that I decided it was finally time to add unit tests and see what issues they could uncover. Unfortunately the current code base wasn’t designed with unit tests in mind. (I don’t fault my prior self, it was important to hit the ground running those initial years and get content fast to start building an audience.) I was able to add a unit test case framework for my PHP and Javascript code, and enough unit cases that I did uncover one issue in a function very rarely called. All things considered, the time spent creating the unit test framework has not paid off yet, but going forward I’ll be sure to code with unit tests cases in mind and that will ultimately lead to less time debugging. It’ll also be useful for the next major code refactoring.

I found a couple of nasty bugs.

The first major bug was an issue in the way I was calculating time, and an example of premature optimization. I was trying to be clever and it bit me. (At least the issue wasn’t in the modal window which I had been working so hard on!) The new approach is not as efficient, but the differences does not appear to be human detectable. Since the time motivation suit is so important, I made sure to have tests cases to catch any further issues.

The second bug was the result of a third party library failing silently on less than perfect input. In my opinion that is unforgivable. Imperfect input is more common than perfect input online, and it’s often easy enough to do basic sanity checking to catch most issues. It also failed for URLs that included non roman characters. Rather than try and patch it, I decided to write my own library (also with unit tests!) with new interface that’s more suited for my use case.

My plan is to avoid third party libraries wherever feasible in the future. I keep running into issues with them. Perhaps it’s an unrealistic fear, but I do worry that the licencing might change on me after I’ve become dependent on one. And then there’s the time the api was completely changed on me

July simultaneously both blew away expectations and disappointed. I earned $1,355, over double of last month and well over the $1,000 target I initially set for myself when starting self employment, but I also had a 10% reduction in audience size.

My initial fear about the increased revenue was the additional ad clicks was due to misclicks, unintentional clicks on ads. A bug in the new interface could move the ads too close to app buttons, causing accidental clicks. That would drive down user experience and hurt my ultimately bottom line long term. (Not to mention if Google thought ad clicks on my site were low quality they may elect not to advertise with me.) Fortunately, that does not appear to be the case. Revenue has been consistently up since the new launch. It’s up among all devices and across all apps, though Time Until saw a considerably larger increase than the other apps. I have also verified there is still a significant separation between app and ad on all major platforms.

My working hypothesis is it’s a combination of factors. Revenue up across all platforms and apps could indicate an update on Google Adsense: better ads leads to more clicks leads to more revenue. It’s also possible that with the new launch and interface tweak the html changed in a way that made the page more accessible to the google spider allowing it to choose better ads.

The new admin panel is already proving invaluable. One of the new features was a view that groups all apache messages by type – warning, error, etc – in order to make it easier to see what’s going on with the site at a glance. This has lead to the realization that visitors are using the apps in some ways I haven’t anticipated. For example, I was intending the name blender to be used with single names, like Sarah + Emily, but found some visitors were imputing multiple names, eg Emily Elizabeth + Charlotte Rose. I only detected this because the space caused a php warning message. It was technically working, but the blended names were a little wonky. The tool now handles this use case much better.

The new error log binning also helped me uncover a spelling mistake in a URL. Since it was a one character typo and I use automatic spell correcting on my 404 errors, the spelling mistake resulted in a 301 redirect message to the right URL. As a result, a human would never notice it, but it could affect web crawlers and therefore ranking & indexing.

Overall errors are down to 0.003 per user. About 80-90% of the errors are non-linking 404 File Not Found errors. This includes instances that are clearly probing to see how my site is put together, and possibly looking for vulnerabilities. (“/admin”, really? I don’t rely on security through obscurity, but at the same time I’m not going to make it that easy for you.) I’m not seeing any more message from Dreamhost about the server being unstable, but I am seeing some indication in the logs that Datayze is under heavy use and that can cause hiccups. Since I wasn’t monitoring the logs before, I don’t have a frame of reference for what’s expected given a site of this popularity. I plan to continue to monitor the situation. At least now it will be easy to switch servers should the need arise.

Finally, I launched Time Since, a companion app to Time Until.

Two years ago I officially rebranded as Datayze, and forever changed the trajectory of my business.

Four days ago I did a major new launch, and this change could prove to be just as meaningful. Not only is the set up more professional – I can now monitor site health from my phone! but I can also do light weight debugging from the rocking chair. Productivity is up, and so is what I’m dubbing ‘developer confidence’.

This past year I’ve had six times the users, six times the revenue, and six times the page views. My Alexa rank is 127,191 surpassing the ranks of all my major competitors, and grown from 4,000 monthly users to a quarter million. It’s stunning to me that I’ve been able to maintain a near 20% month-over-month growth rate since Datayze’s launch. I remember when 600 daily users was a big deal, and crossing the threshold of 1,000 daily visitors. Then came the mornings where I’d reach for my phone as I was getting out of bed to see if Datayze had already had 1,000 visitors by 6:30am. Followed by mornings where I’d eagerly check to see if it was 3,000. Then there are the intangibles not reflected in the numbers. Datayze is having a real impact.

Working for yourself is difficult, exhausting and at times demoralizing, but also ridiculously rewarding. Revenue looks like it’s going to be way up this month, surpassing the monthly target I initially set for myself. It’s an incredible feeling. It’s taken me longer than I anticipated to get to this point as I had hoped to reach this revenue goal last year, and yet, I also never thought I could build such a popular site. (Which also says something about my revenue per user expectations.)

Growth will inevitably slow. It already is showing some signs of a slow down (though I’m still hoping that’s summer related.) I’m hoping to spend the following year diversifying more and insulating myself from seasonal patterns. Diversifying could mean a wider portfolio of apps, or multiple different revenue sources.

I also wouldn’t say no to an Alexa rank of 100,000.

Forgive me for a late update, I’ve been working crazy hours ahead of this last launch. I was desperate to get it out during the holiday week when traffic was low. So far everything looks great, but before I get into that let’s talk numbers.

In June I earned $630.34, just under $100 from March’s high. Users are down 6% overall, and down 9% from organic traffic, two numbers I’m not thrilled about. Mobile users is up 5%, while desktop is down 25% and my Alexa rank continues to inch upwards, a possible sign that summer may be keeping people away from there desktops. I’ll be keeping close tabs on the numbers this month.

Delaying the launch was outstanding issues in Time Until and Miscarriage Chart. Combined those two apps make up 66% of my traffic so they needed to work flawlessly ahead of the launch.

The primary hold up with the Miscarriage Chart had to do with my new approach to mobile. Prior to the launch I had been using PHP code to detect device type (mobile or desktop) and serve appropriate content for the screen size. The primary advantage of this approach was I could serve vastly different html per device. The drawback, however, the PHP code needed to be kept update with the ever changing device landscape. Now that tablets are becoming more common, there’s more device types and screen sizes I need to pay attention to. It was going to become unmanageable. I’m now doing the cleaner approach of using media CSS statements, but it took sometime to find a block of HTML code that could be display as desired correctly across all device sizes via CSS.

For Time Until I wanted to incorporate time selection into the datechooser modal to clean up the interface a bit. I had started this process last year and finally felt comfortable that it was bug free and wouldn’t hurt my brand. I wasn’t sure it was as intuitive as the original datepicker. This is we’re having more experience with interface design would be useful. The interface could still use a little more work – here’s where not having a UX experience is working against me – but it’s better!

The past month, and especially this past week has been crazy busy ahead of the new launch. During evening and middle of the night time feedings I’d test out my site on my phone. I’d open every app on my phone, test every possible input, including invalid ones. I’d check the site health on my new admin panel and logging bugs and issues into todoist, all from my phone. During the day I’d hammer out as many quick fixes as possible. Truth be told I’d rather have another week before the launch, as not all apps were working quite to the level I wanted, but most of the issues I was discovering existed in both my test bed, and the previous launched code already in production. I didn’t want perfect to be the enemy of good.

I was initially thinking I’d have a long night ahead of me, but I’ve been watching the admin panel and have confidence there are no major fires.

In May Datayze earned $629.09 and had -0.4% growth. I hate negative growth, even when it’s to be expected, and even when it’s a fraction of a percent. It’s strongly motivating me to get this next launch out the door.

I had an unexpected interrupt this month with GDPR. I should have been more aware of its approaching deadline than I was. I only realized I could be affected a few days before the May 25th deadline. Fortunately, I have always strived to do the right thing when it comes to privacy, and that helped make becoming compliant easier.

I don’t store any information that can be deemed unique or personally identifiable. I don’t even store passages of text supplied to the writing tools, or results of the URLs crawled by the spider which could theoretical be personal. I do store other form inputs (like age in the miscarriage tool), but not unique and not identifiable. At least in some cases, it’s not even personal. I’ve gotten a handful of emails from users indicating they were using the tool relative to someone else’ pregnancy, like a husband for his wife, or a parent excited for a grandchild. I sometimes see exploring different values, presumably to get a sense of the range of possibilities.

The main hurtle in keeping up with GDPR was that I keep traffic logs which contain ipaddresses. I stored it for website analysis to understand how users use my site and light weight personalization like ordering the apps by preference so users can find the ones they will likely want faster. I opted to go the pseodnomization route of converting the last octlet to 0, since that seems to be the internet standard approach. I’m not sure what I’ll do with regards to personalization. I’m considering dropping that feature, or using cookies.

Other than that my planned big migration is ticking along. I keep thinking my admin panel is set and then coming up with a new idea that could help monitor site health. I recently wrote a server log parsing script that buckets all errors by type and by page. I’m still geeking out over it.

In April revenue dropped to $618.01, and there was a 1.8% growth in users. Less than expected, but not alarmingly so given that we’ll be heading into the summer months soon which tend to be a time of slow down. My Alexa rank continues to climb which could be an indication that my piece of the global audience pie is still growing.

Bit by bit I’ve been able to carve out more time for Sarahsoft.

Last month I lamented not having smoke tests. I ran into a problem a few years ago when my host updated the PHP server. A function I was depending on was deprecated. As a result, one of my apps began to fail silently. Two years ago I lost 2 days after an updating a dependency changed the way the apps displayed. I’ve learned to test often, even when not updating my code. Smoke tests can automated some of that, freeing up more time for development.

At present the primary thing I’m looking for in my smoke tests is development code that slipped into production, such as code that references individual source files rather than stable build files, or specify a build file other than the current one. Although it shouldn’t effect functionality, I’m looking for code with TODOs and debugging output in production. Such conditions could be a sign that I wasn’t ready to launch the new code, and did by mistake. Maybe I forgot a task wasn’t complete, or that I needed to finish an edge case for a feature.

I haven’t gotten any more warnings about memory issues which takes some of the time pressure off. My primary goal is still moving Datayze to it’s own user account, and it’s own VM. I probably should have done this after pushing all the pending changes from the winter so that I was only working on one thing at a time. I’ve needlessly complicated things a bit for myself. Ah well, live and learn.

I have been bit by the coding bug. After last month I had the itch to get cracking again and I desperately wanted to cross stuff off my todo list. Time is still my biggest challenge, but I’m finding a little more time to carve out each week.

First, let’s dive into the numbers. March saw a 16.7% increase in users and topped out at $727.75. My goal of $1000/month feels so close! Time Until Countdown continues to be not only my most popular app, but one of my fastest growing apps as well with a 25% increase in users.

I decided to go ahead and move Datayze to the new user account on my server now, walling it off from my personal stuff. I have a number of new features to roll out, including site wide changes so I set up a “test” domain (new.datayze.com) on the new user account. It’s password protected (so don’t bother trying to visit it) while I iron out all the wrinkles. Once it’s running smoothly, I’ll change the DNS servers to they point “datayze.com” to the new location, and remove the test domain. It should be a seamless transition, but it might take a little while given the number of features I’m rolling out.

My current focus is on upgrading the admin panel so it functions more like a panel and less like a collection of scripts. There’s a work flow to the admin panel now. There’s a section for shepherding new apps from implementation to launch. I already had an analysis framework for better understanding site usage, but it was old and slow, written for a time when I had far fewer users. That’s been spruced up a bit. The biggest thing I’d like to add next is smoke tests, code that’s designed to look for issues before they arise. I check my apps periodically for speed and mobile usability issues, but it would be nice to have to be more proactive.

One potential issue I may have this month: I’m getting warnings about memory usage again. I strongly suspect a memory leak, but tech support thinks it’s this blog (sktyler.com)’s instance of WordPress. By separating Datayze to its own user account I can seamlessly push it to a separate VM. Then, assuming tech support is right, this personal blog with a handful of readers won’t negatively impact my business. Even if tech support is wrong, it’s still worth doing, especially since my goal is to build multiple Datayze-scaled sites.

My goal is to launch Datayze on the new account with all the changes in a few months. I can’t decide yet if that’s a stretch goal or not.

This past month Datayze saw a paltry 1.5% growth in users and a whopping 23% growth in revenue. I’m now up to $627.76 per month, and it was a shorter month! It’s not the $1000/month goal I had set for myself, but I am headed in the right direction.

I intended to focus on emails again this month, however I was contacted about a nasty bug in one of my web developer apps. Given the symptoms it sounded like something that could be effecting all of those apps. I have long since wondered why those apps weren’t more popular, and now I might have an explanation. Even better, the person reporting the bug appeared eager in trying the tool again when it was fixed. It was an opportunity too good to pass up. The issue was a logic mistake with an easy fix. From initial investigation and final testing of the patch was no more than an hour. I will monitor the web development section of datayze in the coming months to see how users respond.

The amount of spam I get is starting to get out of control, and I’m the biggest culprit. Whenever someone encounters a 404: file not found error on datayze, I get an email notification. If the automated script can determine what URL the visitor likely intended, I get an email notification. A corollary to getting a lot of visitors is getting a lot of notifications. Some are for meta data files I’m not currently hosting (e.g. apple-touch-icon.png). Some of those errors are for specifications I’m not using (humans.txt, ads.txt, etc). Some are probing (e.g. wp-admin.php to see if my site uses wordpress). This information is useful, but it can wait until I’m ready to sift through the logs and plan out my next update. No need to send myself a daily notification, or fifty. Instead, I’d like to only be notified in situations that are actionable and time sensitive, such as a misspelled forum referral that can’t be auto addressed.

I’ve been spending a lot of time thinking about how I want to solve problems, and the direction I want to take certain apps. I hope to find the time this coming month to start putting plans into actions.