DEV Community: John

From NASA Exoplanet Query to ExoVault: Building a Better Data Exploration Experience

John — Sat, 11 Apr 2026 13:25:13 +0000

Other project idea I recently decided to build in public was inspired by the NASA Exoplanet Query prompt from the App Ideas repository.

That project eventually became ExoVault:
https://github.com/johnnylemonny/ExoVault

What started as a structured data query idea turned into something much more interesting for me:
a more polished, cinematic interface for exploring NASA exoplanet archive data.

The original prompt

The NASA Exoplanet Query idea is already a really good challenge.

It’s built around:

working with NASA archive data,
loading CSV efficiently,
minimizing delays at startup,
and building a query interface that lets users filter exoplanet data by fields like discovery year, method, host name, and facility.

That made it appealing right away.

It wasn’t just about rendering data.
It was about thinking carefully about:

ingestion,
structure,
search,
and presentation.

What pulled me into this idea

What interested me most wasn’t only the dataset.

It was the possibility of taking something that could have been “just a query tool” and pushing it toward a better exploration experience.

I kept thinking:

What if this felt less like a utility screen and more like a discovery product?

That question shaped the direction of the whole project.

Instead of building only the minimum query UI, I wanted to create something that felt more deliberate, more visually refined, and more enjoyable to explore.

That’s where ExoVault came from.

How ExoVault evolved

In my version, the project became a more premium archive explorer built around:

a custom CSV-to-JSON data pipeline,
a high-performance frontend,
compare mode for exoplanetary systems,
glassmorphic visuals,
and a more cinematic browsing experience.

I built ExoVault with:

Astro
React
Tailwind CSS
TypeScript

and used a custom data pipeline to process NASA’s raw CSV into optimized JSON payloads.

That part was especially satisfying because it made the project feel more complete end-to-end:
not just UI, not just data handling, but both working together.

What I wanted the project to feel like

One of my goals with ExoVault was to make exploration feel intentional.

Not just:

filter,
search,
render rows,
done.

I wanted the archive to feel like something people would actually want to browse.

That meant paying attention to things like:

visual hierarchy,
transitions,
compare flow,
and how the interface frames the data.

I think there’s a big difference between “showing information” and “creating a discovery experience.”

This project made me think a lot about that difference.

What I learned while building it

A few things stood out while working on ExoVault:

1. Data projects become more interesting when presentation is treated seriously

A structured dataset can feel dry or compelling depending on how the experience is shaped.

2. Prompt-based ideas are often stronger than they first appear

The original App Ideas brief gave me a very solid technical core.
The interesting part came from deciding how to evolve it.

3. Frontend polish matters even in data-heavy apps

If the interface feels flat, the whole experience feels flatter too.
Good data presentation is also a UX problem.

4. Public repos push me toward stronger execution

Knowing the project would live openly on GitHub made me care more about the quality of the pipeline, repo structure, documentation, and overall presentation.

Why I like using structured prompts as a starting point

I think structured prompt repositories are one of the best ways to build momentum — especially if you don’t treat them as the finish line.

That’s how I’m trying to use them.

Not as instructions to copy,
but as a framework to build from.

The prompt gives me:

direction,
constraints,
and technical focus.

Then the real project begins when I start asking:

how should this feel?
what should be improved?
what makes this worth sharing publicly?
how can this become more than the base brief?

ExoVault is probably one of my clearest examples of that so far.

From a Calorie Counter Prompt to a Local-First Nutrition Tracker

John — Sat, 11 Apr 2026 13:06:38 +0000

One of the things I’ve been trying to do lately is take project prompts seriously enough to turn them into public, polished repositories instead of leaving them as half-finished exercises.

That’s exactly what happened with NutraFlux:
https://github.com/johnnylemonny/NutraFlux

The project was inspired by the Calorie Counter idea from the App Ideas repository, but I didn’t want to stop at “search foods and show calories.”

I wanted to push it into something that felt faster, cleaner, and more product-like.

The original idea

The original Calorie Counter prompt is already a strong one.

It focuses on:

searching foods,
showing matching results,
calorie values,
and working with structured nutritional data.

It also introduces useful technical constraints:

transforming raw food data into a format that is easier to search,
limiting results,
and thinking about performance and search strategy.

That made it a really good foundation.

What interested me most

What grabbed my attention wasn’t just the calorie tracking part.

It was the opportunity to build a nutrition tool that felt:

immediate,
search-first,
and frictionless.

A lot of apps in this space feel slower or heavier than they need to.

So instead of treating this as a basic exercise, I started asking:

What would this feel like if I designed it more like a fast, privacy-friendly product?

That question eventually led to NutraFlux.

How NutraFlux evolved

In my version, the idea became a local-first daily calorie and macro tracker built around speed, privacy, and a more refined frontend experience.

NutraFlux includes:

instant search-first logging,
wildcard food lookup,
meal categories,
calorie budgeting and progress indicators,
favorites and recently used foods,
adaptive design,
and a more polished visual system.

What I liked most about building it was that the original prompt gave me a functional core — but the product identity came from the decisions I made around it.

That’s where it stopped feeling like a challenge and started feeling like my own project.

Why I made it local-first

One of the biggest choices behind NutraFlux was making it strictly local-first.

Everything lives in the browser:

nutritional data,
settings,
and food history.

