← all rambles

Meet Holly Wally

More than a decade somewhere in the overlap between Product, technology, websites, data, operations, and "why the hell are we still doing it this way?" That last category might actually be my specialty.

Hi. I’m Holly.

Or Holly Wally, depending on which corner of the internet you’re on.

I’ve spent more than a decade working somewhere in the overlap between Product, technology, websites, data, operations, and “why the hell are we still doing it this way?”

That last category might actually be my specialty.

My career has never fit particularly neatly into one box.

I’ve managed products.

I’ve managed projects.

I’ve rebuilt websites.

I’ve designed workflows.

I’ve worked with engineers.

I’ve built internal tools.

I’ve connected APIs.

I’ve automated painfully manual processes.

I’ve gotten way too excited about databases.

I’ve spent an unreasonable amount of time thinking about why two systems that absolutely should talk to each other… don’t.

And lately, I’ve been doing a lot of tinkering with AI.

Basically, if there’s a messy problem somewhere between people, process, and technology, I want to poke at it.

I’m a Product Person Who Likes to Open the Hood

I love Product.

But I’ve never been particularly interested in being the Product person who hands engineering a ticket and waits.

I need to know how things work.

Where does the data come from?

What happens after someone clicks the button?

What API is behind this?

Why can’t these systems talk?

Is that actually a technical limitation?

Or has nobody tried it?

Can we automate this?

Can I prototype it?

And, occasionally:

“Can you give me like two hours?”

That’s usually when things get interesting.

I Build Things

This is probably the easiest way to explain me.

I like building things.

Not always from scratch.

Sometimes building means connecting things that already exist.

Sometimes it means replacing an expensive platform with something much more focused.

Sometimes it’s turning content that lived in two separate worlds into a web-first system that can generate the second format with one click.

Sometimes it’s taking a manual process and turning it into automation.

Sometimes it’s rebuilding an entire website in less time than it probably takes some companies to schedule the kickoff meeting.

Sometimes it’s discovering that people are manually copying information from one system into another and thinking:

“Absolutely not.”

I’ve built internal CRM, time-tracking, and commission tools.

I’ve built automation that moves leads between platforms and preserves the information each system needs along the way.

I’ve built workflows that pull data, transform it, and get it to the person who needs it when the “real” process isn’t working.

I’ve built tools that can take API data and populate third-party web portals instead of making humans repeatedly type the same information.

I’ve worked on platforms where a single internal solution could replace roughly $185,000 a year in software licensing.

I’ve rebuilt major web experiences in days and weeks instead of months.

And one of my favorite emergency solutions went from:

“We have a broken process.”

to a working solution in under two hours.

Not because every solution should be built in two hours.

But sometimes the business doesn’t need a six-month roadmap.

Sometimes it needs someone willing to say:

“Hang on. I have an idea.”

My Favorite Problems Are Usually Expensive, Manual, or Weird

If you show me a perfectly functioning process, I’ll probably leave it alone.

Probably.

But tell me:

“Someone does this manually every day.”

Now you have my attention.

Tell me:

“We’re paying six figures for this.”

Interesting.

Tell me:

“These systems don’t integrate.”

Are we sure?

Tell me:

“That’s just how we’ve always done it.”

Oh no.

Now I definitely need to look at it.

I’m naturally drawn to inefficiency because inefficiency usually means there’s a puzzle hiding somewhere.

And I really like puzzles.

I Live Somewhere Between Product and Engineering

I’m not an engineer.

And I’m not trying to cosplay as one.

There are engineers who understand architecture, infrastructure, security, scalability, performance, and software craftsmanship at a depth I don’t pretend to have.

I want those people involved.

What I can do is get dangerously far before they need to be.

I can understand the business problem.

Map the workflow.

Understand the systems.

Work with the data.

Explore the APIs.

Build the interface.

Prototype the logic.

Put something in front of actual users.

Change it six times.

Discover everything we were wrong about.

And get pretty damn close to an MVP.

Then I can hand it to an engineer and say:

“Here’s the 95%. Here’s what works. Here’s what doesn’t. Here’s what everyone actually needs. Please make this not held together by vibes.”

That’s a partnership I really like.

I don’t want engineering spending its most valuable time trying to figure out what we’re supposed to build.

I want them making what we’ve already proven better.

And Then AI Happened

This is where things have gotten really fun.

I came into AI already understanding how technology works.

So I don’t look at AI as magic.

I look at it as leverage.

It’s another tool in the stack.

A ridiculously powerful one.

I can have an idea in the morning and have something clickable that afternoon.

I can explore technologies I haven’t used before.

I can prototype production-like experiences.

I can test integrations.

I can iterate faster.

I can ask better questions because I understand enough about what’s happening underneath to know what I actually want it to do.

And yes.

I vibecode.

I’ll say it proudly.

What I won’t do is vibecode something and then walk into a room like:

“Yes, I painstakingly handcrafted this application myself.”

Ma’am.

We know.

I’m Part of What I Call the Cross-Stack Generation

I think there’s a group of us sitting in a really interesting place in technology right now.

We learned the old way.

We know what it feels like to debug something without asking AI.

We know Stack Overflow.

We know mysterious production errors.

We know what happens underneath the shiny interface.

But we’re also embracing what’s happening now.

AI.

Automation.

Rapid prototyping.

Tools that can turn an idea into something tangible at a speed that would’ve sounded ridiculous a few years ago.

We understand the old stack well enough to take advantage of the new one.

That’s what I call the Cross-Stack Generation.

And I think we’re in a pretty incredible position.

I Don’t Really Care What the Tool Is

I’ve worked across websites, analytics, SEO, CRMs, APIs, databases, healthcare technology, franchise systems, automation, internal software, attribution, RPA, AI, and probably several things I’m forgetting.

But the technology itself isn’t usually what interests me.

The problem does.

Give me a problem and I’ll figure out which tools belong around it.

Sometimes that’s custom software.

Sometimes it’s WordPress.

Sometimes it’s an API.

Sometimes it’s SQL.

Sometimes it’s automation.

Sometimes it’s AI.

Sometimes it’s an embarrassingly simple solution that makes everyone wonder why we’ve been doing something manually for four years.

Those might actually be my favorite.

So, What’s Holly Wally?

I guess that’s what this site is about.

Not tutorials.

Not a resume disguised as a blog.

And definitely not me pretending I have technology completely figured out.

It’s a place for the things I keep thinking about while building products and solving problems.

Why we overcomplicate things.

Why Product should be more technical.

Why prototypes matter.

Why companies sometimes spend thousands solving problems they haven’t tried solving themselves.

What AI is changing.

What AI absolutely isn’t changing.

What makes great engineers valuable.

Why understanding the system still matters even when AI can write the code.

And whatever else I encounter that makes me think:

“There has to be a better way to do this.”

Because that’s probably the most accurate description of how my brain works.

There has to be a better way.

And then I usually go try to build it.

MORE RAMBLES

Got a problem that needs untangling?

Get in touch