What I Learn by Building Related Projects

A website can fail as a business and still be worth building. I work on several sites that share a lot of the same tools and platforms. That gives me a way to learn: try something on a cheap, low-stakes project, figure out whether it actually helps, and bring the useful parts to another site.

That’s what I was trying to explain when I called this “cross-iterative learning.” The name sounds corny to me now, and the old explanation got carried away. The useful idea is much simpler. Build related things, try different approaches, and let what you learn on one project improve the others.

Give yourself somewhere to try things

A site like NotFakeStore gives me room to play. The project can fail. I can try a strange idea, an unfamiliar plugin, or a feature I wouldn’t have had a reason to explore while doing the usual work on another website.

That freedom matters. If every experiment has to justify itself as a serious business decision, a lot of interesting ideas never get built. With a cheap project, I can follow an idea far enough to find out what it takes to make it work. Even a ridiculous store still raises practical questions about organizing products, presenting information, and getting a page to behave properly.

For example, suppose I want to give imaginary products unusual options. That might send me looking through product fields or variation settings I haven’t used before. While building it, I might find a cleaner way to explain choices on a product page. That approach could be useful on a different store with real products and a much more straightforward purpose.

The imaginary product is an excuse to explore. The knowledge about the tool is something I can keep. I don’t have to make the same joke on every site to use what I learned building it.

Related projects make the learning useful elsewhere

The connection between the projects is important. My websites can cover different subjects while still sharing WordPress, similar plugins, familiar page structures, or the same kinds of publishing tasks. That overlap gives a discovery somewhere else to go.

A better way to organize a long article might help another content-heavy site. A reusable layout might make a second product guide easier to read. A feature I discover while playing with one store might solve a problem I’ve been putting up with on another.

Working on different projects also gives me different reasons to ask questions. One site needs a comparison. Another needs a better way to browse a collection. Another gives me a reason to try something just because it seems fun. If I only build the same page in the same way, I may never run into the feature that makes me think, “Oh hell yeah, I could use that over there.”

In that sense, having several projects puts more feelers out. There are more opportunities to notice a useful tool or pattern. Ten neglected websites can teach me less than one I actually work on. The benefit comes from doing different enough work to discover something, then paying attention to where it might help.

Building gives me something concrete to learn from

Reading documentation and looking at examples are useful. Building gives me a specific reason to do both. Once I’m trying to make a page work, the questions get more concrete: Where does this setting live? What happens on a phone? Does this plugin work with the ones already installed? Can I remove it cleanly if I don’t like it?

A demo can make a feature look perfect. Trying it on an actual project shows me what setting it up involves and what compromises come with it. Maybe it solves the problem. Maybe it adds three new problems. Either way, I have something more useful than a vague impression that the feature looks cool.

This is where the iterative part fits. I build a small version, check it, make an adjustment, and try again. The next project gives me another set of requirements to test the idea against. Sometimes that second use is what shows me which part was genuinely useful and which part only made sense in the first setting.

A useful idea still has to fit the next website

The exciting part is finding something that could help several sites. Once I understand a tool or an approach, I don’t have to rediscover it from scratch every time. The same piece of learning can pay off in more than one place.

But I still need to check the next site. A playful interaction that suits NotFakeStore might distract someone reading a practical guide. Two WordPress sites can have different themes, plugins, content, and audiences. Sharing a platform gives me a head start; it doesn’t make them interchangeable.

So if something works on one site, the next move is a small test on another relevant site. Can I use it to solve a real problem there? Does it still work with that site’s setup? Is the result actually better? If the answer is yes, I can keep it and consider where else it belongs.

Failures need the same attention. If a plugin breaks the test site, I want the mistake contained there. If a problem turns up after I’ve used the same change elsewhere, I need to know which sites have it so I can check them and undo it where necessary. Copying a broken change across every website would multiply the cleanup.

How I’d put this into practice

I’d keep the process small enough that the experiment gets finished:

1. Choose related projects. Start with a couple of projects that share tools or recurring problems. Use one with room for experimentation. An existing test site or staging copy may be enough; buying another domain isn’t a requirement.

2. Pick one thing to find out. “Try more plugins” is too loose. “Can I make these product options easier to understand?” gives the experiment a purpose and gives me something to judge when I’m done.

3. Make it easy to undo. Back up the site and keep a copy of what I’m changing. Change one thing at a time so I can tell what caused the result. For anything that could affect customers, payments, or important data, use a test environment.

4. Write down what happened. Record the tool, relevant settings, what worked, what broke, and any limitations. A short note and a screenshot can save me from trying to reconstruct the whole thing later. Keep track of which sites eventually receive the change, too.

5. Try the useful part on one other project. Choose a site with a real reason to use it. Make a small, reversible change and check the relevant pages and behavior again, including on a phone.

6. Keep it where it helps. Adopt it selectively, adjust it for each site, and leave it out where it doesn’t fit. If the experiment goes nowhere, stop. I can keep the lesson without keeping the feature or the entire project alive.

AI can help me compare approaches, build a first version, or work through an unfamiliar tool. I still have to check what it produces in the actual project. This way of learning works with or without AI.

There’s a limit to how many projects I can give useful attention to. Domains may be cheap, but maintenance and unfinished work still cost time. Starting more websites only helps if I leave myself enough room to build, observe, and bring the lesson back.

What I like about this approach is that it gives the playful work somewhere to go. I can build something because it’s interesting, learn a feature I wouldn’t otherwise have touched, and use that knowledge on a project that needs it. A cheap experiment might fail as a business and still save me time or open up a better way to build the next thing.