Issue 71 · September 12, 2026

Before preordering the iPhone Duo, users pair two existing phones to mock up its foldable layout and personally test whether reading, photography, and pocket storage feel more natural.

As the iPhone Duo launch and preorder approach, people preparing to upgrade want to know less about how attractive the hinge animation is than whether their everyday actions will actually become easier. The product lets users take two existing iPhones, use them to represent the left and right halves of a foldable screen, and hold them in position with a simple printable hinge. Once paired, the two screens change their layouts as the user switches between folding states. Users can then try reading a long article, framing a photo, chatting in split screen, viewing a map, and putting the phones in a pocket.

Each task has a defined set of steps. Reading tests cross-screen layout; photography tests whether the wider unfolded view improves framing; and chatting tests how the keyboard and content area are divided. After each activity, users mark it as smooth, awkward, or unchanged, then add a brief personal note. The system organizes the results by task into a single comparison page, showing which actions improve when the screen gets larger and which add folding, handling, or storage burdens.

The first version only needs synchronized display across two iPhones, several fixed folding states, and a set of common tasks. It will not simulate the real hinge’s weight or thickness, or every third-party app. Users can also share their experience report with family members and invite them to complete the same tasks. That way, the preorder decision is based on having personally worked through everyday use, rather than being led by a launch-event demonstration.

Who it is for

People already using an iPhone who are seriously considering preordering the iPhone Duo. They often become interested after the launch event but cannot use a real device for an extended period before paying. At this point, there are enough specifications and demonstrations; what is missing is a way to work through their own reading, chat, map, and storage habits. Families sharing the cost or a device also need a result they can review together.

Smallest useful version

Use a native iOS app to connect two iPhones. Multipeer Connectivity can handle nearby-device discovery, pairing, and synchronized state messages. Nearby Interaction can provide distance and direction on supported devices, but the first version does not need to depend on it. Users initially select the folding state—closed, half-open, or open—and the printed hinge only holds the phones in position. Both devices use the same task state machine and render their respective content areas. The initial task set covers reading, chat, maps, and photo framing; it does not attempt to run or replicate third-party apps. Reports are stored on the primary device and can be exported as an image or web link.

Why now

Apple announced the first foldable iPhone Duo on September 9 and said preorders would begin on October 16; people preparing to upgrade need to decide before paying whether the larger screen, multitasking, and storage experience suit them. As of September 12, searches for “iphone duo” were still rising, with search volume above 2,000,000 and growth of 1,000%.

Strongest counterargument

The bezels and gap between two phones will noticeably distort the experience of reading across a continuous screen or framing a photo. Existing phones also differ in weight, thickness, and dimensions, making pocket tests especially prone to misleading conclusions. The app can simulate only preset interfaces and cannot show how real third-party apps will adapt. Pairing delays or mismatched states between the two devices may cause users to mistake an engineering problem for a product problem. The printable hinge also creates a setup barrier and a risk of scratching the phone bodies. Unless the report repeatedly makes the simulation’s limits clear, misleading advice will quickly undermine the credibility of a purchase-decision tool.

Open the shareable detail and agent brief

Editors converting landscape footage to vertical video get an editable camera path that follows the real speaker or action, while uncertain sections are flagged for human review.

When a short-form video editor converts a landscape interview, game, or livestream into vertical video, the hardest part is not cropping—it is keeping the frame on the wrong person. The user drops the video into a timeline, selects the main speaker, player, or current action, and the product generates an editable virtual-camera path. The path stays steady within a safe zone so it does not crop off heads or captions; when the system predicts that another person is about to speak or receive the ball, it also begins a smooth move in advance.

Editors can drag key points on the timeline and adjust tracking strength and the safe zone. Every automated move remains editable camera-movement data rather than being baked into an irreversible crop. For conversations with multiple people, the editor can choose “prioritize the current speaker” or “keep everyone visible.” Action footage can follow a ball, car, hand, or another selected subject.

When the subject is occluded, people overlap, the subject exits the frame quickly, or confidence drops sharply, the product stops making the decision automatically, marks the section for review, and shows the candidate subjects it detected. The first version focuses on common people and sports objects and outputs keyframe tracks that remain editable in Premiere, CapCut, or Final Cut. It does not handle captions, color grading, or the final edit.

Who it is for

The core users are editors who regularly reformat podcasts, interviews, courses, and sports footage for vertical video. They often receive Reels or Shorts deliverables only after the landscape master has been locked. At that point, captions, cuts, and pacing usually cannot be rebuilt, so they need to produce a reliable composition quickly. The longer the footage and the more often subjects change, the harder it is to finish shot-by-shot keyframing on deadline.

Smallest useful version

The technical core has three layers: subject tracking, shot planning, and export. After the user selects the subject in the first frame, SAM 2 propagates its mask forward. It supports point, box, and mask prompts and lets users correct the result in later frames. Interview footage then goes through offline speaker diarization, matched against face tracks. Shot planning generates only position, scale, and Bézier keyframes, with constraints for headroom, the caption area, and movement speed. The first version supports one subject and two-person interviews, but not catch prediction for arbitrary ball sports. Export starts with Final Cut Pro’s FCPXML format, which can describe a project timeline and lets applications exchange project data with Final Cut Pro.

