DEV Community: Dave Kurian

When a teammate leaves, what else must lose access? Check more than the seat

Dave Kurian — Wed, 04 Nov 2026 02:06:28 +0000

Removing a teammate from a team is one step. Their access may still live in places the team list does not show: an open session, a pending invite, a shared link, an integration token, or a project they still own. Make the list of what must lose access before you call the removal done.

The buyer question is what else must lose access when a teammate leaves, beyond their seat. A builder's question on this topic is the pack's starting point. We could not re-read that question from this machine, so the checklist here comes from the access model itself and from the SaaS Dashboard kit's screens, read on 4 Nov.

Start with the team, then follow the access

The obvious step is removing the person from the team. Check the team's member list afterwards and confirm the person is gone from it, not just hidden. A removal that only changes a label leaves them with whatever their role allowed before.

Then follow the access rather than the list. Ask what the person could reach through their role: projects, issues, files, reports, and any admin settings. Each of those paths needs a removal rule, and the rule should be the same for every teammate who leaves.

Sample UI with demo data. Shows the screen layout only; it does not show a removal flow or access rules.

Revoke the things a seat does not cover

Invites come first. A pending invite is an open door: someone who was invited but never joined can still accept it. Cancel every invite sent to that person, and check that an invite link cannot be reused after removal.

Shared links come next. A link to a project or a file keeps working for anyone who has it, whether or not the person who created it is still on the team. Decide whether links the person created should be rotated, expired, or handed to someone else.

Integration tokens are the most often missed. An API key, a webhook secret, or an OAuth grant that the person created can keep acting after they leave. Rotate what they set up, and list which integrations were connected from their account.

Sample UI with demo data. The live Security view shows this browser's session only; it doesn't list or revoke other people's sessions, and two-factor needs a provider you connect.

Check the sessions they already have

A person who has signed in on several devices has several sessions. Removing the seat does not end sessions that were already open, unless your app ends them. Decide what happens to existing sessions when a teammate is removed: ending them on the next request, ending them immediately, or leaving them alone for a set period.

Be exact about what your interface can show. The SaaS Dashboard kit's Security view lists the session of the browser you are using. It does not list or revoke another person's sessions. If you want a removed teammate's sessions to end, that behaviour is yours to build on the server, and the removal flow should test it.

Decide who owns what they created

Projects, documents and tasks a teammate created need an owner after they leave. A project with no owner can become impossible to manage, and a deleted owner can make a record look abandoned. Pick a rule for reassignment, such as the team lead or a named successor, and apply it at removal rather than later.

Keep the reassignment visible. A teammate should not be able to use the removal to hide work from the people who need it.

Test the removal from the removed person's side

Sign in as the removed teammate in a separate browser and try each path in the checklist. Open the team, a project, a shared link, the invite, and any API call the token allowed. For each one, confirm that access is refused and that the refusal shows a clear message rather than a blank screen.

Repeat the test after every change to roles or invites. A new permission added later can quietly restore a path you closed.

Plan the removal before someone leaves

Offboarding goes wrong when it is improvised on the day. The person leaving is often busy, the manager is not sure what they had, and the removal is done from memory. Write the list above into the product's admin notes, and make the removal a single procedure that someone can run from start to finish.

Keep the procedure short enough to finish in one sitting. A checklist of six items, each with an owner, is easier to complete than a long document that everyone agrees to read later. Review it once a quarter, and after any change that adds a new kind of access, such as a new integration or a new role.

Check the paths that bypass the team list

Some access does not run through the team list at all. An API token works whether or not its owner is on the team, and a route that calls a paid service can run for anyone who reaches it. If your product exposes server routes, list which ones accept a token from a person and which ones check the signed-in user. For the route side of that question, the check for AI routes that a signed-out visitor can reach covers the same pattern.

Rate limits are the other half. A removed teammate's token should stop working, and a token that is still active should not be able to run up a large bill before someone notices. Rate limiting for an owned API in production covers the limits that keep one account from spending more than it should.

What the SaaS Dashboard kit shows, and what it does not

The SaaS Dashboard kit includes team and people screens, and a Security view for this browser's session. The Security view has a sign-out action that affects this browser only. Its two-factor step needs a provider you connect, and it does not revoke other people's sessions.

The kit gives you the screens to attach removal rules to. It does not decide which invites, links, tokens or sessions a removal should end. The live demo shows the team screens before you buy, and the offboarding rules are yours to define and build.

A short offboarding checklist

Remove the person from the team and confirm they are gone from the member list.
Cancel every invite sent to them, and make sure invite links cannot be reused.
Expire or hand over shared links they created.
Rotate API keys, webhook secrets and integration grants they set up.
Decide what happens to their open sessions, then test it from their side.
Reassign the projects and records they own to a named person.

Sources

SaaS Dashboard kit page and live demo, read 4 Nov 2026: https://otf-kit.dev/templates/saas-dashboard and https://saas.otf-kit.dev (Teams and People screens; Security view with this browser's session only).

Expo Go crashes on Android with 'Failed to download remote update': how to test a games app on a real phone

Dave Kurian — Tue, 03 Nov 2026 21:13:54 +0000

An Expo Go crash on Android that says it failed to download a remote update, while the same project runs on iOS, is usually a question about where the app is loaded from, not about the game. Test the app you will ship on a real Android phone, and keep the Expo Go session separate from that test.

The buyer question is how to test a games app on a real device when Expo Go fails on Android. A builder's Stack Overflow question describes exactly that: an Expo Go crash on startup on one Android phone, with iOS working, on an SDK release. This article relies on a summary of that question and on the Expo documentation.

Separate the Expo Go session from your build

Expo Go loads your project from a development server, and it can also try to fetch a remote update. Those are two different paths. When the error names a remote update, the first question is whether your phone is trying to load an update at all, or whether it is loading the project from your development machine.

Run a test that removes the update path. Start the development server on your machine, open the project from the same network, and reload. If it works on iOS and fails on Android, compare the Expo SDK version on the phone's Expo Go app with the SDK in your project. A mismatch is a common reason for a startup crash, and the fix is to align the versions, not to change the game code.

Check what the device actually loads

Note the exact error text, the Android version, the Expo Go version, and the SDK in your project. Write these down before you change anything, so the next test can be compared with this one. A crash that happens on one phone model and not on another points at the device or its network path rather than the code.

If the failure is on the network path, check whether the phone can reach the development server at all. A corporate network, a VPN, or a strict firewall can block the connection that Expo Go uses. Switching to a different network is a quick test that separates a network problem from an app problem.

Sample UI with demo values. Shows the screen layout only; it does not show Expo Go, the remote-update error, or a fix for it.

Test the build you will ship

Expo Go is a convenient preview, but it is not your app. When a test needs the same native setup as your release, use a development build or a release-like build installed directly on the phone. That build does not depend on the remote update path in the same way, so a crash that disappears there tells you the problem was in the Expo Go session, not in the game.

For a games app, test the parts Expo Go may not represent: audio, storage, and any native module you added. Run each of them on the device once, then again after the app has been in the background for a while.

Why the error can look like a game bug

A remote-update error appears before your game code runs. The screen can stay blank, or the app can close during startup, and the player sees a failed launch rather than a bad level. That makes the problem easy to misread as a game crash, and it wastes the afternoon you set aside for testing gameplay.

Name the failure stage before you debug the game. A launch failure happens before the first screen, a crash during play happens after it, and a sound or input problem shows up only in a specific scene. Keep the three apart in your notes, so each one gets the right test.

What to test once the app starts

When the app opens on the device, test the games themselves in a fixed order. Start with the menu and the store, then open one game, play for a few minutes, leave the app, and return. A games app is often fine for the first minute and fails after a long session, so the long run matters more than the first launch.

Record the scores, the saved progress, and any local data after each step. Local storage that works on the first launch and is lost after a restart is a bug you can only find by restarting the device.

Keep a test log you can share

Write each run down: the build number, the device model, the Android version, the network, and the result. A short log lets a teammate or a tester repeat the path without guessing. It also makes the difference between an Expo Go session problem and a build problem easy to see at a glance.

Share the log with the people who will test on other devices. A single phone is a sample of one, and the failure may depend on the model, the network or the Android version.

