I'm the product for now

Here's an uncomfortable thing for a software founder to admit: right now, part of the product is me.

Not the code — me, personally, sitting with a real business owner, doing by hand the parts Dustav can't do yet, learning the shape of their inbox by working it myself. I'm calling that the plan, not the failure. Let me explain why, because it took me a while to be comfortable with it too.

The walls I kept hitting

Every self-serve path to a stranger had a wall in front of it, and I tried to engineer around each one.

A shop owner isn't going to sign up for an AI developer console and paste in an API key — that's a prosumer move, and my customer runs a sewing shop, not a server. Reading a real Gmail inbox at scale trips a restricted-data threshold that gates any public launch behind a security assessment that costs money and weeks. And even the friendly version — "just describe your email in a sentence and Dustav writes the rule" — still assumes somebody sits down, alone, and does it, and gets it right, and comes back tomorrow.

Each wall was real. Each one I kept trying to lower or route around in code. And I kept not quite getting there.

A human in the loop dissolves them

Then I noticed something almost embarrassing: put me in the loop, and every one of those walls just isn't there.

I set up the key. I connect the inbox — one operator, under the test-user cap, no public-launch gate to clear. I sit down with the owner and we author the first email skills together, on their actual receipts, until the tables fill correctly. The walls were only walls for a stranger provisioning themselves at eleven at night with no one to ask. For a design partner with me attached, they evaporate.

That reframed the whole go-to-market. The thing I'd been treating as "the stuff I have to automate before I can sell" was actually the sale.

It's not a detour, it's the on-ramp

The fear, of course, is the consulting trap: you start doing services to fund the product, and five years later you're a services shop that never shipped a product. I've watched it happen to people. So I want to be clear about why this is different.

Every operator I work with is a paying design partner building the product on their real inbox. Dustav-as-a-service — me plus the software, a real monthly number — isn't a distraction from the moat, it is the moat: knowing your specific business, sold as a relationship instead of a signup. And it's the same lesson this project keeps beating into me, one level up: target user beats a-priori thesis. I built a beautiful companion nobody voted for. I'm not going to build a beautiful self-serve product nobody asked for either. I'm going to validate it with people who pay me, on their real problems, before I ever try to launch it to a crowd.

The discipline that beats the trap

There's exactly one rule that keeps this from becoming a consulting company, and I hold it hard: every manual thing I do for a client is a backlog item.

I start a hundred percent in the loop. And Dustav's entire job — the only thing I'm building it to do — is to let me step out of the loop, one task at a time. The number I watch isn't revenue. It's how much of the work I've handed back to the software. Today I set up the key by hand; the day that's a self-serve flow, I've handed one task back. Today I sit with the owner to author their first workflows; the day Dustav can propose them from reading their sent mail, I've handed back another.

When I've handed back all of it, I'll have a product — and I'll have discovered exactly what it needed to be by being it first, and getting paid to take notes.

The one-sentence version

I'm the product for now on purpose, because the fastest way to learn what Dustav has to become is to be Dustav for a while — sitting across the table from the person drowning in email, doing the job by hand until the software can take it from me.