No account wall.
No cloud sync.
No user data leaving the device.

I really liked that direction because it made the product feel:

faster,
more private,
and more focused.

It also changed how I thought about UX.

When everything happens instantly and locally, the interface itself has to carry more of the experience.

That made clarity, speed, and smooth interaction much more important.

What I learned from building it

A few things really stood out while working on this project:

1. A strong prompt is a good starting point — not a limitation

The base idea gave me a clear direction, but the interesting part was deciding how far to take it beyond the original brief.

2. Product feel matters as much as base functionality

The app can technically work, but it still won’t feel complete unless the UI, feedback, and flow are treated with care.

3. Privacy can be part of the product identity

Making NutraFlux local-first wasn’t just a technical detail.

It became one of the reasons the app feels different.

4. Public repos raise the bar in a good way

Once I knew this would live publicly on GitHub, I thought more carefully about polish, structure, and presentation.

Why I like building from prompts this way

I think project prompt repositories get underestimated sometimes.

But for me, they’re useful because they remove just enough uncertainty to let me focus on what really matters:

interpretation,
technical decisions,
UX,
polish,
and project identity.

NutraFlux is a good example of that.

It started as inspiration from a calorie counter prompt.
Now it’s part of the kind of public open-source work I want to keep building more of.

I Built a Free Hydration Tracker with No Signup: Here’s What I Learned

John — Fri, 10 Apr 2026 16:56:20 +0000

I recently built Drink Daily, a hydration tracking web app designed to be free, simple to use, and available without registration.

🔗 Live app: https://drink-daily.vercel.app/en

This is one of the projects I’m most proud of so far, not just because it works, but because it reflects the kind of products I like building: practical, lightweight, and polished enough to feel good to use.

Why I built it

A lot of small health-related apps create friction too early.

You open the app and immediately hit:

a sign-up wall,
limited functionality,
too much clutter,
or an interface that feels more like a form than a product.

I wanted to build something different:

useful from the first visit
no registration required
clear and focused
pleasant to interact with
good enough to feel like a real product, not just a demo

Hydration tracking felt like a good fit for that kind of experience.

What Drink Daily is

Drink Daily is a free hydration tracking app that helps users keep track of daily water intake without forcing account creation.

The goal was to keep the experience:

frictionless,
fast,
understandable,
and easy to return to.

Instead of overcomplicating the idea, I focused on making the core experience feel smooth and intentional.

What I wanted to get right

When I started building it, I cared about more than “just making it work.”

I wanted the app to feel:

1. Simple

The app should be easy to understand immediately.

2. Lightweight

No unnecessary barriers, no bloated flows, no forced registration.

3. Polished

I enjoy building interfaces that feel refined, so I paid attention to layout, spacing, clarity, and the overall experience.

4. Actually usable

Even for a small app, I wanted it to feel like something people could genuinely use — not just click through once.

What I learned while building it

Building Drink Daily taught me a lot about the difference between having features and creating a good experience.

A few things stood out:

Product decisions matter as much as technical ones

It’s easy to keep adding features, but choosing what not to add is just as important.

Small UX details make a huge difference

Spacing, hierarchy, naming, and flow can completely change how “finished” a project feels.

Friction shows up fast in simple apps

When the app itself is simple, every unnecessary step becomes more noticeable.

Public projects feel different

Building something you’re willing to show publicly makes you think more carefully about quality, clarity, and polish.

What I’d improve next

Like most projects, this one still has room to grow.

Some things I’d like to improve or expand over time:

deeper progress insights
more personalized tracking options
more refinement in the user flow
additional quality-of-life improvements
continued UI/UX polishing

I also want to keep improving how I present and document my public work.

Why I’m sharing it

I’m currently growing my public developer profile and becoming more active in open source and build-in-public style sharing.

This project felt like a good first thing to share because it reflects what I enjoy most:
building practical web apps with a strong focus on clean UI, smooth UX, and modern frontend development.

If you try the app, I’d genuinely appreciate any feedback:

What feels good?
What feels unclear?
What would you improve?

DEV Community: John

From NASA Exoplanet Query to ExoVault: Building a Better Data Exploration Experience

The original prompt

What pulled me into this idea

How ExoVault evolved

What I wanted the project to feel like

What I learned while building it

1. Data projects become more interesting when presentation is treated seriously

2. Prompt-based ideas are often stronger than they first appear

3. Frontend polish matters even in data-heavy apps

4. Public repos push me toward stronger execution

Why I like using structured prompts as a starting point

Links

From a Calorie Counter Prompt to a Local-First Nutrition Tracker

The original idea

What interested me most

How NutraFlux evolved

Why I made it local-first

What I learned from building it

1. A strong prompt is a good starting point — not a limitation

2. Product feel matters as much as base functionality

3. Privacy can be part of the product identity

4. Public repos raise the bar in a good way

Why I like building from prompts this way

Links

I Built a Free Hydration Tracker with No Signup: Here’s What I Learned

Why I built it

What Drink Daily is

What I wanted to get right

1. Simple

2. Lightweight

3. Polished

4. Actually usable

What I learned while building it

Product decisions matter as much as technical ones

Small UX details make a huge difference

Friction shows up fast in simple apps

Public projects feel different

What I’d improve next

Why I’m sharing it

Links