4 ms·

> It is incredibly easy now to get an idea to the prototype stage Yup. And for most purposes, that's enough. An app does not have to be productized and shipped

> It is incredibly easy now to get an idea to the prototype stage Yup. And for most purposes, that's enough. An app does not have to be productized and shipped to general audience to be useful. In fact, if your goal is to solve some specific problem for yourself, your friends/family, community or your team, then the "last step" you mention - the one that "takes majority of time and effort" - is entirely unnecessary, irrelevant, and a waste of time. The productivity boost is there, but it's not measured because people are looking for the wrong thing. Products on the market are not solutions to problems, they're tools to make money. The two are correlated, because of bunch of obvious reasons (people need money, solving a problem costs money, people are happy to pay for solutions, etc.), but they're still distinct. AI is dropping the costs of "solving the problem" part, much more than that of "making a product", so it's not useful to use the lack of the latter as evidence of lack of the former.

threetonesun 7mo ago
I agree, although I'd also say for the majority of problems the first part of even prototyping it is probably a waste of time and most people would be better off asking a simple AI hooked up to search if an appropriate solution already exists, or can be easily made with existing tools.
- TeMPOraL 7mo ago
  At this point if you know about GitHub Pages[0] and know how to copy-paste, it's easier to get an LLM to make you a tool than to find one that works and is free of web entrepreneurship bullshit (ads, trackers, malware, dark patterns, etc.). -- [0] - It would've been even easier if web browsers didn't nerf file:// protocol, but that ship has sailed.
apsurd 7mo ago
But the last "making a product" part does apply to nearly any tool, even a solution to a personal problem. I've started tons of scratch my own itch projects. There's adoption, UX, onboarding costs even if you're the only audience. TLDR: i don't even use my own projects. I churn.
- TeMPOraL 7mo ago
  Think smaller. For some of my tools, if I forget how they worked tomorrow, or the world[0] breaks them next week, it wont't matter, because they served their purpose today. LLMs make it simple to build single use tools like this. (If I ever need it again, I can always have LLM fix it.) -- [0] - I'm not going to accept the insane rate of webshit churn as my fault.
rurp 7mo ago
> if your goal is to solve some specific problem for yourself, your friends/family, community or your team, then the "last step" you mention - the one that "takes majority of time and effort" - is entirely unnecessary, irrelevant, and a waste of time. To a point, but I think this overstates it by quite a bit. At the moment I'm weighing some tradeoffs around this myself. I'm currently making an app for a niche interest of mine. I have a few acquaintances who would find it useful as well but I'm not sure if I want to take that on. If I keep the project for personal use I can make a lot of simplifying decisions like just running it on my own machine and using the CLI for certain steps. To deploy this to for non-tech users I need to figure out a whole deployment approach, make the UI more polished, and worry more about bugs and uptime. It sucks to get invested in some software that then constantly starts breaking or crashing. GenAI will help with this somewhat, but certainly won't drop the extra coding time cost down to zero.
- PaulHoule 7mo ago
  People today say "web applications suck", "Electron sucks", etc. They weren't around in the 1990s where IT departments were breaking under the load of maintaining desktop apps, when we were just getting on the security update treadmill, and where most shops that made applications for Windows had a dedicated InstallShield engineer and maybe even a dedicated tester for the install process.
  - nogridbag 7mo ago
    I wish we had a dedicated InstallShield engineer! I had to design and burn my own discs for the desktop apps I built. And for some reason, the LightScribe drive was installed on the receptionist's computer. I have no idea why, but I was a new hire and I didn't question much.
  - steve1977 7mo ago
    Maintaining desktop apps was not really harder than maintaining the current Kubernetes-Web-App behemoths, at least in my experience.
    - 7mo ago