Before you release a games app

Make the device test part of the release checklist, not a one-off step. Run it on at least one physical Android phone and one physical iPhone, using the build you will submit. Repeat it after each dependency update, since a new SDK can change how the app loads.

For a broader list of issues to walk through by hand before a launch, see the Expo pre-launch checklist. For a related case where Expo Go works on iOS but fails at sign-in on a fresh clone, see the Expo Go login article.

What a starter kit gives you, and what it does not

The Arcade kit is a starter with a games store. Its games run in web views and keep local data, and its live preview at arcade-preview.otf-kit.dev runs in the OTF Kits app rather than in Expo Go. The kit does not fix the Expo Go error, and it does not replace a device test of your own build.

Use the preview to see the screens, then test your own build on the phone you care about. The kit's value is the starting structure. The device test is yours.

Sample UI with demo values. Shows the screen layout only; it does not show Expo Go, the remote-update error, or a fix for it.

A short device checklist

Record the Expo Go error text, the Android version, the Expo Go version, and your project's SDK.
Reload from the development server on the same network and note whether iOS still works.
Test on a second network to rule out a connection problem.
Install a development or release-like build directly on the phone.
Test audio, storage and any native module, then repeat after backgrounding the app.
Compare the two results and keep the record with the release.

Sources

Builder's Stack Overflow question on an Expo Go startup crash on Android with iOS working, dated 3 Sep 2026.
Arcade kit page, checked 3 Nov 2026: https://otf-kit.dev/templates/arcade-kit (HTTP 200).

Google and ChatGPT cannot see your Lovable page: the minimum fix before you buy a template

Dave Kurian — Tue, 03 Nov 2026 17:33:42 +0000

Why can Google and ChatGPT not see my Lovable app, and what is the smallest fix? Check what the crawler gets in the raw HTML first. If your public pages are a single empty container that a script fills in later, most AI crawlers read nothing. The minimum fix is to put real content in the HTML each public route returns, and to give each route its own title and description.

A developer's DEV post on this problem makes the same point, and the fix it describes is the one we would start with. It is one author's account, not a measurement of how crawlers behave across the web.

Check the raw HTML before anything else

Open the page in a browser, then view the source of the page without running scripts. Look for your headline and first paragraph in that source. If they are missing, and you see only an empty root element and a script tag, the content exists only after JavaScript runs.

That matters because the DEV article cites Vercel's analysis of AI crawler traffic, which reports that none of the major AI crawlers it looked at rendered JavaScript. For them, a client-rendered page is close to empty. The same page can look finished to a person and still be invisible to the tools that answer questions about your product.

Do the check on each public route, not just the home page. Pricing, features and the blog are the routes a buyer is most likely to search for, and each one needs its own content in the HTML.

The raw HTML example is illustrative, not the Bundle's source. The live Bundle page is separate CTA context; crawler handling varies.

Put the basics in index.html

A single-page app still has one real HTML file. Give it a proper title, a meta description, Open Graph tags for link previews, and a canonical link. In a Lovable project you can ask the assistant to edit index.html, or change the file yourself and check the result in the raw source.

These tags do not replace real content in the body. They do make the page identifiable when a crawler reads the first response, and they control the preview a person sees when they share the link.

Prerender the public routes

The fix that puts your text into the HTML is prerendering. A prerender step runs the app at build time and saves finished HTML for each public route, such as the home page, pricing, features and the blog. Visitors still get the full app, but crawlers receive real content. For a Vite app like the ones Lovable and Bolt generate, this is usually a plugin plus a list of routes to render.

Keep the list short. Prerender the pages a stranger would search for, and leave the signed-in dashboard alone. A route that needs a session has no public content to show a crawler anyway.

After the change, run the raw-source check again on every prerendered route. The rendered page and the HTML should contain the same headline and first paragraph.

Add a sitemap and robots rules

A sitemap lists the public routes you want found. The robots file tells crawlers what they may read. Both are small files, and both are easy to get wrong when the routes change. Generate the sitemap from the same route list you use for prerendering, so the two never drift apart.

Check that the robots file does not block the pages you want found. A rule copied from a template can hide the whole site without any visible error.

Where a template fits, and where it does not

The Bundle on the pricing page includes the landing templates. They are Vite pages that render in the browser, so their default output has the same empty-container problem described above. Buying the Bundle gives you page structure and sections to adapt. It does not prerender your routes, and it does not make your pages visible to AI crawlers.

If you use a template, do the raw-source check on its pages before you put them in front of search. Then add the prerender step and the sitemap yourself. The template saves design time; the crawler fix is still yours to build and test.

What the crawler does not do

It helps to be exact about the limit. A crawler reads the HTML it receives on the first response. It does not wait for your script to finish, it does not click your buttons, and it does not log in. A signed-in dashboard, a pricing table that loads from an API after the page appears, or a headline that only exists after a fetch will all look empty to it.

That is also why the fix is not a keyword list. Putting a phrase in a meta tag while the body stays empty tells a crawler the subject of a page it cannot read. The content has to be in the body, and the tags have to describe that same content.

Test the fix without guessing

Use three checks. The first is the raw source check described above, run on each public route after a build. The second is a plain-text comparison: copy the headline and first paragraph from the rendered page and search for them in the raw source. If the search finds nothing, the fix is not in place. The third is a look at the sitemap and robots file from the public address, to confirm that the files the crawler reads are the ones you intended.

Keep a short record of each check: the route, the date, the build, and the result. The record makes it easy to see when a later change removed the prerender step, which is a common regression after a dependency update.

Start with the routes that earn the search

Not every route needs the same effort. A buyer finds you through the pages that answer a question, such as a pricing page, a feature page for a specific job, or a comparison. Prerender those first, and make sure each one has a specific title and a first paragraph that states what the page is for.

Leave the rest for later. A settings page, a team invite flow, or an internal admin screen gains nothing from being indexed, so there is no reason to spend build time on them.

Why the tool that built the app matters less than the build output

A Lovable project and a Bolt project can both produce the same kind of Vite output. The question that matters is what the production build sends to the crawler, not which assistant wrote the code. If you move to your own repository, the same checks apply, and the prerender step stays yours to maintain.

For the broader question of moving a Lovable app to your own repo, see how to download a Lovable project and prep the code for agents. For a comparison of the tools themselves, see Lovable alternatives when the MVP tool should not own your repo.

General editorial guidance only: check key text, links and the first response. This does not claim that the Bundle or its templates provide a crawler fix.

A minimum-fix checklist

Check the raw HTML of each public route for your headline and first paragraph.
Give index.html a title, a meta description, Open Graph tags and a canonical link.
Prerender the public routes so each one returns real content in its HTML.
Generate a sitemap from the same route list, and check the robots file.
Repeat the raw-source check after each deploy.
Only then compare templates or pages on design and copy.

Sources

DEV Community, "Why Google and ChatGPT can't see your Lovable app (and how to fix it)", by watershow, posted 26 Oct 2026: https://dev.to/watershow/why-google-and-chatgpt-cant-see-your-lovable-app-and-how-to-fix-it-3en (one author's account; it cites Vercel's analysis of AI crawler traffic).
Bundle and landing templates, pricing page, checked 3 Nov 2026: https://otf-kit.dev/pricing#bundle

How long does your first App Store review take? Apple's numbers and what restarts it

Dave Kurian — Tue, 03 Nov 2026 13:30:58 +0000

Apple says most App Store reviews finish within two days. If your first launch took a week, the time almost always went to a rejection or a reviewer who could not get past your sign-in, not to the queue itself.

What Apple publishes

Apple's App Review page says the team works around the clock and typically reviews at least 50% of submissions in less than 24 hours, and 90% in less than 48 hours. Those are shares of all submissions. They are not a promise about your app, and they say nothing about a second or third round.

So the first pass is the easy part. The delay comes from what happens after the first decision, and that is the part you can prepare for.

Apple's stated goal is to review at least 50% of submissions in under 24 hours and 90% in under 48; individual reviews can take longer.

The three things that restart the clock

Three things usually restart the clock on a first launch.

