Are you a Problem Solver, or Solution Creator?

I’ve been thinking a lot lately about how some people think they are problem solvers, but in reality they are solution creators.

It’s kind of subtle at first glance. They’re the same thing, right? right? In my experience, they’re definitely not.

There’s a world of difference between being a problem solver and being a solution creator. And one of those tends to lead to spinning wheels, wasted money, and a lot of frustration – especially in client work.

Not long ago, a client for my WordPress development agency came to me asking for “WooCommerce optimizations.” That was the phrase they used. They wanted help improving site performance, cleaning things up a bit, maybe making WooCommerce run faster or more efficiently. Totally reasonable request, and I think most people would’ve heard that and gone, “Great, let’s start optimizing WooCommerce.”

But that’s not how I approach things anymore. I’ve learned (honestly, the hard way) that most requests like that are surface-level. They’re symptoms. And if you dive in without slowing down to understand what’s underneath, you often end up doing a lot of work that doesn’t actually help. Or worse—you make the real problem even messier.

So instead of getting straight to work, I asked questions. I looked around. I poked at the edges of what they were saying to see what was really going on.

And what I found was…honestly kind of wild.

They had five separate vendors all touching the same site. One for design, one for development, one for support, one for marketing stuff, and another I couldn’t quite figure out. One key vendor was building custom plugins that were brittle, messy, and hard to maintain. Like, really hard to maintain. Every time something needed to be changed, it was a coin flip whether it would break something else. The whole thing felt like a fragile tower of duct tape and hope.

And, of course, that vendor would charge the client every time it would break, which became very costly, sometimes putting their site out of commission for several hours just from doing something as simple as updating plugins on their website.

So we got on a call with that vendor and started asking questions. Basic stuff about the system they built, just trying to understand the parts. How does the system authenticate, where are the bulk of your customizations, what causes these issues when updating, etc.

Their responses were…concerning. There was always a long pause between each question. The responses were always vague. The kept referring to “the original developer”, and at one point, when asked about a critical security concern, they said, “We’re not doing anything about that.”

That meeting cost the client $3,000.

And the vendor ended it by saying, “Great meeting, everyone!”

I just kind of sat there blinking at my screen. It was not a great meeting.

If I had just taken the original request at face value and started tweaking WooCommerce settings, I might’ve looked productive for a few weeks. I might’ve billed some hours, made some changes, and sent over a few reports. But it wouldn’t have solved anything. In fact, it probably would’ve made things worse, because we would’ve been building “solutions” on a completely unstable foundation. Solving problems that doesn’t actually solve their real problem.

Instead, we pulled back, and had some candid conversations with the client about what we saw. We took the time to explain their problems, and talked through a plan of action on how we could help them actually fix these problems.

The list of problems we suggested to fix had nothing to do with WooCommerce, but by proxy, they did help them make their website work much more reliably, and faster.

It’s just wild how easy it is to fall into “solution mode.” There’s a kind of rush that comes from doing something – especially when someone is paying you to do it. But more and more, I’m learning to slow down. To question the request. To sit with the problem a little longer than feels comfortable.

Because rushing to solve the wrong thing is a great way to waste everyone’s time.

So now, when someone asks for help, I try to make “problem solver” my default state. Not because it’s more noble or something. Just because it works better. I want to build things that last. I want to help people make real progress. And that means I can’t just react – I have to think.

I like to think that people hire me not because I can create solutions, but because I can solve problems. I can consult with the customer, look deep, and understand their real problem. From that, I can help them create a path to actually serving them in a meaningful way.

I’ve realized that, well, it’s freaking hard to correctly articulate a problem sometimes, and there’s a lot of value in spending the time to help a customer understand what they’re asking for in the first place. Sometimes that in itself is out of their reach.

It’s not always glamorous. It doesn’t always look impressive right away. But it gets better results. And it keeps me from spending weeks fixing things that didn’t need fixing in the first place.

There’s a few lessons in this story, I think:

1. If you’re asking someone for help, don’t prescribe a solution (like saying “I need WooCommerce optimizations”) instead, try to articulate the problem (“My website is unreliable”). This prompts your experts to think.
2. Pay attention to when someone prescribes a solution without any context to you, and seek out the context. Think about, and understand the problem deeply.

For example, my nephew messaged me a few days ago, asking for a saw. Now, my nephew has many great qualities, but he isn’t exactly known as a handyman.

Looking at the line of questioning, I opted to ask him for context. “Why do you need a saw?”

