I've wanted to build a Shopify app for a long time.

Not because I had some massive business idea.

Not because I thought Shopify apps were easy money.

I simply liked the idea of eventually becoming part of the Shopify ecosystem and building something useful for merchants.

I registered as a Shopify Developer back in July 2025.

At the time I already had other projects running, so the idea stayed in the background. Every few months I would think about it again, browse the Shopify documentation for a while, look at a few apps, and then go back to whatever I was working on.

Nothing happened for almost eight months.

What finally changed

What finally changed wasn't Shopify itself.

It was development.

Over the last few years I've seen software development from different angles. Some projects were relatively small. Others became expensive and complicated very quickly.

One of our existing products accumulated well over six figures in development costs over time. And that's only engineering. It doesn't include infrastructure, support, operations, marketing, accounting, or everything else that comes with running a software product.

Because of that experience, I already understood how difficult product development could become.

So when AI-assisted development tools started improving rapidly, I paid attention.

Not because I believed the headlines.

Not because I thought software engineers would disappear.

Mostly because I wanted to understand what had actually changed.

A lot of people talk about AI in extremes.

Either it's supposedly replacing entire teams or it's completely useless.

My experience ended up somewhere in the middle.

AI didn't remove complexity.

The difficult decisions were still difficult.

Architecture still mattered.

Product decisions still mattered.

Support still mattered.

Understanding the problem still mattered.

What changed was the amount of friction between having an idea and turning that idea into a working system.

That made me curious enough to try building something myself.

The next question was obvious.

What should I build?

Finding the problem

I didn't want to start with a huge project.

I wanted something practical.

Something I understood well.

Something I personally needed.

That last part ended up being the most important.

For years I've relied heavily on Shopify redirects.

They're one of those features that most people don't think about very often, but they become incredibly useful once you start producing content at scale.

If you publish blog articles, documentation, affiliate content, marketing pages, videos, or partner resources, links eventually change.

Products move.

Pages get reorganized.

Campaigns end.

Redirects allow you to update a destination once and keep every existing link working.

The more content you have, the more valuable that becomes.

In my case redirects ended up everywhere:

• Blog posts
• Documentation
• Affiliate campaigns
• YouTube descriptions
• Internal resources

Over time I stopped thinking about redirects as a convenience feature and started thinking about them as infrastructure.

The problem wasn't creating redirects.

The problem wasn't managing redirects.

The problem was visibility.

I had no simple way to understand which redirects were actually receiving clicks.

Some links were probably generating traffic every day.

Others were probably completely forgotten.

Inside Shopify Admin they all looked exactly the same.

That felt like a surprisingly obvious gap.

The idea behind Redira

The more I thought about it, the more I realized I didn't actually want a completely new redirect system.

I liked Shopify's redirect system.

It already worked.

I didn't want to replace it.

I wanted to extend it.

That decision ended up influencing almost every technical choice that followed.

One of the earliest architectural decisions was avoiding root-level redirect paths entirely.

A lot of applications try to take over URL structures directly.

I didn't want to create potential conflicts with storefront routes or introduce complicated behavior that merchants would eventually have to debug.

Instead, every tracked redirect would pass through a dedicated App Proxy route:

/apps/redira/r/{slug}

The URLs weren't as pretty.

I knew that from day one.

But they were predictable.

Reliable.

And fully controlled by the application.

For me, reliability was a much better tradeoff than having a cleaner-looking URL.

Building the first version

The development process itself was also interesting.

Most of the project was built using a combination of:

• Obsidian
• ChatGPT
• Cursor
• Claude

There was no team.

No project manager.

No sprint planning.

No weekly meetings.

Just notes, documentation, experiments, and a lot of iteration.

Looking back, one of the biggest surprises wasn't how quickly features could be built.

It was how quickly questions could be explored.

Instead of spending hours searching through documentation, I could have conversations about architecture, implementation approaches, edge cases, and tradeoffs.

The bottleneck moved.

Less time was spent finding information.

More time was spent deciding what was worth building.

Within roughly a week I had a working application:

• Redirect management
• Click tracking
• Statistics
• Monitoring
• Documentation
• Support tooling
• A public website

Launching Redira

What surprised me most is that the development itself wasn't the slow part.

The Shopify review process took significantly longer than the actual build.

I submitted Redira for review on March 19, 2026.

On May 1, 2026 it was approved and became publicly available.

Looking back, Redira is not the biggest product I've worked on.

But it's one of the most interesting.

It started as a simple problem I wanted to solve for myself.

It became my first Shopify app.

And it became a practical experiment in understanding what modern software development looks like when AI becomes part of the workflow.

Today I still use the app myself.

That might be the strongest validation of the original idea.

The problem still exists.

And Redira still solves it.