One Month In: Three Things I Got Wrong in Week One

The first version of EventBrief was not the version that launched. The version I built in March was more ambitious, more complicated, and it nearly didn't ship at all. By the time June rolled around, I'd scrapped most of it and rebuilt the core idea three times smaller. This is the story of why.

The AI Agent That Cost More Than It Was Worth

My first instinct was to build an autonomous agent. Something that would wake up every morning, go read fifteen publications, make sense of what happened, and send me a summary without any human input. Fully automated. Smart. The kind of thing that sounds impressive at a dinner party.

I built it. It worked. It also cost me £40 in API credits in the first week.

The problem was not the concept. It was that I'd overengineered the execution. The agent was doing too much. It was calling the API multiple times per article to classify, summarise, and rank them. It was running secondary checks to make sure the rankings were correct. It was generating context it didn't need to generate. Every refinement added another API call. Every API call was money I did not have to spend.

I spent more time debugging why the costs were spiralling than I would have spent just reading the articles myself. And I realised something obvious in hindsight: I did not need an agent that made autonomous decisions. I needed something that read fifteen sources every morning, worked out what actually mattered, and told me in five points. That was it. Simple. Linear. A fraction of the cost.

The version that launched does exactly that. One API call per article. Done. The automation is there, but the ambition is honest.

What it taught me: complexity costs money. Not just in engineering time, but in API calls, infrastructure, and the headspace you spend debugging things that did not need to exist. The best solution is usually the one that does one thing well, not the one that does everything.

If I'd shipped the agent version, EventBrief would have folded by July.

The Overengineering Mistake — Building Features Nobody Asked For

Once I scrapped the agent, I decided the platform needed to be incredible. Saved articles, a personalized feed with topic filtering, an archive search, user preferences, email unsubscribe management, reading streaks, a stats dashboard. I was going to ship all of it in week one.

I built maybe 60% of it before I stopped and asked myself: who is going to use this? Nobody. Because there was nobody to use it yet.

I had thirty email subscribers — if that. The idea that they needed a stats dashboard or reading streaks was fantasy. They needed the five-point briefing and nothing else. Everything else was me building the product I wanted to build, not the product people needed.

The real damage was not the wasted code. It was the delay. Every day I spent building a reading streak counter was a day I was not talking to subscribers, not learning what actually mattered to them, not shipping something people could use.

I cut the scope by 80%. Kept the briefing, the platform login, and the article feed. Shipped that. Everything else came after.

What it taught me: your first instinct about what a product needs is usually wrong. You think in features. Users think in problems. The gap between those two things is where most startups waste time. Build the minimum thing that solves the core problem. Everything else is a distraction until you have real feedback.

The Scope Creep That Almost Happened

By week two, I was getting emails from early users. Not complaints — genuine questions about features. Can I filter by topic? Can I save articles? Can I see what I've read vs what I haven't? Can I get the briefing on Slack?

Each question felt like a feature I should build immediately. Each one felt urgent. I started drafting specs for a Slack integration. I was planning an iOS app. I was thinking about a browser extension.

Then I stopped and did the math. I had thirty users. Thirty. Even if all thirty wanted a Slack integration, that was not thirty thousand users needing one. The effort to build it was not worth the impact.

I wrote back to those early users with a simple message: thanks for the request, I'll note it, but right now I'm focused on making the core briefing work perfectly. That was true. It still is.

The requests did not stop. But I got better at saying no. No to browser extensions. No to Slack bots. No to iOS apps. Yes to the things that mattered — the email redesign, the streak counter, the archive. Things that directly improved the core experience.

What it taught me: every feature request feels urgent when you have a small audience who cares about your product. But saying yes to everything means you finish nothing well. The best founders are not the ones who build the most features. They are the ones who know what to build and what to defer.

What I'd Tell Myself on Day One

If I could go back to the morning I started building EventBrief, I would tell myself three things.

First: the simplest version is almost always the right version. Not because simplicity is elegant, but because it lets you ship, get feedback, and iterate. Complexity just delays everything.

Second: you do not know what your users need. You have guesses. Build the thing that tests your guesses the fastest. Everything else is noise.

Third: saying no is harder than saying yes, and it matters more. The ideas you do not build are often more important than the ideas you do.

The funny thing is, I knew all of this intellectually before I started. Knowledge and practice are not the same thing. I had to actually build the wrong thing, waste money on API calls I did not need, and cut 80% of my planned features to understand what it meant. That is how you learn.

A month in, EventBrief is smaller and simpler than I imagined it would be. It is also real. It works. Thirty people are reading it every morning. That matters more than any of the features I didn't build.