[smalltorch]

Were you using exclusively free plans to build your app?

I didn't find app building to take that long, even without knowing the ins and outs of kotlin and swift.

I did find the process of publishing the app to be one of the hardest things. The last 10 - 20 percent of app development still requires a lot of paperwork of you aren't already a developer.

[InsideOutSanta]

If you read the article, you'll see that the author took the same approach one would use when writing an app manually from scratch:

> I started with a simple hello world application. Then added in the habit list, the ability to add a habit, edit a habit and so on.

This hands-on, incremental approach works, of course. But I don't think it is the most effective way of using LLMs to write apps.

[smalltorch]

It's not apparent if these were exclusively free LLMs though. I still don't quite understand the time scale unless the author didnt pay...which would be really impressive

[oblio]

> This hands-on, incremental approach works, of course. But I don't think it is the most effective way of using LLMs to write apps.

1. Which apps should be built like this?

2. Which apps shouldn't be built like this?

My instinct is that any app worth building and using for a long time should be built incrementally. Otherwise, slop.

[InsideOutSanta]

I don't think any app should be built like this. Rather, I think this approach should be used when you already have a large codebase and are making atomic changes to it. In fact, I think taking this approach for greenfield work is more likely to result in slop because early accidental decisions turn into fundamental design choices.

Instead, I've settled on a top-down approach: I write an in-depth spec for the whole app first, then have the LLM implement reviewable sections of it.

[zem]

I write greenfield projects this way and have continued to do so with LLMs. it works very well if you have a decent idea of the architecture you are heading towards, and if you are willing to refector aggressively if you have a better idea.

to me the key point is that I get those better ideas a lot more readily by looking at the code than by planning up front - I have a good feel for when adding the next feature is harder than it should be, or when the resulting code is messier than I would like, and seeing the concrete code usually gives me the best idea for how exactly to improve it.

[oblio]

Most apps, just like most buildings, aren't greenfield, though :-)