Zoye

For a while I avoided saying this out loud: the agent wasn't good enough, and the whole product rested on it.

Everything else we could fix with normal work. Screens, speed, the bugs, all of it responds to effort. But the entire promise was that you tell it what happened and it handles what follows. And in that first period, it handled the sentence I had in my head when I wrote it, and it fell over on the million other ways a real person says the same thing.

It was too literal. Ask for one thing, get exactly that thing, and none of the obvious work around it. It didn't connect the dots that any decent assistant would connect. It would do what you said instead of what you meant, and then it would be pleased with itself.

I even remember the specific moment I stopped defending it - rationalizing why it doesn't understanding me correctly.

We rebuilt how it thinks, more than once. Not tweaks to the wording we gave it. Structural changes to what it's allowed to do, how it checks its own work, how it asks when it's unsure instead of guessing confidently. That work is still going. I don't think it ever really ends.

Question for anyone building with AI right now: how do you decide when it's good enough to put the agent in front of people?

Our grandkids will not believe we had to use multiple tools and solutions to run one small business - and I'd go even further - a growing company.

There was a period where every fix seemed to produce two new problems, and I started to wonder if we'd made something that couldn't be finished.

I'm not going to give you a number. The number isn't the point and I'd probably get it wrong. The point is the feeling. You wake up, you look at the list, you fix the thing at the top with real satisfaction, and by the evening the list is longer than when you started.

What made it worse was that a lot of them weren't classic bugs. Classic bugs are almost restful. Something crashes, you read the error, you fix it. Ours were mostly the other kind: everything technically worked and the result was still wrong. The user asked for one thing and got a defensible, reasonable, completely unhelpful interpretation of it. There's no stack trace for that.

The thing that got us through it was boring, and I'd do it again. We stopped treating them as individual bugs. Every time something went wrong we asked what class of problem it belonged to, and we tried to fix the class. Slower for any single issue. Much faster over a month.

The other thing that helped, honestly, was that the people testing it stayed. They kept sending us the failures. When someone bothers to tell you your product broke, they still want you to fix it. Those are the ones worth keeping.

I wonder, what did you do in the stretch where progress stopped feeling like progress?

The most useful feedback we got early on wasn't about a feature. It was about trust.

We put the rough version in front of a small group of real users. We expected the notes to be about what was missing. Some were. But the ones that actually stung were about something else entirely, and they all rhymed: I'm not sure it did what it said it did.

That's a brutal thing to hear about a product whose entire promise is that it does the work for you. And they were right. The thing would report success in a way that felt confident, and sometimes the underlying action hadn't fully happened, or had happened differently than described. To the user, that's indistinguishable from lying.

We understood something there that shaped everything after. When software just stores your data, a bug is annoying. When software acts on your behalf, a bug is a betrayal. The bar is completely different. If you're going to let something touch your business, it has to be more honest about its own failures than most software ever needs to be.

That's when "never falsely confirm something that didn't happen" stopped being a nice principle and became a rule we build against.

My question to you would be: Has an agent ever told you it did something it hadn't done? What did that cost you?

