I Built the Thing I Hated Doing

I needed to get a proposal to HoustoNanny, a Houston nanny placement agency.

The PDF I made was beautiful. It looked great. And I sat there looking at it knowing exactly what came next, because I have done this a hundred times before.

The next client would need a different one. So would the one after that. And every time, I would open the last proposal, strip out the old name, swap in new scope, new pricing, new everything, and pray I caught all the places the last client’s name was still hiding.

I could not do it again.

Not because of HoustoNanny. Because of everyone before them.

It started at NTL

The first time it broke me was at Network Test Labs.

Small team. Pile of proposals to get out. And the amount of work it took to assemble one by cutting and pasting and re-pasting the same data into a slightly different shape was insane.

I remember thinking, out loud, there has to be a better solution than this.

I asked the team. Nobody had heard of anything. So I went and did the research myself and found Proposify, PandaDoc, a few others. I picked Proposify. It was great. It was a real upgrade.

Then I went to CMD. Then to Mirai Security. And I watched the same thing happen at every single one.

The tool was never the fix

Here is what took me three companies to actually see.

At Mirai, the team eventually moved off Proposify and onto PandaDoc. Good tool. Polished. Optimized.

And people were still sitting there editing every proposal by hand inside it.

That was the thing that finally clicked for me. The software didn’t kill the grind. It just gave the grind a nicer interface. You still opened a thing, you still hunted through it, you still hand-edited the same repeatable pieces over and over, you just did it in a prettier box.

The tools were built before AI could do the boring part. So they automated the layout and left the work.

The math nobody runs

A proposal “only” takes a day.

That is the trap. Each individual one is just annoying enough to grind through and not quite painful enough to stop and fix at the root. So you pay the tax forever. A day here, a day there, for years, across every company you ever work at.

I have lived the full bill on that. I know what a day of cut-and-paste feels like, and I know how many of them add up to over a career.

So when the HoustoNanny proposal landed in front of me, I made a different call.

I was building Wired Builder from scratch. Clean slate. And I decided this company was not going to inherit the one thing I hated most about the last three.

I wasn’t going to write another proposal by hand. I was going to build the machine that writes them.

What I actually built

Sixteen hours. About two days.

In that time, with Claude Code, I built a real proposal platform. It is live right now at proposals.wiredbuilder.com, and the Houston nanny agency was the first proposal I ran through it.

It is the PandaDoc experience, built for one.

You can poke at it yourself. Here’s a live sample proposal, the same machine running for a made-up landscaping company. Scroll to the bottom and you’ll hit the part that matters.

Here is what happens. I author a proposal in an editor. It goes out as a private link to the client’s email. They open it, and it is gated to them. They read it, they pick an optional monthly plan or they don’t, they agree to the terms, and they accept and pay. Right there in the browser. Stripe takes a one-time launch deposit and quietly saves the card, so when the project goes live I press one button and it charges the balance and starts the monthly plan.

Underneath that:

• Astro running on Cloudflare Workers.
• Supabase for the database and the login.
• Stripe doing the real money work, deposit plus the off-session go-live charge plus subscriptions.
• PostHog telling me which sections the client actually read.
• Sixty-three commits, fourteen pull requests, forty-three passing tests.

That is not a weekend toy. That is a working product, and it took the same sixteen hours that used to buy me one or two proposals back at NTL.

That is the whole point. The exact time that used to produce a single throwaway document now produced the factory.

The part that makes it repeatable

The trick is that a proposal isn’t a document anymore. It’s a set of variables.

Look at the deck I made for HoustoNanny. There’s an opportunity section. A strengths grid. The gap. A pricing breakdown, the Launch struck from four thousand dollars down to an early-partner rate. Three monthly tiers. A terms list.

Every one of those is a shape I will use again on the next client. The words change. The shape doesn’t.

So in my system a proposal is just a few pieces. A hero. A list of sections. A call to action. Each section is a type. Some are narrative. Some are cards. Some are pricing. Some are the optional monthly tiers.

The HoustoNanny deck didn’t get rewritten into the platform. It got poured into it. Prose became a narrative section. The strengths grid became cards. The plans became tiers. The same shapes, filled with different variables.

The content lives in the database, separate from the machine that renders it. I can change a live proposal and it updates with no redeploy.

So the boring middle, the part my brain has always refused to do, is gone. I don’t rebuild the structure every time. I fill in the variables and the thing assembles itself, looking exactly as good as that PDF did, except now the client can actually accept and pay from inside it.

My goal with the sixteen hours was simple. Get any future proposal out in under a day, consistently, repeatably, with no major edits.

That goal is met.

Copyable, but not exactly

Here is where it gets interesting to me, and where I want to take it next.

Because of how it’s built, the engine and the content are two different things. The templates and the variable structure are the machine. Your actual proposals live in your own database.

Which means the machine is forkable, and your work is not.

Someone could take this and stand up their own version, plug in their own variables, their own pricing, their own voice, and run their own proposal factory. But they could never copy my proposals, because those aren’t in the machine. They’re in my database.

Copyable, but not exactly copyable. That’s not a slogan. That’s literally the architecture.

So I want to turn this into something other builders can use. Not a SaaS I babysit. The machine itself, with the variables exposed, for the people who are right now where I was at NTL, asking out loud if there is a better way to do this and getting told no.

There is. I built it.

A confession about this post

Here’s something I want to put on the table.

Inside that HoustoNanny proposal there’s a slide called The Trade. The deal is simple. I give them an early-partner rate I won’t be able to offer once this service is established. In return, if the work earns it, they refer me, and I get to feature the work as a case study.

This post is that clause being cashed in.

I’m not going to pretend otherwise. The same instinct that built the machine also wrote the right to tell you about it into the contract. That’s how my brain works. The story was always going to be part of the build.

I’d rather say that out loud than have you find it on slide ten.

Builder’s Note

I don’t have the ending yet. The HoustoNanny proposal is live, but I’m telling you about the build, not a win. Whether it closes is still an open page, and I’d rather be honest about that than sell you a result I don’t have.

But I already got the thing I was actually after, which was never one signed deal. It was never doing the cut-and-paste again.

So here’s my real question for you.

What’s the thing you keep grinding through by hand because each individual time “only takes a day”? The report. The onboarding email. The same five steps every new client drags you through. The thing you’ve done so many times you could do it in your sleep, and that’s exactly the problem.

What would it cost you to stop and build the machine once, instead of paying the tax forever?

I’d love to hear what yours is. I finally killed mine.