uFincs Update #9

Reflections on Launching, One Month In

Sigh... this is a long post. Longest post by a long shot. Enjoy at your own peril.

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.