Automatic Django App Builder

Show & Tell
1

Hi,

I spent some time during the holidays to put together a small service that spews out Django applications. It’s not fancy - by far - thus the name. Do check it out, comment here please:

Do test the service – it’s not perfect – also: I reserve the right to close any account, delete any app and shut down the service at absolutely no notice - remember: this is my personal project, you pay nothing, you get no rights. If you want this to change, I am definitely willing to accept funds :slight_smile:

2

Would be helpful if there was any information on what problem you’re trying to solve here.
It’s not really clear from the post information, neither from the website itself.
Is this some sort of “lovable”? That generates an entire site from a prompt?

3

Fair point Leandro :slight_smile:

Let me add some context, the idea is still under development. But yes, prompt –> Django app.

Your comparison with Lovable is not fully wrong, though in many aspects, my solution would be ‘un-Lovable’ – let me explain:

First the similarities; this application: https://808d178e-97ce-472e-b8bf-67648d59d6a3.pedestrian.site – was generated from this prompt:

Create an application where people can register, log in and create a list of presents they gotten for Christmas 2025. For each present the user must be able to upload a picture that should be stored as jpeg, at no higher resolution than 500x500 pixels, who they got the present from along with name and description. Lists of gifts shall not be shareable or public available. Give the whole site a winter theme with a snowy landscape background

… and some follow up prompt to fix this and that. But basically the prompt above. Thus this seems like something Lovable does (they do it better though…)

But in order to do so, a ton of choices have been made for you. The fundamental Lovable application follows a very specific tech strategy; so, if your basic needs do not fall onto that narrow path, then Lovable is not really helping you. This solution takes another path, in may ways a path much, much more boring – hence the name pedestrian.

Using this tool, you end up with a fairly basic Django application: it does not use JWT tokens, it uses a plain Cookie and has session storage in the database. It does not use a Postgres database service with edge functions capabilities, it does not, by default at least, run a lot of Javascript (well… typescript… but) in the browser. It does not implement Row Level Security – basically there is a lot of stuff that it refrains from doing. For one simple reason: you are not Google (or any FAANG) – this one keeps things simple.

  • JWT Tokens are primarily designed to allow for a micro-service architecture to be able to validate a token without calling the database. This, in turn, is handy if you want to allow for Google/Facebook/Whatever to be used as login service for your application. If you do not have any of these needs, then it’s a rather complicated setup.
  • RLS or Row Level Security is not a bad thing at all, but see what Supabase themselves write: “RLS is incredibly powerful and flexible, allowing you to write complex SQL rules that fit your unique business needs”. It’s a technology you need to master – besides all the other things you need to master. All SaaS applications since the very first SaaS application has had to deal with RLS - it’s a fundamental part of the economics of running a SaaS application - there is no economy in spinning up a database for each customer. Period. So you can choose to implement your RLS in a sophisticated DB-specific setup - that works for some. Or you can specify your RLS in your business logic, in the very same language that you write the rest of your stack. Which is what everybody was doing before RLS was a thing anyway. One this is not better than the other. The risks and pitfalls are just the same. Do you see yourself as a Python programmer - or as an SQL programmer?
  • Tailscale… well.. that’s just a choice - Mistral AI is doing the magic anyway, I chose Bootstrap just to be different…
  • SQLite – is the choice if DB here. Basically because the Pedestrian model is to end up with a very normal Django application – I cannot offload the DB to Supabase and have all business logic run in the browser (Typescript/Javascript async implemented with potential race conditions and all) – so SQLite is convenient in that it’s not a service separate from the container in which Django is running. In fact a default account on Pedestrian has 200MiB of space. That’s it. This includes a small Alpine Linux, all packages installed by Pip and the database. Neat and convenient. Does it scale? absolute no. Is there backup? no.

So, the idea is that you play around here - then if you end up with something that needs more scale, then at least what you have here is not terribly complex to host differently and it’s not terribly complex to have something with programming knowledge to actually take a look at the. The number of lines of code do not run wild.

Perhaps, giving this tool to non-programmers, this could give more work to Python-Django programmers in that the few project that ever need more scale, would need a bit of help :slight_smile:

Does this make any sense?

1 Like