I can't write code… but I built a company that (mostly) runs itself.

01 · The itch

Why I built a thing for myself first

I'm a points-and-miles person. Not casually, I'm deep in that world, with friends I've made through it I go on a trip with every year. So this started the way most of my favorite projects do: I was annoyed at myself.

I'd noticed something. Sometimes an auction that runs on points (say, a single Marriott point) lets you land an exclusive experience or an amazing event, like a concert, at three, four, even five-times-plus the value that same point would get you if you spent it on a hotel room. Genuinely great deals. And I kept missing them, because checking nine different sites with nine different layouts is a part-time job nobody signed up for. I missed one. Then a second. Then a third.

The information was all public. It was just scattered and easy to sleep through. I wanted one place that watched everything and told me when something good showed up.

Here's the part that matters: I had the idea and the domain expertise years before I had any way to build the thing. That gap, knowing exactly what should exist and being unable to make it, is the most familiar feeling in the world to a lot of smart people. It's the feeling this whole piece is about closing.

02 · The reframe

The job I actually do (it isn't typing)

The obvious question: if you can't code, what exactly did you do?

I did the part I was already good at, and AI did the part I never learned. Think of it like building a house, and I should know a little about that, because my family is in construction and interior design. I've picked up a few things over the years (windows are shockingly expensive to install; a twice-a-year HVAC check is worth its weight in gold), and the design side rubbed off too: growing up around how a space gets planned and laid out shapes how I think about the architecture and flow of what I build. I still can't pour concrete or wire a panel, though. What I can do is be the architect and the building inspector: I decide what we're making and why, I describe how it should behave, and I check, relentlessly, whether what got built actually does what I asked. The AI is the crew that knows how to hold the tools.

That division of labor turned out to be eerily close to my actual profession. A big part of my consulting work is figuring out what great performance in a role really looks like: interviewing people about how they work, then assessing whether they can do the job in a realistic, contextually relevant setting. Directing an AI agent is the same muscle. You describe the goal, you watch what it produces, you catch the moment it confidently did the wrong thing, and you say "no, like this."

And here's the part I love: correct an AI agent once ("do it this way instead") and it does it that way every time after. Tell a person once and you still have to follow up; get the instruction right once with an agent and it sticks. A little time invested up front, making sure the thing actually works, pays off forever. That happens to play to a strength of mine: I think pragmatically, and I'm good at writing clear SOPs and instructions, which is exactly what makes delegating to an agent feel natural. And if that isn't your strength? You iterate. You go back and forth until it does precisely what you want.

The other thing I lean on is behavioral analysis. I've run thousands of assessment-center exercises: watching, in detail, how a person actually shows up against what a role demands. I read an AI the same way. If one model isn't cutting it on a task, I notice quickly, and I switch to another. Play to people's strengths; play to each model's strengths.

Managing a tireless, brilliant, occasionally over-confident assistant is, in the end, a management problem, and I'd had thirteen years of reps at it before I ever opened a coding tool.

I couldn't read the code, so I got ruthless about the one thing I could judge: behavior. If I haven't watched it actually work, it isn't done.

That rule is the only reason a non-coder can be trusted to ship anything at all. A real email landing in a real inbox. My payment processor actually accepting a test card, so I know the checkout behaves exactly as expected. A bad price caught before a human ever sees it. And to be straight with you: it was frustrating about as often as it was magical. Anyone who tells you building this way is easy is selling something. It's possible, which is a far more interesting word.

03 · A guided tour of the hard parts

The robots that never sleep

Start with the hardest part: getting the data.

Picture hiring an assistant whose entire job is to visit 19 travel websites every hour, copy every new auction into one tidy notebook, and never get bored, never take a day off, never miss one. That's a scraper. That notebook is the listings grid you see on the site.

The catch is that those 19 programs don't speak the same language. Marriott's site is built one way, Delta's another, and behind the scenes I count more than a dozen completely different underlying systems. A reader that handles one perfectly is useless on the next: it's like grocery shopping in nineteen unfamiliar stores, where the milk is somewhere in every one but the aisle is different every time. So this isn't one robot; it's a small fleet of AI agents, each taught the quirks of its particular source, all reporting into the same notebook.

Then the part I still find a little wild: the software doesn't just copy a listing, it reads it. A raw scrape is a mess: half-formatted text with no structure. AI turns that into something useful: it works out whether a listing is a hotel stay or a concert or a Grand Prix, where in the world it physically is, and roughly what it's worth in points. The clean, sortable card a visitor sees was assembled, start to finish, without a human touching it.

Learning to be a polite guest

These are public pages (the same listings any member could browse), but a program that checks them constantly needs to be a considerate guest. Visit a site too fast or too often and you stop looking like a person and start looking like a nuisance, so a lot of big sites will, reasonably, ask you to slow down. Early on I was refreshing several programs at once, and a few of them, fairly, told my server to take a break, which paused the updates for everyone.

The fix was simple courtesy. The more sensitive sources now get visited one at a time, gently, at a human pace, well inside what they expect. It's a little slower. It's also just the right way to behave. A surprising amount of this project was teaching my software good manners.

Which price is the real price?

When an auction closes, the last bid you happened to see isn't always the price it actually sold for. Publish the wrong one and you've told people something false about what a deal is worth, and the whole value of this site is trust in its numbers. So I taught it to keep the two apart and only ever show the figure it can stand behind. Nobody will notice that work. That's the point: the invisible correctness is the product.

An auction used to just vanish

For the first month or two, when an auction ended it simply disappeared. Then it occurred to me I was throwing away something valuable, so I had the site start recording the real final price of every closed auction. Then I gave those closed auctions a home, a quiet corner where you can see what similar experiences actually sold for, which is exactly the context you want before you bid. And once I had months of that data, I started turning it into blog posts: what a point is really worth at auction, which programs deliver, when the deals actually happen. None of it was planned up front. It grew one obvious step at a time, which is how almost everything here got built.

Logins, security, and a control room I over-built on purpose

People log in to save favorites and get alerts, which makes me responsible for their accounts. So I went passwordless. Instead of asking you to invent and then forget yet another password, the site emails you a one-time link, a door key that works once and then expires. Fewer passwords for you to lose, and nothing for me to store and accidentally leak.

Behind the public site there's an admin control room, and I'll admit I over-built it on purpose. I have no patience for chores, and I refuse to let this become a second job, so if running it involved a repetitive task, I had the AI build me a button for it. The weekly newsletter is the clearest example. One click and the system reads what's live, then offers me a few possible themes for the week. That step matters more than it sounds: if there's a big sporting event coming up, those listings will otherwise swallow the entire email. So I pick a theme or two; it gathers the auctions that fit, tosses in a couple of wildcards for interest, and drafts the copy around them. Then I go in and make it sound like me. It's always easier to react to a draft than to face a blank page. Curate, don't compose. If I wanted a piece of functionality, I built it. That was the whole luxury.

1 / 4

Email and a blog that run themselves

The thing I'm proudest of isn't any single feature. It's that the whole machine mostly runs without me.

I did not want this to become a part-time job on top of my actual one. So the design goal from the start was: automate everything that can be automated, and make the rest a one-click chore. Scrapers run on their own schedules. Auctions close themselves when their timers run out. When something breaks, the system tries to recover on its own and pings me if it can't.

The email pipeline is a good example of building under a real constraint. I send through a service with a generous free tier and a hard daily ceiling, and I had no interest in paying for email to prove a hobby works, so the newsletter is engineered to fan out in careful batches that stay under that ceiling. A genuine engineering constraint, solved, for $0.

The blog is the part that makes people do a double-take: it half-writes itself. The system looks at the real searches that bring people to the site and drafts posts aimed at the questions they're actually asking. Those posts pull in new visitors from search, who discover the auctions. I review and publish; the AI handles the blank page. It even helped shape the marketing plan, though the part that actually matters is the part no AI can do: the real relationships I've built in the points community over years. AI can draft the post. It can't be the person people already trust.

Could it ever pay for itself?

For the first few months, the site was completely free, and I paid for all of it myself: hosting, the AI, the data feeds, every bit. A labor of love. Eventually I got curious whether it could at least cover its own costs, so I added subscriptions. I'm under no illusions: this is a niche tool for a niche audience I happen to know deeply, and the realistic best case is that it breaks even. That's fine. It was never the point.

Adding payments did teach me a useful discipline, though. I think about real money like a stage production: there's a dress rehearsal that looks exactly like the real show but has no audience and no consequences, and there's opening night. I built and tested the entire checkout in rehearsal mode, with test cards, until I'd watched it behave correctly, and real money only ever moved once I was sure. I also didn't build the payment machinery myself; that runs through a company that does nothing but payments, far better than I ever could. Knowing what not to build is its own skill.

The site I actually wanted to use

One theme runs through the whole project: I built the site I would want to use, which mostly meant removing the little indignities the web has trained us to accept.

I hate fumbling for passwords, so logging in is one click. I'm offended by services that make it easy to subscribe and a maze to cancel, so cancelling here is genuinely two clicks and done. No dark patterns, no "are you sure you want to leave us." And ordinary search drove me up the wall, because it usually only matches exactly what you typed; one typo and you get nothing. So the search here is forgiving: it finds what you meant, not just what you spelled.

None of these are hard, technically. They're choices. And the reason I could make all of them is that the cost of "I wish it worked like this" dropped to almost nothing. When building the better version is cheap, you stop tolerating the worse one. That shift, from complaining about software to fixing it, might be the most underrated thing about this whole way of working.

04 · The credibility engine

What broke, and what it taught me

If everything in a build story works, the person is lying or didn't build much. Two failures taught me more than any of the wins.

The pattern is always the same: I expected one thing, reality delivered another, and the fix wasn't to try harder. It was to change the system so the failure couldn't recur. That's not a coding skill. That's judgment, and it's the part of this that's most portable to everything else I do.

05 · How I work

A phone, a sandbox, and an assistant named Hermes

People assume something this involved demands a desk, two monitors, and long uninterrupted days. Most of it got built in hour-long bursts at my laptop, and when I'm out running errands or at the gym, I can pick it straight back up from my phone by remoting into the machine at home. A spare twenty minutes became real progress. The project fit into my life instead of demanding I clear space for it.

Hermes is the one I'm a little smug about. It's an open-source agent I run on my own machine, in a sealed-off sandbox, on a model that stays local, so it can safely touch private things like my email without any of it leaving home. I talk to it like a person, over iMessage. I can message "how's traffic looking this week?" and it goes and pulls the full picture (every visit, every page viewed, how people actually moved through the site), analyzes it, and reports back. And every morning it sends a briefing: overnight signups, anything left in the contact form, and whether any scraper needs a human. A chief of staff for a one-person company, for essentially nothing.

The honest summary of my workflow: I spend my time deciding and checking, and almost none of it typing. Which, again, is the job I already had.

06 · What it means

The wall just came down

I went in expecting to learn whether a non-coder could build something real. I came out with a bigger takeaway, and it's the reason I lead with my profession instead of burying it.

For my entire career, "I know exactly what we should build" and "I can build it" lived on opposite sides of a wall. You either learned to code, or you handed your idea to someone who could, and watched it come back a little wrong. Not because anyone did a bad job, but because the two of you were holding different mental models of how the thing should behave. Digital teams generally don't speak I/O; I/O teams generally don't speak digital; something always got lost in translation. That wall is the one that just came down. The scarce skill was never the typing. It was knowing what's worth building, judging whether it's right, and refusing to ship things that don't work. AI is genuinely bad at all three. People are good at them. That's why I keep calling this a talent multiplier rather than a replacement. It took the leverage that used to belong only to engineers and handed a version of it to anyone with clear thinking and a real problem.

I find that thrilling, frankly. I've wanted to make things like this for twenty years and never had the means. Now the bottleneck is my own clarity and taste, a wonderful problem to have, because those I can work on.

And it isn't really about me. The product manager who knows exactly what her team needs. The operations lead drowning in a spreadsheet that should be a tool. The consultant who can see the better process but can't build it. Every one of them is now a clear idea and some patience away from building the thing themselves. Most don't know it yet. That gap, between what's now possible and what people believe is possible, is the most interesting place to be standing right now.