We have officially become a fully chat based UI - actually almost no UI (It's still there if you need it though). A fully agentic CRM - The one you don't need to open.

Our first working version was held together with hope.

I'm being specific on purpose. Founders online skip from "we had an idea" to "we launched" and quietly leave out the part where the thing barely stands up.

It did work, in the narrow sense. You could talk to it and it would create something. But the edges were everywhere. It would do the right thing and then fail to tell you it had done it. It would understand a sentence perfectly and then fall apart on the same sentence phrased slightly differently.

The temptation at that stage is to keep it hidden until it's respectable. We nearly did. What changed our mind was a simple realization: we were the worst possible testers of our own product. We knew exactly which words to use. We unconsciously avoided every path we knew was broken. We weren't using it, we were performing a demo for ourselves.

So we put it in front of a few real people instead. Not a launch, not a waitlist. A handful of users we could talk to directly, who were willing to use something rough and tell us the truth.

That decision changed the product more than any other thing we did that year.

💬 Question to you: How rough was your first version when you first showed it to someone outside the team?

Every feature I add, I ask myself one question: can the agent do this for you, or are we making you open the tool again?

What would you like the agent to do for you in your daily work?

Our first plan was to hire someone to build it. I'm glad it didn't work.

We talked to developers. Good ones. And every conversation ran into the same wall, which wasn't about skill at all. It was that we couldn't hand over the thing that mattered.

The specification wasn't "build a CRM with these tables". It was a feeling. It was, this should understand what I mean when I say "Dana wants a quote by Thursday" and it should do the four things that follow from that sentence without asking me four questions. Every time I tried to write that down as requirements, it came out as either something too vague to build or something so specific it missed the whole point.

At some point Marcel said what we were both circling. We were about to pay someone to guess at the part only we understood.

So we built it ourselves. Not because we couldn't afford help, and not out of some purity thing about founders writing every line. Because the product was still a question, not a plan, and you can't outsource a question.

The only people who could sit with it long enough were the two people who couldn't stop thinking about it anyway.

This isn't advice. Plenty of great companies hire early and do fine. But when the thing you're making is still a question, the obsession has to come from inside the room.

Question to you, the founders who built the first version yourselves: would you do it that way again?

Before we built anything, Marcel and I spent about two weeks trying to kill the idea.

That sounds dramatic. It wasn't. It was a lot of coffee and a lot of "okay, but why has nobody done this". Because that's the real question with an idea that sounds obvious. If it's that good, and the market is that big, and the tools are right there, then either somebody is already doing it or there's a reason it doesn't work.

So we went looking for the reason. We looked at what the big platforms were shipping. We looked at the chatbot tools, the automation builders, the ones that promise you a workflow canvas. And what we kept finding was that everyone had built something pointed at the customer. Bots that answer your clients. Very few people were building something pointed at the owner.

That was the gap. Not "AI in business software", everyone has that now. Something that works for you, on your side, with permission to actually do the work rather than just answer questions about it.

The honest version is that we didn't find a good reason not to. We found a hard problem, which is different. Hard problems have a reason nobody has solved them yet, and the reason is usually that they're hard.

We decided that was a good enough answer.

➡️ Next: We went looking for a developer to build it. That went badly, and it turned out to be the best thing that happened to us.

💬 Question to you: When you had an idea that seemed obvious, what made you finally start? Or what made you stop?

Hi everyone 👋 ,

I though to share my journey from an idea to building the product I believe is the future and wanted one myself for a long time. I'll try to keep it as a journal series of short stories of my journey and the issues I've encountered along the way.

I'd love to hear your thoughts and get some of your support and feedback.
So here we go 🙃 .

✅ Building Zoye, Part 1 - The Graveyard.

I kept meeting business owners who were paying for software they had already given up on. Not bad software. Real, well-known tools. The pattern was always the same. Week one, everything gets logged and it feels great. Week four, the deals are happening but the notes live in WhatsApp and in someone's head.
Week twelve, somebody asks "is that in the CRM?" and the room goes quiet.
For a long time I thought that was a discipline problem. People just weren't being rigorous enough.

Then I watched it happen to organized, serious people, over and over, and I changed my mind. It's a design problem. Every one of those tools assumes someone will do data entry after every conversation, forever. Nobody does that. Not you, not your best salesperson, not me. We built a whole software category on an assumption that's false about the way people actually work.

That's the thought Marcel and I couldn't let go of. Not "let's build a better CRM". Something closer to: what if you never had to open it at all?

I'm going to tell this whole story here, from that thought to where we are today, one post every couple of days. The good parts and the embarrassing ones.

🔜 2️⃣ Next: the two weeks we spent trying to talk ourselves out of it, and the question that made us start anyway.