Creators Log timeline archive

Due to the discovery of a new vulnerability just before the production deployment, we could not proceed with only the previous inspection results and temporarily halted to make necessary corrections.

From the perspective of those who update, it can be cumbersome, and there’s anxiety about information leaking and being copied. Furthermore, I think that the return on continuing this effort has been weak. Therefore, I considered whether we could naturally gather information from regular production activities instead of asking everyone to write here every time. What I need right now is not the products to sell, but the needs. If we understand the needs, we can think of solutions like affiliate marketing, marketing support, sales agency, and outsourcing. If we can collect about 100 cases, we can classify them with AI and connect them to my network. That direction allows for scalability. I want to entrust all the projects to experts, automate repeated judgments and connections, and create a system that can operate smoothly even if I'm not there. It's not about doing something difficult; rather, I want to create the experience of "If I had continued recording from the start, connections would naturally increase, leading to sales and work!"

I realized that rather than completely deducing the necessary support solely from public logs, it is more natural to first deliver a hypothesis to the individual and update the current situation based on their response.

Instead of individually confirming and contacting candidates by hand, I wanted to verify a system that delivers proposals directly to them and gathers their responses. When I received it myself, I found that simply "confirming" provided a weak motivation to open the email. Additionally, the internal terminology and dedicated screens were cumbersome, so I positioned the entry as "proposals" and structured the process to ascertain interest within.

I felt that I was stopping too long in the same place, only seeing the trees and not the forest. By waiting for the overall accuracy check, I had become unable to move forward even with the needs that were already visible.

Search for actual partners, recruitments, and sales channels that match the extracted needs from publicly available information, and organize the reasoning and matching criteria for each candidate.

If I cannot predict what will come back from continuing the updates, I believe it is more rational not to go through the trouble of updating. If we can transform our production history into opportunities with external clients, partners, and experts, there is a possibility to create both the meaning of the updates and the monetization of the business at the same time.

We will evaluate the "necessary partners and opportunities" identified by AI for the 10 recently active public projects through approval, modification, and rejection, and check how accurately we can interpret opportunities from the production logs.

Data has accumulated to the extent that we can model the business using past data, and we are now in a situation where we can inject funds all at once at the right timing. Since two initial updates have been created, we want to observe the subsequent actions of the participants.

First, we will stabilize our position without getting carried away. We will check the scope of updates to the development infrastructure and the modifications to the automated inspection to ensure that no critical issues found during the audit regarding safety are overlooked.

We observed a 24-hour period during which X ads with black and white backgrounds were delivered simultaneously, monitoring the click-through rate, cost per click, and activities following registration.

The product has changed significantly since the advertising was stopped, so instead of a simple comparison with the past, we will measure how far new individuals progress in the current version of the Creators Log as a new baseline.

After 24 hours of the advertisement starting, check the delivery performance on both black and white backgrounds, as well as the activity since registration.

Since redesigning the entire top page seemed overly complicated, I focused first on showcasing projects from other creators and changing it to a horizontal display.

Review the updated prompt to make the Japanese expression more natural, and if there are no issues, implement it for the final version.

Since stopping the advertisements, we have implemented numerous features such as the public display, multilingual support, production history, and pathways for interaction and requests. Therefore, relying solely on past advertising results does not accurately evaluate the current experience. We have determined that we need to first revise the presentation to be more inviting and then gather new usage data.

Even with a bright theme, ensure that the stars and lines on the top page do not disappear, and that only the dark parts do not remain unnaturally. Confirm this on the test screen before reflecting it in the production version.

Even if we create a feature that allows the person to correct the translation, the range of what can be read in English will not increase. Therefore, we prioritized making it possible to track production history solely in English.

Reflect the English display of production history in the live environment. After backing up and re-confirming the latest original text, incorporate 636 entries and verify if the history can be tracked in English only.

I decided that translating only public information in a safe batch and rechecking its publication status and source text immediately before deployment would balance speed and safety better than continuing to process the one-time backlog at one item every five minutes.

Translate the additional 54 items in one batch, verify that Creators and Projects can be understood in English alone, and then deploy them to production.

Menus and headings alone are not enough. If readers cannot understand who a Creator is, what they are making, why they are making it, and how far they have progressed, multilingual support has little value. That is why the completion condition is that the page content itself can be understood in English alone.

Translate the main Creator and Project content in production, identify what still cannot be understood in English alone, and decide what else should be translated.

