One cold morning, I checked the temperature before heading outside. MyWeather, the backyard weather station we had built, said it was 33.3 degrees. Apple Weather said 41.

An eight-degree difference was large enough that I assumed something must be wrong with our sensor, but when I walked outside and saw the frozen sunroof on our car, the evidence was pretty clear. For our particular yard at that particular moment, MyWeather had the better answer.

That was satisfying, but not because I had somehow beaten Apple at weather. MyWeather started with a much smaller and more personal question: What is the weather actually like right here?

I had wondered about this for a while, especially when I would go for a run and the conditions outside did not seem to match what my phone was reporting. I looked into buying a home weather station, but most of them came with another LCD screen that needed to sit on a counter and could not be checked when I was away from home. Others required an account or subscription, stored our data somewhere else, or combined all of those things. My wife was not interested in adding more parts, screens, and subscriptions to our lives, and I couldn’t blame her.

Eventually, my son and I asked the question that has started a lot of our projects: Could we just build this ourselves?

A small question with a lot underneath it

MyWeather began as a father-and-son project. I was excited by the idea, and my son was happy to help me see whether we could make it work. Our goal was straightforward. We wanted to place a sensor in our backyard and see the actual conditions at our home on our phones and lock screens, whether we were sitting inside or miles away. No separate display, no third-party account, and no monthly fee.

On the surface, the project seemed manageable. We had a 3D printer, knew enough about Arduino electronics to get started, and could build an iPhone app and the web service behind it. My son took responsibility for the back-end web service that receives and stores the weather data, as well as the first version of the sensor electronics, while I tackled the iPhone app that displays the readings.

We got a basic version working relatively quickly. On our workbench, the electronics were sending temperature, humidity, ambient light, and rain data through our web service and displaying the results in the app. We had answered the original question: Yes, we could build our own weather station. To get it outside, which was the goal, the next step was to design and build a case.

I had little 3D modeling experience, so it became a great opportunity for me to build new skills. My son already knew CAD and had experience designing parts for 3D printing. I had usually been the one assisting him, but the roles reversed this time. When I laid out a part incorrectly, could not figure out how to create something, or designed it in a way that would be difficult to print, he would walk me through what I was doing wrong and show me a better technique.

It was fun to learn from him, and as I became more comfortable, I needed less help and could eventually design and print new versions on my own. The project was already doing more than telling us the temperature. It was creating a reason for us to teach each other, try unfamiliar things, and build skills through actual use.

Assembling the first sensor and placing it outside was an exciting moment. It worked just as we had imagined, and we immediately began learning new things. Once version 1 was working, my son continued to maintain the back end while I kept pulling on all the other threads. What had begun as a project we worked on together increasingly became something I could not stop exploring. Every improvement exposed another question, and every new question gave me a reason to keep building.

The backyard started teaching me

A design can look great on a screen or a whiteboard and still have problems you will not discover until you put it into the real world. This project reinforced that lesson almost immediately.

Once the first sensor was outside, we found improvements within hours. The placement of the temperature sensor left it more exposed to the weather. The opening that gave the sensor access to outside air could also trap heat and distort its readings. Later versions moved the sensor into a climate chamber underneath the unit, where air could flow through more naturally while protecting the sensor from the elements.

The color of the enclosure created another problem. Early on, I used a plastic color called Galaxy, a dark blue with shiny flecks, because it looked great. Once I put it outside, though, I discovered that the dark surface absorbed enough sunlight to warm the enclosure and make the temperature readings less accurate. I experimented with several colors before settling on white, not because it was my original preference, but because it performed best in the environment where the sensor actually had to work.

The weather also contributed its own test plan. One day the station ended up buried under a thick layer of snow and ice, giving it some surprise environmental testing that I definitely had not scheduled.

Each time I put a new iteration outside, the backyard showed me something I could not have learned by continuing to refine the design indoors. I would make a change, print another version, deploy it, watch what happened, and adjust again.

The first major redesign came with version 2. Version 1 had been intentionally simple, with all the electronics laid out side by side in a single plane. That made the case much faster to design and helped us get the sensor outside sooner, but it also made the enclosure large.

Version 2 used exactly the same electronic components and sensors as version 1. The challenge was fitting everything into a much smaller space. To reduce the total volume by 45 percent, I stacked the electronics in two layers. That made the internal design far more complicated. I had to determine what belonged on each level, route the wires between them, and make sure the lower layer remained easy to access if a component failed or needed attention. I also redesigned the center of gravity so the finished sensor was less likely to tip over in the wind.

Version 2 took more time to design, but the result was compact, easier to place, and 20 percent faster to print. None of those improvements came from a roadmap I had created at the beginning. They came from putting version 1 outside and letting the real world show me what needed to change.

It became an onion project

MyWeather started to feel like an onion. Every time I peeled back one layer, I found another interesting problem underneath it.

Version 3 was where the hardware itself began to change, and it became the most complex enclosure I had designed. I replaced the original temperature and humidity sensor with a much more accurate component that also measured air pressure. That required creating a climate chamber at the base of the case where air could move through naturally while the sensor remained protected from the elements.