PaulHoule 7mo ago
In enterprise software there is an eternal discussion of "buy vs build" and most organizations go through a cycle of: -- we had a terrible time building something so now we're only going to buy things -- we had a terrible time buying something so now we're only going to build things -- repeat... Either way you can have a brilliant success and either way you fail abjectly, usually you succeed at most but not all of the goals and it is late and over budget. If you build you take the risks of building something that doesn't exist and may never exist. If you buy you have to pay for a lot of structure that pushes risks around in space and time. The vendor people needs marketing people not to figure out what you need, but what customers need in the abstract. Sales people are needed to help you match up your perception of what you need with the reality of the product. All those folks are expensive, not just because of their salaries but because a pretty good chunk of a salesperson's time is burned up on sales that don't go through, sales that take 10x as long they really should because there are too many people in the room, etc. When I was envisioning an enterprise product in the early 2010s for instance I got all hung up on the deployment model -- we figured some customers would insist on everything being on-premise, some would want to host in their own AWS/Azure/GCP and others would be happy if we did it all for them. We found the phrase "hybrid cloud" would cause their eyes to glaze over and maybe they were right because in five years this became a synonym for Kubernetes. Building our demos we just built things that were easy for us to deploy and the same would be true for anything people build in house. To some extent I think AI does push the line towards build.
- raw_anon_1111 7mo ago
  AI no more pushes things toward build then the unmaintable mess that was internal VB/Access/FoxPro apps before. I’m not opposed to AI or bemoaning “vibe coding”. The answer is still the same with build vs buy “does it make the beer taste better?”. “Do I get a competitive advantage by building vs buying”?
- pjmlp 7mo ago
  You miss a big part of that cycle, incentives, meeting KPIs and OKRs, and who gets to gain from specific decisions being made.
j45 7mo ago
True, but a basic production stage benefits from some amount of backups, dev/staging/prodution, and more than one database.
thegrim33 7mo ago
So your rebuttal to the claim that AI isn't increasing productivity in any measurable way is .. that it does actually increase productivity, but only for apps that aren't being publicly released/shared?
l3x4ur1n 7mo ago
I agree with you. I am personally building small tools and apps to solve my own problems and I would not do that before AI - I would not know how.
- oblio 7mo ago
  Would you pay $1000 per month for that?
  - raw_anon_1111 7mo ago
    I have never come close to running into any limits using codex with my $20/momth ChatGPT subscription every day
    - oblio 7mo ago
      OpenAI is losing massive amounts of money and it needs to pay back hundreds of billions. What do you think will happen to that price 5-10 years from now?
      - raw_anon_1111 7mo ago
        A) Whatever company I’m working for then will pay for it. Right now we get a $1000 a month budget a piece on Claude. I just hardly ever use it. B) price of computing always comes down and models will be a commodity C) If I am an independent consultant by then, I’ll just pay for local inference (I work full time for a consulting company now). You can already get a decent local inference Mac for $500/month.
        oblio 7mo ago
        > B) price of computing always comes down and models will be a commodity Past results are not an indication of future performance. Also funny to say this when hardware costs have spiked.
        7mo ago
johnnyanmac 7mo ago
You forgot the most important factor: able to wow an investor and get them to invest millions on your prototype. Invest that and churn a few years, say "it didn't work out", pocket any difference after the deal falls apart. If you can pull that off 2-3 times, you're set for life. Though, the economy does not seem to be in a good spot to try that strategy out as of now.
androiddrew 7mo ago
I heard a delightful term for building apps only for yourself “houseplant programming”.
scrubs 7mo ago
I mean how else could it be? Some app for Grampa? Junior? The scope of complexity of these problems (which build on tech the viber need not make) is small. There's no serious support dimension or risk. The last step matters. When I'm talking about "apps" as a professional software engineer, I'm thinking about postgres, big table, ramcloud, dpdk, and applications in finance like a security master or system of record. Those apps have actual customers that for the money they pay demand something in product quality Claude can't do. You write "products on the market are not solutions to problems." This speaks volumes and not to the good. You then add "tools to make money" which I read as "side hustle." It's has all the salience and import of a disposable tissue ... what you'd expect people to see that as? Bold leadership? C'mon, get real.
- TeMPOraL 7mo ago
  > You write "products on the market are not solutions to problems." This speaks volumes and not to the good. You then add "tools to make money" which I read as "side hustle." It's has all the salience and import of a disposable tissue ... what you'd expect people to see that as? Bold leadership? C'mon, get real. What I mean is, turning a solution into a product is an explicit step, and that step is not about solving the problem, but about getting paid. This is not a value judgement, merely clarification - one needed especially here, where people get confused by entrepreneurship advice and sometimes forget that they can just solve their own problems and move on. Not every solution needs to be productized, and there's no law of nature or man that says it must be.
  - scrubs 7mo ago
    What you write is for the service provider, not for customers. I'm interested in customers. I'm interested in business, which has a support and risk dimension. Nuff said

