What I Learned from Launching Peak Pals V1

In February 2024, I came across the idea of a “Peak Performance Partner” while reading The Compound Effect by Darren Hardy. The setup is simple: meet with a partner for 30 minutes every week, talk through the past week’s wins, failures, struggles, and realizations, ask for feedback, and hold each other accountable.

I immediately reached out to a friend who cared just as much about personal growth. He said yes, and that started a weekly ritual that lasted for more than a year.

Every Monday at 9 p.m., our phones rang. We rarely missed a week. We treated the call like a mission briefing.

Over that year, we went through a few small wins, a huge number of failures, countless problems, and many realizations that were hard to quantify. We grew in our careers, business thinking, and relationships. More importantly, we lived with more intention than we had in previous years.

The Problem

As we kept doing these calls, one problem became hard to ignore:

I needed a tool built around this exact workflow.

Over the years, I had developed my own second-brain system:

• Heptabase for yearly, monthly, macro planning
• Trello for day-to-day task management
• A Moleskine notebook for the ritual of writing and reflection
• Notion for collecting loose thoughts and organizing files

Each tool worked well on its own. But every Monday before 9 p.m., preparing for the call became a mess.

I would check Heptabase to review the week’s goals, search Trello for completed tasks, flip through my Moleskine for important realizations, and finally pull everything together in Notion. By the time the call started, I had already spent too much energy jumping between four tools.

That defeated the whole point of having a second brain, which was to reduce cognitive load.

The Peak Performance Partner system had helped me a lot. If one tool could make the process simpler, it might help other people who believed in the same idea too. I decided to scratch my own itch and build Peak Pals.

Designing Peak Pals

Before designing the product, I tried to understand why the partner system worked so well for us.

I found two main reasons.

First, it encouraged us to live each day with more intention. Writing a daily journal made me ask, “Did I move toward this week’s goal today?” If the answer was no, that was fine. The question still gave me a chance to pause and reflect.

Second, it combined the carrot and the stick. Completing a weekly goal gave me a sense of progress and made me want to take on the next one. Knowing that another person would see whether I had followed through created social pressure. I did not want to show up every Monday with nothing to say.

Once I understood those two parts, the first version of Peak Pals became clear. I wanted to keep the ritual of a notebook and the clarity of weekly goals, then add asynchronous accountability so people would not need to wait for a weekly call to support each other.

After finishing the initial product requirements, I started building. Four months later, Peak Pals was online. I made plenty of mistakes during those months, but I also made a few decisions that worked well.

What I Did Well

1. Setting Up Production CI/CD Early

I chose Render for the infrastructure instead of managing my own VPS.

It cost more each month, but it saved a huge amount of time. I did not need to spend my limited energy on DevOps and could focus on shipping the frontend and backend. As a solo developer, my time was better spent creating value for users than maintaining servers.

2. Writing a Focused PRD and Small User Stories

I spent a lot of time turning the product requirements into clear GitHub issues. Each issue was small enough to finish in about 30 minutes.

This had two effects I had not expected.

Finishing an issue gave me a quick sense of progress, which helped build a positive feedback loop. It also kept the project moving on days when I was tired after work. Even if I did not have the energy for a large feature, I could still fix one bug or make one small improvement.

A lot of the time, the problem is not a lack of willpower. The brain simply cannot see a clear path between the goal and its current position. Once I had planned the work and written down the details, I could move through the issues almost on autopilot.

Perfect is the enemy of good.

3. Inviting Beta Users Early

This was probably the best decision I made during development.

Seeing the product help real people felt better than anything else in the process. When a beta user found a UX problem or suggested an improvement, I wanted to fix it immediately. It was partly a sense of responsibility, but the stronger feeling was simply, “I want to help you.”

Because I had full ownership of the product, that connection and sense of achievement motivated me more than any external reward.

Special thanks to my beta users: Eishin, Jeff, Samara, Circle, JC, and my mom.

4. Working with a Designer

I invited a designer friend to join the project. Her second perspective was valuable.

As an engineer, I tended to start with technical feasibility. She started with how the user would feel. By putting those perspectives together, we found a balance that let us ship quickly without giving up basic usability and visual quality.

All four decisions helped me maintain momentum. The question behind each one was the same: what will make the product better and get it into users’ hands sooner?

What I Could Have Done Better

Technical and Architectural Regrets

On the frontend, I did not plan the foundation carefully enough.

My full-time work is mostly in large B2B codebases. When I switched back to building a consumer product, I overlooked many basic concerns: internationalization, notifications, mobile responsive design, dark mode, navigation, landing-page SEO, and loading skeletons.

