The day has finally come: uFincs has been open-sourced! Check out the announcement on the official uFincs blog or hop straight on over to the repo if you feel so inclined.

That is all. Carry on.

Enter: the GCP "Easy as Pie" Serverless Hackathon.

The Hackathon

$20k prize pool. $10k grand prize. 5 "runner-up" $2k prizes. All in the name of trying out the latest and greatest in GCP serverless tech: Cloud Functions, Cloud Run, and Cloud Workflows.

Unlike the last hackathon — which had a much more specific theme — this hackathon's theme was much simpler: just use the serverless tech and build something... Cool. Creative. Interesting. Maybe sprinkle in some machine learning if you're feeling it.

Well, I was certainly feeling it. These serverless techs were definitely something I had familiarity with (with the exception of Workflows, which was new to me), so this seemed like a great opportunity to flex some tech muscles and put together something a bit more worthy of a $10k grand prize than my last 3 hour "project".

However, it didn't start out that way. Initially, just like the last hackathon, I wanted to take one of my existing projects — the Dank Meme Classifier seemed like a perfect fit this time — deploy it, and call it a day. But as I went over the judging criteria, I decided to think about things some more:

Technical Execution

• How has the team effectively utilized at least one Google Cloud Serverless product — Cloud Run, Cloud Functions, or Workflows?

• How easy is the application to use?

• How advanced is the prototype presented?

Completeness

• How soon could your project go to market?

Return on Investment (ROI):

• Is the project cost-effective?

• Is the project worth pursuing?

If I wanted to win the grand prize, I'd have to look at maxing out all of these criteria. The Dank Meme Classifier would get close, but I had my concerns about the ROI category: I didn't really think it would be considered a "project worth pursuing". Additionally, while it was a "complete" product, it wasn't a particularly "advanced" one.

The Idea

As such, I started brainstorming. I still wanted to use the Dank Meme Classifier as a base, but wondered how it could be expanded to be more "advanced"...

How about a game? What if we gamify classifying memes?

Yep, that was my brilliant idea: The Dank League of Memeing Battlegrounds. A game where you're given 10 memes, a timer, and the ability to swipe them up and down to guess if they're dank or not. And how do we know if they're actually dank or not? Using the dank meme classifier!

So how does that idea do on the judging criteria? Well, Technical Execution would be effectively flawless. Cloud Run will host the Frontend (React App) and Backend (Flask API) just like is done for the Dank Meme Classifier, and Cloud Workflows will replace PubSub to coordinate the litany of Cloud Functions that are used for ingesting and processing memes from Reddit. Gotta make sure to use all three services cause that'll clearly win more points.

As far as ease of use and how advanced the 'prototype' would be, well, that's just all about building, so just gotta execute to prove those right.

Same thing as far as Completeness goes.

Now, that pesky ROI category... the project was always going to be cost-effective — as long as we look at things from an infrastructure POV — since these serverless services are basically free at the scale we use them.

But is the project worth pursuing? Well, it's more worth pursuing than just the Dank Meme Classifier, so that was good enough for me. Of course, this is almost assuredly what did me in in the end as far as not winning the grand prize, so... no.

In any case, a game about swiping memes up and down was it.

The Implementation

Once the idea had been manifested, the project just became the usual building process: Sketch out the UI. Build some Figma mockups. Put together a giant to-do list. And Just. Start. Grinding.

First up was getting all of the Cloud Functions for the meme ingestion pipeline re-deployed and refactored to work with Cloud Workflows. As I mentioned, they were originally built to work with PubSub, but I found Workflows basically perfect for this use case of passing data between a bunch of Functions. Of course, I also wanted to expand the number of Functions being used for... you know, 'judging' purposes.

Next up was building the new Frontend. Decided to go with NextJS this time just to get some more experience with it (the ongoing hotness and all that), but it was just the usual process of "build each page, make them functional, yada yada". Nothing but fun, grindy React + Sass here. Of course, making the game actually work wasn't completely trivial, but it also wasn't all too difficult once I threw react-spring at the problem.

And really, that's what makes an app feel "polished": lots and lots of (react-spring) animations. If you want the secret to wowing the judges, the answer is always "add more animations".

After several weeks of off-and-on coding, I had a working game. Much wow.

But of course, the actual app is only one component of a hackathon project. As everyone knows, it's the presentation that really matters. And just like for the app, I decided to take my presentation up a notch this time.

Just to compare things, this is the video I submitted for last year's hackathon.

And this is what I submitted this year.

This year's video is an improvement in every single way possible over last year's.

For example, last hackathon's video was literally a single take, completely made up on the fly, using basic screen recording and my laptop's built-in mic. No edits, no effects, no nothing; I just needed to record a demo as fast as possible to submit before the deadline.

This year, though, not only did I script the video... not only did I use a proper dedicated microphone... not only did I do multiple takes... not only did I screen record dedicated a-roll/b-roll... not only did I spend much more than just 10 minutes on it...

I literally taught myself (the basics of) video editing and Final Cut Pro to stitch everything together.

That's right, using the proceeds from my first hackathon win, I ended up buying my first Mac (an M1 Macbook Air) and unlocked access to Apple's line of Pro creative apps — Final Cut being the obviously useful one here. Quite poetic that it would end up playing a big part in 'winning' me my next hackathon.

Of course, that's just the technical side of the presentation. The creative half was coming up with the utterly 'humorous' branding and messaging. It's one thing to build a joke project; it's quite another to full-commit and market it as one.

And with that, I had a complete project submission! Twas a fun month putting everything together and learning the basics of video editing.

But now, for the final results...

The Results

Serverless Hackathon winners announced | Google Cloud Blog

Yep, I 'only' won one of the runner-up prizes (or, as they put it, "Best in Show" prizes). I can only speculate, but I would bet serious money that the reason I didn't end up taking home the grand prize was that my project idea was too much of a joke. Heck, the blog post even goes out of its way to say that the judges awarded the Dank League of Memeing Battlegrounds an "A+" for execution, so it only seems like the logical (and utterly unsurprising) conclusion.

In the end, was it worth it? Well, the ROI was certainly several orders of magnitude worse relative to my first hackathon win, but it was still (kinda) a win, so... probably.

Would I have done anything differently? No. Should I have done anything differently? Well yeah, guess I should have chosen a more serious project idea! A useful/serious project idea combined with my level execution would almost certainly guarantee a grand prize win.

But where's the fun in that?

Till next (hackathon) time.

It sure has been a while since I posted here. I guess it's time to catch you up on what's been going on with the matters concerning my existence.

Last Time

uFincs Update #13 was published more than 4 months ago. At this point, even I barely remember what was in it. Let's see... oh right, looks like it was about my experimentation with Capacitor for the native apps. Yeah, we'll get to the latest update on those in a bit...

But first, let me address the elephant in the room.

Where have you been for 4 months?

Long story short, towards the end of August, I ended up getting recruited for a full-time job.

Yes, I ended up putting uFincs on the back burner.

Why? I guess burnout, mostly. Turns out, being a solo founder is hard! Who could've guessed?!

Anyways, I basically just needed a break from working on uFincs. It just so happened that that break came in the form of working for someone else on something entirely different. I must say, it's been nice to have a team to talk to on a daily basis and to have a steady paycheck again — two things that were noticeably absent when working strictly on uFincs.

So why have I now returned? Well, I figure 4 months of silence is long enough as-is, so it couldn't hurt to bring in the new year with an update. That, and I've got some things to discuss.

Let's start with the good stuff: new features! Or, at least, one new feature.

Currency Symbol Preference

Yes, after oh-so-many people asked, I am finally relieving the world from being forced to use the almighty "$"! Now you can choose from €, £, or even ￥ to display across the entire app. Or, well, just about any currency in the world; it's a long list.

No, this is not "multi-currency" support; this is just allowing you to customize the (singular) currency that's displayed across the app. Multi-currency support is still not happening any time soon.

And yes, this is all I managed to accomplish for uFincs in the past 4 months. I really have been spending my time purely on New Job™ and relaxing.

OK, with the obligatory new feature announcement out of the way, I want to dive into a new year's classic: the good old retrospective.

2021 Retrospective

How was 2021? Was 2021 a good year? Well, it certainly couldn't have been worse than 2020, so I guess, relatively, it was a good year!

But was it a good year for uFincs? Yes and no. If we go all the way back to the first uFincs posts (Update #1 and Update #2), we'll find my goal for the year:

The focus of 2021 will really be getting uFincs into people's hands (aka, applying the wonder that is marketing), and getting paying customers. I'm putting it on public record that my goal is to get 100 paying customers on any paid plan (monthly, annual, or lifetime) in 2021.

First of all, I did not hit that goal. At the end of the year, I've got (checks notes) 4 paying customers.

However, even though I didn't hit my paying customer goal, I still think 2021 can be considered a good year for uFincs. Why? Because it launched. Even if I had gotten zero paying customers, I'd still say this was all successful and worth it because I actually managed to put uFincs 'out there'. The fact that I acquired any paying customers is just the cherry on top of that (thanks everyone for your support!).

And it's not like business goals are the only thing I had set for myself. As far as technical/development goals were concerned, I did pretty damn well on them, delivering pretty much every feature I had planned (well, except for my precious command palette... and native apps... hmm). Which is really to say, uFincs is at the point where I'm happy with it; it can do at least everything I need it to do and then some.

So what stopped me from accomplishing more? What stopped me from hitting that glorious 100 customer goal? A few things:

• The general anxiety of launching.

• My general lack of expertise in the fields of marketing/sales.

• My general unwillingness to market uFincs using 'conventional' methods (e.g. paid ads).

• A general feeling of burnout.

This all just means that I clearly need to over-correct and set much less aggressive goals for 2022! Speaking of which...

What's Next for uFincs in 2022

Going forward, uFincs is very much going to be a "part-time" affair for me. Based on the last few months, I'd say that I'll be putting roughly 1/10th of the work in as I did in 2020/the front half of 2021.

Really, most of this comes down to uFincs not really being viable as a self-sustaining business. Could it eventually grow to be one? I can see that happening, but it's definitely one of those businesses that would grow along the SaaS ramp of death.

That means that my goals for uFincs (at least for now) have changed. Rather than trying to grow and acquire customers, my primary goal is now to minimize the overhead that I incur for uFincs.

What does that entail? Well, really it just means that I'm gonna be scaling back my development/marketing efforts for uFincs. That is, fewer new features and fewer blog posts.

Although this goal does put me in a small pickle about what to do with some of my backlogged blog posts. I've got some posts that were supposed to be key marketing pieces for uFincs, but now I'm not quite sure what to do with them now that I'm not trying to market uFincs. I could just publish them and forget about using them as marketing pieces but that just feels like a waste... Or I could just wait to publish them until after open sourcing.

Speaking of which, what do I actually intend to do with uFincs in 2022?

Open Sourcing

My main goal is to open source it.

Now, that might seem contradictory relative to the goal of "minimizing overhead" (and it probably is), but considering what uFincs is (a self-contained, privacy-focused finance app) and what I've gotten as feedback from people, open source seems to be very high up on people's wishlists.

But even beyond what other people want, it's what I want. Look, I didn't go into this business seriously thinking that I'd strike it rich (as much I might have hoped otherwise). As such, I've always planned for uFincs to go open-source eventually. Now it's just a matter of making that happen. There's some administrative and technical stuff that I need to take care of before that can happen, but I want it to be the big thing for uFincs this year.

And before anyone asks, no, the paid version of uFincs isn't going anywhere. Remember, more than anything else, I am uFincs' #1 customer, so I'm reliant on uFincs being available as a service to manage my own finances. It just so happens that others make use of the same publicly available service :) (not that I'd fault anyone for just self-hosting it instead once it goes open source)

Native Apps

Now, about those native mobile/desktop apps... After thinking about it a lot, I've decided not to 'officially' release them. Between all the nightmare stories I've heard about dealing with the app stores, the general extra support overhead they'd introduce, not to mention the technical overhead of publicly maintaining 4 'versions' of uFincs... frankly, I just don't want to.

However, that doesn't mean that they're not happening. I've had the code and the ability to generate the iOS/Android/Electron builds of uFincs for many months at this point (thanks Capacitor!). So I'm going to compromise on this by keeping that code in the repo when uFincs goes open source — then anyone who really wants a native build can compile it for themselves.

On the one hand, from a security/privacy perspective, this is probably about as good as it gets! (building from source, that is) On the other, however, I acknowledge that it's a pretty terrible user experience. So I'm not taking the possibility of app store builds for uFincs off the table; it'll just be one of those things I deal with in the future if I ever get super ambitious again.

Anything Else?

No, not really. At this point, I don't want to commit to delivering any especially fancy new features or anything (which, knowing myself, means that I'm effectively committing to accomplishing nothing...). At this point, I very much want to just play it by ear. There's obviously a ton of things in my backlog with some features having been re-prioritized due to people's feedback, but I'm just gonna work on things slowly.

