An aquarium lives or dies by the balance of its water. pH, hardness, nitrates, CO2 drift slowly, without warning, and by the time you notice, it is often the fish or the shrimp that have paid for it. The problem is not measuring: everyone tests their water. The problem is catching the drift in time, and knowing whether a number is good or not. Most aquarists jot their readings into a spreadsheet that warns them of nothing, or into old, austere apps.

That is the problem I set out to solve. I turned it into an application: a modern, deliberately simple aquarium tracker that turns each test into a clear per-species verdict, alerts you when a parameter drifts, and keeps the history, the photos and the tank's evolution. Around that core, a few features that give you a reason to come back: breeding tracking, a budget, a scape journal. Starting from a problem you live yourself and working back to the product: that, to me, is product vision.

I did not write a single line of its code. The AI typed all of it.

And that is exactly where I learned the most about what separates an idea from a product.

Seeing the product

A product begins with a problem, not with a list of features. Mine fit in one sentence: make a silently drifting body of water readable. Everything else follows from it. Turning a test into a verdict, warning before the damage: these are not technical choices, but the direct translation of that problem.

One of my most serious competitors is not an application: it is a spreadsheet. Any aquarist records their readings in a Google Sheet, for free and without limit. There is no point competing on the number of features, a spreadsheet is infinite. I can only stand out on what it will never do:

  • read a trend at a glance;
  • fill in seconds on a phone;
  • know the thresholds specific to each species;
  • follow a breeding line.

Where the spreadsheet records, the product accompanies. Every time I wanted to add a feature "because it would be nice", it was that spreadsheet that brought me back in line: deciding what you do, and above all what you don't do, is a product decision.

Thinking the model

I built this product for myself first. I keep aquariums, I had the problem, and solving it myself appealed to me. Only then did it become a testing ground: a place to sharpen the way I work with AI and the way I design a product, starting with its economics.

Because even a project made for yourself deserves a look at whether it holds up. So I looked at the numbers before getting carried away:

  • a competing application tops out around eight thousand installs, not millions;
  • freshwater fishkeeping has been declining for about a decade, even if nano tanks and shrimp are growing;
  • willingness to pay stays moderate.

I drew a conclusion without kidding myself: this will be a side income and a portfolio piece, not a product that pays a salary. Having built it for myself first makes that ceiling easy to accept, and above all useful: it sets what I invest, the time I spend, the point where I stop.

The budget follows the same rule:

  • nothing on hosting until there is a paying customer;
  • nothing on advertising until organic acquisition has proven it converts;
  • a price designed for the audience: an affordable monthly plan to lower the first barrier, an annual plan for loyalty, a lifetime plan for a niche that distrusts subscriptions.

Spending follows proof, never the other way around.

Deciding the architecture

That leaves the technical form. It is the part I care about most, because it touches the job I am aiming for: cloud architect.

I know exactly what I use, and why, without having written a line of it. A static front end with Supabase behind it, to rely on a managed Postgres database, authentication and access rules rather than running a server. The free tier as long as the product earns nothing, with a clear path to the paid tier when the time comes. A PWA install to skip the app stores at the start. I wanted the paid model's limits checked in the database, not only in the interface, because a barrier that lives only in the browser can be bypassed. And I funneled every database access through a single point, so that switching providers one day comes down to a few lines.

None of these choices is a line of code I typed: they are decisions. Which services, for what reasons, with what trade-offs. Knowing what you assemble and why is the heart of that job.

What makes a product

An aquarium tracking app will not change the world, and that was never the goal. It will have taught me the essential thing: between an idea and a product, there is a problem to understand, a model to weigh, an architecture to decide. On this project, that is the part of the work that was mine, and it is also the part that interests me most.

And these three moves are not just about an aquarium. Understanding a need before serving it, checking that a project holds up economically, choosing services and owning their trade-offs: that is an architect's daily work, at any scale. A small product is a good place to practice it, without a safety net and for real.

That is the path I am pursuing: cloud architecture. An aquarium today, larger systems tomorrow, with the same way of thinking.