The value of Creators Log is not translating menus, but enabling third parties to understand what someone is making, how they are deciding, and how far they have progressed. I also believe that if the same history can repeatedly support selection before a company commissions work, oversight during the engagement, and proof of results afterward, then the creation record itself may generate transactions.

Receive Codex’s language-tab fix and verify in Preview how the Japanese/English switch at the top affects existing screens.

Projects already have settings for who they are looking for, links to public demos and test sites, comments, collaboration offers and conversations, work requests, Wall Meetings, and Creator Support. Rather than layering on similar features, we decided it would be better to see whether the existing entry points are actually used.

Review URL structure, translation scope, the relationship with original text, search, cost, and publication boundaries so public Creators, Projects, and updates can be read safely in Japanese and English.

Apps, games, music, and physical goods all require different sales methods and rights handling. Trying to cover everything with one payment feature would create an ever-growing set of Project-specific requirements. What can likely be shared across domains is the creation history, translation, evidence for judging trust, and entry points that let outside people take the next action.

Make a final roadmap decision, including the policy not to build a system for selling anything, and only if it is adopted, determine which existing features can be reused.

The current fees from support and consultations offer limited room for growth, so we are reconsidering the business model itself by reasoning backward from the question, “What would we do if we wanted to build ¥10 billion in revenue?”

Consider and test models such as a project-history foundation for organizations and a project-discovery foundation for companies, then decide which business model to adopt.

Rather than adding more features, we decided to first reach a state where real users are posting and replying to one another.

Expand the audience for operations announcements and publish a notice so all registered users can be informed that “Everyone’s Reality” is now available.

Because it felt more natural not to ask people who only want to look to begin creating, and to require profile setup only when they start interacting.

After GitHub recovers, apply the pre-release improvements in order, beginning with the post-menu fix.

Hiding the update content made it impossible to tell what had changed and made the page look like “a graveyard of Project updates.” Since casual posts and conversations should also emerge here, “Everyone’s Reality” feels more fitting than “Everyone’s Updates.”

Show one sentence explaining what changed on every Project update, make the entire post area open the details, and rename the heading to “Everyone’s Reality.”

A list containing only Project updates looked like “a graveyard of text called updates.” It did not reveal people’s personalities or ways of thinking, and it was unlikely to generate conversation.

Improve the timeline UI/UX, connect likes, replies, mentions, and notifications to posts, and then perform real-device checks before opening it to everyone.

To make the service easy to use without getting lost and help Project updates reach users more effectively.

Expand the collaboration and support contact feature to all eligible Projects.

Even if we add features, users have no reason to return if updates and new activity never reach them. We need not only features that move projects forward, but also mechanisms that bring people together, create conversation, and sustain relationships.

Organize consent and delivery settings so that daily update notices and a future weekly digest reach the users who want them.

Displaying a Need has little value if outside visitors cannot act on it immediately. Real-device testing also showed that the funding-offer screen was written from the Creator’s perspective, causing even me to drop off, and that the Owner could not verify the external view.

While logged in as the Owner, check the “public view” on a real device and verify that it matches what outside visitors actually see.

The first implementation had too many choices and explanations, and even displayed irrelevant suggestions, which felt unpleasant. Because the feature matters only when it is public and leads to real action, it was narrowed to show exactly the single option chosen by the Creator.

Move the recruitment display on the public page to just before the progress record, make it slightly smaller on mobile, and show an action button only when an appropriate existing path is available.

Public pages alone do not reveal whether someone wants funding or serious commercialization. Rather than deciding the next action solely from public information, I want a system that checks both where the Project is currently stuck and what the person themselves wants.

Complete the design of a system that organizes the support each Project needs and the opportunities the Creator wants, then proposes the next action together with the reason.

Because the feature should make continued Project updates more enjoyable, but only after the scope of information sent to AI and related safety conditions are properly established.

Pause the detailed work for a moment. Take a broad view and return to overall strategy: what information do companies, supporters, and others want to see, and how should it be made visible?

Will the character comment naturally?

A small display in the lower right was easy to ignore, and generic lines or a tone that sounded like outside commentary were too weak as a response to an update. The adjustments therefore prioritize accuracy of content and expression, not only speed of display.

As Owner, publish one meaningful update and verify that the specific content, character-like tone, and facial expression all match.

Daily update work can feel mundane. The question is whether a character that responds immediately can affect the willingness to update. We will begin with an experimental validation.

Deploy to production for the Owner only, perform one manual update and one AI update, and verify the lines, expressions, display method, and related behavior.