1. A rejection. Apple sends the build back with a reason. You fix it, build again and submit again, and the new submission goes through review as a new submission. Apple's page does not give a resubmission time, so plan for one before you pick a date.

2. A reviewer who cannot sign in. If your app needs an account to show anything useful, the reviewer has to get past the login screen first. Put a working demo login in App Review Information, with an account that already has data in it. Without one, the review stops at the first screen that asks for credentials.

3. An app that looks unfinished. Apple's review guidelines call this App Completeness. Placeholder screens, buttons that do nothing and features that only work after manual setup all get flagged. The fix is to test the build on a clean install, with nothing pre-filled from your own device.

A timeline you can plan around

This is an illustration of how the restarts add up, not data from any launch.

Day 0. You submit the build with the demo login in App Review Information.
Days 1 to 2. Apple's first decision, inside the window the App Review page describes for most submissions.
Day 2, rejected. You read the reason, fix only what it names, and resubmit that day.
Days 3 to 5. The second review runs. If the demo login works, the review moves on. If it does not, the same restart happens again.

The difference between a two-day launch and a week-long one is usually whether the reviewer could get in and finish the core flow on the first pass. Plan the launch date for the week-long case, and treat the two-day case as a bonus.

What the reviewer does in the first few minutes

Reviewers open the app, sign in with the demo account and walk the main flow. They look for crashes, dead buttons and screens that stop at an empty state. Before you submit, run the same walk on a clean install:

Delete the app and reinstall the exact build you will submit.
Sign in with the reviewer account only. Do not use your own device session or a saved login.
Go through sign-up, sign-in and onboarding, then open every tab and every screen the navigation shows.
Try each primary button once. Anything that does nothing gets removed or finished.
Check that the seeded account has data on every screen, so no list looks broken.

If a step needs a setting only you know, such as a sandbox key or a feature flag, the reviewer will hit it too. Move that setting into the build or into the demo account before you submit.

What to do after a rejection

A rejection is a reply with a reason, not a verdict on the whole app. Work through it in this order:

Read the reason and the screen or guideline it names. Reproduce the problem on a clean install before you change anything.
Fix the named issue, and check the same area for the same problem. A second rejection for the same thing costs another full round.
If the reason is unclear, ask in the App Store Connect Resolution Center before you rebuild. Apple's reply tells you what to change, and a guess costs a round.
Write a short note in the resubmission explaining what changed. It helps the reviewer find the fix without re-reading the whole app.

Keep the demo login working through every round. A rejection often happens after a successful sign-in, and an expired reviewer account turns a small fix into a new delay.

Illustrative App Review Information card. Provide working demo credentials privately; the masked values shown here are placeholders, not usable login details. The Fitness Kit phone UI is sample data.

Why a demo account beats a note in the review box

Some teams put a sentence in the review notes, such as "sign in with Google" or "create an account and it will work." A reviewer with no matching account, or with a sign-in that needs a code sent to a phone they cannot reach, is stuck either way. A working login with seeded data removes that guess. Use an email and password the reviewer can type, and make sure no step in the flow sends a code to a real inbox.

What to do before you set a launch date

Create a demo account for the reviewer and write its login into App Review Information.
Seed that account with realistic data, so every main screen has something to show.
Install the build on a clean device and walk through the flow above.
Remove placeholder text, dead buttons and any screen you have not finished.
Put one resubmission inside your launch window, so a rejection does not move the date.

The Fitness kit gives you sign-in, sign-up and onboarding to test against, with the main screens already built on Expo SDK 58. It does not give you a reviewer account, a store listing or a review outcome. Those are yours to set up, and the checklist above is where to start.

Get the Fitness kit

Want to see it running first? Open the live Fitness demo on your phone and test the sign-in path the reviewer will use.

Where this does not apply

The Fitness kit is a native Expo app, so the review path can differ from other app types. The kit does not predict approval time for your app, and nothing here guarantees a first-pass approval.

If you are still setting up the submission itself, start with the App Store submission checklist for an AI-built app. For the Apple-specific gaps, read the App Store submission article on what reviewers flag.

Sources

Apple, App Review status (developer.apple.com/help/app-review/after-submitting-for-review/review-status/). Re-opened 3 Nov 2026. Quoted: "reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours."

Reach one paid-worthy result before you polish the SaaS dashboard

Dave Kurian — Tue, 03 Nov 2026 13:26:27 +0000

How do you scope a SaaS MVP so it can test willingness to pay before you spend weeks polishing features? Pick one job a customer already wants done, define the single result that proves it worked, and put a few target users through that path before you add another screen.

A builder's r/SaaS thread about onboarding, retention, and conversion raises the same tangle this article addresses. When the first version has many screens and no agreed result, every feedback round produces more polish and less evidence. This is one thread, not market research. It still points at a useful sequence: decide what the first paying user gets, then build only the path that delivers it.

Name one job and one observable result

Write the job as a sentence a customer would recognize: "track a client's weekly deliverables," "approve a quote before work starts," or "get a team's open issues into one board." Then write the result you will observe. Good results are specific and visible: a record is created, a status changes, a teammate receives an invite, or a report is shared. A vague result such as "the user feels organized" cannot tell you whether the MVP worked.

Keep the result small enough to finish in one session. If the job needs three roles, two integrations, and a migration before anyone can see a result, split it. The first version is for testing a promise, not for covering every case the future product might need.

Illustrative MVP path: choose one customer job, observe one result, then ask for a real commitment; this is not an OTF experiment or product workflow.

Run the path with a few target users

Choose three to five people who match the buyer you want. Give each one the same starting point and watch them attempt the job without a tour. Record where they stop, what they expected to happen, and which screen they used instead of the one you designed. Do not treat a friendly comment as evidence unless it names a result they got or wanted.

Use the sessions to decide what to remove, not what to add. If a user never reaches the observable result, the next change should shorten the path to that result. A dashboard with more charts will not fix a path that stops before the first useful action.

12 production screens. Login and database wired.

The SaaS Dashboard Kit includes login, a database, and a working dashboard. Live demo at saas.otf-kit.dev: see the live demo.

Ask for a real commitment before expanding

Once the path works for a few people, test a commitment that costs them something. That might be a paid pre-order, a deposit, a signed letter of intent, or a paid pilot with a clear end date. The exact choice depends on your market, but a click on "interested" is weaker than a decision that involves money, time, or a named team.

Set the test up before you build more. Write down the price or commitment, the number of people you will ask, and what counts as a yes. If the answer is no, change the job or the audience before adding features. If the answer is yes, you have a reason to invest in the next part of the product.

Be careful with analytics at this stage. A dashboard template can show charts, but charts are not product events. You still need to define the events that show the result happened, and you need to implement them in your own app before trusting the numbers.

Write down what you will not build yet

Conceptual scope illustration: observe one simple workflow before adding polish; the pictured research practice is not included in the SaaS Dashboard starter.

Scope gets clearer when you list what stays out. Write a short "not yet" list next to the job: settings pages, team roles, reporting, integrations, and any screen that exists only because a competitor has one. The list does not say those features are bad. It says they cannot distract from the first result.

Review the list every time someone asks for a new screen. If a request does not change whether a target user reaches the result, it moves to the later list. This is where most early polish goes wrong: a reasonable idea arrives, gets built, and then the test has to wait for code that does not affect the decision.

Keep the not-yet list visible to everyone who works on the product. A founder, a designer, and a developer can each have a good reason to add something. The shared list lets them see whether the addition helps the first result or only makes the product look more complete.

Decide in advance what the test result will change

A test is useful only if it can change your next step. Before you run it, write two outcomes. If the target users reach the result and a few of them accept the commitment, the next step is to add the one screen that makes the path repeatable. If they stop before the result, the next step is to change the job, the starting point, or the audience, not to add a dashboard widget.

This prevents a common mistake: treating a mixed result as a yes. A few warm conversations, a single early payment, or a request for a demo are signals to investigate. They are not proof that the product is ready to expand. Record the numbers and the reasons people gave, and make the decision from that record.

Set a stopping rule too. If five target users cannot reach the result with the first path, pause and simplify before you build a sixth feature. A stopping rule protects the time you would otherwise spend polishing a version that nobody has finished using.

What a SaaS dashboard starter can and cannot provide

