Building Three Products with AI Changed How I Build

Why I Wanted to Build This Product

Every day, I generate a huge amount of browsing history, emails, documents, links, and scattered thoughts, but it is difficult to turn this information into knowledge that I can actually continue using.

After working on several AI projects, I noticed a very obvious pattern: the more complete the context you give AI, the better the final result usually becomes.

That gave me an idea: build an AI-driven program that collects information scattered across different places, understands, categorises, and organises it, and finally generates structured reports automatically.

[[Image: Concept illustration or overall architecture diagram of the personal information organising AI app]]

Let’s Build It

The first step was to make sure the AI could find enough information.

I first tried building a program that recorded what I did on my computer, including the web pages and PDFs I had viewed, as well as articles and sentences I had copied. After that, I connected email, because email often contains very important confirmation information, such as orders, tickets, and booking records.

Years of design experience have taught me that, at this stage, the most important thing is not to keep adding features, but to test as quickly as possible whether the idea actually has value.

So my first test question was very simple:

Generate a travel report for my trip to Milan.

The result was quite good. The AI found most of the ticket information and organised a rough itinerary, but it was not complete.

What Was the Problem?

I realised that AI’s ability to explore outward is actually quite limited.

If you ask it to search directly, it usually only looks for information that is directly related to the keywords. It rarely actively thinks about what other information might be involved in a trip. This greatly limits the final result.

First Adjustment: Explore First, Then Search

So I adjusted the process for the first time: when creating a new report, instead of searching immediately, the AI should first expand and break down the question, then search separately based on those directions.

The result did improve, but I quickly realised that this was still not enough.

Even if AI explores the problem in advance, it can still essentially become: generate more keywords first, then search those keywords.

The second adjustment was when I really felt the result had changed.

Second Adjustment: Not Searching, but Reconstructing What Actually Happened

I stopped thinking of the task as:

search("Milan Lugano")

Instead, I redefined it as a higher-level problem:

“Reconstruct what actually happened during this trip from scattered information and evidence.”

The difference may look small, but it changed the entire way the Agent worked.

For example, it first discovered an email:

Airbnb · Lugano · Jul 2–4

Previously, this might simply have been treated as a search result.

But now, it treated this piece of information as an anchor.

Once there was an anchor, new questions naturally appeared:

Every time a new piece of evidence was discovered, the direction of the next search changed.

Eventually, it gradually reconstructed the entire trip:

London → Stansted → Malpensa → Milan → Chiasso → Lugano → Milan → Gatwick → London

The second version of the travel report was already very close to what had actually happened.

It found my July 1 train ticket from London Liverpool Street to Stansted Airport, as well as the Malpensa Airport → Milan Central ticket after I arrived in Italy.

Then, from an Airbnb email, it discovered that I had made a last-minute booking in Lugano for July 2–4. Based on Trenord emails, it then found the Milano Centrale → Chiasso train ticket.

There was one missing piece of information during the return journey: it could not find a clear Lugano → Milan return ticket.

However, on July 5, it discovered that I had purchased a ticket to Triennale Milano, and that evening there was also a Deliveroo order delivered to an address in Milan.

So it could reasonably infer that: after leaving Lugano on July 4, I had already returned to Milan.

Finally, on July 7, it found a Gatwick Airport → London Bridge train ticket, which made the timeline of the whole trip almost complete.

[[Image: Timeline of the second Milan / Lugano travel report]]

There was another very important change here: the AI began distinguishing between “facts” and “inferences.”

For example:

Airbnb confirmation can prove that a booking was made, so it is strong evidence.

Airbnb welcome + review does not just show that it was booked, but provides further evidence that the stay actually happened.

Deliveroo Milano · Jul 5 is also a very strong location signal, suggesting that I was most likely in Milan that day. The fact that the AI made this inference by itself was quite surprising.

I was extremely satisfied with this change, and it significantly increased my confidence.

From “Trying to Do Everything” to Deliberately Narrowing the Product

One of the biggest temptations of AI is that implementing features becomes too easy.

