Choosing Purpose Over Imitation — The Week Haru Space Became a Messenger

This post looks back on Haru Space’s first week using Git history and design documents from July 1–5, 2026. I wrote it about seven weeks later.

The first Haru Space screen looked almost nothing like Haru Space today.

It began with something close to a portfolio page. Next came a small PoC inspired by the operating structure of an online community. I could build screens with rooms, members, and administrators. Yet the more screens I added, the clearer a more important question became.

The question was not what we could build, but what we were building it to protect.

The biggest change that first week was not a new button or a flashy feature. It was the decision to stop making Haru Space resemble a reference product and choose a purpose of its own.

The decision to learn without copying

Looking at an existing service can help a project start quickly. Familiar interfaces and operating flows offer clues about the problems people repeatedly encounter. But there is more distance between learning from something and copying it than I first thought.

The structure we studied included login, membership approval, multiple rooms, administrator tools, and real-time conversation. What we needed was not that service’s code, imagery, or private data. We needed the sequence of actions people actually depend on when running a small community.

I decided to reinterpret that sequence around Haru Space’s purpose.

• A space where approved members can enter with confidence, rather than one designed to gather as many strangers as possible
• A space where people who speak different languages can stay in the same conversation, rather than one designed to maximize message consumption
• A space where people can check the original message when needed, rather than seeing only a translation
• A space where an administrator approves membership and the system records who approved whom, so each approval leaves an accountable trail

That decision gave the product a single sentence.

Haru Space is a private group messenger that helps people we care about stay close despite differences in language.

Once that sentence existed, feature priorities changed. I could judge which journey must remain unbroken first, rather than which feature looked most impressive.

A complete journey, not a mockup

The standard for the first MVP was simple. Instead of displaying several screens, it had to let one person complete a real journey from beginning to end.

A person requests membership. An administrator reviews the request. Once approved, the person signs in and enters a room in the group. They leave a message. The recipient first sees it translated into their own language and can open the original when needed.

That sounds short on paper, but the journey contained nearly every foundational product problem: authentication state, administrator and member permissions, room access, message storage, translation failure, screen updates, mobile input, and production data. If any one of them broke, the person could not reach the destination.

So during the first week, I focused on connecting that path instead of adding more menus. We separated the room list from the chat screen and gave announcements, media, and administration their own responsibilities. We also added a health endpoint so we could tell whether the deployed server was alive.

At the time, these changes felt like minor technical housekeeping. Looking back, they formed the first skeleton that could survive as the service grew. Separating screens helped us narrow failures by feature. A health check let us replace the vague statement “the site is down” with a more useful question: how much of it is still working?

Keeping the conversation moving when AI fails

Translation is important to Haru Space, but it cannot be more important than the conversation itself.

That was also the part of the early design I treated most carefully. A translation provider can be slow or fail to respond, and a development environment may not yet have its external API key connected. If message delivery fails with translation, AI stops being helpful and becomes a single point of failure that blocks conversation.

We therefore chose to store the original message in its own field and place the translation beside it. The system first tried OpenAI and then used Azure as a fallback. If neither service was available or the required keys were absent, it stored a fallback value containing a “translation pending” label and the original message, so message creation did not fail. We did not choose an approach that saved only the translation and discarded the source message.

I have returned to that principle repeatedly while designing later AI features for Haru Space.

AI should not be the only key that makes a core action possible. It should be a collaborator that helps people perform that action better.

When adding AI, it is easy to ask only, “What does it do when it succeeds?” The more important question I learned to ask that first week was, “When it fails, can people still do what they originally came to do?”

The first production incident came from beyond the screen

As soon as the features began moving in front of us, an operational problem appeared. The account used in the deployed service first needed its access state repaired. After that, we found that the existing users table in some environments lacked columns the application expected. On screen, both problems looked like login failures, but their causes were outside the authentication interface.

At first, I followed the visible symptom and rechecked the account and login path. Recovery required two distinct steps: repairing the deployed account’s access state, then safely adding the expected columns to the existing users table. We also added exception logging and clarified the schema repair procedure so unexpected API errors would be observable on the server.

The incident was small, but its lessons lasted.

1. A production error may not originate in the same layer where a person sees it.
2. Database changes have a lifecycle separate from code deployments.
3. Friendly error messages and observable root causes are both necessary.
4. A schema repair should not be a script that succeeds only once; it should be safe to run repeatedly against an existing table.