The SaaS Dashboard kit is a web starter with email sign-in, projects, teams, analytics screens, and its own API and Postgres database. The kit is a one-time $99 purchase for the full source. Its live demo lets you click through the running app before you buy.

Those screens give you an editable base for the first job, but they do not decide the job for you. The kit does not supply the onboarding experiment, product analytics, or a subscription billing setup. Its analytics screens are interface components, not instrumentation for your product events. If your test depends on a payment flow, a trial, or an activation metric, you still need to build and verify those parts against your own rules.

A starter also does not remove the need for a clear result. Use the kit to avoid rebuilding login, a data model, and a dashboard shell. Spend your time on the single path that tests whether someone will pay.

For a related question about how to price the first tier, see how to price your first paid tier. For what changes when an early prototype meets real users, see why sandbox MVPs break in production.

A short scope checklist

Write the job in one sentence a customer would recognize.
Define the single observable result and how you will see it happen.
Build only the screens and data needed for that path.
Run the path with three to five target users and record where they stop.
Set a real commitment, a price or a named team, and decide what counts as a yes before you test it.
Add the next screen only after the test changes what you will build.

Original post with the same scope checklist: Reach one paid-worthy result before you polish the SaaS dashboard

Sources

r/SaaS: "Onboarding, user retention, conversion?" — thread dated 31 Oct 2026. One builder thread, not evidence of market-wide demand.
SaaS Dashboard kit — kit page, checked 31 Oct 2026 (HTTP 200): email sign-in, projects, teams, analytics screens, own API and Postgres, $99 one-time.
SaaS Dashboard live demo — checked 2 Nov 2026 (HTTP 200).

Should an AI-built app ship as an installed app or a web page? Decide by trust and reach

Dave Kurian — Tue, 03 Nov 2026 11:01:13 +0000

Should an AI-built app ship as an installed mobile app, or as a web page? Choose by what users must trust before they install, how far they need to reach, and how often you must update. Trust is the constraint most builders underweight, because a web page asks for less of it.

A Hacker News thread asked whether people hesitate to install apps built with AI tools. The comments split. Some people never install them, or only in an isolated environment. Others say the bigger concern is quality: that such apps are often quickly abandoned and full of bugs. This is one discussion, with opinions, not a measurement, but it names the two worries a buyer brings to an install: security and whether the app will be maintained.

Trust is the first question

An install asks for more than a page view. The user grants a device-level permission set, keeps a copy of the code on their phone, and accepts an update path you control. A web page asks for a visit and sometimes a sign-in. If your audience is careful, start with the web, and add an installed app only when a clear feature needs it. Review the AI-called routes too: the spend-leak check for AI routes covers the server side that a web page also exposes.

Trust is not only about the code. Users judge a product by its visible care: a working sign-in, a clear privacy note, a support address, and a changelog that shows the app is maintained. Those signals matter more than the tool that produced the first version.

Reach and updates decide the second question

A web page reaches anyone with a link. It updates the moment you deploy, and nobody has to approve a store review. An installed app reaches people who open it often, can send notifications, and can work offline, but each release travels through a store or a distribution channel, and an old version can stay on a device for weeks.

If your product is used daily from a phone, such as a workout log or a habit tracker, the installed app earns its cost. If people use it once a week, or only on a laptop, a responsive web page is often the better first release.

Install versus web is a delivery choice. The Fitness Kit Workout screen and demo values are shown as sample UI; the browser-link symbol is illustrative.

A decision table you can fill in

Use four rows to choose the first release. Fill each with evidence you already have, not a guess.

Question	Points toward the web	Points toward an installed app
How often do users return?	Occasional use	Daily or near-daily use
Do they need offline or device features?	No	Yes, such as local storage or notifications
How fast must fixes reach users?	Same day	Store review is acceptable
How much trust does the first visit need?	Low to moderate	High, with a visible track record

If most rows point one way, follow them. If they split, ship the web version first and test whether the native features are needed before building the store release.

Build one shared codebase when you can

A common middle path is one codebase that produces a web version and native apps. That reduces duplicate work, but it does not remove the trust question. A web version can be the first thing a careful visitor sees, and it gives you a place to show the app's behaviour before they install anything.

The OTF Fitness Kit is one example. Its page describes a mobile template for iOS, Android and web, built from one Expo codebase with a real database. It gives you a starting point that targets all three. It does not make your app trustworthy by itself, and it does not audit the code for security. Those checks are yours before you ask anyone to install.

You can click through the running app at the live demo to see the screens before you decide which release to ship first.

Make the install decision easier to trust

Whatever you ship, make the next step explicit. A web visitor should see what the app does on the first screen, with no sign-in wall until the value is clear. An installer should see a short description of what the app asks permission for, and why.

Publish a changelog and a support address before the first install. A visible record of fixes is the simplest answer to the "abandoned slop" worry in the thread. It shows that someone reads reports and ships corrections.

Test with people who are sceptical of installs, not only with people who already like them. Ask them what would stop them, then fix that before the store listing.

What the first release should show

Whichever channel you pick, the first release should answer three questions before anyone is asked to commit. What does the app do in the first minute? What data does it keep, and where? How do I reach a person if something breaks?

Keep the first minute free of walls. Show a real example of the main task, with sample content clearly marked as sample, so a visitor understands the value before creating an account. A visitor who sees a working example is more willing to trust the app than one who sees a sign-up form on an empty page.

Be specific about data. Name what the app stores, where it lives, and how a user removes it. A sentence such as "your workouts are stored on our server and you can delete them from settings" is more useful to a careful user than a general promise about security. Only write the sentence once the deletion path works.

Answer the support question with a real address and a response time you can keep. A reachable person is the strongest counter to the worry that a fast-built app will be left to rot.

Fitness Kit demo screen; nutrition values are sample UI.

What to avoid promising

Do not promise that the app is secure, audited, or free of bugs unless you have done that work and can show the evidence. A sentence such as "fully secure" invites the exact scrutiny the thread describes, and it is easy to disprove.

Do not describe a starter kit as a security review. A kit gives you a structure and a set of screens. The checks that decide whether an installed app is safe to run are still yours: dependency review, permission scope, data handling, and the code paths that touch the network. For the bugs a dev client hides, walk the release build by hand; the Expo pre-launch checklist lists the common ones.

Avoid comparing your app with a store app on features you have not built. A careful buyer will test the claim, and a single gap undoes the rest of the page.

A short checklist before you choose

Write down how often a target user needs the app in a typical week.
List the device features you truly need. If the list is empty, start with the web.
Decide how fast a bug fix must reach users.
Publish a support address and a changelog before asking for an install.
Ship the web version first if the evidence is mixed, then test the native need.
Review security and data handling yourself before any release, whichever channel you choose.

Sources

Hacker News, "Ask HN: Are you hesitant to install vibe-coded apps?", posted 14 Oct 2026: https://news.ycombinator.com/item?id=50090796 (a discussion thread, opinions only; not a survey).
OTF Fitness Kit page, checked 3 Nov 2026 (HTTP 200): https://otf-kit.dev/templates/fitness-kit

Before Bolt subscriptions go live, check the Stripe production cutover

Dave Kurian — Tue, 03 Nov 2026 10:27:46 +0000

After export, a successful preview can still hide a broken live payment flow. Treat production as a separate Stripe cutover, not as the last click in a deploy.

When an app builder reports that Stripe webhooks stopped working after export, it is tempting to blame the payment provider or rewrite the checkout page. First separate the path into three things that can fail independently: which environment the app is using, where the server creates a checkout session, and which webhook endpoint receives and verifies events.

One builder described exactly this class of breakage after exporting an app: webhook failures and subscriptions that did not behave as expected. That is one report, not evidence that every export has the same cause. The useful response is a checklist that makes the cutover observable before real customers depend on it.

Start with the payment path, not the button

Draw the flow from the user's click to the state your app stores:

The browser requests a checkout session from your server.
The server chooses a product or price and asks Stripe to create a session.
Stripe returns a hosted checkout URL, and the browser redirects.
Stripe sends events to a registered webhook endpoint.
Your server verifies the event and updates the account or subscription state.
The product reads that state and grants the intended access.