threetonesun 7mo ago

I agree, although I'd also say for the majority of problems the first part of even prototyping it is probably a waste of time and most people would be better off asking a simple AI hooked up to search if an appropriate solution already exists, or can be easily made with existing tools.

TeMPOraL 7mo ago
At this point if you know about GitHub Pages[0] and know how to copy-paste, it's easier to get an LLM to make you a tool than to find one that works and is free of web entrepreneurship bullshit (ads, trackers, malware, dark patterns, etc.). -- [0] - It would've been even easier if web browsers didn't nerf file:// protocol, but that ship has sailed.

apsurd 7mo ago

But the last "making a product" part does apply to nearly any tool, even a solution to a personal problem. I've started tons of scratch my own itch projects. There's adoption, UX, onboarding costs even if you're the only audience. TLDR: i don't even use my own projects. I churn.

TeMPOraL 7mo ago
Think smaller. For some of my tools, if I forget how they worked tomorrow, or the world[0] breaks them next week, it wont't matter, because they served their purpose today. LLMs make it simple to build single use tools like this. (If I ever need it again, I can always have LLM fix it.) -- [0] - I'm not going to accept the insane rate of webshit churn as my fault.

rurp 7mo ago

> if your goal is to solve some specific problem for yourself, your friends/family, community or your team, then the "last step" you mention - the one that "takes majority of time and effort" - is entirely unnecessary, irrelevant, and a waste of time. To a point, but I think this overstates it by quite a bit. At the moment I'm weighing some tradeoffs around this myself. I'm currently making an app for a niche interest of mine. I have a few acquaintances who would find it useful as well but I'm not sure if I want to take that on. If I keep the project for personal use I can make a lot of simplifying decisions like just running it on my own machine and using the CLI for certain steps. To deploy this to for non-tech users I need to figure out a whole deployment approach, make the UI more polished, and worry more about bugs and uptime. It sucks to get invested in some software that then constantly starts breaking or crashing. GenAI will help with this somewhat, but certainly won't drop the extra coding time cost down to zero.

PaulHoule 7mo ago
People today say "web applications suck", "Electron sucks", etc. They weren't around in the 1990s where IT departments were breaking under the load of maintaining desktop apps, when we were just getting on the security update treadmill, and where most shops that made applications for Windows had a dedicated InstallShield engineer and maybe even a dedicated tester for the install process.
- nogridbag 7mo ago
  I wish we had a dedicated InstallShield engineer! I had to design and burn my own discs for the desktop apps I built. And for some reason, the LightScribe drive was installed on the receptionist's computer. I have no idea why, but I was a new hire and I didn't question much.
- steve1977 7mo ago
  Maintaining desktop apps was not really harder than maintaining the current Kubernetes-Web-App behemoths, at least in my experience.
  - 7mo ago

PaulHoule 7mo ago

In enterprise software there is an eternal discussion of "buy vs build" and most organizations go through a cycle of: -- we had a terrible time building something so now we're only going to buy things -- we had a terrible time buying something so now we're only going to build things -- repeat... Either way you can have a brilliant success and either way you fail abjectly, usually you succeed at most but not all of the goals and it is late and over budget. If you build you take the risks of building something that doesn't exist and may never exist. If you buy you have to pay for a lot of structure that pushes risks around in space and time. The vendor people needs marketing people not to figure out what you need, but what customers need in the abstract. Sales people are needed to help you match up your perception of what you need with the reality of the product. All those folks are expensive, not just because of their salaries but because a pretty good chunk of a salesperson's time is burned up on sales that don't go through, sales that take 10x as long they really should because there are too many people in the room, etc. When I was envisioning an enterprise product in the early 2010s for instance I got all hung up on the deployment model -- we figured some customers would insist on everything being on-premise, some would want to host in their own AWS/Azure/GCP and others would be happy if we did it all for them. We found the phrase "hybrid cloud" would cause their eyes to glaze over and maybe they were right because in five years this became a synonym for Kubernetes. Building our demos we just built things that were easy for us to deploy and the same would be true for anything people build in house. To some extent I think AI does push the line towards build.

