A Founder’s Note

Why I built Loupely

I want to tell you why I built this.

A few months ago I built a yarn marketplace. I’d recently picked up knitting, the way I pick up most things, all at once, and I’d noticed that the marketplaces that already existed were genuinely bad. I called the project FMX. I didn’t expect it to become a business. I wanted to see what I could build now that the distance between an idea and working software had collapsed for someone like me.

What I built, over 3 weeks, was 4 interconnected WordPress plugins. A core engine for product listings and inventory. A demand engine that captured buyer interest and matched it to sellers. An analytics layer. A coaching layer that helped sellers improve their listings. The whole thing worked. It never had a single buyer or seller, and I never opened it to the public. But it worked.

It worked, and building it nearly broke me. Not because the building was hard. Because I could not see.

What “hard” actually meant

I want to be specific, because the hard part is the part that gets glossed over.

I would build a feature. Everything on the screen looked finished. There were no error messages, no red text, nothing that announced a problem. And then 3 days later I’d discover that something deep inside it had never worked at all. Inventory I thought I’d saved wasn’t saving. Fields that existed in the database couldn’t be typed into from the screen. A button that said delete the selected items deleted everything, not just the selected items.

The save button looked fine. Nothing saved.

The only way to find out was to test every scenario I could think of, watch what happened, and hunt for the moments where reality didn’t match what the interface was telling me. I spent more time finding bugs than building features. And the bugs were never where I expected. They were 3 layers deeper than the thing I was clicking on. The error message blamed one thing. The real cause was somewhere else entirely.

This is what it feels like to run software you can’t see inside. You’re the only person who can tell something is wrong, and you have no instrument that shows you what. You’re flying blind, and every gauge in front of you insists everything is fine.

The part I don’t usually say out loud

There were nights I cried at my desk. Not because the work was too hard. Because I could not see what was happening, and I couldn’t tell whether I was making progress or making it worse. I’d spend hours on something, watch it appear to work, and have no way to verify whether that was true except to test it myself and hope I happened to test the right thing.

If you’ve never felt this, it’s hard to explain how lonely it is. Everyone tells you that you can build now. Nobody tells you that building something and being able to operate it are 2 very different things, and that the gap between them is where you’ll spend most of your hours, alone, at 3 in the morning, trying to prove that a button did what it said it did.

I’d spent a lot of my life feeling capable and unseen at the same time. This was that feeling again, in a new form. I knew I was not stupid. I knew the work was not beyond me. The system was simply not observable, and I’d started to quietly absorb the blame for that anyway.

Building my way out

About halfway through FMX, I stopped trying to think harder and started building instruments.

When I couldn’t trust what the screen was telling me, I built diagnostic views that let me see for myself. Logs organized into tabs. Plain explanations of what each piece was actually doing. Blocks I could copy out and hand to someone, or something, to get help with a specific failure. I had no idea this was a real practice with its own name. I just needed to see what was happening, so I built tools that let me see.

When I made too many changes at once and broke things I couldn’t recover from, I built a habit of naming stable versions to roll back to. Rollback checkpoints before risky stages. I had no idea that was a real practice either. I just needed to survive my own mistakes without losing the whole project.

I built about a dozen of these over those 3 weeks. Each one came from a specific moment of pressure where I needed something that didn’t exist. Later I learned that most of them were rough translations of practices that professional engineering teams have been refining for decades, with books and conferences and whole companies built around them. I’d never heard of any of it. I derived working versions on my own, from scratch, because I needed them to get through the night.

Here’s the thing that took me a while to understand. I didn’t invent these ideas. But I also wasn’t handed them. They came out of need, not coursework. And the versions I built worked precisely because they were built for my actual situation, which isn’t the situation a professional team operates in. The right instrument for a non-technical operator looks different from the right instrument for an engineer. I would know. I built one because the other did not fit.

What I’m building now

Loupely is the instrument I needed and didn’t have, rebuilt as something anyone can install.