If the checkout screen opens but the user's account never becomes active, steps four through six deserve attention. If the server cannot create a session, start at the environment and server request. A button that navigates successfully proves neither event delivery nor entitlement updates.

Write down the owner of each step: browser, app server, Stripe account, webhook receiver, and database. After an export, confirm every URL and secret belongs to the deployed app, not only to the original preview environment.

Separate test and live configuration

Stripe's test and live modes use different keys and separate resources. A product or price configured in one mode is not automatically available in the other. Make an explicit configuration checklist for the deployed environment:

The public key in the browser is the intended mode's publishable key.
The server's secret or restricted key is stored only in server-side configuration.
The price identifier sent to the server exists in the same mode as that key.
The success and cancel destinations return to the deployed app's expected routes.
The deployed process has restarted or otherwise loaded the intended configuration.

Never paste a secret key into a React component, a public repository, a browser console, or a support message. If a secret was exposed, rotate it using Stripe's current key-management process and update the server environment. Do not "fix" a production mismatch by moving a live secret into client code.

Use separate names for preview and production variables so the difference is visible during review. For example, a deployment checklist can say "preview key + preview price" and "live key + live price" without copying any secret values into the document. Store the actual credentials in the hosting platform's secret manager.

Illustrative checklist: keep each mode's keys, endpoint, and signing secret paired. No values are shown.

Register the production webhook destination

A local or preview webhook listener is not automatically the endpoint Stripe should call for a live app. Register the deployed HTTPS endpoint in the Stripe environment that will process real payments, then copy that endpoint's signing secret into the server-side secret store for that deployment.

Keep a short record of the endpoint URL, selected event types, environment, and the secret's storage name. Do not record the secret itself. Preview and production endpoints can have different signing secrets; using the preview secret in production makes signature verification fail even when Stripe reaches the server.

The receiver should verify Stripe's signature against the unmodified request body using the signing secret for that endpoint. If you parse or rewrite the body before verification, the signature check can fail. The handler should return a successful response after it has accepted the event for processing. If the work is asynchronous, persist or enqueue the event before acknowledging it, so a process restart does not silently discard the update.

Example sequence only. It is a generic pattern, not a shipped SaaS Dashboard Kit feature.

Test one complete event path

Before opening a real checkout to customers, run one controlled test through the deployed application and inspect both sides of the path:

Create a checkout from the deployed app using the intended test environment.
Complete the test payment with Stripe's documented test method.
Confirm the registered endpoint shows a successful delivery attempt.
Inspect your server logs for signature verification and handler outcome, without logging secret values or payment details.
Read the resulting account or subscription state from the database.
Sign in as that test user and confirm the product's access matches the saved state.
Trigger a cancellation or renewal-related test if your application's access logic depends on it.

Do not treat a redirect to a "success" page as proof of payment. A success URL is part of the browser flow; the webhook is a separate server-to-server event. Your application should decide what access to grant from trusted server-side payment state, not from a query parameter that a browser can change.

Also test the failure path. Send an event that your handler does not recognize and confirm it is safely recorded or ignored. Retry a delivery and confirm the same event does not create duplicate entitlements or duplicate business actions. Stripe can deliver events asynchronously, and solid handlers should be designed for retries rather than assuming each event arrives exactly once. For a deeper implementation note on that pattern, see storing idempotency keys in Postgres.

Debug in the order the evidence points

When an event is missing, use the event delivery record to answer a few concrete questions:

Was the event created in test or live mode?
Was it sent to the expected endpoint URL?
Did the endpoint return a non-success status or time out?
Did signature verification fail?
Did the handler accept the event but fail while writing application state?
Did the database update succeed while the UI continued to show stale state?

Each answer points to a different owner. A wrong mode suggests configuration. No delivery attempt suggests endpoint registration or event selection. A failed HTTP response points to reachability or handler behavior. A signature error suggests the wrong endpoint secret, an altered request body, or verification code. A successful delivery with no access change points to application state transitions.

Change one variable at a time and keep the failing event ID, timestamp, mode, endpoint, response code, and sanitized log excerpt together. That makes it possible to compare the preview and production paths without exposing credentials. Avoid rotating every key or changing product logic before you know which boundary failed.

Use a cutover checklist that can be repeated

Before the first real subscription, have a second person walk through this list against the deployed environment:

The live deployment uses the intended Stripe account and live-mode resources.
Checkout sessions are created on the server; secret credentials never reach the browser.
The configured live price exists in the selected mode.
The production webhook uses the deployed HTTPS URL and its own signing secret.
The receiver verifies signatures and safely handles retries.
A test event reaches the endpoint and produces the expected database state.
The application grants and removes access from verified server-side state.
Logs show enough to diagnose failures and contain no secrets or unnecessary payment data.
A rollback or disable switch is known in case a real event behaves unexpectedly.

If any item is unknown, keep the payment path in test mode and resolve that gap first. The goal is not to add every billing feature before launch; it is to know which environment is active and prove the small path you intend to rely on.

Where a starter helps, and where it stops

An editable SaaS starter can save time on the dashboard, sign-in, data model, and application shell. It cannot make your Stripe account, production endpoint, prices, webhook secrets, or subscription access rules correct by itself. Treat those as an integration you own and verify against your own deployment.

The OTF SaaS Dashboard Kit provides editable dashboard and API scaffolding with its own Postgres database. It does not include subscription billing for your product. Use its live demo and product page to inspect the shell, then plan the payment integration as a separate work item. The decision here is whether you want a faster starting point for the app around billing, not a claim that the billing path is already implemented.

Original post with the same checklist: Before Bolt subscriptions go live, check the Stripe production cutover

Sources

Stripe API keys and environment modes: key types, test and live modes, and the distinction between API keys and webhook signing secrets.

Stripe says Incomplete after a trial card is added: grant access from subscription state

Dave Kurian — Tue, 03 Nov 2026 04:27:20 +0000

If a free trial asks for a card later, Stripe can show the subscription as Incomplete while a 3DS step is still pending. Do not grant access from the checkout redirect. Map each checkout to your own account ID when it is created, and grant access from the subscription's state after webhooks confirm it.

The buyer question is how to make a no-card trial turn into a paid account without a customer who paid still showing as free. A builder's Stack Overflow question about this exact sequence describes a 14-day trial, a card added later, and a status that stays Incomplete after a 3DS challenge. This article relies on a summary of that question and on Stripe's documentation.

Why the status is the thing to read

Stripe's subscription documentation describes the states a subscription can move through. A trial is shown as trialing. When a trial has a paid price after the trial ends, or the customer must confirm a payment, the subscription can be incomplete instead of active. Stripe's documentation says that if the customer does not pay within 23 hours, the subscription moves to incomplete_expired and its invoice is voided.

That gives you two rules. First, a subscription in incomplete is not a paid account, even if the customer has just been through checkout. Second, incomplete_expired is a state you must handle, not an error to ignore: the customer has to start a new subscription to get access back.

Map the checkout to your account before Stripe is involved

The redirect back to your app is not proof of payment. Create an internal account reference before the checkout session exists, and store it on the session's metadata. When a webhook arrives, use that reference to find the account. Do not match on email address, because the email on the Stripe customer can differ from the one in your app.

Keep the mapping in your own database: account ID, Stripe customer ID, subscription ID, and the last status you saw. A row like this lets you answer the support question "is this person paid?" without opening the Stripe dashboard. For the first-session side of a trial, see turning SaaS trial onboarding into the first useful action.

Sample UI with demo values. Shows the screen layout only; it does not show Stripe, billing, a trial, or access rules.

Process webhooks idempotently

Webhooks arrive more than once and not always in order. Record each event ID as you process it, and skip any event you have already applied. Update the stored status from the subscription object in the event, rather than from your own guess about what should have happened.

Then reconcile entitlements from that stored status. Access should follow a single function that reads the subscription state and returns allowed or not allowed. If several code paths grant access, a late webhook can revoke access that a newer event had just granted, so keep one path.

Handle the 3DS step as a state, not a failure

A 3DS challenge can leave the subscription waiting for the customer to finish authentication. Show the customer a clear next step in your app: that the payment needs confirmation, and a button that resumes it. Do not show a generic error, and do not treat the wait as a failed signup.

