From Building an App to Building a Product, in 260 Days

Today, after 260 days of building, breaking, rebuilding, and quietly losing my mind on weekends, I am shipping Azynote v1.0.0.

That sentence is the easy part. The interesting part is everything that happened in between, and almost none of it has to do with the app itself.

Let me try to write that down before the launch dust settles.

It started out of pure curiosity

Honestly, this whole thing began as an experiment.

I wanted to know how far you could actually go, as a developer, building with AI. Not the demos. Not the keynote version. The real thing. What is easy. What breaks. What is annoying. What feels like magic the first time, then like quicksand the second.

So I started poking. Small experiments. Side projects nobody would ever see. Things that did one thing, often badly, and taught me a lot.

And then something flipped.

Around the time one of those prototypes actually started to work, I noticed the gap between "I have an idea" and "I have something I can use tomorrow morning" had collapsed. Things that used to take a weekend took an evening. Things that used to take a quarter took a weekend. You could feel it in real time, on your own laptop, with your own coffee.

Curiosity turned into excitement. Excitement turned into a quiet, slightly competitive challenge to myself: instead of stacking up cute experiments, what if I picked one of my own problems and went after it for real?

The problems I had in mind were not exotic. They were the kind of friction every meeting-heavy job in tech generates. The same friction I had watched dozens of people around me deal with for years.

At that point, the natural continuation of the experiment was no longer to keep building for myself. It was to put something in other people's hands.

So I picked meetings.

Why meetings: four hats, eight calls, one brain

If you sit in meetings for a living, you already know what I am about to describe. But let me try to name it precisely, because the language matters.

Sit in any meeting and count the hats you are wearing in real time.

You are answering the questions coming at you. You are asking the ones you actually came in for. You are listening for the signal nobody is saying out loud. And you are typing notes fast enough that tomorrow-you can make sense of any of this. Your brain is doing four jobs at once, and only one of them is the reason you joined the call.

Now multiply that by four or five meetings in a day. Or six. Or eight.

By 4pm, my brain has hit the spinning beach ball stage. Everything still works, technically. It just takes a beat longer for every thought to load. And I am smiling on camera pretending it is fine 😅.

I used to walk out of meetings in one of two states. Either I had notes that looked complete, but I knew I had stayed at the surface and missed the deeper signal. Or I had read the room perfectly, caught every nuance, and my notes looked like a toddler's grocery list: three words, two question marks, zero context.

That is the part that bothered me the most.

It means the quality of what you capture from a meeting is correlated with where it sits in your day, not with how important the meeting actually was. The board update at 5pm gets worse coverage than the standup at 9. That is a tax I did not want to keep paying, and I doubt I am the only one paying it.

If AI is good at anything, it should be good at taking that load off. Capture should not depend on how tired you are. The summary, the action items, the follow up email should not depend on whether your last coffee was three hours ago.

That became the brief for Azynote: silent capture during the meeting, no bot popping into your Zoom or Teams call, your voice never leaving the machine, and the meeting outputs (summary, follow up email, action list) one click away instead of twenty minutes away.

Not a chatbot. Closer to a colleague who happened to attend every meeting, and remembers all of it.

What 260 days of building with AI actually taught me

Look. I did not just build an app with AI. I built an app while learning what it is like to develop on top of AI as the substrate. Those are not the same thing.

A few honest observations.

The advantages are real. Prototyping cycles compress from days to hours. The first version of almost any feature can exist before the coffee is cold. Transcription, summarization, structured extraction: genuinely solved. There is real leverage here.

The limits are also real. AI is great in the middle of a problem and bad at the edges. It produces a confident first draft and a sloppy last 10%. Determinism is gone. Anything that used to be a guarantee becomes a probability, which means you have to design for graceful failure everywhere, not just at the corners.

The friction is the part nobody warns you about. Latency budgets. Cost ceilings. Prompt versioning. Models drifting under you. Evaluations that are not really evaluations. Decisions about what to run locally, what to call out to, and what should never leave the user's machine. None of this shows up in a demo. All of it shows up the day you ship.

If you only build toys, you can ignore most of these. If you want to ship something a stranger pays for, you cannot.

And here is the trap nobody talks about loudly enough: when code comes fast, ideas come fast too. Every feature feels one prompt away. Chat? Why not. Smart editor? Sure. Auto-generated customer cards merging every past meeting? Let's try. My first prototype was a neat espresso machine: one button, one shot, perfect. Two weeks later it had grown into a full industrial coffee plant, pipes and buttons everywhere 😅.

The culprit was not the AI. It was me. I let curiosity drive implementation without enough filtering. Speed makes it harder to see which ideas actually deserve to exist.

So I gave myself a brutal little rule:

Every time I think of a new feature, I ask: how often will I actually use this? If I can't answer in one second, it's not for now.

It sounds simple. It is. It also kills most of the ideas I get excited about, and that is exactly the point.

App versus product (the lesson I did not see coming)

Here is the thing I would tell anyone starting out today, the lesson that took me 260 days to fully metabolize:

Building an app is easy now. It has never been easier. With the current tools, a competent person can put together something that works, looks reasonable, and demos well in a single weekend.

Building a product is a completely different exercise.

A product is not the app. The app is one artifact inside a much bigger thing.

A product starts with identifying a real problem precisely enough that you can commit to it. Not "engagement", not "users come back", but a specific pain, in a specific person's week, real enough to drive you back to your desk after a bad day. The app is what falls out of that commitment, not the other way around.

Then there is everything around it, and "everything around it" turned out to be most of the work:

• Naming, positioning, and a brand that does not sound like every other AI tool launched this quarter
• Documentation that meets people where they are, not where I am
• A voice that stays consistent across the website, the app, the changelog, and the cold message I send to a beta tester at 11pm
• Marketing assets, video, content
• Actually finding the first humans willing to try the thing and tell me where it hurts
• Onboarding that does not assume the user already shares my mental model

None of this is glamorous. All of it is the actual job.

And here is the part I want to be transparent about: those 260 days were not 260 full days of work. Azynote was nights, weekends, mornings before the day job, the occasional vacation day. Most of that time was not even spent in an IDE. It was spent figuring out what kind of product I was actually building, and for whom.

That is the real lesson. The code is the cheap part now. The product is the hard part.

What v1.0.0 is, and what comes next

Azynote v1.0.0 is opinionated on purpose.

It runs on macOS at launch because shipping one platform well beats half-shipping two. It is local-first where it counts: transcription happens on your laptop in real time, so the audio of your meetings never leaves your machine. When you need them, one click turns the transcript into a summary, an action list, a follow up email, and more. Gemini is the model provider today; opening Azynote to others is on the short-term roadmap.

One product. One thing. One kind of person: meeting-heavy professionals who want their attention back.

The promise has not changed since day one: the real payoff is not time, it is presence.

There is a lot I still want to build. Next on the list: multi-provider model support, speaker diarization, and deeper agentic workflows. Stay tuned.

If you are a Mac user who collects meetings, and you recognized yourself in any of the above, do not hesitate to give Azynote a try.

The first 14 days are free, no charge 🙂 : azynote.com