You Probably Don't Need to Hardcode Your Data

While building an app, it is very tempting to put everything directly into the code at first. It is fast, there is nothing else to configure, and for a prototype it often feels completely reasonable.

I did the same thing with ingredient data in a cooking app I was experimenting with. The app needed categories and a list of ingredients users could select from, so the obvious first version was simply to keep that data inside the project.

That works perfectly until you realise that the data itself is part of the product.

If I discover that an ingredient is missing, fix a spelling mistake or want to add another option, I do not really want to change the source code, rebuild the application and release a new version just for that. The application logic has not changed. Only the data has.

That was the point where using a database started making much more sense.

Code and product data are not the same thing

A useful question I have started asking is: does this value describe how the application works, or is it content the application uses?

If it is part of the application structure and changes very rarely, keeping it locally can be perfectly fine. If it is something I expect to add, edit or eventually manage independently from the app release cycle, hardcoding it starts becoming inconvenient very quickly.

For my ingredient list, Firestore was useful because the application could load the current data from the database instead. I could add another ingredient remotely and the app would see it without requiring a new App Store build.

It also leaves much more room for the project to grow later. The same data could eventually contain translations, additional properties or other information without forcing all of it into application code.

Not everything needs to be remote

At the same time, I do not think the answer is to move every constant into a database.

For example, I ended up keeping the basic ingredient categories locally in a JSON file while storing the actual ingredients in Firestore. The categories were a small and relatively stable part of the interface. The ingredients were the part I expected to change and expand.

That distinction feels more useful than simply saying “databases are better than hardcoded data”.

A database adds its own complexity: fetching data, handling failures, permissions and eventually deciding how that data is maintained. If a list is tiny, fixed and genuinely belongs to the application itself, a local file may still be the simpler solution.

The important part is noticing when something that started as a convenient constant has quietly become content.

A small decision that makes later changes easier

This is not a particularly complicated architectural lesson, but it is one I can already see saving work later.

Hardcoding is excellent when I am trying to make an idea work quickly. The mistake would be assuming that everything I hardcoded during the prototype should remain that way forever.

If I expect to change something without wanting to release a new version of the application, that is usually a good sign that it should live somewhere outside the code.

For me, the simplest version of the rule is:

Keep stable application structure in the app. Keep changing product data somewhere you can change it independently.

That is enough architecture for now.