After building a reasonably good MVP, I started constantly adding things to it.

For example, I wanted to predict what users might want to do next based on their browsing behaviour, so I built a Chrome extension to collect browsing information and clicks, then used open-source components to filter and understand web content.

The result was not very good.

There were several reasons:

I Gradually Realised Several Problems

AI Still Needs Human Judgment

If you want AI to provide genuinely valuable information, you usually need to give it a framework first, something similar to a skill, a set of rules, or a workflow.

You cannot simply drop AI into an empty space and expect it to know what it should do.

At least for now, people still need to tell it: what is worth paying attention to, which directions it should think from, and what kind of result should be considered valuable.

This may also be one of the important differences between AI and humans at the moment — perhaps one day it will be able to make these judgments itself.

How Do You Control an Idea That Keeps Expanding?

The product itself went through a similar process.

At the beginning, I wanted to do almost everything. But gradually, I realised that a product this broad, even with the help of AI, was far beyond what one person could realistically build well.

So I started narrowing it deliberately.

For now, I have decided to focus first on organising travel information: including future travel summaries and suggestions, task boards, booking organisation, and email follow-up.

This is still not a small scope, but at least it allows me to control the quality of the information and output, so that the AI can genuinely help users make decisions instead of simply generating more content.

[[Image: Product roadmap showing the shift from “trying to do everything” to focusing on travel organisation]]

AI Made Me Truly Understand What “Building a Product” Means for the First Time

In the past, I worked mainly as a Product Designer: understanding problems, designing experiences, building systems, and then working with Product and Engineering teams to bring them to life.

But this time, there were almost no clear role boundaries.

Product, Design, Engineering, Research, QA, and even part of Project Management were all mixed into the same loop.

AI certainly made many things faster, but its bigger impact was that it allowed us to reach the genuinely difficult problems much sooner.

The technology stack was one of the things I discussed most with AI:

Should I use Electron or build natively? Should I develop something myself or directly use mature open-source components? Which things are worth building from scratch, and which ones are simply reinventing the wheel?

At the same time, I also had to constantly suppress AI’s overconfidence, because it often underestimated the difficulty of real development and the large number of problems hidden in the details.

Eventually, my workflow gradually became:

AI proposes an approach → check the documentation → inspect real projects → build a prototype → validate the risks → then decide whether to develop it

For example, on macOS, I went from building my own AI Agent, to experimenting with integrating Pi, an AI Agent project, and later embedding OpenCode. I basically went through all the different technical approaches and their associated problems.

Through this process, I gradually realised that what really matters is not whether “AI can write it,” but whether the task boundaries are clear enough and whether the chosen technical approach has already been validated.

The Boundaries of Technology Are Also the Boundaries of Reality

Once the initial functionality started taking shape, I began thinking about how to make more people genuinely willing to use it.

The current design requires Full Disk Access on macOS, which naturally raises security and privacy concerns.

Even if all data processing happens locally and only the cleaned, necessary information is sent to AI, an unknown application asking for such a high level of system permission is still difficult for users to trust.

I tried applying for Google Auth and Outlook Auth, hoping to solve this through more transparent authorisation methods, but the formal approval processes on both sides were more complicated than I expected.

The testing stage can support around 100 users, but if I want to expand beyond that, I need to complete additional reviews and verification.

At one point, this was extremely frustrating.

Later, I started looking at the problem from another angle: perhaps I do not need to take responsibility for all of the AI capabilities and account authorisation myself.

If some of these capabilities could live inside ecosystems that GPT or Claude have already established, while my product only handled local information processing, organisation, and presentation, the entire problem might become much simpler.

[[Image: Privacy protection diagram showing local processing + transparent authorisation]]

The Designer’s Advantage

Since I started coding with AI, I have opened Figma noticeably less often.

But this has actually made me feel even more strongly that knowing how to use Figma — or more accurately, having a designer’s way of thinking visually — is still a very obvious advantage.

The advantage of a designer is being able to “see” what the finished product will look like earlier than others, and therefore identify potential problems sooner.