I also replaced the original ambient-light sensor with a new one that could measure UVA as well. That required designing a separate window that protected the electronics without interfering with the ambient-light or UVA readings. A voltage sensor was added so the system could estimate the remaining battery charge. Before that, I could not always tell whether the station had failed or had simply run out of power.

Fitting the new components and sensors into the same physical footprint required a significant redesign of the case interior and many rapid prototypes. I would not have been able to create version 3 at the beginning of the project. It depended on everything I had learned from versions 1 and 2, as well as the CAD skills I had developed along the way.

More data also made the app more useful. It could calculate dew point and create a frost alert based on actual conditions instead of simply notifying me whenever the temperature dropped below a fixed number.

Each addition opened another rabbit hole.

Measuring ultraviolet light sounds simple until you learn that many transparent materials are specifically designed to block it. I needed a window over the light sensor that would protect the electronics while still allowing UVA through, which led me into research about materials I had never had a reason to understand before. I had to find something that performed correctly, was affordable, was easy to obtain, and could be incorporated into a part I was making at home.

Battery life led somewhere completely different. To make the station last longer between charges, I needed a deeper understanding of how the Arduino computer inside it used power and memory. I learned that a small section called RTC memory remained active while most of the system was in deep sleep. Using it meant MyWeather could wake up, take its readings, send the data, and return to sleep more efficiently.

Once the station could measure its voltage and calculate dew point, I wanted the MyWeather app to alert us when the battery was low or frost was likely. I assumed that would require push notification infrastructure, but a little digging revealed that iOS supports local notifications created directly on the device. That let me add frost and low-battery alerts without building another back-end service, and I had the feature working in less than an hour.

These were not subjects I had planned to study. They became interesting because they were connected to a real problem sitting in my backyard. I was not learning about memory, airflow, or UV-transmissive materials in the abstract. I could make a change, put it outside, and see whether it worked.

That made the learning stick.

A high rate of learning

A 3D printer makes it possible to manufacture a new physical design at home, but printing still takes time. As I started making multiple changes in a day, our printer became the bottleneck.

That created another design problem. I was no longer thinking only about whether a part would work inside the weather station. I was also thinking about how much material it required, whether it needed unnecessary supports, and how it could be designed to print more quickly. A faster print meant I could try another idea sooner, which meant I could learn more in the same amount of time.

The same thing was happening in the software. I was able to iterate faster than ever before. New development tools made it possible to design, build, and test ideas in hours instead of days. In one afternoon, I created dynamic backgrounds in the MyWeather app that changed based on the time of day, season, and position of the sun. I added lock-screen widgets, animated transitions, changing icons, and other small details that made the app feel more alive.

My friends in the gaming space (looking at you, Sean) call an experience like this “full of juice.” It comes from spending time on craft and dialing in small details such as the animated transitions, changing icons, and lock-screen widgets that make a product feel cared for. Too many organizations say they want to create something special but do not give teams the time and support it takes. Because MyWeather was something we were building for ourselves, I could keep polishing the experience simply because I knew those details would make it better.

That freedom also changed my rate of learning. In a company, a new product often requires conversations about customers, market size, manufacturing cost, pricing, profit, staffing, and priorities before much can be built. Those are legitimate questions, but they slow down exploration. With MyWeather, it did not matter much whether a part cost three dollars or eight. I could make a decision, try it, and know by the end of the day whether I was moving in the right direction.

In a handful of weeks, I had working hardware, live data, an app, and multiple generations of physical prototypes. In a larger organization, a team might still have been preparing the presentation explaining what it hoped to build.

There are still threads to pull

I still have plenty of threads to pull. I want to explore nowcasting, which means predicting what is likely to happen right here during the next few minutes or hours instead of forecasting the weather several days away. It would be useful to know whether it is likely to rain during a run, based on conditions measured at my own home rather than at a weather station miles away.

I would also like to add UVB sensing so the system can calculate the actual UV index in our yard, and I have explored using a small solar panel and rechargeable battery so the station might operate for months, or potentially indefinitely, without needing to be brought inside and recharged.

The ideas keep expanding. Could I make a portable version for backpacking? Could several of them measure conditions along a running route? Every answer seems to create another question.

That is what I have enjoyed most about building MyWeather. We started because I wanted a more accurate temperature at our home, but following that curiosity led me into electronics, software, industrial design, material science, low-power computing, home manufacturing, and weather prediction. It also gave me the chance to learn CAD from my son and then use what he taught me to keep pushing the project forward.

The weather displayed on my lock screen is useful, especially on mornings when it tells me that my car is probably frozen. But the part I value most is the rhythm I found: ask a question, build something, put it into the real world, watch what happens, and adjust.

I still do not know where the project ends, and that is part of why it has remained so much fun. Curiosity does not really have a finish line. It simply gives you another reason to try something and see what you learn.

More about MyWeather

MyWeather is still evolving. I’ll continue documenting new iterations, experiments, and what I learn on the MyWeather page in the Cohdoo Garage.

Curiosity Doesn’t Have a Finish Line was originally published in Engage on Medium, where people are continuing the conversation by highlighting and responding to this story.