To which he explains that he has a couch that is completely water damaged in his basement from a recent flood, and he has no way to get it out without taking it apart.

I do have a saw, but I can tell you with confidence that my circular saw (or really, any saw for that matter) would probably just make a gigantic mess and not really help.

As it turns out, this isn’t my first water logged couch (long story), so I happened to know exactly how to break it apart. Crowbars, hammers, and a utility knife. Those were the right tools for this job.

Now, had I just blindly said “oh yeah I have a saw, sure here you go”, it would have without any doubt made the problem worse. Sawdust would get everywhere, we’d probably hit a nail and damage the blade, it might get caught in the fabric and do something unpredictable. Someone would probably get hurt, and the cutting probably wouldn’t even help break the couch down.

But by asking a follow-up question, I was able to save my nephew (and let’s be honest, myself) a lot of pain.

My customer asked for “WooCommerce optimizations” but what they needed was someone to take ownership of their site, and make it work reliably. That’s a much deeper need that took some effort to work out.

My nephew asked for a saw, but what he needed was assistance getting a couch out of a basement.

Ask questions. Think about the problem. Understand it fully. Even when you think you understand it, ask more questions. You may uncover a deeper problem still. Keep going until you’re confident you have everything you need. More context only makes you more capable of solving a problem.

PHPNomad As A Static Site Generator

Wait a minute…why can’t PHPNomad make PHPNomad’s documentation site?

At Novatorius, our projects increasingly venture beyond WordPress. I recently shared how PHPNomad can function as an MVC framework with some configuration.

I’ve mentioned it a few times on this blog that once I started using PHPNomad, I realized that I want to use it for everything. WordPress plugins, apps, services…why not a static site, too?

After evaluating my initial Docusaurus setup, I realized this was entirely feasible. I just needed to implement a few key components that my MVC framework setup didn’t have yet:

1. Support for routing from directory structures
2. Markdown compilation
3. A local server setup
4. A command to compile static files

With these features in place, PHPNomad was ready to power its own documentation site.

There’s a few things that I particularly love about how this is set up.

1. It does not need Node, or Webpack.
2. The dependency stack is minimal compared to other setups. If you have PHP and Composer installed, you have what you need.
3. It’s dead-simple to set up with GitHub pages
4. Customizing the non-markdown content can use whatever template engine you want, including vanilla PHP if you want. I like Twig, so I used the Twig integration for this.

Now, that doesn’t mean you can’t use Webpack if you need some robust JavaScript or whatever, but for a basic documentation site? Is that really necessary? I don’t think so Instead, I opted to leverage Pico CSS with minor custom styling tweaks. The only JavaScript file is for syntax highlighting via Prism.

The actual script that compiles everything just uses PHPNomad, and is literally just calling a PHP script.The local server is just using PHP’s built-in webserver feature.

Real World Benefits

It’s wild to think about static site generation through the nomadic lens. We’re not just talking about another static site generator here – we’re talking about using the same exact patterns we use for everything else to build documentation.

Think about that for a second. Most documentation solutions are like “Hey, learn our special way of doing things!” But with this approach? If you know PHPNomad, you already know how to build and maintain the docs. The same strategies, the same templating, the same everything – just pointed at markdown files instead of database records.

The best part? I didn’t have to compromise on anything I love about modern documentation sites. I still get the clean URLs, the nice navigation, the markdown processing – all of it. But instead of learning someone else’s system, I’m using the same patterns I use everywhere else. That’s exactly what the nomadic approach is all about.

This means that anyone on my team at Novatorius has a pretty good baseline on how to maintain this repository. So, if there’s a problem, or something needs done to maintain it, I have a much wider range of people who can help. It’s not this awkward codebase that is totally different from what I build in every day, it’s using the same patterns I’m using everywhere else.

It’s a perfect example of what gets me so excited about PHPNomad. Once you have these patterns down, you can just… use them. For anything. Dynamic sites? Check. WordPress integration? Done. Static documentation? Why not! It’s all just PHP doing what PHP does best – getting stuff done.

Looking Forward

I’ve made the repository public, and I’m considering turning a version of it into a GitHub template, similar to the MVC app template.

The ability to develop in a consistent environment, regardless of the final deployment platform, continues to validate PHPNomad’s approach. As I’ve often said, once you get comfortable with PHPNomad, you want to use it everywhere. The consistency in patterns and methodology across different types of projects is invaluable.