I decided we had done enough and moved forward with public release.

Because the top page and X already communicate the service, the signup screen should not become a large explanation page. It is better to add only a short indication that this is a new registration and what type of service it is.

After changing the signup start page, observe the conversion rate from signup_view to signup_submit.

Along with improving discoverability, added the paths needed for people to request and accept actual work.

Work requests could arrive, but recipients could not reply, so it was necessary to address the issue in advance.

Because many features have now been implemented, measure their effects and accelerate the PDCA cycle.

Rather than adding new features, the priority is a flow in which recorded work is communicated, brings people in, and helps them discover the next Creator or Project.

Because updates and their reasons were buried deep in the history, and there was no way to find public Creators or Projects by name.

Add keyword search across Creators and Projects in Explore.

Made it possible for Creators who meet the safety requirements to begin accepting support on their own.

Because the foundation for controlling a safe public scope was in place, making it appropriate to proceed to real use.

Explore improvements to the discoverability of Projects and Creators, as well as the usability of the friend-invitation feature.

Because the work had focused mainly on desktop, mobile readability issues became clear again, so they were fixed before proceeding with the support feature.

Support only emerges once people can post updates. The underlying usability problems therefore needed to be fixed first.

Now that the mobile improvements are largely complete, proceed with full implementation of the support feature.

Turned not only the payment screen but also post-support notifications, sales confirmation, and expected payout information into one coherent experience.

Actual use showed that completing payment is not enough; users also need to know who receives it, how much is received, and when it can be confirmed.

Run one ¥500 support payment in production and confirm the received amount and notifications to both parties.

Changing the specification so support is directed to the Creator rather than to a Project.

Because when I thought through who people truly want to support, I realized it is the person who keeps creating Projects.

Place the support button in the Creator section and verify in production the new flow from selecting an amount to the Stripe screen.

Alongside delivering updates, the flow is being connected so users can reach their first creation log without getting lost and that record can ultimately contribute to Creator income.

Because improving the user experience meant implementing early the experience of a log turning into income.

Complete one real support payment and verify the Creator’s receipt and its reflection in the admin screen.

At what point during an unfinished Project would you feel like offering support?

Added a return path that delivers creative activity even to people who are not currently visiting, rather than relying only on in-app notifications.

Real emails became harder to read as more updates were included, so the structure now prioritizes different Creators and lets recipients start by checking their own updates.

In the next automatic delivery, verify real-data delivery and readability.

How many Project updates in a single email would remain easy to read?

Continued improving the public pages and refined the admin-area UI/UX so that Creators themselves can keep using the service more easily.

Because in actual use it was extremely hard to tell what was public and what action to take next.

Because the work has focused on desktop views, review the main screens on mobile and adjust readability and usability.

Prioritized capturing support needs and strengthening how trust appears from the outside, not just building sales paths.

Because even with traffic and consultation paths, people are unlikely to move toward support or transactions if they cannot understand what is being made or what they can ask about.

Watch advertising traffic, consultation and brainstorming meetings, and the input of Creators’ problems, then decide which point of contact to strengthen next.

Does this public page make it clear what is being built and what kinds of consultation are available?

As participation increased, we stopped sending email announcements for every Project update. Instead, we created a way for the operations team to post announcements on the Dashboard.

Because the X advertising campaign is progressing well, making this the right time for the change.

Next, design a way for Creators to enter the support they currently need and the problems they are facing.

What support would be most helpful right now for the Project you are creating?

Moved from merely showing the offering on a public page to a stage where it can actually be purchased and lead into a consultation.

To prevent people from getting lost after purchase, notifications to buyers and Creators, an inquiry path, and an operations review screen were also prepared.

Next, organize the overall priorities and define the conditions for opening the consultation menu gradually to a small number of Creators.

Would it feel useful to have a path for booking a short consultation after viewing a Project in progress?

We had also considered paid consultation paths based on practical skills, but redesigned toward a single entry point for each Creator through a “consultation and brainstorming meeting” offering.

Because prioritizing clarity should make it easier for Creators to generate revenue.

Before enabling payment, verify order management, refund and cancellation conditions, legal disclosures, and how the scheduling URL will be revealed.

Would you see value in paying for one-on-one consultation or brainstorming with a Creator you personally thought looked promising?

Made identifying and fixing the save, reply, edit, and discovery friction encountered by real users the top priority.

Because users have begun creating real Projects and leaving comments after registration, and the friction they encounter in actual use is becoming useful material for product improvement.