It’s a Chrome extension and a WordPress plugin that work together. When something on your site stops working, the checkout that won’t process, the form that won’t send, the login that suddenly fails, Loupely captures the evidence from both the browser and the server at the same time. Then it tells you, in real human terms, what broke, where it came from, and what to do about it. 2 sentences before anything downloads. Not a wall of logs. A diagnosis.

The reason both sides matter is the reason I lost so many hours. What you see on the screen is the front end. The cause almost always lives somewhere you can’t see: the server logs, the error output, the order of operations behind the page. Loupely reads both together and finds the relationship between them, which is invisible when you only look at one side. That relationship was the thing I spent 4 days chasing, over and over, without knowing where to look.

And then it doesn’t stop at the diagnosis. Every diagnosis comes with a triage, the specific next step. Sometimes that’s a setting to change, named exactly, the precise screen and field. Sometimes it’s a conflict you can resolve yourself. And when it does need a developer, Loupely hands you a complete evidence file and a ready-to-send message that contains everything they need to write the fix on the first try. No more paying for the back-and-forth. No more developer guessing from a screenshot. The question they always ask is already answered before they open the file.

And when something looks wrong, not broken

There’s a second kind of failure I learned to dread. Not broken in a way that produces an error. Just wrong. The button is the wrong color. The section refuses to center no matter what you change in your page builder. 2 elements sit on top of each other. The layout that was perfect on desktop is a stack of rubble on mobile. You can see it. Everyone who visits your site can see it. And you cannot fix it.

So I built Loupely Lens for that. You click on the thing that looks wrong, the way you’d point at it if someone were sitting next to you, and Lens reads the entire CSS picture behind it. The rule that won, the rules that lost, where each one came from, the parent elements above it that are quietly constraining everything. Then it tells you why, in plain language, and gives you the same kind of triage: a setting, a safe override you can paste in yourself, or a clean handoff for whoever fixes it.

Lens works on any site you can open in Chrome. Not just WordPress. Shopify, Webflow, Squarespace, anything. Because the browser already knows exactly why your page looks the way it does. It generated that answer the moment the page loaded. It’s just never spoken a language you were taught to read. Lens translates it.

Two tools. One account. Loupely is for when something stopped working. Lens is for when something looks wrong. You can have both problems on the same site on the same morning. I usually did.

Who I built this for

Not developers. Developers can already read the cascade and the stack trace. They do not need a translator.

I built it for the person who manages a website and can’t read CSS or PHP fluently and has had the kind of week where nothing makes sense and every tool keeps insisting everything is fine. The business owner whose checkout went down on a Tuesday with no warning. The freelancer managing a dozen client sites who loses an afternoon to a single misbehaving rule. The merchant who’s opened the browser inspector once, seen the wall of text, understood that the answer was somewhere in there, and had absolutely nowhere to go with it.

These are capable people who’ve been failed by their tools. Not beginners who need to be educated. The information that would resolve their problem has been sitting in the browser and the server the whole time. Nobody translated it for them. That’s the only thing standing between them and the fix, and it’s the thing Loupely removes.

How it is priced

Plainly, because I hate how most software does this. Both tools are free to install and free to capture. The full evidence file always costs nothing, which means even on the free tier you can hand a complete picture to a developer or paste it into whatever you use for help. The diagnosis, the part that reads the evidence and tells you what it means, is the paid layer.

You can buy diagnoses as credits, $19 for 10 or $29 for 20, and they never expire. Or you can go unlimited for a year: $99 for Loupely, $49 for Lens on its own, $129 for both together, $349 for agencies running unlimited client sites. One credit pool covers both tools. No subscription you have to remember to cancel. No countdown timers. The price is the price, and a single hour of a developer you didn’t have to hire pays for it many times over.

Why this one

This is the most like me that any work I’ve done has ever been. The part where I sit with a problem long enough to find the actual shape of it. The part where I take something invisible and make it possible to see. I’ve been doing that in smaller ways for most of my life, often without anyone noticing, sometimes without noticing it myself.

If you manage a site and you’ve stared at something broken or something wrong for days, certain you were missing something obvious, certain it was somehow your fault, Loupely is for you. You were not missing anything. You just could not see. I built the thing that lets you.

I built it for the version of me that did not have it.