This is nearly as dumb as the post that "Claude code is useless because your home built "Slack App" won't be globally distributed, with multi-primary databases and redis cache layer... and won't scale beyond 50k users".

As if 97% of web apps aren't just basic CRUD with some integration to another system if you are lucky.

99% of companies won't even have 50k users.

▲

aerhardt 8 hours ago | parent | next [-]

Distributing an app to 100 users inside an enterprise is already a hellish nightmare and I'm pretty convinced that citizen developers will never be a thing - we'll sooner reach the singularity.

▲

jschveibinz 7 hours ago | parent [-]

Here's my take:

I think that citizen developers will be a thing--but not in the way you might be thinking.

More people will be enabled (and empowered) to "build" quick-and-dirty solutions to personal problems by just talking to their phone: "I need way to track my food by telling you what I ate and then you telling me how much I have left for today. And suggest what my next meal should be."

In the current paradigm--which is rapidly disappearing--that requires a UI app that makes you type things in, select from a list, open the app to see what your totals are, etc. And it's a paid subscription. In 6 months, that type of app can be ancient history. No more subscription.

So it's not about "writing apps for SaaS subscribers." It's about not needing to subscribe to apps at all. That's the disruption that's taking place.

Crappy code, maintenance, support, etc.--no longer even a factor. If the user doesn't like performance, they just say "fix ___" and it's fixed.

What subscription apps can't be replaced in this disruption? Tell me what you think.

▲

poisonborz 6 hours ago | parent | next [-]

Almost everything requires a UI. There's just nothing faster than quick glances and taps. It's why voice assistants or hand-waving gesture controls never took over. Having an agent code all those - possibly very complex things - is just impossible without AGI. How would it even work?

- Would the agent go through current app user flows OpenClaw style? Wildly insecure, error-prone, expensive.

- Tapping in to some sort of third party APIs/MCPs. authed, metered, documented how and by which standard to be not abused and hacked?

The unhyped truth is that LLMs are just wildly more competent autocomplete, and there is no such disruption in sight. The status quo of developers and users mostly remains.

▲

aerhardt 7 hours ago | parent | prev [-]

Well, your example is timely.

Today I asked ChatGPT to make me a weekly calorie plan and it was perfect. But then I still use MyFitnessPal to log my calories because their food database is outstanding, and the UX of scanning food barcodes is unbeatable. They have the most niche items in my country, Spain.

How are LLMs going any of that? An app is often much more than a CRUD interface.

Maybe I could build a custom app that scans the nutrition facts table and with voice I could explain how much I ate or something - I’m technical, but really, I have better things to do and I’d rather pay MFP 10 bucks a month.

	▲	dragandj 4 hours ago \| parent \| next [-]
		> An app is often much more than a CRUD interface. "I could have written Facebook over a weekend" syndrome :)
	▲	tstrimple 2 hours ago \| parent \| prev [-]
		The data sources often exist to build these things yourself. For your example there is Open Food Facts and USDA FoodData Central. https://world.openfoodfacts.org/ https://fdc.nal.usda.gov/ Both would make a great foundation for this sort of app. OFF is crowdsourced and does include barcode information. I have no idea how robust the dataset is for your geography though. If I were to build something like this for personal use, I'd be looking at a PWA that can leverage the camera for barcode scanning. I'd work with the existing crowd sourced database as well as provide a mechanism for "manual" entry which should just be scanning a barcode and taking a picture of the nutrition information. I've personally built systems like this before and all of these things are well within the capability of most SOTA LLM to build out.

▲

mattmanser 8 hours ago | parent | prev | next [-]

That's not actually true.

When you move to the enterprise layer, suddenly you get the opposite problem, you have a low amount of "users" but you often need a load of CPU intensive or DB intensive processing to happen quickly.

One company I worked for had their system built by, ummmm, not the greatest engineers and were literally running out of time in the day to run their program.

Every client was scheduled over 24 hours, and they'd got to running the program for 22 hours per day and were desperately trying to fix it before they ran out of "time". They couldn't run it in parallel because part of the selling point of the program was that it amalgamated data from all the clients.

	▲	bearjaws 4 hours ago \| parent [-]
		Without seeing more this seems like it could be solved by not recomputing the entire history to add on data. Depends what kind of math you are doing however. Some sort of check point system could likely save significant IO. What am I missing that requires you to recompute all data every day?

▲

Iulioh 9 hours ago | parent | prev [-]

Well, users or _paying_ users?

It's an important distinction

	▲	jjk166 8 hours ago \| parent [-]
		Probably either. And excluding non-paying users only further narrows the applicability.