You know, "move slowly and build things".

Final Thoughts

2021 was an interesting year. I managed to accomplish one of my dream goals (launching a business, no matter how small). Then, in a complete twist of fate, I managed to pivot into full-time employment. Not exactly what I had in mind for finishing up 2021, but it just means that 2021 was successful in ways even I couldn't have anticipated.

Who knows what's in store for 2022. I suspect full-time employment will be taking up a large portion of my time but maybe open sourcing uFincs is what causes it to take off. Only time will tell.

Speaking of which... till next time :) And Happy New Year!

Last Time

uFincs Update #12 was just a preview of the new Import Rules feature (of which the official announcement can be found here).

I anticipated this being a rather large feature to implement and — lo and behold — it was! I originally estimated that it would take 4-6 weeks, then 4-8 weeks, and it ended up taking the full 8 weeks. Just another grand example of Parkinson's Law at work!

Anyways, that's in the past. Now we have to discuss the future. What exactly is next for uFincs?

There's one large elephant in the room that I want to talk about: native apps.

Native Apps

A 'feature' that has been highly requested (for good reasons), native apps have been something that I've just kept pushing back more and more. This has been for primarily two reasons:

1. There is a large amount of upfront work to build them, even taking into account all of the efforts I've gone to ensure that we can re-use as much code as possible.

2. There is a non-insignificant time cost (mostly related to development velocity) to supporting more platforms than 'just' web.

As much as everyone (myself included) wants there to be native apps for uFincs, I've found it hard to justify their development. Sticking with 'just' a web app seems so much simpler and easier, especially for the company-of-one that is uFincs.

And while I had included them as part of my roadmap for 2021, if I was going to go about building them in React Native (my original plan), then they would have likely taken up the majority of my 2021 development time by themselves. Weighing feature development vs native app development (vs marketing vs ...) is always a tough decision, with features generally winning out with web apps since web apps technically do work on all platforms.

However, I recently came across a piece of technology while reading Hacker News that, quite frankly, I probably should have already known about. However, in my defense, if I didn't know about it, then it certainly stands to reason that maybe they are lacking in their own marketing department.

In any case, I'd like to do some of their marketing work for them and introduce you to Capacitor JS.

Capacitor

From the team behind Ionic, Capacitor is a "cross-platform native runtime for web apps". In other words, you just plop the @capacitor/core package in your web app, run a command or two to bootstrap the files for an Android and/or iOS app, and now you've got your web app running in a 'native' Android/iOS app.

Quite literally.

I know there have been several attempts to achieve such an experience in the past, but wow, Capacitor is the first one I've tried that actually nails it. Heck, it took me longer to get a stupid Android emulator working than it did it to integrate Capacitor into uFincs!

Within maybe half an hour, I'd gone from "installing Capacitor" to "uFincs running as a native app on an emulated device". Now, to be fair, that half an hour did not include having uFincs working on a native device (I only said running). There was still a bit more work to be done to get all of the networking config in place so that the app could talk to my local API server (which, again, is more the fault of the Android development experience than anything to do with Capacitor).

But still. That turnaround time is insane compared to what it would take to, say, rebuild the whole app (mainly the UI) in React Native. I'm talking like 1 hour vs several months here.

So how does Capacitor do it? Well, as far as I can tell, it's not especially more innovative than other solutions have been in the past. It basically just takes the built static assets from your web app and serves them inside a web view that is rendered within the native app. It also does a bunch of bridging to allow the web code to talk to native code for features like push notifications (aka stuff I don't really care about for uFincs). The core idea is still just "run the web app in a web view with a native shell", but with a more refined and polished development experience.

Obviously, if uFincs didn't already have a mobile-optimized design, then all this Capacitor magic would be a rather moot point. So you could argue that the many months I spent in 2020 redesigning the uFincs UI would be where all the 'work' has gone.

But all I really care about right now is the marginal work it would take to go from "uFincs as a web app" to "uFincs as a native app that can be installed from the app stores". In this case, Capacitor seems to shrink that time down dramatically, again relative to my original plan of using React Native.

The Spike

In that vein, I decided to take on the Capacitor integration as a 'spike' (aka a short-term experiment or proof-of-concept, but you know how those Agile folks love their buzzwords). After my initial experimentation with getting Capacitor working with Android, I wanted to see if I could then get it working on iOS and desktop, and then get it as close as possible to a 'publishable' version (aka iron out the kinks).

iOS ended up taking a bit more work, mostly due to styling issues. Since the web view on iOS is still just Safari, I ended up having to deal with all the same quirks/bugs I ran into when first testing on Safari. They all happened again because the "is Safari?" logic that I had relied on checking the user agent (an already unreliable indicator), but the iOS web view didn't have the same user agent. Thankfully, it was mostly just a matter of adding a Capacitor.getPlatform() === "ios" check.

Additionally, I decided to switch from using IndexedDB to using Capacitor's Storage plugin for redux-persist's storage backend, just as a more reliable way for storing user data. I know that Capacitor doesn't recommend using the Storage plugin for large amounts of data, but I'll need to do some further performance testing to see if it really hampers anything as a user scales to thousands of transactions.

Another big change I did (for Android and iOS) was remove every mention of signing up or subscribing. Not from past experience or anything, but I know that the app stores have been particularly stringent when it comes to managing paid subscriptions through anything but their own payment services. I figured preemptively removing all such mentions would save me some headaches in the future (if you want such an example of a headache, check out this latest situation).

Yes, this makes for a worse user experience (since one could download the app and be greeted with only an option to log in but not sign up), but since we provide the ability to use the app without an account, I think the compromise is worth it.

As far as desktop goes, while Capacitor doesn't have first-class support for something like Electron, there is a community-built plugin for adding Electron as a Capacitor platform. Which, I will say, worked basically flawlessly — just as the Android and iOS platforms did.

The final 'hurdle' was changing out the app icons for our own. There's an officially supported tool called cordova-res that can handle generating the necessary icon assets from a base file, but I found it to not generate the best assets for Android (they were sized incorrectly); I ended up just using Android Studio's built-in asset generator for the Android app. The iOS icons turned out fine, however.

Altogether, after a week's worth of work and play, the "Capacitor spike" resulted in the ability to build uFincs as a native Android app, a native iOS app, and an Electron app for Windows, Mac, and Linux. AKA, everything that matters.

However, this was only the spike — the beginning. I don't think the native apps are yet ready to be published, but I'll elaborate on that in a bit.

First, I want to take a short minute to discuss the catches.

The Catches

So what are the catches? Surely there must be catches right?

Well, it depends on how pedantic and nitpicky you want to be.

As much as the app that Capacitor generates is indeed a 'native' app (from a binary/distribution point-of-view), it doesn't make use of the traditional native UI elements. So if you're an utter stickler for only using those widgets which have been blessed by the designers-that-be at Google and Apple, then you probably think this approach is pretty sacrilegious!

However, that's a mostly moot point as far as uFincs is concerned, because if I were to build it in React Native, I certainly wouldn't be going out of my way to re-re-design the UI to match each system's native elements. That, my friends, is too much.

Other than that, I suppose there might be some superficial performance penalties to choosing this hybrid approach. Not that there wouldn't also be any with React Native.

So... I don't know what the catches are yet. Personally, I think this Capacitor approach is just pure upside. I get to re-use the exact same code base, everyone gets the exact same uFincs experience, but I still get to distribute on the native app stores.

Plus, from a security standpoint, this approach still gives me the native app 'benefit' of not worrying about the Frontend server being compromised and immediately serving a version of the app that breaks all of the encryption features. Of course, if I really wanted to trash my company and entire career, I (or a malicious actor) could still push a compromised update through the app stores, but for those that want an "install once" experience, the Capacitor approach still affords that.

So, with only a week's worth of Capacitor experience under my belt (and not even a published app to my name), I can super confidently say that there are no catches.

The Next Steps

While uFincs has now been made 'technically' fully functional as a native app, as is true of all things, the 80/20 rule still applies. They're still a few wrinkles to iron out.

Small things like "how do you fetch the latest data?". With the web app, you can just refresh the page and all your latest data is pulled down. Well, you can't exactly "refresh the page" with a native app, so we'll need either a button to do it manually or a process that runs in the background (probably both).

Then there are things like setting up a new CI/CD pipeline. I mean, since the code is all the same, that also means that all the same tests should apply, but how exactly do we handle things like "continuous deployment" with mobile apps? I don't think we actually do, but it's the process of figuring out how we're going to handle deployment/distribution that is important.

Speaking of which, app stores. God, app stores. I have been dreading the moment I'd have to start dealing with them. It's one thing having a web app where I have complete and utter control over the entire deployment process, being able to deploy anything and everything at the push of a commit. It's quite another having to submit every update to entities that are known for being both much slower and much less reliable than my precious build pipeline.

In the best case, maybe the uFincs native apps will be available (as a beta) within the next month or two. Assuming I don't get arbitrarily rejected from the app stores for no reason. ¯\_(ツ)_/¯

Final Thoughts

Other than the native apps, I've been slowly getting through some other (much smaller) items from my backlog. Check out the uFincs changelog for all the details.

As I've mentioned in the past, I've also been planning another big marketing push. If I can get the native apps into beta, then that'll probably happen sometime around September/October. Also got some blog posts that I need to finish up for that. Hopefully, this push will be enough to pick up a couple more customers.

Can never have enough customers :)

Till next time.

Just wanted to let you know that, if you aren't (yet) a subscriber to the official uFincs blog, the post announcing the official release of Import Rules has been put up over there. 

That is all. Please continue on with your day.

Last Time

During uFincs Update #10, I gave a short update on the rules system just as development was really ramping up. Now that it's more or less fully functional, I'll be previewing it in preparation for launch (hopefully) sometime at the end of the month.

Import Rules System

If you want to jump straight into trying it out, you can use a 'staging' version of uFincs here: https://ufc-381.ufincs.com. If you have an account with uFincs, then you can log in using those same credentials. Don't worry; any changes you make here won't be reflected against your actual account's data.

