Hi! I’m Ryu from AMANEKU Studio.

At the time of writing this, Shipaton has been underway for five days.

In my previous post, I wrote about choosing our app’s name and logo.

This time, I want to show exactly how the two of us are working together—including the decisions that failed and the ones we had to reverse.

We are building ROLL Beauty, an app for saving a 360-degree visual record of a haircut and sharing hairstyle references without exposing the user’s face.

There are only two people on our team. When one of us gets blocked, half the team stops. That is why the first thing we decided was not a feature or a screen. It was how to divide the work.

We Split the Roles Cleanly in Two

• Nao:Engineering only—technical design, implementation, and testing
• Ryu (me):Everything else—the revenue model, pricing, user acquisition, communications, terms, policies, and other documents

I do not write code. Nao does not do marketing.

With only two people, it may sound safer for both of us to stay involved in everything. In practice, we found the opposite.

When both people own everything, both people get stuck in the same place.

We also attend different universities, so we do not see each other every day. To keep moving anyway, we agreed on a simple communication system.

Our Main Communication Tool Is a One-to-Three-Line Daily Build Log

Each of us writes a short build log every day.

There are only three rules:

• Write what you did, where you got stuck, and which decisions changed.
• Do not try to make the writing polished.
• One to three lines per day is enough.

The log is not a status report.

Its purpose is to save the reason behind a decision before we forget it.

Three days later, someone always asks, “Why did we do it this way again?” Without a log, we have to repeat the same discussion from the beginning.

This article itself was assembled from those daily logs.

What Happened on Nao’s Side

In these first five days of engineering, there were more stories about fixing things than stories about getting them right the first time.

The Face-Hiding Feature Took Less Than One-Quarter of the Estimate

We want users to be able to share hairstyles online, so hiding the face is essential.

We originally assumed we would need to detect the face and then mask it. Nao estimated two to three days of work. Once he tested the idea with real data, he realized that dedicated face detection was unnecessary. The pipeline we were already using to turn the background white included a way to identify facial skin. He could reuse that instead.

When he applied the blur, the face disappeared while the hair remained completely untouched.

The feature took half a day.

Long Hair Made Our Recordings Inconsistent in Size

This problem took the most time.

When Nao measured real samples, he found the following differences between people:

• Difference in face height: 6%
• Difference in vertical length including the hair: 105%
• Difference in width: 49%

In other words, any dimension that included hair was too unstable to use as a reference. Face height was the only reliable baseline.

We changed the system so that every record uses the same width, while the vertical dimension is calculated from the amount of hair. The final records can have different heights for short-haired and long-haired users, but the face appears at exactly the same size.

Our first attempt used head width as the reference. That failed because hair also changes the apparent width—the same problem we had already found in the vertical dimension.

We discovered something else along the way: during recording, people unconsciously moved forward and backward, changing the apparent size of the head by as much as ±35%.

Correcting all of that afterward would add complexity and uncertainty. A clearer instruction in the capture guide—“Please stay still”—is more reliable.

We Failed Twice at Extracting Only the Rotating Part of the Video

We recorded an eight-second video, then extracted only the section in which the person is actually turning.

Our first approach measured changes across the image. It falsely detected rotation when someone simply moved a hand before the capture began.

Measuring the visible area of the hair worked immediately and matched our manual review. But we reached that solution only after two failed attempts:

• We tried optical flow, but the plain wall in the background had too little visual texture for it to respond reliably.
• We used the same threshold to detect the beginning and end of the rotation, but the end was detected too early and the final 50 degrees were cut off.

Those failures remain in the log exactly as they happened.

What Happened on My Side

My first five days were mostly about deciding numbers and constraints.

We Set the Pricing

Our planned prices are:

• Japan:¥780 per month, ¥3,900 for six months, or ¥5,800 per year
• United States:$7.99 per month, $29.99 for six months, or $39.99 per year

To arrive at those numbers, I researched subscription pricing across beauty-related services and built a basic revenue and cost plan for the business.

We Will Not Stop Free Users From Recording

We made one clear product decision: the free plan will not limit how many times a user can record.

The difference between the free and paid plans is how many past records a user can view:

• Free:View the 10 most recent records
• Paid:View every record

Suppose a free user already has 10 records and creates an eleventh. Recording still works normally. The oldest record simply becomes unavailable to view.

A common alternative would be to disable the capture button after the user reaches 10 records. But that would mean the people who use the app most—the people showing the strongest engagement—would be the first ones prevented from using it.

That felt backward.

So we limit viewing, not recording. We never stop the act of capturing a new haircut.

We Had to Redesign the Referral System

Our first idea was simple: invite a friend, and both the inviter and the invited user receive a discount.

After researching the available Apple and Google purchase mechanisms, we concluded that our original direct user-to-user discount model would not fit the platform rules.

We changed the system so that we issue and distribute the codes ourselves.

The invited user receives a reduced price of ¥580 instead of ¥780 for two months. The inviter’s price does not change. Instead, the number of successful referrals remains visible on the inviter’s profile.

Our Goal Was Off by an Entire Order of Magnitude

This was the biggest strategic change of the period.

In our previous article, I wrote that our goals were 1,000 installs in the first week and 100 paying users during the competition.

After calculating the realistic level required to place near the top of the event, I realized that we needed more than 10 times that amount.

Honestly, our target was off by an entire digit.

I rebuilt the weekly acquisition targets. Instead of dividing the total evenly across each day, I shaped the plan like a mountain: a slower launch, stronger growth in the middle, and another push before the deadline.

Then I wrote out one action for every day from August 5 through September 30—all 57 days, one line at a time.

The goal was simple: never leave a day without a defined action.

What Working as a Two-Person Team Actually Looks Like

Our responsibilities are separate, but we are allowed to challenge decisions inside each other’s area.

That rule had more impact than anything else during these first few days.

Example 1: We Stopped the Record From Rotating Automatically

Our first design automatically played a full rotation as soon as the user opened a record.

I asked Nao, “Won’t people think this is just a sequence of photos?”

He agreed. We replaced the automatic rotation with a still image and a “← SLIDE →” prompt.

Our reasoning was that the interaction becomes easier to understand when the user performs it directly.

Example 2: Different Users Rotated in Different Directions

During capture, some people turned clockwise and others turned counterclockwise.

If we preserved the original direction, the expected drag direction would also change from one record to another.

When I pointed this out, Nao immediately said, “Yes, we absolutely need to fix that.”

The app now detects direction from the initial movement and normalizes every record to the same orientation.

Example 3: I Withdrew One of My Own Ideas

I suggested an interaction in which a comment would open after the user tapped and rotated it.

Nao asked me to imagine the actual sequence of actions. Once I did, the interaction felt awkward, so I withdrew the idea immediately.

With two people, we can notice mistakes quickly.

But only if neither person is too polite to point them out.

The Unexciting Decisions Are the Ones That Prevent Rework

The things we decided during these first five days may sound ordinary:

• Pricing
• Discount conditions
• The dimensions of a saved record
• The method used to detect and extract rotation

But if we skip these unexciting decisions, we will have to rebuild everything later.

These first five days became our period of deciding before building.

Next time, I hope to share the product running on an actual screen.

Before I finish, I have one question:

Have you ever taken a photo of the back of your head after leaving a hair salon?

If so, who was that photo for?

I would genuinely appreciate your answer in the comments. We plan to use that feedback directly in the next version of the product.

Thanks for reading.