Some of these should have been in place from the beginning. Adding them later requires much more refactoring. They are early architectural decisions whose cost grows as the product gets larger.

The backend was a different story. My full-stack experience is roughly 80 percent frontend and 20 percent backend, so Peak Pals was also a chance to practice. I still had a lot to learn about authentication flows, high-level abstractions, user model orchestration, and Redis caching.

I would not call those decisions mistakes. I simply had not gone deep enough yet. Since Peak Pals was a side project, I treated that gap as an investment in learning instead of expecting a perfect implementation.

1. I Did Not Design Mobile First

Peak Pals is a daily app. Most users write their journal entries on their phones, but I built the desktop version first and treated mobile as something to add later.

I had assumed that reflection and deep work belonged on desktop. That assumption came from my own habits, not from user behavior.

Most users still expect a mobile-first experience. Many problems in the flow only became visible when I used the app on an actual phone. If I started again, I would design mobile and desktop together, beginning with the mobile flow. It also would have forced me to think more clearly about which components should work across devices.

2. I Ignored SEO

At the beginning, I thought of Peak Pals as a hobby project, so I did not take SEO seriously.

That was a poor fit for the product. Peak Pals depends on people searching for ideas like peak performance partners, goal-tracking tools, accountability systems, and online journals.

I should have chosen Next.js and built the foundation for programmatic SEO from the start instead of using a pure single-page application. That early decision now makes it much harder to acquire users through search.

3. I Had No Business Model

This was my biggest mistake.

I never planned to charge for Peak Pals. I even imagined keeping it free forever. My reasoning was simple: helping people already felt valuable, and I did not think the product was worth charging for.

Later, I realized that giving the product away for free limited what I could build.
I could not afford to spend much on LLM tokens, so I had no practical way to add the AI features I had imagined for helping users reflect. I also could not justify the development cost of advanced features for heavy users.

The maintenance cost was only around $20 per month for four services and a domain. Even so, that ceiling shaped every decision. Revenue would have given me a reason and the resources to invest more deeply in the product.

Charging is about more than making money. A sustainable business model lets a developer keep improving the product. By refusing to charge, I was also giving myself permission to keep Peak Pals at the hobby-project level. That may have reduced the value it could create for users in the long run.

Architecture and business decisions both deserve attention early. I read Indie Hackers every week and still managed to make all the classic beginner mistakes.

What Comes Next

At the time of writing, Peak Pals has more than ten daily active users. That is a small number, but it still makes me happy. (07/2026 updates: now DAU at 50+)

There are many product questions I have not solved:

1. Peak Pals is NOT a social network. I want it to record and encourage the authentic process instead of becoming another stage for displaying polished outcomes.
2. It should still be useful when someone uses it alone. The Pals feature should improve the experience, but it should not be required.
3. I want to preserve active human reflection while using automation and AI to reduce the effort. I have not found the right balance.
4. The hierarchy of year, week, and day feels clear. I am still unsure whether month belongs in the system.
5. The onboarding and retention experience both need more work.

Working through these questions and bringing Peak Pals closer to the product I have in mind will be the next part of the journey.

I recently saw a product called 750 Words featured on Indie Hackers. It is similar to Peak Pals in some ways, and after 17 years of iteration it has reached $26,000 in monthly recurring revenue. I deeply respect what its creators have built.

It reminded me that even a small idea can build a good long-tail business if it finds the right people.

It also exposed the other side of the problem. A good product is only the baseline. People have to discover it.

The technical mistakes and architectural decisions I made can all be fixed. But if nobody knows Peak Pals exists, none of those fixes matter. My next step is not limited to improving the product. I also need to learn how to help the right people find it.

That may be harder than optimizing the code.

If the idea resonates with you, check out Peak Pals and let’s grow together.

Notes from the Week

The pace at my full-time job finally returned to something sustainable.

The previous stretch of rushed development and constant disorder only improved after several difficult conversations with my teammates. There was a lot of frustration behind that change, but now I can focus on the work I am good at without being drained by small interruptions and office politics. That rhythm gives me a sense of achievement without exhausting me.

On Friday, I finished my management work as quickly as I could and used my lunch break to visit MOA with my cousin. We handled a few new airsoft guns and caught up on each other’s lives. It also brought back memories of following him around as a kid while he played survival games with groups of grown men.

Over the weekend, E and I watched *Kokuho*, which was a 10 out of 10 for me. I strongly recommend seeing it without watching the trailer first.

Before the film, we sat in a café for a while. I worked on the structure of this article and continued reading Sanmao’s *Stories of the Sahara*. I once told a friend from a writing class that when I still have the patience to enjoy literature, it means my life is under control. My sense of beauty only seems to work when I am in that state.

This week, I was.