Humans are visual creatures, after all. Visuals remain one of the most direct ways to understand complex things.

My working loop has now become:

Idea → AI → Real interface → Modification

This loop is extremely fast, but it also quickly exposed another problem: design lost a stable Source of Truth.

I can see the page directly inside the real application, but it is difficult to freely adjust the entire interface in the same way I can in Figma.

If I go back to Figma to make changes, I then need to synchronise those changes back into the code.

At the same time, the global view of the product also begins to disappear.

It is very easy to get trapped inside individual pages and features, while the overall structure and logic of the product gradually becomes less clear.

To solve this problem, I started building an auxiliary tool:

A tool that allows a product with no traditional design files, and which is primarily written by AI, to still have a visual editing experience similar to a design tool, while shortening the synchronisation path between the application and the design as much as possible.

This is UI Sync — the name is temporary.

As I continued building it, I found myself liking this way of working more and more.

So this small tool, which originally existed only to make it easier for me to develop the main product, may eventually become an independent product of its own.

The first product I built was a dashboard for managing a personal stock portfolio. I called it Catfolio.

The idea came from a very practical problem.

I have several investment accounts and buy and sell stocks at different times. Working out my real cost basis, investment returns, and the performance of the portfolio as a whole was painfully tedious by hand.

At the same time, I was learning about quantitative investing. I wanted a platform of my own where I could test different algorithms, indicators, and strategies instead of being limited to the fixed features of existing tools.

So I decided to build one myself.

At the start of the project, I made a fairly radical decision: no Figma and no traditional product design or development process. AI would build the entire product directly.

Claude Code designed the interface, and AI wrote almost all of the code. I used a design system to manage components and styles, then kept asking AI to add more features.

At first, it felt fantastic.

An idea could become a working feature almost as soon as I described it. Work that might once have taken a designer and engineer several days could now appear in a few hours.

But once the product reached a certain scale, problems began to appear.

There were more features, more charts, and increasingly complex relationships between pages. AI could complete each task in front of it, but it rarely asked whether a feature should exist at all or how it related to the product as a whole.

The product kept growing, but gradually lost its clear centre.

The code also became difficult to manage. Changing one feature affected other pages. New bugs appeared constantly, and fixing one problem with AI could create several more. The larger the project became, the slower AI coding felt.

The same thing happened visually.

Even with a design system, the product still had a strong “AI-made” quality. The components were consistent and the spacing was mostly correct, but the interface lacked real hierarchy, rhythm, and careful judgment.

A design system can keep a product consistent, but it cannot give it taste.

To address these problems, I stopped adding features and returned to the product itself.

I removed most of the charts and kept only the core views that genuinely helped me understand the portfolio. I reworked the information architecture, reset feature priorities, and reorganised the page hierarchy.

Visually, I redesigned the main interfaces by hand, revisiting typography, spacing, information density, and interaction details to remove as much of that templated AI feeling as possible.

I am now gradually bringing back some of the better ideas, but adding them through clearer rules and a more maintainable structure instead of simply piling them into the product.

As tools get faster, an unclear product direction becomes more dangerous. By the time you notice the problem, AI may already have travelled a long way in the wrong direction.

The second product is Catfill.

Catfill is a Chrome extension for filling in forms. Users can let it learn their personal details or import information manually. When they encounter a form, one click fills most of the fields on the page.

But it has one very important boundary:

Catfill fills the form. It never submits it.

Whether it is a job application, registration, or another important form, the final review and submission always remain with the user.

It reduces repetitive work without making important decisions on someone’s behalf.

Compared with Catfolio, Catfill is very simple and very clear. It is not an all-purpose platform. It solves one specific problem: helping people complete repetitive forms faster.

This time, I changed how I used AI.

Before writing any code, I researched the technical details: what a browser extension could read, how different form controls should be recognised, and which actions might introduce risk.

I then designed the complete product flow, defined the feature boundaries and edge cases, and handed AI a set of relatively well-specified implementation tasks.

This time, I clearly felt that I had the steering wheel again.