If the customer abandons the step, the status will eventually move on. Your app should show that state honestly, with an option to start again, rather than leaving the account in a limbo that looks paid.

Sample UI with demo values. Shows the screen layout only; it does not show Stripe, billing, a trial, or access rules.

Test the paths in test mode

Run the trial in Stripe's test mode with a card that requires authentication, and walk each path: completed authentication, abandoned authentication, and a replayed webhook. For each path, confirm the stored status and the access result. Then replay the same customer.subscription events in a different order and check that the final access decision does not change.

Keep these tests in CI. A change to checkout or to webhook handling is the usual way this regresses, and the cost of catching it is a few test cases.

Tell the customer what state they are in

A trial that is waiting on payment confirmation is confusing from the customer's side. They added a card, they see a trial badge, and they still cannot use the product. Write the copy for each state directly: "Your trial is active until the date shown," "We need you to confirm this payment to continue," and "Your payment was not confirmed, so your access has ended. Start again to keep going." Each sentence should match a status you actually store, so the screen cannot promise access that the account does not have.

Send one email per state change, not one per webhook. A customer who receives three emails for one checkout will assume the product is broken, even when the sequence is correct.

When the trial ends

The moment a trial turns into a paid subscription is the second place the status can stall. Check what happens when the first invoice fails, not only when it succeeds. A failed payment can move the subscription to past_due while your app still grants full access, which is a common gap. Decide in advance how long a past-due account keeps access, and make that rule a line in the same access function you use for the other states. For the rate-limit side of paid API routes, see rate limiting for an owned API in production.

Refunds and cancellations need the same care. A cancelled subscription should lose access on the date the rule says, not on the date your database last heard from Stripe. Test the cancellation path with the same webhook replay you use for checkout.

Where the SaaS Dashboard kit fits, and where it does not

The SaaS Dashboard kit is an editable web app with email sign-in, projects, teams, issues, and analytics screens, on its own typed API and Postgres database. It gives you the dashboard, auth and app shell to build on.

It does not supply Stripe billing or trial logic. Checkout, webhooks, the subscription mapping, and the 3DS handling described above are yours to wire. The live demo shows the running app before you decide whether its shell fits your product.

A checklist before you grant access

Create an internal account reference before each checkout session, and store it on the session metadata.
Store the mapping from account to Stripe customer and subscription in your own database.
Read access only from the stored subscription state.
Process each webhook event ID once, and update status from the event's subscription object.
Show incomplete as pending, with a resume step for the 3DS challenge.
Handle incomplete_expired by asking the customer to start again.
Test completed, abandoned, and replayed authentication paths in test mode.

Sources

Stripe documentation, subscriptions overview and subscription statuses (trialing, incomplete, incomplete_expired), read 3 Nov 2026: https://docs.stripe.com/billing/subscriptions/overview
Builder's Stack Overflow question on a no-card 14-day trial, Incomplete status after 3DS, dated 11 Mar 2026: https://stackoverflow.com/questions/79905281/payment-status-shows-incomplete-after-adding-card-during-14-day-free-trial
SaaS Dashboard kit scope, checked 3 Nov 2026: https://otf-kit.dev/templates/saas-dashboard (HTTP 200).

Sound stops after a few minutes on Android in your Expo app: release your audio players

Dave Kurian — Tue, 03 Nov 2026 01:07:38 +0000

Your Expo game or kids' app plays sound on launch. Ten minutes later, on an Android phone, nothing plays at all. Restarting the app brings the sound back for a few minutes, then it dies again. iOS often keeps working, which makes the bug easy to miss in simulator testing.

This is not a problem with the phone's volume or with one file. It shows up when the app keeps creating audio players and never lets go of the old ones.

What one developer found

In a post published on 29 October 2026, Göksel Köktaş described building an offline app for two- to four-year-olds with Expo and Cloudflare. The author reports that in expo-audio each player opens an Android media session. Calling remove() on a player was not enough in their app. The sessions piled up until they reached about 100, and then no sound played.

The fix they describe has two parts: call release() on each player when it is done, and share one player for the short voice lines instead of creating a new one per line.

This is one developer's report from one app. We have not reproduced the ~100 limit ourselves, and the number may depend on the Android version, the device, and the expo-audio release. Treat it as a pattern to test, not a fact about every device.

What the Expo docs say

The current expo-audio documentation is more specific than a single line of advice:

AudioPlayer.remove() removes the player from memory to free resources.
When you use createAudioPlayer() directly, the docs say it is your responsibility to call release() once the player is no longer needed. Without it, the docs warn, you can get memory leaks.
The useAudioPlayer() hook releases its player automatically when the component unmounts.

So the rule is simple. If you create players yourself in a loop, a sound effect function, or a screen that mounts and unmounts often, you own the cleanup. If you use the hook at the top of a component, the hook does it for you.

Check your app first

Before you change code, confirm the leak on a release build, not in development:

Install a release build on a physical Android device. Debug builds hide timing and memory behaviour.
Trigger your most-used sound effect 150 times in a row, with a short pause between plays.
Note the first time the sound is silent or noticeably late.
Repeat with the screen that plays the most audio, leaving and re-entering it between runs.

If silence appears after a repeatable number of plays, you have a player-lifecycle problem. If it only appears after backgrounding the app, look at audio focus and session handling first.

The 150-play number is a starting point, not a standard. What matters is the shape of the result. If the failure point stays the same across runs, the cause is probably the count of live players. If it moves around with the device's memory pressure, look at what else the app holds in memory, such as images or a large web view, before you blame audio.

It also helps to count while you test. Add a temporary log line in your audio helper that prints the number of players created and released. If "created" keeps climbing while "released" stays flat, you have found the leak without needing the device to go silent.

Fix how you create players

The fix is about ownership. Pick one of these patterns per sound:

Long-lived sounds (background music, a menu loop): create one player when the app or screen starts, keep a reference, and release it when the screen goes away.
Short effects (tap, win, error): create one player per effect at startup and reuse it with seekTo(0) and play(). Do not create a new player on every tap.
Voice lines in a learning app: load the clips into one player and swap the source, instead of one player per word.

Whatever you choose, keep the number of live players small and fixed. A counter is a useful guard during development: log every create and every release, and fail the test if the counts drift apart.

Illustrative only. Framed Arcade screen is sample UI with demo values; it does not claim that Arcade Kit or Expo detects or fixes audio-player leaks.

Here is a small pool for short effects. It creates each player once, reuses it, and releases everything on unmount. The shape is the point; adapt the names to your app:

import { createAudioPlayer, type AudioPlayer, type AudioSource } from "expo-audio";

// One player per effect, created once and reused for every play.
const pool = new Map<string, AudioPlayer>();

export function registerSound(name: string, source: AudioSource) {
  if (!pool.has(name)) {
    pool.set(name, createAudioPlayer(source));
  }
}

export async function playSound(name: string) {
  const player = pool.get(name);
  if (!player) return;
  await player.seekTo(0);
  player.play();
}

// Call this when the app or the audio screen goes away.
export function releaseAllSounds() {
  for (const player of pool.values()) {
    player.release();
  }
  pool.clear();
}

Two details matter here. seekTo(0) lets the same player replay a short effect without a new allocation. And releaseAllSounds() is the only place a player is released, so the create and release counts match by construction.

Where this matters for a kit-based app

The Arcade kit runs its games in web views and keeps local data. Its games are not built on expo-audio, and we did not find a native audio player in the kit that this post applies to. So this is not a bug in the kit.

It matters when you add native sound next to a kit: a game-over sting, a reward chime, or a voice prompt in the app shell. Those are the places where a new player gets created on every event. A game that feels fine for ten minutes can still go silent after a long session, and a player's first test rarely runs that long.

If you are shipping to children or to a small audience that plays for a long time in one sitting, put the 150-play test in your release checklist, not in a one-off debug session. The Expo pre-launch checklist post covers other things to walk through by hand before you submit, such as fonts and menu routes.

Illustrative only. Framed Arcade screen is sample UI with demo values; it does not claim that Arcade Kit or Expo detects or fixes audio-player leaks.

Before you ship

