The first version of my water-temperature app began as a small project in May 2024. The question behind it was small too: what is the water temperature near me? That is enough of a reason for an application to exist, provided the answer is easy to find and easy to understand.
A weather app can contain this information somewhere among wind, rain, pressure, maps and forecasts. A dedicated app has a different opportunity. It can put one answer at the center and make the surrounding interface serve that answer. The early project eventually became AquaDegrees, but the useful starting point was the question, not a list of features.
There is a trap in making an app around a single number. The interface can become so clean that it removes the context needed to interpret the number. A large temperature with a degree symbol looks authoritative. It does not tell you which location it represents, how recently the underlying information changed or what kind of observation produced it.
A number needs a place
"Near me" is convenient language for a person and an incomplete instruction for a data system. A location on land is not a water measurement. A coastline contains bays, open water and places separated by terrain. Even before choosing a screen layout, the app needs a defensible relationship between the user's position and the water location being described.
I think the interface should make that relationship visible in ordinary language. The user should not have to understand a grid or an API response. They should be able to tell whether they are looking at the place they intended.
The same applies to time. There is a difference between the moment the app fetched a response and the time represented by the data. Refreshing a screen does not necessarily create a newer observation. A careful interface can show useful freshness information without turning a simple utility into a technical dashboard.
The initial prototype also gives a reason to think about missing information early. Location access can be declined. A network request can fail. A previously available value can become stale. None of those situations should quietly become zero degrees or an apparently current number. The absence of an answer is part of the product, because it is one of the states a person will encounter.
That is where a narrow scope helps. With one main task, it is easier to ask whether each state makes sense. A location label, a temperature and a clear explanation when data is unavailable can be reviewed as a whole. Adding more screens would not necessarily improve that experience.
I do not think a small app has to justify itself by growing into a platform. It can become better by making its original answer more dependable and reducing the work required to get it. That leaves plenty of engineering: data handling, permissions, presentation, errors and later maintenance all still exist.
The May prototype is the beginning of that work. The size of the question is an advantage. It gives me a simple way to judge the app: after opening it, does someone know more about the water they are thinking of entering?