AI was no longer deciding what the product should be. It was helping me implement a solution I had already thought through.

Because the scope was clear, the code was easier to maintain. When something went wrong, I could identify the source instead of asking AI to keep trying inside an increasingly complex system.

I also drew several illustrations for Catfill. I wanted it to be useful, but also to have a personality of its own.

In the end, the product actually launched.

I even began experimenting with promotion. Marketing and commercialisation are still things I need to learn, but Catfill gave me my first complete journey from idea and design through development, testing, and release.

Catfill taught me that AI is best at executing a clearly bounded, logically defined problem rather than a vague and expansive vision.

Before coding with AI, the most important task may not be writing a better prompt. It may be answering a few more fundamental questions:

AI becomes genuinely efficient only when these answers are clear.

The third product is MOMO.

The vision for MOMO was bigger than either of the first two products.

I wanted it to collect and understand many kinds of personal information, including browsing history, email, notes, photos, calendars, tasks, and meeting records, while running entirely on the user’s device.

None of this information leaves the device. In the future, I may also use the Foundation Models framework in macOS 27 so that information understanding and AI analysis remain local as well. For MOMO, privacy is not a feature to add later. It is a fundamental design constraint.

When needed, MOMO could organise relevant material, present it clearly and beautifully, and suggest what to do next based on the information already available.

If someone were planning a trip, for example, MOMO could know which flights and hotels were booked, which car-rental companies had only been browsed, and which activities were still undecided.

It would not merely store information. It would try to understand the relationships between pieces of information.

This time, I applied what Catfolio had taught me.

I designed the interface by hand before asking AI to implement it. Before development began, I also spent a long time discussing technical approaches with AI and investigating mature open-source components so I would not rebuild things unnecessarily.

I deliberately chose a mature, AI-friendly technology stack to reduce the chance of errors in obscure frameworks or complex environments.

The front end uses Electron. Because Electron includes browser capabilities, I hoped to use them directly when working with web pages and browsing behaviour rather than relying entirely on an external browser.

Early progress was very smooth.

MOMO could record user actions and the pages visited in Chrome.

But a more fundamental problem quickly appeared:

It knew what the user had visited, but not what the user had actually seen.

At first, the system mainly received page titles and links.

A page title and URL are nowhere near enough to tell AI what actually matters on the page. It cannot know whether the user cares about a price, date, location, product specification, or a particular paragraph.

This made me realise that the ceiling of an AI product often depends less on how intelligent the model is than on the quality of the data you give it.

If the input is only a messy browsing history, the model can do little more than guess from limited evidence.

AI has a chance to generate something valuable only if the system can extract page content, structure, prices, dates, and the parts the user truly cares about, then clean them into usable context.

So I began adding content extraction and preprocessing components to clean the information the system had collected.

Some human input was still necessary.

Through behaviour or explicit actions, users need to tell the system what matters. A page may contain a huge amount of information, while only a small part of it is relevant to the task at hand.

The more accurately the web content is cleaned, the more useful the final report becomes.

As the technical problem became clearer, I encountered another, more familiar one.

Once again, I had imagined the product on too large a scale.

I wanted MOMO to manage every kind of personal information and work automatically in every context: travel, research, shopping, job hunting, meetings, scheduling, and personal knowledge management.

It seemed able to do everything.

Seen another way, that meant it had no sufficiently clear starting point.

I felt less like I was building a product and more like I was attempting to build a new personal operating system. That was far beyond what either I or today’s AI could realistically deliver.

It was the same mistake I had made with Catfolio: imagining a platform that covered every scenario before making even one scenario work properly.

Once I recognised this, I removed most of the features and created a smaller product branch.

This version does one thing: it creates a complete travel report from information the user has browsed, received, and saved.

It retains the underlying collection and analysis capabilities, but limits the output to travel planning.

First, it needs to answer a few concrete questions accurately:

Only when the travel report can be produced reliably, accurately, and completely will I consider adapting the system to research, shopping, or other contexts.

This time, I stopped asking what it might eventually do and started with the one thing it must do well now.