On a real iPhone, verify and fix the issue where the screen remains zoomed in after text input and improve the readability of the comments section.

Does the comments section on the Project page look like an easy place to read reactions and replies?

Before expanding monetization paths, changed the decision to first establish the operations contact points and legal disclosures needed once the user base grows.

As the number of early users began to grow, the service needed a place to receive questions and defects, reassuring public information, and an operations-side response path.

Prepare the disclosures required under the Act on Specified Commercial Transactions and define the conditions for taking paid consultations and support flows into production.

Would having an inquiry contact point and terms of service reduce anxiety when using the service for the first time?

Fixed broken flows, clipped displays, and slow transitions found on real devices, and removed the issue where seed data was mixed into the list.

Actual use showed that being able to move without getting lost and correctly discover interesting activity matters more than the number of features.

Remove completed Projects from the active list and refine the inclusion rules for discovery surfaces.

Can you find a Project on the Explore page that makes you want to open it?

Changed update-email delivery from all registered users to only Creators who are currently public.

To avoid sending unnecessary notifications to people who only registered, and to test whether active users return to each other’s work.

Publish one real public update and confirm that it is sent to and received by the intended audience.

Would notifications about other Creators’ updates give you a reason to return and see what they are doing?

Moved from the stage of continuously adding features to welcoming real Creators and testing whether registration, updating, and return visits occur.

The recording and consultation mechanisms have completed one test cycle. The next question is whether, as more people use the service, records lead to continued activity and new opportunities.

Complete the limited update-notification test, begin recruiting initial Creators, and observe what they do after registration.

Does this explanation communicate what someone gets back from using Creators Log?

Changed the public page from directly proclaiming enthusiasm to a quieter structure that conveys activity status, an overview, what is public, recent movement, and the story behind the work.

Putting every uncertainty and effort at the forefront felt heavy for first-time visitors, and the pressure of explanation began to outweigh the project’s appeal. Deep records should accumulate behind the scenes, while showing only the necessary slices allows the underlying energy to come through.

Use the updated input prompt to create new Snapshots for Creators Log, Resignation Assessment, and My Tiny World, then check whether the public-facing slice feels natural across different kinds of challenges.

Shifted from centering the design on leading to consultations, requests, and transactions to centering it on recording and sharing the moments of an unfinished challenge itself. The record now preserves not only progress, but also what changed and why the decision was made.

Problems can sometimes be solved independently before advice is needed, so problem-solving alone is not a reason to keep using the service. By contrast, preserving uncertainty, conviction, and changes of direction exactly as they existed before completion, and having someone witness them, has a value different from publishing a finished product.

Leave the first public Snapshot on Creators Log’s own Project and check on the actual page whether first-time visitors understand the current state and energy of the challenge.

Using Creators Log’s own history, manually create three promising sales angles, three likely request types, and three initial audiences to show it to.

Does this explanation make it clear that this is a service where work in progress can lead to commissions?

Create one new update on Creators Log’s own public page and check whether first-time visitors understand the current state of the challenge and how they can support or get involved.

After seeing this page, do you feel like supporting it or getting involved?

Using Claude’s audit, review the current screens, flows, and data structure against the loop “a question worth seeing → external reaction → improvement history → trust,” then choose the first gap to close.

I want to examine why viewers would want to respond, and how showing that their response influenced an improvement could turn into trust. Can this experience be established through a minimum flow?

Design a minimum flow that adds materials such as AI chats and implementation reports to a Project and organizes them into progress, decisions, learning, next actions, and candidates for publication.

For creators using AI across multiple Projects, would an experience where “you drop in the materials, your current state is organized, and only what is needed can be shared externally” be a reason to keep using the service?

Check the top page on a PC and a real iPhone and confirm that first-time visitors can read the Hero, the benefits of using Creators Log, the publication scope, and the featured Projects.

With the message “The more of your process you preserve, the further trust can travel,” I want to see whether individuals creating with AI feel, “I want to put my work here.”

Publish one Creators Log update and use an iPhone to check whether the Decision Log on the public page communicates to a first-time visitor what was considered and where the decision changed.

I want to see whether a first-time creator, looking not at technical work history but at questions, uncertainty, and changes in judgment, feels, “I want to preserve my own creative process too.”

Have the first creators use it and validate the experience of the AI-assisted update flow.

Will a creator seeing it for the first time feel, “I want to put my work here”? Where will they get lost in the flow?