The first thing you'll notice is that the "Import Transactions" option in the "Add" button menu no longer takes you directly to the import process. Now there's this sort of 'overview' page:

This overview page combines the new view for the import rules with the options for importing transactions. Currently (as was previously the case) we only support importing from CSV files, but this new design gives us a good place to put any future import options.

Let's take a closer look at the rules. Here's the new form for creating/updating a rule:

An import rule is quite simple: it consists of a set of conditions and a set of actions. If, during import, a rule's conditions match for a certain transaction, then the rule's actions will be applied to the transaction.

I've kept things quite simple for this initial implementation. A condition can match against a transaction's Account or Description property, using either a plain string or a regex. An action can set one or more of a transaction's Account, Description, or Type.

That's it.

However, even with this limited set of actions and conditions, I expect that this will still cover a large majority of use cases. After all, the import process is usually just a matter of cleaning up some transaction descriptions and categorizing them to the right account. These rules should help to drastically cut down on any repetitive importing or to help with importing a large number of transactions all at once.

Of course, if there are any other conditions or actions that you want supported, just let me know!

Once a rule has been created, here's what it looks like in the table:

Yeah, I'll admit, it's not the prettiest thing. But it gets the job done.

Finally, here's what the rules look like during the import process itself. First, you'll find a new section during the fourth step (Adjust Transactions):

And you can open it up to reveal a list of the currently active import rules:

These are all of the rules whose conditions matched up with any of the transactions that you're currently importing.

If you want to add any other rules, you can also do that here.

Finally, you can toggle the rules on or off, in case you need to reference the original values from your CSV file.

That's all I've got in terms of the preview. While the functional implementation is basically done at this point, I'm still in the weeds when it comes to testing. There's a lot of weird ways the rules system can be abused to create invalid transactions, so I'm definitely trying to cover as many of those corner cases as possible before releasing this out to everyone.

In the meanwhile, feel free to try it out and let me know what you think!

Till next time.

I'm not much of a hackathon guy. Partly because I see them as a waste of time, partly because I'm far too pessimistic to think that I'd be able to put together anything 'win-worthy' in such a short period of time.

But on March 16th, I came across this post on the GCP subreddit:

Official Google Cloud Code_Love_Hackathon | 10k Prizepool

Being someone who is fairly experienced in the ways of GCP (formerly Associate Cloud Engineer/Professional Cloud Architect certified), I figured this would be a fun break from the never-ending marathon that is building a startup (uFincs, by the way).

The hackathon overview outlined the details:

• 4 different project categories:

  1. "The Next Level of Love" = build an app that makes developer lives easier

  2. "The Next Level of Gaming" = build a game of some sort

  3. "Spreading the Love" = build a messaging app of some sort

  4. "Wildcard" = build whatever you want, duh

• Besides the per-category themes, you also had to make use of the new GKE "Autopilot" mode, along with the GCP Cloud Code IDE extension

• A prize pool of $10k USD distributed as $2k to each category winner, along with $2k in a bonus category for "Best use of GKE Autopilot"

• Lasts from March 29th to April 21st (basically a month, if you include pre-official start time)

First of all, this is the first month-long hackathon that I've ever seen. I mean, I guess it makes sense given the (virtual) times we live in, but still, I thought that was a pretty excessive timeline. 

Secondly, the requirements seemed rather easy. I'm decently experienced with GKE, so just making it easier by tacking on Autopilot meant that all I had to worry about was choosing a category to enter in.

For reference, GKE's new "Autopilot" mode just relieves you, the cluster operator, from having to worry about managing nodes. Instead of getting billed based on nodes, you get billed based on how much CPU/RAM each pod is allocated (except it costs a lot more, strictly comparing compute resources).

Just another layer of abstraction in the never-ending game of "The Cloud".

Finally, while $2k per category is a pretty nice chunk of change, it definitely wasn't enough to warrant building a fully custom project and certainly didn't warrant a month's worth of work.

As the start date of the hackathon approached, I brainstormed some ideas but ultimately decided that it wouldn't really be worth my time. The better ROI here was prepping uFincs for launch, so I decided to just continue on with my marathon instead. 

In the meantime, I registered for the hackathon and joined the related Slack team just to keep an eye on updates (and on the competition).

One Month Later

