How many environment variables does your application need before it will even start locally?
I've seen projects where the first thing you have to do after cloning the repository is find an .env.example and start copying values:
```text id="r6m2k8"
DATABASE_URL=
REDIS_HOST=
AUTH_SECRET=
STRIPE_SECRET_KEY=
AWS_REGION=
SOME_EXTERNAL_API_KEY=
ANOTHER_SERVICE_TOKEN=
Then comes the fun part.
Ask someone else on the team for the missing values.
Figure out which services need to be running.
Create accounts.
Generate API keys.
Restart the application.
And only then can you finally see the project running on your machine.
I've started thinking that there's something really nice about applications that don't need any of that.
## Zero configuration is a feature
One of the goals behind Utilifie was to keep the local development environment as boring as possible.
No database credentials.
No Redis connection.
No third-party API keys just to use the tools.
No external service that needs to be running in the background.
The ideal setup is simply:
```bash
git clone <repository>
cd utilifie
npm install
npm run dev
And that's it.
The application should work.
Moving work to build time
Part of making this possible is being intentional about where work happens.
For example, things that don't need to happen dynamically can be generated during the build.
Search-related data can be prepared ahead of time rather than requiring another service during development.
Google Search Console verification can also be handled through static verification files and metadata rather than introducing another runtime dependency.
And the actual utilities themselves don't need a backend for many operations.
If a browser can parse, calculate, encode, decode, transform, or inspect something locally, there's often no reason to send that data to an API first.
The browser is already sitting there waiting to do the work.
Fewer dependencies, fewer things to break
This isn't just about convenience.
Every external dependency introduces another thing that can fail.
A database can be unavailable.
A Redis instance can be misconfigured.
An API key can expire.
A third-party service can change its API.
A new developer can forget to configure something.
None of these are necessarily bad architectural decisions. Sometimes you genuinely need those services.
But if you don't need them, why add them?
That's the part I like about a zero-environment-variable setup.
The configuration surface becomes smaller.
And a smaller configuration surface is one less thing developers have to think about before they can start working.
The boring setup is often the good setup
There's something satisfying about cloning a project and having it work immediately.
No Slack message asking for credentials.
No five-page setup guide.
No mysterious .env variable that nobody remembers why it exists.
Just:
npm install
npm run dev
Then you're in.
That's one of the principles we're trying to follow with Utilifie:
If something can be static, make it static.
If something can run in the browser, let the browser run it.
If something doesn't need configuration, don't create configuration for it.
Simplicity isn't the absence of engineering.
Sometimes, it's the result of making enough deliberate engineering decisions that the complexity no longer needs to be exposed to everyone else.
You can explore Utilifie here:
Top comments (0)