One brief, fourteen platforms

I looked at Finfold differently after taking it to Link-X Demo Day.

Presenting beside a large screen feels nothing like polishing a case study at a desk. A slow model, a thin source, or an unexplained number becomes visible immediately. I was presenting the original Chinese idea, 一鱼多吃, through a product now called Finfold. It could turn one product update into channel-native copy and visuals for fourteen platforms, then carry published results into the next round of recommendations.

Preparing for that room also exposed a weakness in the old story. It said a lot about interface decisions, but much less about how I found the problem, what I studied, how research changed the design, and what I still could not prove. Those are the questions I would ask another product designer, so this rewrite answers them directly.

The research started with seven rewrites of my own

The first research material was my own publishing workflow. I had one product update and wanted to share it on X, Xiaohongshu, WeChat, LinkedIn, Reddit, and Product Hunt. Copy and paste took seconds. Making each version credible did not.

X needed a first line that earned attention. Xiaohongshu needed to begin in the reader's daily problem. WeChat needed the full reasoning. Reddit was highly sensitive to promotional language. Product Hunt needed a tagline, description, and Maker Comment built for a launch context. I rewrote the same update seven times and recorded what each edit was doing.

Two kinds of work appeared. Product names, prices, release dates, and capability boundaries had to stay consistent. Openings, structures, tone, image formats, and calls to action had to change with the platform. A general chatbot made drafting faster, but I still had to explain the product and the channel again in every session. Seven manual rewrites became seven rounds of prompt setup and checking.

I studied the job on fourteen platforms

I expanded that self-observation into platform task analysis. For each channel, I documented the job a user was trying to complete, what the first screen needed to do, how the text usually unfolded, which image formats were common, what the community rejected, and which outcomes could be recorded after publication.

X made the first line and thread rhythm important. Xiaohongshu connected title, cover, body, and save value. WeChat involved long-form structure, layout, and image cadence. Reddit, Hacker News, and Indie Hackers required community value before product promotion. Medium and Substack were closer to evergreen reading and subscription relationships.

Those differences entered the product. The public workbench now supports fourteen platforms and nine image formats. A user can select at most six platforms in one run. Generating all fourteen at once looks impressive in a demo, but it increases waiting and the surface area for partial failure. Six is closer to a real publishing batch and easier to review.

Alternative review clarified where Finfold should begin and end

I reviewed three familiar product shapes against the same task. General chat was strong at drafting, but users repeatedly supplied brand and platform context. Template generators were predictable, but flattened real situations into fixed formats. Content-operations suites handled calendars, approval, and publishing well, while creation and brand judgment often lived elsewhere.

Finfold connects the parts that were repeatedly separating. Brand Memory stores positioning, audience, voice, banned words, and approved examples. Platform rules shape generation before the first draft. Independent cards hold each channel's version and status. Visuals live inside the same content kit. Published results return as input for the next recommendation.

Brand rules had to participate before generation

The earliest version checked brand consistency at the end. Eleven drafts would finish, then the product would warn that the tone might be wrong. The warning was accurate and badly timed. The user had already spent time editing.

I moved those constraints before generation. Product naming, locked facts, banned promises, tone boundaries, and calls to action became inputs. The system checks again after generation. The same approach supports stricter packs for advertising, healthcare, legal, and finance content, where absolute claims and guaranteed outcomes need to be stopped early.

I removed the illusion of permanent success

The first dashboard displayed an attractive set of numbers: 42 pending, 11 in review, and 18 scheduled. They made the product look mature. They were demo data, so I deleted them.

The early generation flow had a silent fallback too. When the model failed, a template filled the card and the interface still reported success. The demo stayed smooth, while the user lost the ability to tell whether content came from the model, a cache, or a template. Publishing one wrong claim could damage an account that took years to build.

I kept successful cards intact and gave failed cards their own explanation and retry. The public workbench now makes the login boundary explicit. Anyone can inspect the interface; generation requires a free account. There is no mysterious disabled action.

Waiting became visible at the card level as well. Each output can move through reading, applying rules, generating, and checking. Completed cards appear first, so the user can begin editing. I do not claim a percentage improvement in perceived speed because I have not run an experiment that supports one. I can verify that state and recovery are now visible.

Field evidence adds credibility without pretending to be user research

Link-X Demo Day did not prove product-market fit. It proved that I took a working product into a public setting and could explain the connection between research, interface decisions, technical constraints, and unresolved questions.

That distinction matters in a portfolio. Real projects rarely follow a perfect research-insight-solution-success sequence. Finfold combines self-observation, platform task analysis, alternative review, product implementation, and public demonstration. The event photos add field evidence. They do not become interview findings simply because people were in the room.

What I can prove today

As of August 11, 2026, the public homepage, workbench, and pricing page tell a consistent v0.9.0-beta.3 story. The live surface exposes fourteen platforms, nine image formats, Brand Memory, and a previewable workbench. A free account includes 50 creation credits, and the workbench explains why a run is limited to six selected platforms.

That evidence proves the product is live, the core workflow is inspectable, and commercial packaging exists in the real interface. It does not prove retention, revenue, or content-growth outcomes. I still need better evidence for why paying users stay and which feedback loops materially improve the next generation.

The next research round will focus on real tasks. Founders and solo operators will bring a product update they genuinely need to publish, then work through source input, platform selection, editing, export, and performance recording. A one-week content diary will capture what they return with, where they leave, and which recommendations they actually adopt. The research needs to follow behavior far enough to explain retention.