raw_anon_1111 7mo ago
AI no more pushes things toward build then the unmaintable mess that was internal VB/Access/FoxPro apps before. I’m not opposed to AI or bemoaning “vibe coding”. The answer is still the same with build vs buy “does it make the beer taste better?”. “Do I get a competitive advantage by building vs buying”?
pjmlp 7mo ago
You miss a big part of that cycle, incentives, meeting KPIs and OKRs, and who gets to gain from specific decisions being made.

j45 7mo ago

True, but a basic production stage benefits from some amount of backups, dev/staging/prodution, and more than one database.

thegrim33 7mo ago

So your rebuttal to the claim that AI isn't increasing productivity in any measurable way is .. that it does actually increase productivity, but only for apps that aren't being publicly released/shared?

l3x4ur1n 7mo ago

I agree with you. I am personally building small tools and apps to solve my own problems and I would not do that before AI - I would not know how.

oblio 7mo ago
Would you pay $1000 per month for that?
- raw_anon_1111 7mo ago
  I have never come close to running into any limits using codex with my $20/momth ChatGPT subscription every day
  - oblio 7mo ago
    OpenAI is losing massive amounts of money and it needs to pay back hundreds of billions. What do you think will happen to that price 5-10 years from now?
    - raw_anon_1111 7mo ago
      A) Whatever company I’m working for then will pay for it. Right now we get a $1000 a month budget a piece on Claude. I just hardly ever use it. B) price of computing always comes down and models will be a commodity C) If I am an independent consultant by then, I’ll just pay for local inference (I work full time for a consulting company now). You can already get a decent local inference Mac for $500/month.
      - oblio 7mo ago
        > B) price of computing always comes down and models will be a commodity Past results are not an indication of future performance. Also funny to say this when hardware costs have spiked.
        7mo ago

johnnyanmac 7mo ago

You forgot the most important factor: able to wow an investor and get them to invest millions on your prototype. Invest that and churn a few years, say "it didn't work out", pocket any difference after the deal falls apart. If you can pull that off 2-3 times, you're set for life. Though, the economy does not seem to be in a good spot to try that strategy out as of now.

androiddrew 7mo ago

I heard a delightful term for building apps only for yourself “houseplant programming”.

scrubs 7mo ago

I mean how else could it be? Some app for Grampa? Junior? The scope of complexity of these problems (which build on tech the viber need not make) is small. There's no serious support dimension or risk. The last step matters. When I'm talking about "apps" as a professional software engineer, I'm thinking about postgres, big table, ramcloud, dpdk, and applications in finance like a security master or system of record. Those apps have actual customers that for the money they pay demand something in product quality Claude can't do. You write "products on the market are not solutions to problems." This speaks volumes and not to the good. You then add "tools to make money" which I read as "side hustle." It's has all the salience and import of a disposable tissue ... what you'd expect people to see that as? Bold leadership? C'mon, get real.

TeMPOraL 7mo ago
> You write "products on the market are not solutions to problems." This speaks volumes and not to the good. You then add "tools to make money" which I read as "side hustle." It's has all the salience and import of a disposable tissue ... what you'd expect people to see that as? Bold leadership? C'mon, get real. What I mean is, turning a solution into a product is an explicit step, and that step is not about solving the problem, but about getting paid. This is not a value judgement, merely clarification - one needed especially here, where people get confused by entrepreneurship advice and sometimes forget that they can just solve their own problems and move on. Not every solution needs to be productized, and there's no law of nature or man that says it must be.
- scrubs 7mo ago
  What you write is for the service provider, not for customers. I'm interested in customers. I'm interested in business, which has a support and risk dimension. Nuff said