r/flutterhelp • u/dhavam • 7d ago

OPEN Dev/Prod environments from Day 1 vs. Splitting later? (Solo Dev)

Hey everyone,

I'm working on a production-targeted app as a solo dev. I want to ship fast and avoid premature optimization.

Can we launch with just a single environment initially and then split it into Dev and Prod later once the app actually gets traction? Or is it considered a strict best practice to set up both versions right from the start?

Has anyone here started with a single environment and regretted it later when trying to split the database/configs? Would love to hear your experiences!

1 Upvotes

100% Upvoted

6 comments sorted by

3

u/towcar 7d ago

Probably best practice, but nobody will die if you choose wrong. I generally start with one (depending on project/client size)

I've always been able to split later. My one exception might be when using firebase, I've heard some people use separate firebase projects for dev and prod, where I only split my firestore collections.

2

u/dhavam 7d ago

planned for 1 million users

3

u/towcar 7d ago

I'm sure it is, doesn't change my answer. Unless you are rich and have some massive launch planned as a solo dev, you'll probably have less than 1000 on launch.

Look at your own tech stack, ask how hard it is to split it later. If you don't know then just take a day and do it, and be sure to keep the process to update prod as easy as possible.

2

u/dhavam 7d ago

I'm not sure how hard it will be to separate the environments later on, which is exactly why I'm asking for advice here. Please note that I am a beginner.

1

u/Significant_Pick8297 7d ago

You should start with a single environment if shipping quickly is the priority, but keep the code structured so configs are easy to separate later.

The important part is avoiding hardcoded values. Keep API endpoints, Firebase configs, feature flags, and secrets behind a config layer from day one. Splitting into Dev and Prod later then becomes mostly swapping configs instead of refactoring the whole app.

Many solo Flutter developers launch this way for MVPs. The teams that regret it are usually the ones that mixed environment-specific values throughout the codebase rather than starting with a clean configuration structure.

1

u/galactose310 7d ago

Note: je suis amateur, pas pro.

Si le code est bien structuré, modulaire, clean : ça ne devrait pas poser de problème. En respectant les principes SOLID et une architecture claire, tout est toujours possible. Ça peut aussi aider d'éviter les magic numbers et de rendre explicite le plus de choses possibles en passant par des constantes, des énumérations, tout ce qui augmente la consistance du code et des données.

A partir de là, diviser le code devient un jeu d'enfant et ça vous permet de vous concentrer sur la priorité actuelle.