Why now

A September 11, 2026 post on r/EntrepreneursGrind complained that after trying three landscape-to-vertical tools, the result was still just a centered crop; existing options had not reliably followed the speaker or action. As of September 12, the post had 2 points and 0 comments, and the problem surfaced at the delivery point where creators were converting landscape YouTube content into Reels.

Strongest counterargument

Speaker diarization and face matching can fail together, causing the camera to follow the wrong person continuously. If the system moves early toward the wrong next speaker, the finished video will contain an unexplained pan. Sports footage adds occlusion, cuts, and small fast-moving objects that are difficult for a single tracking model to cover. To reduce false positives, the system must retain confidence scores, candidate subjects, and edit history, increasing storage and interface complexity. Coordinates, scaling, and interpolation after FCPXML import also need validation across versions. If editors still have to watch all the footage, the time savings from automation fall sharply. Private interviews and unreleased sports footage may also restrict cloud processing, forcing the product to absorb the performance cost of local inference.

Open the shareable detail and agent brief

When a researcher receives an AI-generated mathematical proof, independent review agents probe its weakest reasoning nodes and attach reproducible counterexamples or failure traces.

A mathematics researcher receives a polished AI-generated proof but suspects that one lemma is being concealed by elegant wording. The user uploads the proof, its definitions and dependencies, and runnable code. The product breaks the argument into a checkable dependency chain, then sends it to multiple isolated review agents. Each agent has a distinct assignment: find counterexamples, inspect implicit assumptions, try to reconstruct a lemma, or validate critical steps through small-scale enumeration.

A review agent cannot simply say, “There may be a problem here.” It must identify a specific reasoning node and provide an input that triggers failure, an unmet premise, or a search program that can be rerun. The interface displays disputed points within the proof structure. When a researcher selects a node, they can see which agents independently found the same issue and which only raised an unverified suspicion.

When the author revises the proof, the system reruns only the affected branches and preserves the previous round’s conclusions. Passing sections show the verification method and execution range, while uncovered sections are clearly marked with their boundaries. The first version focuses on proofs with a relatively high degree of formalization, where symbolic computation or finite search can check the mathematics. It does not promise to replace peer review, and it does not treat an agent majority as proof of correctness.

Who it is for

Mathematics researchers reviewing AI-generated proofs. They have usually understood the main idea but are stuck on a lemma that looks suspiciously smooth. Manually checking every dependency is slow, while asking the model to prove itself can repeat the original error. The product fits use in seminars, before submitting a preprint, or before responding to peer-review comments. Users need rerunnable failure evidence, not another overall confidence score.

Smallest useful version

The workflow accepts a numbered proof with attached definitions, cited lemmas, and code. The model first extracts the propositions, premises, and citation relationships; the user then confirms the dependency graph. Nodes that can be formalized are converted into Lean 4 files and checked by the kernel, including with `#print axioms`. The remaining nodes are assigned to isolated agents for counterexample search, premise auditing, and lemma reconstruction. Checks over finite objects run in restricted containers that save the random seed, inputs, and outputs. The first version supports only Lean 4 and executable scripts, not purely diagrammatic proofs. Node contents are cached by hash, and changes trigger reruns according to the dependency graph.

Why now

On September 11, a Hacker News post about a mathematics-and-AI statement sparked discussion; as of September 12, the post ranked first with 580 points and 640 comments. The statement also notes that some AI mathematics results have been announced hastily, without sufficient writing or methodological refinement, leaving researchers more often with proofs that are difficult to verify quickly.

Strongest counterargument

Turning a natural-language proof into a correct dependency graph can itself introduce misreadings. If the node boundaries are wrong, later agents may precisely inspect the wrong object. Counterexample searches cover only the specified range, and failing to find a counterexample can easily be misread as a pass. Formalization may also change the original proposition into an easier one to prove. Running multiple agents creates significant model and compute costs. Uploading unpublished proofs to the cloud raises confidentiality and priority-publication concerns. The product should proceed only if authors confirm the proposition mapping and the interface strictly separates “checked” from “proved.”

Open the shareable detail and agent brief

Event audiences each control one section of a letterform grid, collectively building a changing title on stage and leaving behind an animated replay.

When an event host is about to put a title, slogan, or guest name on stage, the product turns the audience from people reading letters into people making them. The host enters the text and chooses a glyph style, and the product breaks each character into assignable grid modules. Audience members scan a QR code to join the room; each phone receives a small area, where its user completes a local action by swiping, rotating, or lighting cells. The stage projection continually combines the pieces into the text the audience is building together.

On-screen prompts tell each person only what their piece should become, so nobody needs to install an app or understand type design. The host can run the process as a timed letter-building challenge, a race between two teams, or a relay transformation. If a module receives no response for too long, the system hands it to another nearby participant. The projection shows overall progress, while each phone retains its module and team status.