A month has passed. I had just finished up some big feature development work for uFincs along with dealing with some ops-related tasks that I had been putting off (check out the start of the DevOps Detour series if you're interested in that). I was well on track for launching uFincs in the next week.

It was purely coincidental that on April 21st, the final day of the hackathon, I checked into the Slack channel to see an update saying that it was the last day of the hackathon. It was around 7:00 PM at this time, and the hackathon finished at 3:00 AM my time. 

I made the fortunate decision to log in to the hackathon platform and check out what projects had been submitted. With only ~8 hours to go, surely most teams would have submitted by now (or not, depending on what kind of person you are). And you know what I saw?

A fully open category.

While 3 of the 4 categories had a smattering of submitted projects (no more than 3 or 4 each), the "Next Level of Gaming" category had zero entrants.

This was my opportunity.

If I could submit something, anything, to this category, then I'd be the winner! Obviously. It was just a small matter of submitting what...

Well, this is where the 'cheating' comes into play. See, the official rules for the hackathon didn't say that you couldn't re-use code from an existing project — all you needed was the IP rights to submit the project (heck, you didn't even have to submit any source code). 

Now, is re-using old (open-source) projects against the spirit of a hackathon? Probably.

But money.

So, digging into my portfolio of GitHub projects, I narrowed it down to two:

1. The Dank Meme Classifier

2. The Buzzword Bingo

Re-purposing the Dank Meme Classifier into a game of sorts was one of the ideas I had had when first brainstorming for the hackathon, but considering the time constraints, I didn't think it'd be wise to attempt anything of the sort. So I decided that The Buzzword Bingo would be perfect, considering it was already a game!

In fact, The Buzzword Bingo was also already containerized. So really, all I had to do was spin up a new GKE cluster, deploy it, and call it a day!

And at 7:00 PM, that's what I decided to do: I committed myself to getting this project back up and running and submitting all of the necessary components of the hackathon project (namely: some marketing fluff, a demo video, and some slides).

First things first was provisioning a new Autopilot cluster to deploy on. I decided to spin up a separate GCP project to keep everything contained (and so that I could easily tear it all down later). I used Kubails (my home-grown framework for developing GKE-native apps) to provision a new project and quickly deployed a new cluster using the generated Terraform configs — although I had to do some minor tweaks to get the Autopilot settings working since it conflicted with some existing node pool configs.

Within a couple minutes, my new cluster was up and running. I tried to deploy my usual stack of cert-manager and ingress-nginx, but ran into some more conflicts with Autopilot mode. If I remember correctly, one of the deployments tried to make some changes to kube-system, but that namespace seemed to be locked down in Autopilot clusters. I can understand why, but it did make my life a bit harder.

Well actually, it ended up making my life easier. By foregoing cert-manager and ingress-nginx, I was able to just deploy the two services that make up The Buzzword Bingo (a backend WebSocket server and a frontend React app) directly as deployments with individual load balancer services. It was gonna cost me more to run it (since using ingress-nginx would have meant only needing a single load balancer), but this was only going to be for a short time anyways. And with a $2k prize on the line, I figured I could afford it.

And you know what else I figured I could afford? A new domain name. See, I actually do have an always-available version of The Buzzword Bingo (for portfolio purposes), but I run it on GCP Cloud Run because it's basically free (haven't been charged for it yet and I hope you, dear readers, don't end up costing me anything :). But since the version running for the hackathon would be on a different IP, I figured a new domain name couldn't hurt. 

I finally decided on a minor re-branding: http://lovelybuzzwordbingo.com (now defunct). Why "Lovely"? Because the whole theme of the hackathon was "love", and if I was really gonna phone it in, I might as well make this the one on-theme change that I would make. Cause I certainly didn't have the time nor care to make any other changes.

With the domain name bought, the load balancers balancing, and the DNS records… resolving, by 8:00 PM, the Lovely Buzzword Bingo was now open for business!

That was the 'hard' part. Or 'less easy' part. I mean, I can deploy GKE apps in my sleep at this point (or at least, my Cloud Build pipelines can), so the only thing left to do was write up all the marketing fluff for "what the project is", "what problem it solves", "how it does it", yada yada. Having spent the last few months writing marketing copy for uFincs, that wasn't much of a problem (although my many years of bullshitting-through-school-projects certainly helped as well).

Of course, it was oh-so-much easier to write these kinds of things when you're not taking it seriously. I mean, the app in and of itself is pure "not taking it seriously", so at least we were on theme for that (for reference, I originally made The Buzzword Bingo as a joke… for a presentation… in an ethics course… in university).

The only minorly annoying part of the submission requirements was a 3-5 minute 'pitch' video showing off the project. Since we didn't even have to submit the source code, I assumed that this was basically all the judges were basing their decisions on. So I'd have to be utterly deliberate about thoroughly explaining every minute detail of the project.

Or something like that. I'll let you be the judge of just how terrible my pitch was:

No script, no edits, one take — just the way I like it.

In fact, I'll let you be the judge of my whole submission: everything I submitted can be found at the end of this post.

Ultimately, by 10:00 PM, I had my video recorded, my marketing fluffed, and my slides hastily thrown together. Clicked submit and called it a night, hoping that no one else would submit any more 'gaming' projects and that I'd be the de facto winner.

The Next Day

I woke up the next morning to have my worst fears realized: there were more gaming submissions. Not one. Not two. But three more submissions had shown up in the wee hours of the night. 

Ah crap. There go my chances.

Looking over the other submissions (which I won't include here because of 'legal' reasons), some of them definitely looked like they had work put into them. Like, one of them had a whole story for how they came up with the idea, beta tested it, implemented it, and further conducted user testing. I honestly thought that that project had it in the bag.

The worst part of all this is that the gaming category didn't even end up having the fewest submissions; one of the other categories only had two!

Sigh. At least I didn't waste much time putting the whole thing together. And it was certainly hilarious to imagine what the judges would think when they would inevitably have to gaze upon my monstrosity. But I definitely didn't have any hopes of winning at this point.

So I just kind of forgot about the whole hackathon after that. Judging would happen over the next week with the winners being announced on May 3rd as part of a Kubernetes conference. Maybe I'd remember to check the Slack sometime in the future to see how it went down.

Back to uFincs, I suppose.

(And back to uFincs I went, where I finally launched and gained my first paying customers. Check out that story here: uFincs Update #7)

May 3rd

Remember, I had completely forgotten about the hackathon at this point. I was just riding off the high of more-or-less successfully launching uFincs to the world.

So when I received the following email from one of the hackathon coordinators, you could say that I was surprised:

Hey Devin, 

Thank you all for participating in the {Code_Love_Hack}! 

On behalf of Google, I wanted to let you know that we appreciate all the time, effort and dedication that went into creating each amazing project. The judges had so much fun seeing all the apps and games you created!

Without further ado, here are the {Code_Love_Hack} winners:

Challenge #1 - The Next Level of Love
Team Member: [redacted]
Project: [redacted]

Challenge #2 - For the Love of Gaming
Team Member: Devin Sit
Project: Lovely Buzzword Bingo

Challenge #3 - Spreading the Love:
Team Member: [redacted]
Project: [redacted]

Challenge #4 - Wildcard AND For the Best Use of Google Kubernetes Engine Autopilot:
Team Member: [redacted]
Project: [redacted]

Congratulations to the challenge category winners and congratulations to all for creating such wonderful projects!! BeMyApp will be reaching out to the winning teams, as well as the winners of the survey participation drawing.

Hope to see you at a future hackathon! 

And here's the official follow-up post from the GCP blog.

So yeah, somehow, by the grace of all-that-be at Google, I won the gaming category. With 'only' 3 hours of work.

🎉🎉🎉

I can only assume this was possible because the judges were greatly amused by the idea of playing Buzzword Bingo at their next meeting. Or perhaps they just found the other entries to somehow be even worse. I don't know. I doubt they'd tell me even if I asked: the official rules prohibit them from revealing the scores they gave for each project.

In any case, I'd say $2k USD for 3* hours of work is probably the best ROI I'll ever make, at least for a very long time.

And that's how I won a month-long hackathon in 3 hours. By reusing old work, making a big joke out of it, and not taking it seriously at all.

My hackathon win rate is now 100%.

* Obviously it took me more than 3 hours to originally build The Buzzword Bingo, but that’s not exactly the point, is it Mr. Pedant?

Takeaways

So what can you, dear reader, learn from all of this? 

Whatever it is, I certainly don't suggest taking it to heart. 

Disclaimers

There is nothing to disclaim except that there are no disclaimers. I wasn't paid to write this post or promote GCP in any way — I just thought the whole affair was funny.

My Complete Submission

And here's everything that I submitted as part of the hackathon. May it guide all of your future hackathon'ing efforts.

Title

“Lovely Buzzword Bingo”

Short Description

“A game to synergize with your corporate friends at the next holistic team meeting.”

Banner Image

Logo

Video

"The Issue"

“You know, sometimes, when I'm listening to my boss, or my boss' boss, ramble on and on about 'innovation', 'best practices', and 'blockchain', I just want to tune out. I'm sure all of my teammates want to as well, since we're all in the same boat really. So I wanted to build something to both increase our team synergy while improving the alignment between boss and team.”

"Our Magic Solution"

“Lovely Buzzword Bingo (http://lovelybuzzwordbingo.com) is our magic solution. Here, we have something fun and simple that _all_ team members can enjoy: bingo, but with buzzwords. Now we all _have_ to pay attention to what the boss says, otherwise how are we going to get a bingo? Everyone can just pull it up on their laptop, or another monitor, and play along. Truly, team bonding at its finest.”

"How it Works"

1. Visit http://lovelybuzzwordbingo.com

“You'll be presented with a beautifully hand-crafted bingo board, with only the most holistic buzzwords included.”

2. Attend a Company Meeting

“Give the site to all your team mates as well. This is the point where you have to listen to your boss for once. You'll see, in the game, all the people who have connected.”

3. Win!

“Surely, if you were listening, then your boss will spout off enough buzzwords to easily get you a bingo. Congrats! You're a winner! Your random username will be displayed for all to see.”

Slides

https://docs.google.com/presentation/d/1YQanInRIghocVIcVaRSlk0CxId4DtEtVsMyiyQNHfZE/edit?usp=sharing

Anyways, if you haven't heard, I recently (hard) launched uFincs on Hacker News. So guess what? The matter ever so concerning my existence today is the fallout of that event.

Last Time

The last time we talked about launching and marketing was during uFincs Update #7, where I discussed the (good) fallout of initially launching uFincs, along with the unplanned Hacker News soft-launch.

It hasn't been long since I wrote that post, but now that we did our official "Show HN" post, I figured now's a good a time as any to reflect on where we are and think really, really hard about where we should be going. Basically, overthinking and overanalyzing all the many pieces of feedback I've received over the last month.

The Hacker News Hard Launch

For the unaware, I only refer to this event as a "hard" launch to differentiate it from the "soft" launch described in uFincs Update #7, wherein I posted a comment on a popular Show HN thread that drove a good bit of traffic.

In this case, however, our "hard" launch was putting up a Show HN post of our own — specifically, this post on May 11th:

Show HN: I built uFincs – a privacy-first, encrypted personal finance app

As you might recall, I stated that, based on the reception of the soft launch, I expected this launch to either take off like a rocket or never turn into anything at all. As in, I didn't expect a lukewarm reception.

Well, I got a mostly lukewarm reception. Just over 50 upvotes on the main post is no mean feat (seemingly above average), but it is definitely not a rocket-level takeoff.

If we look at traffic numbers for the day, you'll see that they aren't even all that much better than the soft launch:

A couple hundred more visitors and page views is certainly good, but not exactly great.

However, to get a better view, let's look at the 5 day period following (and including) each launch. First, here's the soft launch (from April 28th to May 2nd):

And here's the hard launch (from May 11th to May 15th):

Overall, we got roughly twice the visitors and page views for the hard launch. This would only seem reasonable considering the post would have had much larger visibility due to being on the front page of the Show HN section; we were in the top 5 for almost all of the first day and still within the top 10 throughout most of the second day. It's only once we fell down/off the Show HN page (on the third/fourth days) that traffic dropped off dramatically.

And if you're wondering, yes, the post did briefly make it to the front page of Hacker News, but only to #28 (i.e. the very bottom) for a very short period of time (less than 10 minutes). However, those 10 minutes on the front page easily represented several hundred visitors all on their own.

In terms of new customers... this launch has represented a gross gain of precisely 0 new customers (so far). I'll get into the overall conversion stats in the next section, but this certainly seems to be an indicator that either our lead times are just going to be longer than I might have hoped (in the best case) or it indicates that perhaps our traction was over-represented during the soft launch (in the worst case).

In any case, if we only look at traffic numbers, then I'd consider this launch to be a mild success. Not as good as it could have been, but as long as it gets uFincs in front of more people, then I guess anything's a success, right?

Conversion Rates and Overall Stats

Traffic stats are only one piece of the puzzle. Now let's narrow down the funnel and look at conversion rates. Specifically, sign-up and no-account login rates, as those are the two metrics that I consider the most important (and that I have the stats on).

As a refresher, "no-account login" just refers to being able to try out the app without an account. It's basically our equivalent of a free trial.

Let's start with overall sign-ups. To date, since we officially launched on LinkedIn on April 19th, we have had 29 people enter an email and password to create an account. Of those 29, 3 have become paying customers. So, 3/29 = 10.3% conversion rate when looking at sign-ups. However, at least two of those sign-ups used obviously fake emails, so discount those as you see fit.

Based on the first result from Google, this conversion rate seems to be fairly average. However, since our business model is a bit different from those cited in the article (no free trial, but a 'free' no-account tier), who knows if it's actually any good.

If we choose to benchmark ourselves against the "freemium" model, then it'd make more sense to look at the no-account login conversion rate, so let's do that. Since our initial launch, we've had ~1600 no-account logins. At a 3/1600 = 0.1875% conversion rate, this is obviously utterly terrible, no matter how you benchmark it.

And if we look at our total traffic of 3.7k visitors since launching, then that means we can get roughly half of our visitors to try out the app in no-account mode, but obviously our sign-up and conversion rates look much worse from that angle.

However, one thing to keep in mind is that it is very hard for us to correlate all of these interactions to create a complete funnel of website visitor → no-account login → sign up → paying customer. This is simply a matter of not having the data to do it because of all the privacy-preserving measures we put in place. So all we can really look at are the raw numbers.

Additionally, an observation that I've made is that, so far, every sign-up that has turned into a paying customer has come from someone who signed up and then immediately subscribed to a plan. I've yet to observe anyone sign up, hit the paywall, leave, and come back later. I'll definitely have to email these prospects sometime in the future to ask if they're still interested (and tell them that their account will be deleted otherwise), so who knows if these parties will ever convert. Although it does make me question if we would get better results by just following the industry standard of actually providing a free trial...

In any case, those are the overall stats that I'm looking at so far. Looking at them now, it definitely seems like we still have too little data to really base any hard decisions on (I mean, 3.7k total visitors certainly doesn't seem like a lot, absolutely or relatively speaking). As such, let's instead break down these stats to further compare the Hacker News launches.

Stats for the Hacker News Launches

Let's take a look at the raw stats for each launch, using the same 5 day periods that I used above for the traffic charts.

Soft launch:

• 1.2k visitors

• ~1000 no-account logins

  • 1000/1200 = 83.3% no-account rate

• 15 sign ups

  • 15/1200 = 1.25% sign up rate

• 2 paying customers

  • 2/15 = 13.3% conversion rate

Hard launch:

• 2.3k visitors

• ~500 no-account logins

  • 500/2300 = 21.7% no-account rate

• 13 sign ups

  • 13/2300 = 0.56% sign up rate

• 0 paying customers

  • Big old 0% conversion rate

Right off the bat, it's obvious that Hacker News accounts for the vast majority of our traffic, period. However, it is curious that our no-account login rate was so much better for the soft launch over the hard launch (damn near 4x better) — nearly everyone who visited the marketing site also decided to try out the app. And obviously the paying conversion rate is infinitely better, so there's that.

I can only assume this is because the traffic from the soft launch was just so much higher quality (i.e. was greatly more targeted) than the hard launch. Because we hijacked a thread/comment that was very specifically about what uFincs is about (and because the thread itself had extremely high visibility), people who would read through to my comment seemed to be more inclined to read about and try out uFincs.

This is juxtaposed by the hard launch, where our traffic just turns into "ye olde generic Show HN browser". Sure, there was twice as much of it, but it certainly seemed lower quality (by these numbers, about 1/4 as 'quality').

However, I think that my messaging/branding played a good bit into this as well. During the soft launch, I purposely positioned uFincs as a compromise between pure privacy (dedicated apps/self-hosting) and pure non-privacy (a web app with a very permissive privacy policy). However, during the hard launch, because we specifically branded uFincs as "privacy-first", this seemed to 'trigger' a certain subset of folks into arguing that uFincs wasn't good enough privacy-wise (which, as the developer, I'm obviously aware of, but that's apparently just not good enough). I will get into the ramifications of this conclusion in a later section.

In any case, the numbers can only lead me to believe that the soft launch was actually more successful than the hard launch. This makes sense since it's in line with the old startup saying of "go where your audience is". While uFincs might have an appeal to the broader hacker audience, it definitely has an appeal to the more targeted "privacy-minded personal finance" audience.

So those are the hard (quantitative) numbers. Now let's take at the more qualitative data — specifically, all of the feedback and requests we’ve had lobbed at us.

The Feedback

As part of 'launching' (i.e. making posts to various platforms), I've received numerous pieces of feedback and requests, both in the form of comments and from people reaching out afterwards (mostly through email, cause I'm certainly not on any social media — unless you count LinkedIn...). I want to summarize all of that feedback here to put into context the decisions I'll be making later.

Let's start things off on a positive note.

The Positive

If there's been one consistent refrain from all the feedback I've received, it's this:

The app design and execution are good/great/f*cking amazing.

Even those with constructive/not-positive feedback to give praised the execution of the app and the marketing site. Everyone seemed to love it.

This is good, cause I spent I significant amount of time trying to get the design just right. I eventually want to write up a post on how I (re)designed uFincs, but let's just say that I always find UI/UX design to be the most time-consuming part of building out a feature.

In a distant second place, a large number of people liked/appreciated the straight-shooter/humorous spin that I put on the messaging for the marketing site. They indicated that it resonated well with them and found that it was fitting given the market (i.e. personal finance).

Finally, a good number of people appreciated the philosophy that I'm shooting for (privacy-first, encryption, having a one-time lifetime plan, being able to use the app without an account, etc). In fact, a good chunk of the people who reached out directly were those who shared my philosophies and wanted to see about potential collaboration efforts.

Overall, I'd say this is all pretty good. As they say in the startup world, "it's not about the ideas, it's about the execution", so being universally praised on the execution certainly seems like, if nothing else, a good start. Although I still have to wonder if it's enough...

Anyways, on to the more negative things (which will be kept separate from the feature requests).

The Not-Positive

There weren't many truly 'negative' things that I received as far as feedback goes. Really, whenever someone had something to complain about, it was mostly just requesting some form of a feature. However, we'll get into "feature requests" as part of the next section.

So what do I consider negative? Well, mindless complaints about the pricing are pretty negative. And also to be expected. I'm not exactly running a charity here, so getting people who complain about the pricing for an app that "just" forces you to manually record all of your transactions is well within the realm of reason. These complaints can basically just be ignored. If anything, when people complain that the monthly plan is 2x the price of the annual plan, that just gives me the incentive to raise the price of the annual plan, not lower the monthly plan!

The second big 'negative' feedback that I consistently received was partially negative feedback and partially feature request: that we weren't privacy-first "enough". In that, if we wanted to 'dare' call ourselves "privacy-first", we needed to be X.

To some people, X was "be open-source". To others, X was "being self-hostable" or "having dedicated mobile or desktop apps". Basically, since we're a web app, we can't possibly be "privacy-first" since we can just push "funny JS" at any time to compromise the security of everything and that it's all security theatre.

Which, from the strictest technical POV, is true. I've documented this well as part of our Security Overview. However, if we're coming at this from the strictest technical POV, then we also have to consider that there's nothing inherently more secure about being self-hostable (or a desktop/mobile app) — I could just as easily compromise the distributed executables or push a compromised update/executable sometime in the future. So there's still trust there.

OK, you say, then it must also be open-source. Well then, I say, are you actually going to audit all of the code? Or all of the dependencies? Are you even capable of determining whether something is secure even if you could audit it? Unlikely. So you either trust that someone else has audited the code, or you just loop back to trusting that the code is 'inherently' secure (because I say it is). So there's still trust there.

So really, what these people are complaining about is less that we are not "privacy-first enough"; it's that we aren't a 100% trust-less solution (and — spoiler alert — nothing is). So the fact that we are a web app has — again, in the strictest sense — nothing to do with it. Sure, it makes it slightly easier for us to compromise things, but there's still trust involved one way or the other.

Of course, Hacker News (and the programming community at large) has a known bias for 'hating' on JavaScript and web apps in general, so complaints like this are to be expected (I didn't write up that Security doc without an audience in mind, after all). Whether or not they should be taken seriously is a different matter entirely.

Other than that, there wasn't much 'truly' negative feedback.

So now let's take at the 'mixed' feedback: aka all of the wonderful features that uFincs supposedly needs.

The Requests

While there was a good amount of positive feedback and a small amount of negative feedback, there were a lot of feature requests. A good chunk of it came in the form of features we're definitely not supporting (specifically, bank integrations), but I was surprised that no one asked for anything budgeting related.

However, there were certainly a non-zero number of people who stated things along the lines of "if only uFincs had X, I'd pay up immediately!" or "uFincs would be a hit if only it had Y!".

Mmhmm, right.

Before we get into the nitty-gritty of what features were actually requested, let me first address the chicken and the egg problem that I face as a developer/business owner: I want to prioritize the feature requests of customers who have already paid (i.e. I want to provide good customer support), but people don't want to pay until uFincs has all the features they want. So, how do I prioritize which features to work on? This is a question that we will dive deep into in a later section, but keep it in the back of your mind for now.

Desktop/Mobile Apps

By far, one of the most requested 'features' was to have a dedicated desktop and/or mobile app. The reasons for why, however, deferred a good bit.

Some people wanted a mobile app so that they could use uFincs on the go (but they already can with the mobile version of the web app? which is, by the way, also an offline-first PWA).

Some people wanted dedicated apps for the 'security' improvements (which, as we addressed above, are 'just' security theatre).

And others merely stated that it'd be "good" to have. Very helpful.

Thankfully, it doesn't take much to convince me that dedicated apps are a good idea — they're already on my roadmap for a reason!

Open Source and API

Next up on the 'most requested' list was making uFincs open-source. The most obvious reason was for greater transparency (we say we're encrypted but are we actually?), although there was certainly a good number of people who just wanted it open-source otherwise. Surely this wasn't just code for "I want it open-source so that it would be free", so I'll definitely assume otherwise.

Open sourcing is kind of a tricky balancing act when it comes to SaaS. It's basically making the bet that the goodwill generated by open sourcing will be enough to bring in new customers while still being greater than the support load that comes with maintaining an open-source product/community. And if there's one thing I've learned during all of my startup research, it's that free customers are the worst (primarily because they tend to be the most support sucking). However, the fact that we bill ourselves as "privacy-first" does change the equation just a tiny bit.

Something interesting that someone suggested as the reason that people want uFincs open-source is that they actually want some way to extend uFincs — aka, an API. Unfortunately, making a public API for uFincs is quite a bit more tricky because of all the encryption we do client-side. As such, we'd basically need to provide a programmable client of some sort rather than just a REST API (e.g. a sort of uFincs SDK, or perhaps a kind of self-hostable API proxy).

In either case, open-sourcing and building a public API of some sort are definitely things that I want to do (as a developer), it's just a matter of weighing them against their business benefits.

Multi-Currency Support

Currently, uFincs supports nothing but the glorious dollar sign $$$. As a Canadian, this makes nothing but perfect sense.

Obviously, there are other countries in this world. Multi-currency support is just kind of one of those "some time, in the future" features that I've kept putting off. Although, there are different ways this kind of support can be implemented, at its most basic level, we could just change which symbol is displayed next to monetary symbols. Easy enough.

But, as one person requested, there's also a need for being able to automatically convert between different currencies. This increases the complexity by a fairly large amount, due to now requiring the use of external APIs for dealing with the exchange rates, as well as a rather large overhaul of the accounting system (as it was definitely not designed with this in mind). But I can see why such a feature would be useful.

In any case, this was one of the most 'concrete' features requested.

Better Import System

Oh boy. This was a contentious topic (for a good reason).

As it turns out, there are a large number of people who don't enjoy entering each of their transactions by hand (shocking, I know). Even more shocking, there are people with a long history of transactions that they don't want to just ignore/throw away! Who'd have thought?! (certainly not me)

Well, that's why we built CSV importing to begin with, but apparently that's just not good enough for some people. For some people, who have thousands of transactions in a giant CSV file, the prospect of going through and manually categorizing each transaction to get it into uFincs is just too much. Hard to blame them. For these people, a sort of 'rules' system for automatically assigning accounts based on descriptions seems to be the most fitting solution.

But others, they don't have CSV files — they come from other programs like Ledger CLI or (gasp) GnuCash itself. They want to just import their stuff over immediately, without going through an intermediary.

And finally, the most dreaded group: the ones who want bank integrations. They don't want to deal with importing or manually entering things — no, they want it all done automatically. As I wrote in "Why Categorizing Upfront is More Effective", that whole flow runs completely opposite to the ideals of uFincs (aka my ideals). After all, when I envisioned uFincs, there were two things I said I'd never do: bank integrations and budgets.

However, from a business perspective, it's perhaps not prudent to ignore these needs (but maybe it's also not prudent to spread myself too thin).

In any case, while I still don't want to support dealing with things like Plaid, I do believe I have a potential solution to 'the bank problem': if/when we finally create a public API (of some sort), then people can just integrate with whatever they want. Plaid has a free tier, so the community could create their own Plaid integrations and everyone would be happy! (in theory)

But I think the main takeaway is that, as much as I want to push "recording manually is better", that's definitely a smaller market than those who want automation (which I expected; I had just hoped it wouldn't be too small).

The Biases

While all of these requests and feedback is good, it's also good to keep in mind the biases of who's providing the feedback (and who's not).

Obviously, the groups we've targeted thus far have been primarily of the developer/entrepreneur mindset. Being myself of those mindsets, I feel I can understand fairly well where people are coming from when they give positive/negative feedback.

What's worth noting is that I feel it can be misleading to work off of only given feedback. Just because someone left a comment somewhere doesn't mean that we should necessarily value it highly. What about all the people who didn't leave comments? Hard to work off anything from them, for obvious reasons, but the 1% rule of Internet culture is a thing for a reason.

Additionally, we also have to take into account the feedback of our existing customers... except we've gotten next to no feedback from them. This either indicates that they're happy with the current experience, or confident that, whatever might be 'wrong', I will be able to notice and fix it (alternatively, if they're privacy-minded, they just don't want to talk to me).

Finally, the way I worded my launch posts can certainly lead to biases in the feedback I received. Taking the Hacker News hard launch post as an example, because I made sure to link to a FAQ and specifically address things like pricing, there were next to no comments on the things that were addressed. Does that mean that everything is good? No, it just means that people were disincentivized from talking about the things I addressed in favour of talking about things I didn't address (case-in-point, self-hosting).

In retrospect, perhaps it was to my detriment to try and minimize repeated discussion about things I've already addressed (by providing the FAQ) since it gives me less qualitative data to work off of.

Analyzing the Feedback

We've already gone through a bit of the analysis w.r.t. the feedback and feature requests, but I want to go up a level. Think things through at a more aggregate level.

First, the most important thing to realize is that our feature requests can be broadly grouped into two categories: product-level and ecosystem-level.

Multi-currency support, a better import system, bank integration? Those are all product features. Open-source, desktop/mobile apps, an API? That's right, ecosystem features.

Totally coincidentally, these two categories also map fairly well to the two sides of the audience that we target: people who want a good-looking, full-featured app (aka the "modern GnuCash" side) and people who care about privacy. Our original goal was to build something that would target people who share traits from both audiences; that is, our 'niche' would be "privacy-first finance apps that use double-entry accounting".

Based on the data presented so far, however, it would appear that we are not adequately satisfying either audience. The 'features' group finds uFincs lacking in, well, features, and the 'privacy' group is much the same. This means that either our mythical 'blended' audience is too small or we just haven't gotten uFincs in front of enough people. At sub-10,000 people that even know about uFincs' existence, it could very well be the latter, but the former is always what keeps me up at night.

Something worth noting is the relative sizes of these audiences, at least from an intuitive POV. It is (quite) likely that the audience of people just looking for a good, solid personal finance app is much, much larger than the audience of people who particularly care about privacy in general. As such, one might even consider the former audience to be a so-called "mass market".

Some feedback that I've received (throughout the entire process of building uFincs) is that we should be targeting a more mass-market audience; some have even gone so far as to describe uFincs as being "too sophisticated", primarily taking issue with my dedication to the art of double-entry accounting.

However, my sheer stubbornness has caused me to continue building an app that, first and foremost, meets my own needs. It's just been that, as a startup, our greatest "leap of faith assumption" is that there others like me who want a similar app. While finding 3 such people within the first couple of weeks of launching seemed to indicate potential traction or product-market fit, perhaps it was much more of a fluke than I initially thought.

In any case, I would like to posit a couple of possible scenarios. The following is that "later section" that I kept mentioning above. These scenarios break our current leap-of-faith assumption: instead of trying to appease a mixed audience, what if we catered to only one or the other?

That is, what would happen if we went down the path of pleasing the hard-line privacy advocates? What would happen if tried pleasing only the 'features' crowd?

All of this is to try and determine our path forward from here.

Diving into Privacy-First

As we've established, we currently call ourselves "privacy-first", but some people think that that's too strong of a term to be using at this stage.

Well, what would need to happen to fully satisfy this group of people? What would we need to do to be 'truly' "privacy-first"?

I would think that the first thing would be having to open-source all of the code. The immediate side-effect of this is that the "non-negotiable" trait of "privacy-first" — being self-hostable — would then be quickly checked off. After all, with all the code comes all of our Docker configurations, and it's not like uFincs is a particularly difficult app to host.

Personally, I would assume that this would be sufficient for 80% of hard-liners. They could inspect the code (or not), they could run the code themselves, they could be 'reasonably' assured that no funny business is going on and be content using the product (assuming they weren't also partly a 'features' person, which, let's face it, everyone is).

That last 20% would likely still be too skeptical of running a web app (even if it was self-hosted!) and would demand a mobile and/or desktop app.

Hey, I never said these theoretical hard-liners were rational.

The Costs

Now, what are the costs of the above? Well, open-sourcing is — in the strictest sense — trivial to do. Self-hosting, if we didn't explicitly support it but merely allowed it through the ability to build your own Docker images, would also be trivial. Although if we did explicitly support self-hosting, then there's the matter of maintaining a public repository of the images as well as having to deal with customer support. Of course, open sourcing would also bring on an amount of 'customer' support (since community management doesn't exactly come free).

The desktop app would, technically, be easy to put together because we'd just be wrapping the app in Electron. But there are more costs to it than just 'building' it. Just like the Docker images, a desktop would app would still require dealing with distribution and updates. Also, there are the very real (monetary) costs of having to buy into the Mac/Windows ecosystems to handle just compiling the app for each environment (although this is more true for Mac than Windows).

Finally, the mobile app would be the most costly, both in terms of time and money. Money, again, because of buying into the Apple ecosystem, and time because of having to build the app itself.

While I could wrap the existing web app up with something like PWABuilder to make a 'native' app, you can only do that for Android. So, if we wanted an iOS app, the least costly approach would be to build it using React Native. Thankfully, I've made sure to build uFincs with the assumption that large parts of it would eventually be re-used in a React Native app, so a good portion of my work would be re-usable. But even just the work of rebuilding the UI is non-trivial, so I would expect a solid several months would be required to put together a proper mobile solution.

Tack on the usual support and distribution costs from everything else above, plus the fact that we now have to maintain a completely separate app (on two platforms!) and the costs are quite high.

The Benefits

Those are the high-level costs to diving into the privacy-first audience, assuming that audience only cared about privacy. But what about the benefits? What do we gain from pleasing this particular group of people?

...

...

Good will?

...

Realistically, from a monetary POV, I wouldn't expect to generate much of anything from this audience. How exactly do we generate money from these alternative software distribution models? Charge for prebuilt versions of the self-hostable images or desktop/mobile apps? Well, when there seems to be a large overlap between "cares about privacy" and "knows things about technology", this seems unlikely to be viable (people will just compile from source).

"What about asking for donations?", you say. To which I reply: we all know how poorly that works out in practice for the majority of software projects.

As such, none of these alternative models seem nearly as viable as SaaS, so the expected (direct) ROI is basically zilch. At best, the good will generated by these users would prompt other not-so-privacy-caring folks to opt for the convenience of the SaaS and pay for that instead.

You might say, "Wait a minute, you're discounting all of the 'free' dev work that you'd get from people wanting to contribute!", and you're right: I am discounting it. To zero.

Altogether, this is the ramification of trying to cater too hard to the privacy side of the equation: it just doesn't seem viable as a small startup. Especially a small startup with only a single person, that's bootstrapping, is in the personal finance sector, and deals in B2C SaaS. I mean, that's already a cocktail for things to go wrong; no need to throw the friggin lighter at it!

Obviously, other companies seem to be able to get away with this business model ('privacy-first', open-core, and SaaS) — take Plausible Analytics for example. But I think one key differentiator is that these companies tend to be B2B. Businesses want the support and convenience of just paying for a SaaS rather than the overhead of self-hosting, so it makes good business sense to just pay up (plus businesses tend to pay more in general).

I can't even think of any B2C companies pulling this off!

Thoughts

So yeah, doesn't seem like focusing solely on the privacy-first aspect is our way forward. Instead, maybe we should treat this is as a marketing/branding problem instead of a development one. It's much easier to slightly re-brand ourselves from "privacy-first" to the (apparently much less strict) "privacy-friendly" rather than catering to all the needs of this audience, so maybe we'll just do that.

This isn't to say that I don't want to (eventually) do all of the above. Remember, this discussion is more of a matter of determining our next immediate steps.

Let's now consider the opposing scenario of dealing only with the 'features' crowd.

Diving into Features

Let's say we ignored the privacy crowd for now. What would we do instead?

Obviously, build out features. Which features? Well, considering I've received 'commitments' on the order of "if uFincs had X, I'd pay" for both multi-currency support and a rules system for importing, I'd say those seem like pretty decent places to start.

Beyond that, bank integration seemed to be the #1 missing feature for the more mass-market developer, but since I'm adamant about not (directly) having it, I figure opening up API access would be a viable alternative. If we were to just expose the existing API as is, that would either mean shunting all of the encryption work off to the downstream developers, which would likely end very poorly, or just throwing out encryption altogether so that the API only deals with regular data. The later would certainly be the easiest (from a downstream developer's POV), but I don't think there's much sense in throwing out all of that work.

That means that 'exposing the API' would really come in the form of something like a Node client that can access our API while still preserving the privacy aspects of our encryption system.

Of course, not everyone wants to work in JavaScript/Node, but since I also don't want to support a client for every language under the sun, the better solution would be to have some sort of API proxy that is self-hostable separate from the app itself. That way, users could self-host an API server that handles the data encryption/decryption/key management while still being able to interact with uFincs via the ubiquitous interface that is REST. I think this combination of Node client + API proxy would be particularly potent.

Coincidentally, the Node client and API proxy would also be good targets for open-sourcing if only because they'd be much smaller to deal with. Plus it'd give me another (good) excuse to push forward open sourcing our custom e2e encryption Redux middleware since that's what currently encapsulates all of our encryption logic. So even the privacy folk win a bit here!

Speaking of winning...

The Costs

As opposed to the general 'ease' of just throwing all of the code up on GitHub and calling it a day, these features have a definite time cost to them.

For multi-currency support, eesh, I'd say that's easily a month-plus endeavour. Between all of the new UI work, having to re-architect a good portion of the system, and bringing in third-party APIs, that's a very significant feature to deal with.

For an import rules system, depending on how fancy I get with it, I can see that being a 2-4 week endeavour. That, again, is mostly a UI problem; the data structures and logic aren't anything special. But since I'm so slow and deliberate in making sure the UI/UX is good, that's what ends up taking the most time.

As for a basic Node client to replace API access, that's actually a lot harder to estimate, if only because it's more of an unknown than the other features. In theory, it's just "pass some data, encrypt it, send it off to our API" or "request some data, decrypt it, pass it to the developer", but I think there's going to be a good bit more work that goes into the API design than anything else. Thankfully, we can re-use most (if not all) of the encryption/decryption logic, so that won't be much of a problem. Just to design and build the API is likely a sub-month-long endeavour, but adding in all of the necessary testing and documentation that goes along with something of this class could definitely push it past a month.

If we wanted to be 'super' extra, we could write our own Plaid integration using the Node client, both as an example and both so that users get some immediate benefit out of it. Even better if we can combine this with our rules system to automatically classify transactions! I figure that wouldn't take more than a week or two.

The Benefits

Well, I guess we kind of already went over the benefits. If we built out everything, then I have at least a handful of people I can go to and say "look, your request has been built; you ready to pay now?". Obvious monetary benefit #1.

A good side effect of this is that these people would hopefully then be enthralled by the fact that I listened to and implemented their feedback, so maybe word-of-mouth then comes into play.

Besides these features directly benefiting those who requested them, they also broaden our market appeal. That means that subsequent marketing pushes should appeal to the larger "personal finance" audience in general. Of course, the downside to this is that we start becoming that much more similar to our competitors, weakening our niche. Although considering my concerns about our niche being too niche, maybe that's not a bad thing.

And like I said, there's no reason to throw out all of the privacy-related work we've done so far; it just means softening the messaging.

So Where do We Go From Here?

So after all that (over) analyzing, where the heck do we go from here?

Well, first we need to re-iterate what our goals are. Currently, the most pressing goal is to acquire customers, make money, and reach ramen profitability. If we fail to hit our yearly goal of 100 customers, then... bad things.

With that in mind, what are the actions we could take? I think it basically comes down to a series of classic "pivot or persist" decisions:

• Do we continue on with marketing, trying to acquire more customers? Or do we switch back to product development, to increase the chances of future marketing pushes being more effective?

• If we do switch back to development, what do we work on? Do we tackle feature requests or ecosystem requests?

Let's start with the first question.

Marketing or Development

As of the writing of this post, it has been almost exactly one month since we first launched. Between all of the blog writing, the launching, replying to people, and not doing much of any proper development work... I'm exhausted. I feel like just sinking my teeth into a large new feature just to change things up — even if, from a business POV, I'd probably be better served by continuing this marketing push.

However, I think we can compromise on this by instead just down-sizing our marketing efforts back to writing blog posts. There are a couple posts that I'm particularly keen on writing, so I think the best choice (at this very moment) is to switch back into development, work on something big and new, and fill out my downtime with some blog post writing. Of course, in the short term, making that minor branding switch from "privacy-first" to "privacy-friendly" should also be done.

Such are the tradeoffs you make when you are but one person: can't exactly do everything at once. And even if you tried, that's a speedrun to burnout.

Features or Ecosystem

Based on our analysis of the feedback, I think it's obvious that we should focus on more features right now. Particularly, more ways of letting users get their data into uFincs. The obvious starting point for this is the import rules system, followed by the Node client for enabling 'API' access. I think those two features will open up our audience options by quite a bit, while still not compromising on our core privacy values.

And maybe, just to appease the many other people of the world, we can throw in a preference for changing the dollar sign (but not yet implement full multi-currency support).

That should cost us somewhere in the neighbourhood of a couple months of work, after which we'll be able to either pivot back to marketing or maybe start pushing towards desktop/mobile apps.

Wrap Up

Given an endless number of requests, features, and possibilities, how can one possibly determine which option is the best at any point in time? Well, thus far, I've used the heuristic of "whatever I would want". But now that we've received real people requesting specific features, it would seem that changing that heuristic is in our best (business) interests.

So while our hard-launch on Hacker News might not have been the most successful (in the short term), I think, for being only a month in, we're doing OK. As they say in YC: "Talk to your users, write code".

I guess it's time to get back to writing code.

Till next time.

Last Time

The last part was all about cluster upgrades and improvements. And guess what? We got more of the same today!

Only this time, we're gonna tackle upgrading some in-cluster services that have been out-of-date for far too long. Get ready for some hot, steamy, debugging action!

Upgrading cert-manager

Oh cert-manager, how I loathe thee.

Or at least, I did before realizing how easy the upgrade would be.

See, just like everything else in the cluster up to this point, it was kind of a "set it and forget it" affair. Couple of years back, cert-manager was still fairly new on the block. But since it was replacing a similar but deprecated project (kube-lego, I believe), I figured I just had to bet that it would be 'the' solution for.. cert management in Kubernetes.

Thank god I was right, cause I really did not want to deal with setting up automated TLS certs more than I had to.

In the beginning, most of the pain of cert-manager came from its infuriatingly vague error/log messages. This, combined with having to wait X hours for DNS changes to 'propagate', made debugging and getting the first set of TLS certs issued a royal pain in the ass.

And then there was that time that cert-manager had to be upgraded because of a bug that was causing it to ping Let's Encrypt too often...

And then there was the time they introduced the webhook service and it broke cert-manager in GKE unless you opened a very specific port to the control plane...

And then there was that time where deleting the cert-manager namespace would just never finish and be stuck in limbo...

Yeah, it wasn't fun in the early days.

Eventually, things (mostly) stabilized when it hit v0.12. There was still the odd hiccup where cert-manager would just fail to renew a cert (one time it was because the GCP service account expired... another time it was seemingly because of a cosmic bit flip...), but it (mostly) worked.

So when I read the news that they had finally released a v1.0 last year, I have dreaded going through with the upgrade process ever since.

Well, with all these other upgrades and improvements I was making, I figured I might as well bite the bullet and upgrade to (what I could only hope) is an actual stable version of cert-manager.

…

My god. It went splendidly. Damn near perfectly, really (and for those who know me, no, that was not sarcasm).

First of all, cert-manager has excellently documented all of the upgrade steps needed to move between versions. For example, here are the instructions for v0.12 to v0.13. Rather empty, which is a good thing!

In fact, moving all the way from v0.12 to the latest v1.3 (a jump that included 8 separate releases!), there was only one upgrade step I needed to do: from v0.13 to v0.14, you just needed to delete the deployments before applying the new ones.

So I literally just deleted the cert-manager deployments and applied the latest v1.3 manifests.

Worked without any other changes.

Honestly, I was flabbergasted. I literally set aside like 6 hours to do the upgrade (expecting everything to go wrong), but nothing did. Certs still worked, got renewed, no errors. Just, magic.

So... huge props to cert-manager for finally getting things sorted out!

Well, except for one thing...

CA Injector Errors

cert-manager runs three different deployments by default: the main cert-manager process that handles issuing and renewing certs, the webhook process that ensures the manifests we deploy are configured correctly, and the cainjector process that... presumably handles injecting a.. CA.

It doesn't really matter what the cainjector was doing, the point is that it was throwing a whole heck of a lot of errors. Like, hundreds of errors an hour.

Specifically, errors with the message "unable to fetch certificate that owns the secret", "Certificate.cert-manager.io \"[redacted]\" not found" (GitHub issue over here).

Basically, what seemed to be happening is that the CA injector would try to.. inject the CA into secrets that it couldn't find the corresponding Certificate resource for. Now, why wouldn't it be able to find the Certificate? Well, I'm not quite sure, but I have a good hunch...

See, as totally awesome as cert-manager is, it had (and still has!) this weird idiosyncrasy: when it issues a cert, it does so in a Kubernetes Secret resource. In order to make use of this cert, we need to give it to our Ingress resources so that ingress-nginx knows which cert to use for TLS.

However, because of our per-branch deployment scheme, our Ingress resources are spread across many different namespaces. But the cert Secret is only in the cert-manager namespace... and the Ingress can only read cert secrets from its own namespace...

So how can we use the cert? Well, based on my understanding at the time (which seems to still hold today), you're supposed to just copy the secret between namespaces.

A little brute force, but hey it works. Especially when you throw in the ingress-cert-reflector to handle automatically copying the secret to every namespace.

This worked fine for quite a while. Until I finally decided to check the logs and noticed the cainjector complaining about every secret in every namespace it wasn't in. Presumably because there was no corresponding Certificate resource in each namespace that the secret was copied to.

But of course, since my HTTPS was working just fine, I didn't really care all that much, so I just let it be.

But when I finally upgraded cert-manager and found that the cainjector was still throwing these errors, I figured I might as well try and fix it properly.

And that's when I finally learned that ingress-nginx has a --default-ssl-certificate option.

I have no idea if this option existed back when I first set everything up, but if it did, I regret not stumbling onto it sooner.

As the name suggests, it allows you to specify a default SSL cert by pointing at a secret in any namespace. WOW. How crazy is that!?!

So bam, just like that, I no longer need the ingress-cert-reflector to copy my cert secrets around. Just specify a default and we're all good.

There's just one problem... you know how everything up till now has been "one thing to leads to another"? Well, this also led to another thing.

I figured, heck, while I'm over here re-configuring ingress-nginx and upgrading cert-manager, why don't I also upgrade ingress-nginx?!?

Upgrading ingress-nginx

You remember those 6 hours I had allocated for the cert-manager upgrade? This is where they went.

At the time, I was running ingress-nginx v0.17.1…

The latest version was v0.45.0. Only, like, a couple dozen versions to jump up. No biggy right? If cert-manager went smoothly, surely so would ingress-nginx?

Nope, no it would not. I mean, it could have been worse (what can't be?), but this upgrade wasn't fun.

First of all, the upgrade docs were much worse than cert-manager's:

To upgrade your ingress-nginx installation, it should be enough to change the version of the image in the controller Deployment.

"Should be enough", yeah right!

First of all, at some point in the past, ingress-nginx changed where they hosted their Docker images from Quay to GCR. So... I literally can't just change the version because I'm on an old enough version that I used the Quay image, and they don't publish the latest images to Quay anymore! Strike #1.

Secondly, since I use the static manifests, I can just check that there are fairly significant changes between my (old) version's and the latest's. So... changing 'just' the image, not quite. Strike #2.

Then again, it's hard to blame them for not having upgrade docs for such an old version. It's more commendable that cert-manager does.

Anyways, I figured the easiest way to upgrade is to just grab the latest manifests and YOLO it. Obviously, I ported over whatever config changes I had made, but other than that, I literally just YOLO'd it.

And.... it worked! Or at least, it seemed to work. Containers weren't throwing any errors. Site was coming up just fine.

Except then I tested this one thing... I navigated directly to app.ufincs.com (the subdomain for the app itself, vs ufincs.com which is for the marketing site) and instead of being redirected to the login page, I found something strange: I was presented with the home page of ufincs.com instead.

Uh oh.

Then I tried navigating to the login page via the Login link on this strange home page. Worked.

But then I tried navigating directly to the login page via ufincs.com/login: infinite request loop.

Oh shit.

First thing I did was roll back the ingress-nginx upgrade to make sure this wasn't somehow already how it worked. It shouldn't have been, but since the marketing site does use redirects to get the user to the app, I figured it's possible that I had somehow broken it earlier.

But it was fine with the old ingress-nginx. So it's definitely the new version's fault.

But what could it be? What could have changed between versions of Nginx to cause this strange behaviour?

My first thought? Caching.

See, we make use of Nginx to cache the static assets that are served from the Express servers of the marketing/app services. Nginx is way faster at serving that content than forcing the Express servers to do it all (and I didn't want to bother setting up a proper CDN).

So somehow, the root route for the marketing site was being cached and served for the app service. And then... something was being cached incorrectly to cause the infinite login request loop.

After some curl debugging to check the cache hit/miss status of various pages, flushing the Nginx cache, trying to inspect the Nginx cache, and finally just setting up separate caches for the marketing and app services, I deduced that it was indeed a caching issue. The only question was why.

My assumption was that, somehow, the key used to index cached requests had changed between Nginx versions. Digging into the proxy_cache settings, I found the default value for the proxy_cache_key:

$scheme$proxy_host$request_uri

Well, the $scheme should be the same between requests; it's just HTTPS. The $request_uri would also be the same since it's just the root route /.

So, by logical deduction, $proxy_host had to have changed to somehow be the same and cause root requests to different services to overlap.

Well, according to this, $proxy_host is defined as the "name and port of a proxied server as specified in the proxy_pass directive".

And how is proxy_pass defined? Well, the only way to find that would be to check the Ingress' generated nginx.conf. A quick kubectl exec -it <nginx pod> -- cat /etc/nginx/nginx.conf later and we look what we've got here! I'm not going to post the whole config (cause it's huge), but guess what? Every instance of proxy_pass is the same!

They're all defined as:

proxy_pass http://upstream_balancer;

Well, what the heck is upstream_balancer? Searching through the rest of the config file, we find this:

upstream upstream_balancer {
    ### Attention!!!
    #
    # We no longer create "upstream" section for every backend.
    # Backends are handled dynamically using Lua. If you would like to debug
    # and see what backends ingress-nginx has in its memory you can
    # install our kubectl plugin https://kubernetes.github.io/ingress-nginx/kubectl-plugin.
    # Once you have the plugin you can use "kubectl ingress-nginx backends" command to
    # inspect current backends.
    #
    ###
    
    server 0.0.0.1; # placeholder
    
    balancer_by_lua_block {
        balancer.balance()
    }
    
    keepalive 320;
    
    keepalive_timeout  60s;
    keepalive_requests 10000;  
}

Because all of the proxy_pass values are the same, the $proxy_host value is the same for all requests. Which makes our cache keys overlap at only the route level, rather than the host + route level.

Looks like we found our culprit!

But now, how do we fix it? Presumably, we need to replace $proxy_host with something else, since the $scheme and $request_uri should be fine.

Thankfully, the proxy_cache_key directive lists the following as an example:

proxy_cache_key "$host$request_uri $cookie_user";

This would be for adding cookies to the cache key. But what's more important is the use of the $host variable. According to the docs, it should take the hostname from the request itself. Which should suit our needs just fine!

And yep, changing the proxy_cache_key to:

proxy_cache_key "$scheme$host$request_uri";

Seems to fix the issues. No more infinite request loops, no more wrong home pages. Success!

And that's how my 6-hour cert-manager upgrade turned into a 6-hour ingress-nginx upgrade.

What, did you think this was the last of the DevOps detour? Oh no, we've still got a lot more to go. From Docker image caching problems to improving our monitoring suite, there's probably another 2 or 3 parts to go.

Now whether or not I get the ambition to write them all is a different matter... So, stay tuned for potentially more rounds of the DevOps Detour!

In particular, have you heard that uFincs has officially launched? Yeah, let's talk about that.

Last Time

If you remember all the way back in uFincs Update #4 at the end of March, I was talking about all my wonderful launch plans and how I was gonna take the month of April to really focus on marketing and launching.

Well, it's now May, so it seems like now's the best time to reflect on how that went.

Procrastination

As much as I had wanted to set aside the whole month for marketing/launch efforts, that's not exactly how it played out. As evidenced by uFincs Update #5 and uFincs Update #6, I took a couple weeks detour to deal with some DevOps-related tasks that I had been putting off (upgrading the GKE cluster, setting up monitoring, that kind of thing).

This ended up claiming the first week of April.

Setting up an Official Blog

The second week of April I had a realization that I should really set up an official blog for uFincs. Partly so that I could have one place that would have the canonical 'launch' post that I could then link to elsewhere, and partly to have a medium for capturing emails/sign-ups for anyone that didn't want to immediately sign up for uFincs itself.

And so, blog.ufincs.com was born.

I decided to just host it on Substack because, well, it's damn simple. Plus it's where I host my personal blog (i.e. what you're currently reading) so it made sense from a consolidation POV as well.

Although, I did run into a snag when trying to set up the custom domain for the blog. Bought the $50 custom domain add-on from Substack, set up the specified DNS records, and... nothing.

All I got was a generic error when trying to finish the setup process:

As you can imagine, not particularly helpful.

Thankfully, Substack's support was helpful. After one support reply that effectively amounted to "Have you tried turning it off and on again?" (yes, thank you), it was quickly escalated to an engineer who "made a fix on the Cloudflare end". Couple hours' turnaround; pretty good Substack!

After that, it was just a matter of stretching my marketing copy muscles to pump out the announcement post.

In retrospect, the official blog didn't end up making much of an impact. Didn't get any new newsletter subscribers (which, considering it's a blog specifically for content marketing, I'm not surprised), and the announcement post got less than 50 views. Although, I believe that has more to do with me not using the announcement post as effectively as I could, in addition to the Blog link on the marketing site not being particularly well-positioned as a CTA. Will have to improve that in the future.

Anyways, at least I can feel good about having an 'official' blog (as opposed to this blog, which is utterly unofficial, even though it's the more interesting one :).

Besides setting up the official blog, that second week of April was spent writing the posts for my various launch targets: LinkedIn, Startup School, and Indie Hackers. Let's go through each of those launches, one by one.

LinkedIn Launch

LinkedIn was the first place I launched uFincs. This made the most sense to me for mostly one reason: so that I could finally fill the hole in my 'employment' history. Yes, it has bugged me that, because I didn't have uFincs officially on my resume, there was a 1+ year gap since I graduated into a global pandemic. Superficial, I know.

This also gave me the wonderful opportunity to set up an official company page!

As you might guess, I do like my 'official' things.

Anyways, on Monday, April 19th, I did three things: put up a post on the company page, put up a post from my personal account, and finally updated my employment history. Besides having a fairly small network (only ~50 people), I wasn't really expecting much considering it's, ya know, LinkedIn. Who's actively checking LinkedIn, of all places, for exciting news?!

Exactly.

Although, I was banking on one thing: the fact that this was my first post. I've seen LinkedIn app notifications come in explicitly for people who made their first post, so I was thinking that I might be able to take advantage of that system for the uFincs launch. Did it work? No idea; didn't ask anyone.

I was also expecting a notification to go out for my employment update, but again, no idea on that front.

In the end, thanks to a core few people liking and commenting on the post, I was able to get just over 600 'views' on it. Pretty good for a network of only 50!

Not only that, but I got first my (paying!) customer as a direct result of the personal post. They ended up being a 2nd level connection, before upgrading to 1st level when they inquired about uFincs (and subsequently bought a subscription).

Hey, considering my expectations were basically nil, I'd say getting my first customer through LinkedIn is pretty good!

As far as the official company post went, it got basically zero traction. Again, not surprising. Probably should have picked some more niche hashtags to slap on it, but I'm a noob to social media in general, so yeah...

Anyways, I'd call the LinkedIn launch a success!

The Startup School launch, though, is a different story...

Startup School Launch

So, why did I decide on Startup School (SUS) as my second launch point? Well, I'd been through the SUS curriculum, became "SUS Certified", and generally knew it as a positive place to launch, so it just made sense to me. Of course, I also knew that the audience wasn't particularly large, so I wasn't expecting much in the way of a response.

On Wednesday, April 21st (two days after the LinkedIn launch), I made this post to the "Show SUS" section of the Startup School forums.

And... crickets.

No upvotes. No comments. Nada.

About what I expected. It seems to be very 50/50 in terms of Show SUS posts over there.

However, it wasn't until several days later (on Monday, April 26th — coincidentally, the same day that I got my first customer from LinkedIn) that I received this comment:

This - is - f***ing - amazing.

I have no idea if the idea is any good because it's not really my area at all (I guess you'll find out!) but the execution on this is incredible.

Come join our company if this doesn't take off. The pay is sh*t and the hours are worse - but real recognizes real my friend.

Very nicely done.

Needless to say, I was having a very good day that day. It was definitely nice to finally have some external validation for all the elbow grease I'd put into uFincs. Especially validation that was so... strongly worded :)

Other than that, I got less than 10 pageviews from SUS, so I wouldn't exactly call this launch a success. But it was good to get out of the way.

Up next, Indie Hackers.

Indie Hackers

Indie Hackers is an... interesting forum. If I had to summarize it as — effectively — an outsider, it'd be "the place to self-promote to others trying to self-promote".

Cause really, most everyone posting there has a higher goal than just "posting for the fun of it". Obviously, myself included!

So, time to get in on this 'self-promotion' action. First things first, got to set up another 'official' product page! Surely no one will take you seriously without a product page.

Well, as it would turn out, no one was gonna take me seriously, period. At least, as long as we define "take seriously" as "visit my web page in large quantities".

After creating the product page, I figured I had to do some research about which group to put my launch post in. And there's a lot of groups on Indie Hackers.

Having come from Startup School (and more generally, Hacker News), I looked (and found) a "Show IH" group, so I figured that was the place to launch things on Indie Hackers... Until I realized that it was listed under the "Inactive Groups" section. And perusing the posts in the group definitely reinforced that feeling.

Yeah, that didn't seem like a good idea.

It was at this point that I figured that Indie Hackers was less about directly launching products and more about writing vaguely relevant posts that somehow feed back to your product. I mean, meta time, this post is no different. So, figuring that the actual launch post wasn't gonna matter much either way, I decided that the Landing Page Feedback group is where I'd launch.

Side note: It's only as I'm literally writing this that I realized there is a Product Launch group. So... :facepalm: on me for that. In my defence, it was more towards the bottom of the "Fastest Growing" section and, as I said, there's a lot of groups. Goes to show just how much of an outsider I am.

Anyways, on Friday, April 23rd (two days since the SUS launch, four since the LinkedIn launch) I threw up this sad excuse for a post in the Landing Page Feedback group.

And just like SUS, crickets. To this day, I still haven't gotten any response on it and only about 5 page views for ufincs.com came from Indie Hackers. Figured as much.

Like I always say, as long you set your expectations to zero, you can never be disappointed!

Launch Thoughts (So Far)

And speaking of zero expectations, that wraps up the first three launches for uFincs. I went in expecting nothing and came out with a paying customer and a strongly worded compliment.

I'll take that!

However, this isn't actually the end of the story. I would be hit with a surprise one morning only a couple of days later...

Hacker News Soft-Launch

On Wednesday, April 28th, two days after acquiring my first customer, I woke up in the morning and found this post near the top of Hacker News:

Show HN: I made a simulator for personal finance

Oh boy. Anytime something about personal finances shows up on Hacker News, it usually does pretty well. This particular post would end up getting nearly 500 upvotes, which is really good for a "Show HN".

I figured that, even though I hadn't officially launched uFincs on Hacker News, it would still be a good idea (from a marketing POV) to self-promote uFincs in this kind of thread. It was already on topic, so I just needed the catalyst...

And yep, there it is. What was, at the time, the top comment in the thread:

Looks interesting, but based on the privacy policy terms of data usage, transferability, and so forth, I can't in good faith test with real financial data...

So now, not only did I have a relevant thread (personal finances), but I had a relevant top comment about data privacy. This was the perfect storm of opportunity. I couldn't pass this up.

And you bet I took it.

For context, I have a private Slack channel hooked up to the Backend of uFincs so that I can receive notifications for when various things occur. Namely, when people sign up, subscribe to a plan, or enter what I'll refer to as 'no-account' mode.

Within 10 seconds of posting my comment, I was already getting Slack notifications.

Within a minute, the channel had already filled the screen with messages from users entering 'no-account' mode.

Within a couple minutes, I had to mute the channel to save myself from going insane.

In fact, you know how Slack inserts timestamps every now and then to group together blocks of messages?

It took more than 4 hours before things slowed down enough for Slack to put a new timestamp:

...

My whole day was just sitting at my computer, watching the charts on my monitoring dashboard, watching the web traffic from Simple Analytics, and responding to comments/questions.

It. Was. Wild.

Received basically nothing but positive feedback. Tons of people checked out the app and marketing site. Even had a couple people reach out personally to say that they had been working on similar ideas and wanted to see about potential collaboration opportunities!

Honestly, I'm just glad nothing fell apart. It's good to know that my infrastructure could handle this kind of load without breaking a sweat. I mean, absolutely speaking, it wasn't that many views; only a couple thousand page views and around 1k unique visitors. But it was wayyy more than anything the system had seen before.

For context, here's how Nginx (our internal load balancer) fared. First, CPU usage (where 1000ms/s = 100% load, I believe):

And now requests/second:

Obviously, that spike around 12:00 PM is right around when I posted my first comment.

In fact, during all this, not only did uFincs stay up and running, but Hacker News itself went down!

Man, didn't think I'd be reverse-hug-of-death'ing Hacker News that day! /s

On top of all that, I even pushed a production deploy to fix a little something in the Backend, while everything was going on. Yes, I'm that crazy.

Finally, here's the marketing site analytics (again, courtesy of Simple Analytics) to really bring it home:

That first noticeable drop at 1:00 PM is, as far as I remember, when the top comment I replied to no longer became the top comment. And then everything just kept falling as the thread itself fell down the front page of Hacker News.

But still, I'd consider this a wild success. In my opinion, this soft-launch completely validates my thoughts that uFincs is indeed solving a hole in the market. Everyone who's given me feedback has only had positive things to say, whether it be the execution/design of the app itself or the idea as a whole. Of course, there were those that complained about the pricing, but that's to be expected (I'd be more surprised if they didn't complain).

And it's all that much sweeter once you take into account that I got my second paying customer late into the night that day. The cherry on top, as they say.

Obviously, my traffic levels have since fallen far off that peak. But I'm still averaging ~50 page views a day on the marketing site and maybe a dozen or so 'no-account' logins. Which is a significant improvement over the big fat ZERO from before. This also means that word-of-mouth is now at play — the most elusive of marketing strategies.

All this, from only a one-off comment! Albeit, a one-off comment in a thread where the involved parties were likely to be solid leads. But still, I wonder just how much crazier a Show HN of my own will be. Honestly, at this point, I can only see two outcomes:

1. It sees absolutely zero traction whatsoever (because I didn't pray to the right Hacker News gods that day).

2. It utterly explodes.

Considering the traction of the post that I hijacked, I think it's fair to say that 2. is a likely outcome. I wouldn't expect my post to be only 'mildly well received', but who knows — it's the internet after all.

Of course, there's only one way to find out. I'm sure my own Show HN post will be happening sometime in the near future, so keep an eye out for it!

Final Thoughts

So yeah, of my original launch targets (LinkedIn, Startup School, and Indie Hackers) only LinkedIn really panned out. And I knew that uFincs would do well on Hacker News, I just hadn't planned to get there so soon.

So what's next? Well, I think a Show HN post of my own will be my next launch target. Like I said above, that should probably happen in the next week or two. Hopefully that drives enough traffic/word-of-mouth to get to my elusive "10 paying customers" goal. It's at that point where everything basically starts turning to gravy.

Of course, I need to keep up the blogging/content marketing. SEO is, based on my research, a long-term game, so I just gotta keep pumping out these posts in the hope that it pays off in the future (well, more so for the official uFincs Blog than my own personal blog; although I like to think that my personal blog can make for some good forum posts :).

Other than Hacker News, I still have various subreddits and Product Hunt on my radar. I'll probably be doing a couple subreddit launches over the course of May, but Product Hunt will definitely be deferred for a later month. I want to have a decent customer base before I launch there, to show some level of 'maturity' (and by 'decent', I'm really just thinking > 10).

But yeah, very exciting times. I've finally gone from burning money with no income whatsoever to burning money while making a small bit of income! Surely, one of the hardest steps for any entrepreneur to take. It's only up from here!

Till next time.