Every createAudioPlayer() has a matching release() on the path that leaves the screen.
Short effects reuse a player instead of creating one per event.
A release build passes the 150-play test on a physical Android device.
You have checked the current expo-audio docs for the SDK version your app uses, because the API changes between releases.

Sources

Göksel Köktaş, "What I learned building an ad-free, offline app for 2–4 year olds with Expo and Cloudflare", DEV Community, 29 October 2026: https://dev.to/goksel_koktas_4cd92edb6cb/what-i-learned-building-an-ad-free-offline-app-for-2-4-year-olds-with-expo-and-cloudflare-4ma7 (author's own report; not independently reproduced)
Expo, expo-audio documentation (AudioPlayer, remove(), release(), useAudioPlayer), read 3 November 2026: https://docs.expo.dev/versions/latest/sdk/audio/

Turn SaaS trial onboarding from an app tour into the first useful action

Dave Kurian — Mon, 02 Nov 2026 23:04:40 +0000

If a free trial opens on a tour of every screen, most new users leave before they reach the one action that makes the product useful. Put that action first: one screen, one job, one result the user can see. Add guidance only after you have measured whether people complete it.

The buyer question is how to make a trial start with the product rather than a walkthrough. A builder's r/SaaS thread on onboarding, retention, and conversion raises the same concern. It is one thread, not market research.

Why a tour is the wrong first screen

A tour explains the product before the user has a reason to care. It shows the sidebar, the settings, and the team page in the order you built them, which is the order that makes sense to you. A new user has no project yet, so most of the tour describes things they cannot use.

The cost is quiet. The user clicks through, feels they have seen the product, and closes the tab without creating anything. The trial is then spent on an explanation, not on the result that would make them pay.

Define the first useful action

Pick the single action that proves the product works for this user. For a project tool it might be creating one project and adding one item to it. For a reporting tool it might be connecting one data source and seeing one number. Write it as a sentence the user would recognize, and make sure it can be finished in one session.

Then check the action against the product's promise. If the promise is "track client work in one place," the first action should put one client piece of work in that place. An action that only opens a settings page does not count, however tidy it looks.

Put the action on the first screen

When the trial starts, show the empty state of the first useful action, with one clear control to begin it. The user should not have to find that control through the navigation. Remove the sidebar items the first action does not need, or move them behind a collapsed group, so the screen has one obvious next step.

A useful test is to count the clicks between signing in and seeing the result. If the count is more than a few, the first screen is still a tour in disguise.

Sample UI with demo values. Shows the screen layout only; it does not show a trial, a conversion, or a user outcome.

Add guidance after the action is measured

Only after you know whether people complete the first action should you add guidance. A short inline hint next to the control, or a single checklist item that marks the action complete, is usually enough. Add a longer tour only when the data shows a specific step that people cannot find, and then build the tour around that step rather than the whole product.

Keep the guidance tied to the action. A hint that says what to click, and why, is more useful than a sequence of screens that describes features the user has not needed yet.

What usually breaks the first action

Three failures show up again and again. The first is an empty state with no example: the user sees "No projects yet" and no hint of what a good first project looks like. Show one realistic example next to the empty state, clearly marked as an example, so the user knows what done looks like.

The second is a required setting that blocks the action: a team name, a billing field, or an integration the user has not connected yet. Ask for it after the first result, not before. A user who has seen the result is more willing to finish the setup.

The third is an action that succeeds silently. If creating the project saves it but shows no confirmation, the user cannot tell whether the step counted. Confirm the result on screen with the saved item, and link to the place where it now appears.

Each failure is visible in the first session if you watch a few new users try the action without help. Watch before you write any guidance, and fix the step the users actually stall on.

Sample UI with demo values. Shows the screen layout only; it does not show a trial, a conversion, or a user outcome.

Adjacent reading on first sessions

First-session flow is not unique to SaaS. A fitness app faces the same question about the first workout, and the fitness app first-two-minutes guide covers that version. The principle carries over: the first screen should offer one action with a visible result, not a tour of the whole app.

Measure completion, not clicks

Decide what counts as completion before you ship the change. The event should fire when the result exists, such as a project saved with one item, not when the user opens a page. Store the event with the user ID and the trial start date, so you can see the share of trials that finish the action within a set window, for example the first two days.

Be honest about the numbers you collect. A few trials tell you where people stall, not what the average trial does. Write down the sample size before you read the result, and treat a small sample as a reason to look more closely, not as a conclusion.

Hold the email sequence until the action is measured

Onboarding emails are easy to add and hard to judge. If the first action is unclear, a sequence of emails repeats the confusion on a schedule. Wait until the first action has a measured completion rate before writing a sequence, and base each email on the step the user has or has not finished.

Where the SaaS Dashboard kit fits, and where it does not

The SaaS Dashboard kit is an editable web app with email sign-in, projects, teams, issues, and analytics screens, on its own typed API and Postgres database. Those screens give you a dashboard shell to put the first action into. The live demo shows the running app before you buy.

It does not include a product-specific onboarding tour, activation analytics, behavioral emails, or retention tools. Your first action, its completion event, and the guidance around it are yours to define and build. The kit gives you the screens; it does not tell you which action your trial users need.

A checklist before you ship a trial change

Write the single first useful action in one sentence.
Put its empty state on the first screen, with one clear control.
Remove or collapse navigation the first action does not need.
Define the completion event as the result existing, and store it with the trial start date.
Measure completion over a fixed window before writing guidance or emails.
Add a tour only for a step the data shows people cannot find.

Sources

Builder thread on r/SaaS about onboarding, user retention, and conversion, dated 11 Oct 2026: https://www.reddit.com/r/SaaS/comments/1x2w0qv/onboarding_and_engaging_new_users/
SaaS Dashboard kit scope, checked 2 Nov 2026: https://otf-kit.dev/templates/saas-dashboard (HTTP 200).

Expo apps hide launch bugs your dev client never shows: fonts, routes, filters

Dave Kurian — Mon, 02 Nov 2026 18:58:29 +0000

Your Expo dev client will not flag several kinds of bug that matter before launch, including fonts that never load, menu links to screens that do not exist, filters that match nothing, and settings you can reach only during onboarding. Check them by hand on a release-like build, then turn each check into a line in CI or a small test so it stays fixed.

These six come from one audit, not a survey. One React Native developer, Najmul Hasan, audited a finished Expo app and listed six bugs that the dev client never showed. None of the findings were architectural. They were small errors that stayed hidden because the same paths were tested in the same dev client every day. The pattern is plausible for many apps built this way, but it is one app's audit, so treat the list as a walk-through, not a measurement.

Why the dev client hides them

The dev client loads the same screens, with the same demo rows, through the same taps. A menu item you have never opened, or a filter you have never tapped with real data, stays invisible. A release-like build changes what the app loads: the bundled fonts, the production routes and the data your users actually have. The source's core advice is to audit that build, not the dev client, and to walk every screen and every link.

Build a preview binary for the walk-through. The source uses an EAS preview profile for Android (eas build --platform android --profile preview). Your own build command will differ, but the rule is the same: test what users install.

1. Fonts that never loaded

The app declared custom fonts, including a dedicated Bengali typeface, but nothing loaded them. React Native does not warn loudly. Text renders in the system font, and the design you think you are shipping is not the one on screen.

The fix is to load every font the app uses in one place, with useFonts in the root layout, and to hold the splash screen until the fonts are ready. The check is simple: every fontFamily string in your code must appear in the map passed to useFonts. A grep finds the mismatches in seconds.

2. A menu item that points to nothing

A Profile menu entry linked to a route with no screen behind it. In Expo Router, routes are files, so a typo or a deleted screen leaves a link that goes nowhere, and the app shows the gap only when someone taps it.

The source suggests turning on typed routes (experiments.typedRoutes in app.json) and running tsc --noEmit in CI. A link to a missing route then becomes a type error before the build leaves your laptop.

3. A filter tab that was always empty

A "verified" tab on the community screen filtered on a condition that no record ever satisfied. It looked fine with a few demo rows, and nobody tapped the tab with real data.

For each filter, seed at least one record that should match and assert that the result is not empty. A unit test for the filter function is enough. Two records, one matching and one not, catch the empty tab, and the test costs a few lines.

