Michael's Feedback

Round 1 — 2026-03-02

In-App Browser Ejection Strategy

The specs must be very clear on how exactly ejecting from Facebook happens. There are two possible approaches:

Option A: Session-Based (Anonymous → Link)

Create a session stored on the backend during the quiz/funnel.
Give the user a specific link that opens that session in the mobile web browser.

Create the actual user entity during a sign-up process using email or phone number.
Give the user a link that logs them in via mobile web browser.

Considerations for Option B

Google Sign-In won't work — users are not signed into Google inside the in-app browser, so "Sign in with Google" will fail and block users who rely on it.
Password risk — if the user creates a password inside the in-app browser, they may not remember it later and will have to go through password reset.

Ejection Destination: Mobile Web vs. Native App

We need to decide whether we're ejecting users into mobile web browser or into the native app.
The native app does not support automatic login via a login link — if we tell users to download the Twofold app, they'll have to either sign in with Google or enter email/password manually.
We cannot quickly build a flow that carries the session from the in-app browser into the native app.

Key Decision

Each option has pros and cons. We need to weigh them and decide where in the funnel exactly we eject from the in-app browser — and into what (mobile web vs. native app).

No Credit Card Early in the Facebook Funnel

Given that we're focusing on the Facebook and Instagram funnel (users arriving from Facebook and Instagram ads), we should not consider any funnel variants that take a credit card early in the process. The flow should be:

Show great value first.
Eject from the in-app browser into a desktop or mobile browser.
Only then, at some point, take a credit card — this also gives better signal to Facebook.

We need to be very deliberate in allowing Facebook reporting to work correctly. We need to give Facebook as many signals as possible about what the user is doing — both inside the in-app browser and after ejecting.

Design Consistency with the Twofold App

The current onboarding in the Twofold app resembles the website (www) but is completely different from the actual app the user lands in. For the new Facebook and Instagram funnel, we should align the design to how the actual application looks to maintain consistency. This is more important than modernizing the color scheme.

Choose colors that are similar to the colors used in the app.
Slight changes to fonts or colors are fine if we believe they improve conversion ratios, but it needs to feel like the same application.

Simplicity as a Core Principle

Our users are not tech-savvy. They struggle with too many options.
Users have told us that one of the things they appreciate most about Twofold is simplicity.
We need to maintain that simplicity. We need to be laser-focused on what we do and what we do very well.

Quality as a Differentiator

A lot of user feedback says we are better than competitors in terms of quality.
One idea: tell users they can try other apps and we're confident they'll always come back to us.
Caveat: not sure if this specific idea is good marketing — take it with a grain of salt.

NUX & Activation: Web vs. Native App

The current NUX greatly improved conversion to activation on desktop web.
However, it did not improve conversion to activation on the native app. There may be differences between how native app and desktop web work in terms of having a NUX-like experience.
We can consider whether we want something like micro steps towards activation after onboarding and sign-up are complete — i.e., when the user lands on the /new page.

We can consider sign-up methods that don't involve email + password — for example, just collecting the email and sending a login link or a code. However, there are trade-offs:

Login link — can have deliverability issues (emails not arriving, landing in spam).
Login code — requires the user to open their email, find the code, and paste it back into Twofold. This can be cumbersome, especially for less tech-savvy users.

Both approaches may introduce friction that outweighs the benefit of removing passwords.

Round 2 — 2026-03-03

Quiz Progress Indicator

I prefer quizzes that have progress at the top. However, I'm not sure that we have to do that because on longer quizzes it might be off-putting.

"$0 Today" Messaging

We had a very short experiment which showed slightly negative results for this kind of text. We can try that again, but we should probably deprioritize it.

Chat Interfaces

I don't like chat interfaces. I think that they are slow and most of the time the chat interface doesn't provide as much value as just a regular interface.

Dark Backgrounds (Version 10)

I don't like the dark backgrounds of version 10. It seems to have no energy in my opinion.

Post-Quiz Summary Screen (Version 11)

In version 11, after finishing all the steps of the quiz, we get a screen that shows how much time will be saved. But this screen is very hard to read because there are too many sections.

In-App Browser Ejection Flow

What we should do is only take the name and email of a user inside the in-app browser.
When they click sign up, we should eject them from the in-app browser into the mobile browser.
In the mobile browser, the email should be pre-filled.
We don't need to show all the other data carried over from the quiz in the mobile browser — that data will be stored inside the URL or inside local storage.
The sign-up page in the mobile browser should be the full sign-up page, which also has the option to sign up with Google.
We should never actually do the sign up inside the in-app browser.
We do need to send all collected data (quiz answers, email, first name) to our servers so that if the ejection fails mid-process, we can send them an email as a fallback.

Michael