The first version can support single-line titles, a limited glyph set, and browser-based participation via QR code, then export a complete letterform animation after the event. It is not meant to replace professional motion-design software, and it does not require every participant to draw precisely. The appeal is that dozens of people each complete one small action and then see a result on stage that only this group could have made together.

Who it is for

The core users are hosts and event producers planning a short interactive moment at a wedding, school celebration, product launch, or annual company event. The best moments are the opening, a guest’s entrance, or just before a brand slogan is revealed: attention is already focused on the stage, but the audience lacks one immediate action everyone can take. After scanning in, each person handles only a small piece, avoiding complex rules that could slow the program.

Smallest useful version

Rasterize a limited glyph set offline and store each character’s module coordinates and permitted actions. A room service uses WebSocket to synchronize module states, team progress, and host commands. The phone renders only its assigned area and sends swipe, rotation, and lighting events. The server uses heartbeats and a timeout queue to reclaim unresponsive modules and reassign them to participants who are still online. The projection client composes the global image from the event log; after the event, the same log generates the replay animation. The first version will not parse arbitrary fonts or handle multi-line layout.

Why now

As observed on September 12, GLYPH Immersive ranked No. 8 in Product Hunt’s new-product feed, giving modular grid-based glyphs visibility within the product community. This makes it easier for event teams to imagine a static title as interactive content completed collectively by the audience.

Strongest counterargument

Unstable event networks can desynchronize module states, leaving visible gaps in the projected letters. Reclaiming a module too quickly can interrupt someone who is still working; waiting too long can undermine the countdown. Differences in touch accuracy and page-sleep behavior across phones add accidental inputs and disconnections. A small glyph set limits event themes, while expanding it requires ongoing checks of each character’s legibility and action paths. Hosts also need rehearsals, backup rooms, and a one-click closeout; otherwise, a single stall can disrupt the stage rhythm.

Open the shareable detail and agent brief

Before a new-moon stargazing trip, users reserve a private observation seat filtered by horizon, light pollution, and nighttime rules, instead of scrambling to find a dark place where they can legally stay.

As a new moon approaches, urban stargazers and astrophotographers find that the difficult part is not the lunar date but finding a place that is dark enough, open to the horizon, and willing to host people late at night. The product turns rural farms, campsites, and private land into bookable nighttime observation seats. Hosts specify visible horizon directions, nearby light sources, parking arrangements, power, restroom facilities, and whether equipment such as equatorial mounts is allowed. Users enter their equipment, group size, and expected arrival time.

The booking page shows more than a point on a map: it also displays the moon’s position that night, the direction of the target object, and weather risks. On arrival, stargazers check in along a low-light route, while the phone switches automatically to a red-light interface to avoid disturbing others with headlights and screens. Hosts can set capacity limits, quiet hours, and vehicle access rules, then release the next batch of seats after an observation ends.

The first version will start with a small number of verifiable sites around new-moon weekends. It will support reservations, rule confirmation, and weather cancellations, but will not guarantee that users see any particular celestial object or handle wilderness safety for them. Stargazers get a place where they can genuinely stay for the night; hosts turn underused land into a bounded, courteous nighttime experience.

Who it is for

Urban stargazers who already own a telescope or astrophotography equipment. They typically check cloud cover, imaging targets, and group size a few days before a new moon. Ordinary campsites may be too brightly lit, while public dark-sky sites may not allow overnight parking. Before loading the car, they need to confirm the view, rules, and cancellation terms in one place.

Smallest useful version

Use PostGIS to store seat coordinates, horizon azimuth sectors, and nearby light sources. Skyfield can calculate the moon’s altitude, azimuth, and phase by location and time. Weather data will come from the NWS API’s hourly forecasts and alerts, with the first launch limited to sites in the United States. Hosts upload four-direction night views, parking routes, and equipment restrictions; people perform the first round of verification. Bookings cover only seats, group size, vehicles, rule confirmation, and weather cancellations. The product will not yet promise visibility or provide wilderness navigation or automated safety judgments.

Why now

Searches for “new moon september 2026” in the United States have reached 500+, up 75%, and the new-moon date is prompting stargazers to plan nighttime trips that month. This search interest had already fallen back by September 11, shifting demand from checking the date to finding a legal, overnight-capable location with controllable lighting shortly before departure.

Strongest counterargument

Every new site requires verification of property ownership, zoning rules, nighttime operating permits, and neighborhood restrictions. Hosts must also deal with liability from falls, stranded vehicles, damaged equipment, and severe weather. If view and lighting information is self-reported, it can easily differ from the on-site experience, while manual review slows expansion. Several consecutive cloudy nights around a new moon could concentrate refunds, eroding revenue and host confidence. If supply is too sparse, users still face long drives, making repeat bookings difficult. Red-light check-in can reduce disruption, but it cannot replace clear routes and on-site safety measures.

Open the shareable detail and agent brief