4. A score shown on the wrong scale

The trust score was stored on one range and drawn as if it sat on another, so the badge showed progress that did not exist. Any number a user reads as good or bad needs one owner for its range. Put the maximum in one constant, import it into the code that writes the score and into the component that draws it, and convert in one helper.

Sample UI with demo values. Shows the screen layout only; it does not show the bugs, and the kit does not detect them.

5. A setting you can reach only during onboarding

Language selection existed only in the first-run flow. A user who picked the wrong language had no way back. The source's rule is that every choice made during onboarding needs a permanent entry point in Settings, and a fresh install should reach it in under three taps. Test it that way: delete the app, install it, and count the taps.

6. Dead files in the bundle

An old mockup file stayed in the repo. It does no harm until someone imports it or a reviewer spends time on it. Run an unused-file finder once before launch, and delete only what you have read and confirmed is unused.

Sample UI with demo values. Shows the screen layout only; it does not show the bugs, and the kit does not detect them.

A walk-through you can run in an afternoon

Install the release-like build on a real device, not the dev client.
Open every menu item and every link, and note any screen that does not open.
Tap every filter and every sort with real data, and note any tab that returns nothing.
Check every score, badge and percentage against its stated range.
Find every onboarding choice and confirm it has a Settings entry.
Run the unused-file check, and read each result before you delete anything.

If you have only one afternoon, start with the first three items. Fonts, routes and filters are the checks that pass in the dev client and fail on a device most often, and each one can become a test or a CI step. The score and dead-file checks matter too, but they are slower, because they need you to read the code and decide what is really unused. Write down the build number and the result of each step as you go, so the next release starts from what you found last time rather than from memory.

Save the list as a file in the repo and repeat it before each release. The same bugs return when a new screen is added without a route check or a filter test. For the store side of the same launch, see the app store submission checklist for AI-built apps, and for links between screens, see the deep-linking checklist for Expo production.

Where the Fitness kit fits, and where it does not

The Fitness kit is a mobile template for iOS, Android and web, built on one Expo codebase with a real database. Its screens include onboarding and profile and goals, so the walk-through above applies to it as it does to any app you start from it. Walk those screens on a release build before you rely on them.

The kit does not promise that your fonts and locales are wired, that every route is covered, or that your filters return what your users expect. Those checks are yours. You can click through the running app at the live demo before you decide.

Sources

Najmul Hasan, "Expo React Native Pre-Launch Checklist: 6 Bugs Your Dev Client Won't Show You", DEV Community, posted 31 Oct 2026, read 2 Nov 2026: https://dev.to/najmulhasan-dev/expo-react-native-pre-launch-checklist-6-bugs-your-dev-client-wont-show-you-e4f
Fitness kit scope, checked 2 Nov 2026: https://otf-kit.dev/md/templates/fitness-kit.md

Your AI-built app's AI endpoint has no login check: close it before it spends your credits

Dave Kurian — Mon, 02 Nov 2026 13:14:01 +0000

In a Lovable- or Bolt-style app, any server route that calls a paid model and skips the login check can be called by anyone who finds its URL, and every call bills your account. Find those routes by listing every server route, then marking the ones that call a model and the ones that check who is signed in. A route that does both, and has no check, is the one to close first.

A developer read 25 public vibe-coded apps, mostly Lovable, by reading their code and git history. None had a hardcoded secret. Eleven had any server layer at all; the other fourteen were frontend-only. Two of the eleven exposed an AI-calling route with no login check and no per-user rate limit. The author calls that "n=2, not a statistic," and the sample is small. Treat it as a checklist of where to look, not as a market study.

What the scan found, and what it did not

The useful part of the sample is the shape of the two failures. One was a pair of Supabase edge functions with verify_jwt set to false and CORS set to *. The other was three Next.js API routes with no middleware. In both, the route worked for anyone who had its address. The article also names two more patterns to check for: verify_jwt = false combined with the service role key, and loose row-level security policies.

The sample does not tell you how common this is across all apps, or how your own app compares. It shows where to look.

Find the routes that spend money

List every server route. In Supabase, that means the edge functions under supabase/functions/. In Next.js, that means the handlers under app/api/ and any other route handlers. In Express, that means every route registration.
Check the login gate on each route. In Supabase, look for verify_jwt in supabase/config.toml, and check whether the function reads the signed-in user from the request. In Next.js, check which paths middleware.ts covers, and whether the handler checks the session itself. In Express, check whether auth middleware sits on the route.
Mark the routes that call a model. Look for requests to the OpenAI, Anthropic, or OpenRouter APIs, or a direct fetch to their URLs. A route that passes the request to another internal function still counts if that function calls a model.
Fix every route that is both signed out and model-calling. Require a signed-in user before the model call, then add a per-user limit so one account cannot run up the bill.
Keep the service role key off reachable routes. A service role key bypasses row-level security. If a route that a signed-out visitor can reach uses it, that route can read or change any row.

Keep the list in a file your team reviews. A new route added later without the check is the usual way this problem comes back.

Conceptual comparison of public and signed-in route paths, each reaching a paid model; not an OTF feature.

Why model routes cost more than other routes

Most routes in a small app cost almost nothing per call: a database read, a form save, a page load. A route that calls a model is different. Each request sends tokens to a paid provider and returns a bill line you do not control in the moment. A script that loops on that route can run up spend quickly, which is why it needs its own check.

That is why the check belongs on the model call itself, not only on the page that happens to use it. A signed-in page that calls an unprotected route is still an open door for anyone who finds the route URL directly. Treat the route as the unit of protection.

Who should own the check

The check should live in one place that every model-calling route passes through, rather than being copied into each handler by hand. A shared helper that reads the signed-in user, applies the limit, and then calls the model is easier to review than ten separate copies. When a new route needs model access, the review question is simple: does it go through the helper?

Give the helper a short test suite. One test should send a request with no session and expect a refusal. Another should send a request over the limit and expect a clear error. Run both in CI so a future change cannot quietly remove the check.

Hypothetical spend-leak illustration; no OTF product behavior or measured usage is shown.

Test the open door from outside

Read the code first, then test the deployed app. From a machine with no session, send a request to each model-calling route and confirm it is refused. The request should carry no cookie and no bearer token. A reply that returns model output, or a rising usage count on your provider's dashboard, means the route is open.

Test again after every deploy. Do not assume that a fix on one route covered its siblings. Both failures in the sample were in routes that looked protected until someone read them.

Add a per-user limit, not only a login

A login check stops anonymous callers. It does not stop a real account from making thousands of calls. A per-user limit caps how much one account can spend in a window. Put the counter on the server, keyed by the user ID from the verified session, and reject calls over the limit with a clear message. Store the counter where a visitor cannot reset it, such as the database rather than the browser. For the wider setup, see rate limiting for an owned API in production.

Pick the limit from your own cost model: what one normal session costs, and how much you can lose before someone looks at it. That number is a product decision, not a default from a template.

Where the kit fits, and where it does not

The SaaS Dashboard kit is a Vite + React 19 app with email sign-in, its own typed API, and a PostgreSQL database. That gives you a login layer to build on. It does not include AI routes, and its product page does not document per-user rate limiting. It is not a security review of your app. If you add an AI route to it, steps 2 to 4 above still apply to that route.

You can click through the running app at the live demo before deciding whether its login layer fits your project. For a wider pre-launch pass, see the AI app security checklist.

A short checklist before launch

List every server route, including edge functions and API handlers.
Mark each route that calls a paid model.
Confirm every marked route requires a signed-in user on the server.
Add a per-user limit on every marked route.
Keep the service role key off any route a signed-out visitor can reach.
Test each model-calling route from outside with no session, and confirm the refusal.

Sources

DEV Community, "I scanned 25 vibe-coded apps. The API keys were fine. The server wasn't." by ad23dev, posted 1 Nov 2026, read 2 Nov 2026: https://dev.to/ad23dev/i-scanned-25-vibe-coded-apps-the-api-keys-were-fine-the-server-wasnt-1lc6
SaaS Dashboard kit scope, read 2 Nov 2026: https://otf-kit.dev/md/templates/saas-dashboard.md