When building a service, the successful path is easiest to see. Once operations begin, failure paths determine product quality. Those first login problems were the earliest sign that Haru Space was becoming a service we had to operate, not merely a collection of screens.

Small mobile frictions were not small problems

Around the same time, a series of mobile problems emerged. Tapping the input field could zoom the screen. New messages did not always take the reader to the latest position. Refreshes made the screen flicker. When a media upload failed, people sometimes could not tell why.

Each issue looked like a minor UI bug. In a private messenger, however, mobile is not a secondary screen. It is the primary environment. If someone must readjust the screen every time they type and scroll to find each new message, even excellent translation will not sustain the conversation.

Instead of covering the problems with one large change, we separated them and worked through them one by one. We reduced the mobile input zoom, corrected the position of recent messages, and removed unnecessary flicker during refreshes. An upload failure no longer disappeared silently; it left enough information for the person to choose what to do next.

That work made me abandon the idea that “mobile support” is a final step where a desktop screen is simply made smaller. The actions most often interrupted on mobile must be treated as part of the product’s core flow from the beginning.

How one photo and one notification became operational features

Image and video thumbnails and push notifications arrived later in the first week. They looked like convenience features, but both touched operating cost and trust directly.

Loading the original media every time a list appears slows the screen and increases data transfer. We chose to show a small thumbnail in the conversation list and fetch the original only when someone opens it. Push notifications likewise needed a user-controlled on/off choice, while browser and device subscription records had to be managed separately. People also should not receive a notification for their own message.

We did not yet have a complete cost model or a sophisticated notification policy. Even so, we began asking three questions together whenever we added a small feature.

• At what moment does the person actually want this?
• What data must be transferred to reach that moment?
• How can it stop when it fails or when the person does not want it?

Those same questions later became a standard for designing media storage, real-time connections, AI calls, and automation costs.

What I got wrong during that fast first week

Many changes landed in a short period. The speed made progress easy to see, but there were moments when the feature list began to outrun the product direction. While building the home hub, additional menus, personalization, and notifications, I made choices without sufficiently verifying whether people truly needed those things first.

Writing a verification sequence in a document did not automatically prove that production verification had happened. The records from that time retain procedures for checking login, approval, messages, and attachments. In the records we can review today, however, CI output and deployment logs are not available to the same standard at every point.

For that reason, this retrospective does not overstate what we “verified.” It distinguishes what was implemented from the checks we established. Joining only the successful outcomes might make a promotional story, but it would make a poor build log for informing the next decision.

A practical checklist from week one

If I were handing this week of experience to someone starting a similar service, I would organize it in this order.

1. Write a one-sentence promise before a feature list

The sentence should say who can continue doing what, and at which moment. Without it, the feature count of a reference product quietly becomes the roadmap.

2. Take only the structure of the actions from a reference

Do not copy its screens, code, data, or brand. Extract the sequence through which a person joins, receives approval, and achieves their goal, then redesign it around the value of your own service.

3. Check whether the core journey remains walkable without AI

When an external model or API fails, the original message, input data, and the person’s next action should remain available. If removing AI leaves nothing usable, the cost of failure is too high.

4. Include schema and observability in the first deployment

Build health checks, error logs, idempotent migrations, and a minimal operational checklist alongside the features. These are the tools that connect “it worked on my computer” to “we can recover it in production.”

5. Verify the most frequently repeated mobile actions first

Walk through login, input, sending, viewing the latest message, and error recovery on a small screen. Shrinking a desktop interface does not create a mobile experience.

6. Record decisions and limits in the same document

If you record only what was chosen, the next person repeats the same debate. Include why you chose it, what you gave up, and what remains unverified.

The moment Haru Space began

At the end of that first week, Haru Space was far from finished. Permissions needed to become more granular. Boundaries between groups, real-time costs, and the distinction between public and private data were all still ahead of us.

But it was clearly different from what had come before.

After passing through a portfolio page and a community PoC, we could say who entered this space, why they came, and which part of their experience we intended to protect. A complete path now ran from joining and approval to conversation, translation, and checking the original. When that path broke in production for the first time, we began looking at the data and observability instead of fixing only the screen people could see.

Looking back, Haru Space did not begin with its first commit.

It began when we chose what to protect, rather than what to resemble.

The next record will follow how a single photo and a single chat room became both cost and security policies, and how growing beyond one group taught us the difference between hiding something from view and preventing access to it on the server.