These apps look gimmicky but they are growing like crazy. CalAI, for example, is making 35M+/yr. I’m hoping that some people really find value in these apps and that they are not just a pure marketing driven play.
I've heard from someone who knows that they're scamming people like crazy. Supposedly they also setup a bunch of LLCs to hire influencers then never paid them.
There is good money in the App Store once you crack social marketing. The founder shows several videos of reloading the App Store Connect page showing revenue numbers. It's not unbelievable.
I don’t mind if the reality of their business is similar to gyms in the sense that they make money off of peoples desires but have low utilization.
I used calorie counter apps before and they helped me lose weight (by mostly educating me what to eat/avoid). With these apps, I feel like the core premise - counting calories - isn’t even working and they’re selling people hopes and dreams. That’s danger territory.
That’s exactly what I was thinking when I read the article. ”Why are you thinking this is meant to work?”. But of course, normal trusting people will believe it if it’s on the ”trusted app stores”.
These apps with graphs are just selling you a sense of control, of compulsive metric driven decision making. Its partly the consumers’ own fault – many people won’t care even if they knew. But it’s also predatory by the companies. It’s consumer tech in a nutshell: put a pretty but shitty app on the App Store, spend 80% on marketing, show ads in the free tier, sell overpriced premium offerings to those who are careless with money, rinse and repeat. I follow some subreddits and groups for ”entrepreneurs” and it’s just like this.
I suspect this might be because diet marketing before AI was one of the most fraught with misinformation subjects you could run across. This is because the "sale" of the idea has an effect on every salesman, so all of the salesmen are trying to sell every thing at once,since that's also selling their thing, and ground truth gets stampeded. Now when you combine diet marketing and AI, you get a multiplier. Both in the sellers and the buyers, since the desire to believe is stacked.
This makes me sad. Yes a fool and their money are soon parted but this drives user expectations for apps even lower, pushing competent apps out of the market because of the price difference.
This is cool. I’ve been working on a similar product but with Changelog focus (productsync.io). Happy to chat if interested, you can reach me from murat at productsync.
I suspect the frequency of people asking this type of query is low enough that mainstream apps will likely never implement such a feature.
However, it would be interesting to see if you can solve this kind of problem using GPT or replit. I expect AI to cover all such longtail use cases by quickly whipping up not-so-perfect but gets-the-job-done apps/code.
Unrelated to the OP product but I’m curious how people are solving this issue on smaller scale with nextjs + prisma/drizzle. Do you just run the builtin migrate script with npm run?
We use a CI job that runs drizzle migrate whenever the schema files change. Drizzle doesn’t have rollbacks though. Replacing this process with pgroll as a sort of drop-in replacement would be nice. Then orchestrate everything with a couple of CI jobs, and done!
Auto-complete on steroids sounds like the correct assessment.
Aider & Cursor is worth the try if you're interested in trying out multi-file edits. I think both are interesting (ergonomics-wise) but the current SOTA models do not perform well.
For single file edits or chat, I would recommend Cody (generous free tier) or some self-hosted alternative.
If you're looking for a technical job, the easier path would be to find a PM/Designer job at one of your target companies and try switching to a dev role within the company. When you apply as a junior developer, your previous work experience will not be considered relevant. You'll be competing with other junior developers (who also likely don't have any relevant work experience) and it's much harder to differentiate yourself. Whereas if you want to switch roles inside a company, people who are familiar with your skills are likely to take a bet on you (if you have a good track record).
On the other hand, the masters program will introduce you to a new network of people, and working towards a goal with a cohort is much more motivating than learning by yourself.
I agree with your suggestion with one caveat: having a Master's degree when switching to a dev role would be very beneficial. Both in terms of how it looks on paper and in terms of competency.
The hard part is not going open-source today but remaining open-source as your product evolves. When using a split model like this, inevitably the open-source version serves SMBs and the paid version serves Enterprises. Given enough time, you end up having two different versions of the product for two different customer segments and logically axe the version that doesn't make you money anymore.
It's likely not even going to be a conscious or intentional choice. At some point your enterprise customers are going to have enough bugs and feature requests to keep you busy full time, and your open source project might languish unless you make a conscious effort to dedicate a percentage of your time on it.
Ironically as some companies have already started noticing, when you stop being able to market your product as open source the start of the funnel will start to dry up. The start of the funnel is often not monitored, and the sales might even continue going up as your successful open source users go to enterprise. By the time you realise the funnel has dried up it might already be too late to turn back as competitors have filled the void you left.
In my opinion, this just means you've done a poor job on the architecture side of things. If you need a paid version that has extra functionality then your free version needs to be extendable.
Your free version should in theory just be a freemium version of your product. And your freemium version of your product should lead to paying customers and be a major way of generating leads and customers. If it's not doing that then it should be a case of do you need to stop adding so many features to the free version or is it that a free version just isn't used by enough people to even matter?
If no one is using it, then really stop building it you're just wasting your time just so you can virtue signal that it's open-source. Really, the only people who will be mad will be the ones not helping you out.
When your enterprise product is a superset of your open source product, you need a trigger that leads to buying. If that trigger is a feature, then it is only effective as a trigger if it is broadly useful to the product. In which case, you either withhold it from open source or cripple (or rate limit it) in open source. Your sales team - told to meet quarterly revenue targets and held accountable to that - will lobby for strict limits on these features.
My first hand experience is that there are two likely outcomes: (1) You limit the utility of the open version to create a buying trigger and your open source users dwindle away as the open product doesn't meet their needs. Or, (2) your community has sufficient momentum to build the feature itself and your sales team starts losing deals to your open source offering.
This model also creates harmful intra-organization conflict between those who argue for short-term revenue (probably their continued employment depends on that) vs. those who argue for the largest open source user base. It also creates conflict with your users as you intentionally offer a worse product to your largest user group (open source users).
I didn't know about the @container queries, they look interesting.
Having said that, I'm not a huge fan of pushing more state logic to CSS. I understand the benefits (from the github page) but pushing more text into the style string without thinking about tooling (how to debug etc) is dangerous.
This is what most people want + some utility functions & good default variables (for colors etc).
If you're doing relatively straightforward things, tailwind is super easy to work with and that's why a lot of people prefer it today. Having it inline makes it easy to digest (both for humans and LLMs) until things get complicated.
I see this similar to using javascript in your project. When you start fresh on a new project, typescript can be seen as a bottleneck, slowing you down. As project evolves your needs also evolve and other solutions might be a better choice.
reply