DEV Community: Uriel Bitton

SaaS Team Invitations: Show Who Gets Access to What

Uriel Bitton — Wed, 30 Sep 2026 15:19:55 +0000

A SaaS team invitation should make four things clear: who is invited, which workspace they will join, what they can do, and whether access has actually started. Keep a pending invite separate from an active member. Then make the server enforce the same rules the interface describes.

An invite touches two people and often two different account states. A smooth email screen is only one part of the work.

Put the workspace and role beside the email

Show the workspace name, recipient address, and selected role before sending. Use a small set of understandable role names and explain the actions each one allows. “Member” is too vague if it can include billing changes or deleting a project.

Choose a limited default role that matches the intended task. OWASP’s authorization guidance recommends least privilege, denying access by default, and checking permissions on every request. Apply that reasoning to who can send an invite and which role they can assign.

A disabled admin option in the browser is not an access check. The server should reject an unauthorized role or a workspace the sender cannot manage, even if someone changes the request.

Give pending invitations their own state

After the request succeeds, show “Invitation sent” and list the invite as pending. Keep the address visible so the sender can catch a typo. Make expiry, resend, and revoke actions easy to find where your product supports them.

Auth0’s organization invitation model includes a recipient, organization, expiry, and optional roles. It is one concrete example of the details an invitation system needs to track. Its defaults are product-specific; they are not a universal rule for your app.

If the server has queued the email but has no delivery confirmation, say that the invitation was sent or queued. Avoid claiming that the recipient received it. If sending fails, preserve the form and explain the next action.

Explain acceptance before granting access

The receiving page should identify the inviter, workspace, and role. Give the person a clear choice to accept. If they are signed into a different account, show which identity is active and offer a safe way to switch.

Check the recipient rules your authentication system supports. The server needs to bind acceptance to the intended identity and workspace, validate the invitation, and reject expired or revoked invitations. An invitation link should not become a way to choose arbitrary access.

After acceptance, show the workspace and the first useful task. If the role permits only viewing, the interface should reflect that without hiding a server failure behind an endless loading state.

Make repeat actions predictable

Decide how your product handles a second invitation to the same address. Perhaps it resends the pending invitation. Perhaps it asks the sender to change the role explicitly. State that behavior in the interface and keep it consistent.

An acceptance request may be retried after a slow response. Handle that retry without creating duplicate memberships or producing a misleading error. A revoked invitation should remain invalid after a resend or an old browser session.

Test the handoff between the two people

Use a small set of cases before release:

A permitted sender invites the right address with a limited role.
A sender attempts to assign a role they cannot grant.
The recipient opens the link while signed into a different account.
The link is expired, revoked, or already accepted.
The same request is submitted twice.
A member’s role changes after they have already loaded a page.
A person tries to access another workspace by changing an identifier.

Check both the visible message and the server result. These cases help you find mismatches; they do not replace a security review.

The invitation is complete when the intended person joins the intended workspace with the intended access. Use that as the definition of success, then make every intermediate state tell the truth.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

Password Reset UX: Make Recovery Clear and Safe

Uriel Bitton — Tue, 29 Sep 2026 18:41:44 +0000

A good password reset flow helps a person regain access without revealing whether an account exists. It gives clear next steps, uses a short-lived reset link or code, and explains what happened after a new password is set.

This is a small product flow with a large trust cost when it fails. The copy, security checks, and failure states need to agree.

Start with one clear request screen

Ask for the email address or account name your product uses. Label the field plainly and allow password managers and paste. Put the reset action where a person expects it from sign-in.

After submission, show a message such as: “If an account matches, we'll send a reset link. Check your inbox and spam folder.” Give a route back to sign-in and help for someone who no longer has access to that inbox.

The OWASP Forgot Password Cheat Sheet recommends a consistent message for existing and non-existing accounts and similar response times. An error that says “No account found” can help someone probe for registered users.

A neutral message does not require vague help. Tell the person what to look for, how long to wait before retrying, and where to get support. Make those times reflect your actual service.

Treat the link as a limited key

A reset link or code should be single-use, expire after an appropriate period, and be generated and stored securely. OWASP describes those controls in its recovery guidance. The email should send the person to your own service, not ask them to reply with a password.

The GOV.UK password pattern also advises using a time-limited reset link or code and notifying the person when a password reset has happened. Do not email the new password.

Write the expired-link screen before it happens. “This link has expired. Request a new one” is more useful than a generic “Invalid token.” If a newer request replaced an older link, explain the next safe action without exposing account details.

Make the new-password screen usable

Tell people the actual password rules before they submit. Let them paste from a password manager, and provide a way to show or hide the value if that fits the product. Keep focus order clear and identify errors next to the affected field.

Do not force a surprising new rule only after someone has typed and submitted a password. If confirmation is required, explain mismatches without clearing both fields unnecessarily.

The reset should not silently sign someone into a session unless your security design specifically supports that. OWASP recommends the normal sign-in path after reset and considering existing-session handling. Show a success state with a clear “Sign in” link and send a separate account notification.

Test the cases that usually get missed

Use test accounts and disposable tokens. Check:

A real and an unknown email get the same public response.
A valid link works once; a second use is rejected clearly.
An expired link offers a safe restart.
A new password that fails the policy gets a useful error.
A network failure does not claim the reset succeeded.
The notification goes to the right address and contains no password.
Keyboard and screen-reader users can finish the whole flow.

This test list is a starting point, not a security audit. Review rate limits, logs, token handling, and session rules with the people responsible for authentication.

Keep support connected to the flow

Some people have lost access to the email or phone on the account. Give them a visible support path with a careful identity-check process. Do not ask for secrets in an open form or promise recovery the team cannot provide.

The final check is simple: Can a real user recover access, and does every visible state tell the truth about what happened? Fix any mismatch before polishing the illustration on the request page.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

SaaS Delete Dialogs: Say Exactly What Will Be Lost

Uriel Bitton — Mon, 28 Sep 2026 17:27:54 +0000

A useful delete confirmation dialog names the item, explains what else will disappear, and gives the user a clear way to stop. For a SaaS product, the copy and the keyboard behavior should support the same decision.

A red button alone does not explain the scope. “Delete project” might remove an empty folder, shared reports, or work that other people still need. Make that difference visible before the final action.

Write the consequence before styling the dialog

Start with three questions: What is being deleted? Who or what else is affected? Can the user restore it?

Here is a hypothetical dialog for a project tool:

Delete “October client report”?

This removes the project and its 12 saved reports for everyone in this workspace. You cannot restore them from this app.

Cancel · Delete project

Use those claims only if the product behaves that way. If the action moves the project to a recoverable trash folder, state the real recovery window. If attachments stay elsewhere, say so when that would change the choice.

Avoid “Are you sure?” as the entire message. The person needs enough detail to know what they are confirming.

Match the interruption to the action

Use a confirmation step where a mistaken action would be costly. For frequent, recoverable actions, consider a clear undo flow instead. That is a design choice to test with your users, not a rule that every product must follow.

Typing a project name can add a deliberate pause for a serious action, but it does not replace an explanation. A person can copy a name without understanding what will disappear.

The W3C alert-dialog pattern is intended for an important message that interrupts a task and needs a response. It describes a labelled dialog with its alert message connected for assistive technology. Do not make every routine notice an alert dialog.

Keep keyboard focus inside the decision

The W3C modal-dialog pattern describes moving focus into a modal, keeping Tab and Shift+Tab within it, and closing it with Escape. For a difficult-to-reverse final action, it suggests considering initial focus on the least destructive choice.

For the example above, Cancel is a sensible starting point. A keyboard user should not land on Delete merely because it is visually prominent.

When the dialog closes, return focus to the control that opened it when that control still exists. If the deleted row is gone, choose a logical place in the remaining workflow. A modal label alone does not implement any of this behavior.

Design the failed request too

Write down what the person should see while deletion is running, when it succeeds, and when it fails.

For example, keep the selected project name visible while the request runs. If the server rejects the request, retain the project and explain that deletion did not finish. Let the person retry or cancel. Do not show a success message just because the button was clicked.

Also check a stale page: what should happen when a teammate has already removed the item? The interface should resolve the current state without trapping the user in an endless retry.

Review the flow with a small test list

Use a disposable test project, then check these cases:

Open the dialog using only the keyboard and read its title and consequence.
Move forward and backward through the controls; check Escape and Cancel.
Confirm one deletion and check where focus goes afterward.
Simulate a failed request and verify that the item still exists.
Check whether another user's view and any recovery screen match the promise in the dialog.

These checks do not replace a full accessibility review. They do give the deletion flow a concrete promise to meet: the user understands the choice, can operate it, and sees what actually happened.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

SaaS File Uploads: Make Selection, Errors, and Success Clear

Uriel Bitton — Fri, 25 Sep 2026 16:18:59 +0000

A useful file upload tells people what they can choose, what the system is doing, and whether their file is ready to use. Build those three parts together. A drop zone alone does not finish the job.

For a small SaaS, an upload may be the first time someone brings their own work into the product. That makes the details worth checking before adding a more elaborate interface.

State the rules before someone chooses a file

Put the supported formats, size limit, and file count beside the input. Use the same rules your server enforces. Avoid making people discover a limit only after a long transfer.

A hypothetical invoice tool might say: “Upload one PDF, up to 10 MB.” If a user needs several files, explain whether they can select them together or must upload them one at a time.

Use a visible label that names the task, such as “Upload an invoice.” Keep a keyboard-accessible file picker even if you also support dragging files onto the page.

Treat file selection as the start

Selecting a file does not necessarily mean it has been sent. Show the selected filename and make the next action clear. If uploading starts immediately, say so before selection. If it needs a button, use a label such as “Upload invoice.”

The HTML file input can guide selection with its accept attribute. MDN explains that this is a browser hint, not validation. The server still needs to validate the upload. A filename extension or a browser filter is not enough to establish that a file is safe or usable.

Let the user replace a mistaken selection before committing it where the workflow allows. Keep the filename visible so they can check their choice.

Write errors around the next action

“Upload failed” leaves several possible problems unresolved. Did the connection drop? Was the file too large? Was its format unsupported?

For the hypothetical invoice tool, useful messages could be:

“This file is larger than 10 MB. Choose a smaller PDF.”
“We couldn't upload the file. Check your connection and try again.”
“We uploaded the PDF, but couldn't read it. Try a clearer copy.”

These messages describe different states. Only show the last one when the file really reached the service and the processing step failed.

W3C's form notification guidance recommends clear feedback with instructions for fixing errors. Keep the message near the input, associate it with the control, and make dynamic feedback available to assistive technology. Color alone should not carry the meaning.

Separate transfer from processing

If the file needs scanning, parsing, or conversion after transfer, give that work its own status. “Uploaded. Checking the invoice…” is more useful than leaving a progress bar at 100% while the page remains unusable.

Only show a percentage when you can measure the relevant progress. Otherwise, a short status message is an honest choice. Avoid announcing every small progress change to a screen reader; meaningful state changes are easier to follow.

Finish with the result and the next action: “Invoice ready. Review the extracted details.” If processing can continue after the user leaves, explain where they can find its status later.

Try the uncomfortable paths

Use this review list before calling the flow finished:

Choose the wrong format, an oversized file, and an empty file.
Cancel the picker and choose the same file again.
Interrupt the connection, then try again.
Complete the flow with a keyboard and with a screen reader.
Check what a second click does while an upload is already running.

These are suggested checks, not reported test results. Your product may need more, including checks for its file-processing and security requirements.

For every path, ask: can the user tell what happened, keep their bearings, and take the next step? That is the standard a useful upload should meet.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

SaaS Pricing Page: Build Plan Selection With Real Radio Buttons

Uriel Bitton — Thu, 24 Sep 2026 18:53:00 +0000

A SaaS pricing page should let a visitor compare plans, choose one with a keyboard, and submit the choice through a normal form. Use native radio buttons inside a fieldset, keep visible labels, and treat the styled pricing cards as an enhancement of that form.

This gives you browser behavior, keyboard support, and a value that can be validated on the server without rebuilding a selection control from generic div elements.

Start with the form, not the cards

Each plan is one option in a single choice. That maps directly to radio buttons that share the same name.

<form action="/signup" method="post" class="pricing-form">
  <fieldset class="plans">
    <legend>Choose the plan that fits your team</legend>

    <label class="plan-card">
      <input type="radio" name="plan" value="starter" checked />
      <span class="plan-name">Starter</span>
      <span class="plan-price">$19 per month</span>
      <span>For one person testing a repeatable workflow.</span>
    </label>

    <label class="plan-card">
      <input type="radio" name="plan" value="team" />
      <span class="plan-name">Team</span>
      <span class="plan-price">$59 per month</span>
      <span>For a small team sharing work and permissions.</span>
    </label>

    <label class="plan-card">
      <input type="radio" name="plan" value="business" />
      <span class="plan-name">Business</span>
      <span class="plan-price">$149 per month</span>
      <span>For teams that need controls and priority support.</span>
    </label>
  </fieldset>

  <button type="submit">Continue with selected plan</button>
</form>

MDN recommends grouping a set of radio buttons with fieldset; the nested legend gives the group a caption. The shared name="plan" also means the browser submits one selected value.

Keep every plan label clickable

Wrapping the radio input inside its label makes the whole card part of the control. A visitor can click the text, price, or empty space inside the label.

Keep the input available to assistive technology. Do not use display: none on it. You can place it visually and style the card from its state.

.plans {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr));
  gap: 1rem;
  border: 0;
  padding: 0;
}

.plans legend {
  font-size: 1.25rem;
  font-weight: 700;
  margin-bottom: 1rem;
}

.plan-card {
  position: relative;
  display: grid;
  gap: 0.5rem;
  padding: 1.25rem;
  border: 2px solid #d6d6d6;
  border-radius: 0.75rem;
  cursor: pointer;
}

.plan-card:has(input:checked) {
  border-color: #5b45e0;
  background: #f6f4ff;
}

.plan-card:has(input:focus-visible) {
  outline: 3px solid #1a73e8;
  outline-offset: 3px;
}

.plan-name,
.plan-price {
  font-weight: 700;
}

Do not make color the only selected-state signal. Keep the radio control visible, add a border change, and make the keyboard focus easy to see.

If you need to support browsers without :has(), add a small progressive enhancement that toggles a class. The radio buttons should still work without it.

Put price details next to the choice

The visitor should not have to remember what a plan includes while choosing it.

Each card should answer:

What does it cost, including the billing period?
Who is it for?
What limit changes between plans?
Which important feature is included or excluded?
What happens after the visitor continues?

Use the same order for each card. Avoid putting the critical difference in a tooltip. Tooltips are easy to miss on touch screens and during keyboard use.

If monthly and annual billing change the displayed price, keep the billing period in the visible text and in the submitted data. A number without its period can create a false comparison.

Use JavaScript for feedback, not basic selection

You may want the button to repeat the selected plan. Read the checked radio instead of creating a second source of truth.

const form = document.querySelector('.pricing-form');
const button = form.querySelector('button[type="submit"]');

function updateButton() {
  const selected = form.elements.plan.value;
  const label = selected[0].toUpperCase() + selected.slice(1);
  button.textContent = `Continue with ${label}`;
}

form.addEventListener('change', updateButton);
updateButton();

The form remains usable if this script fails. JavaScript changes the feedback, while HTML keeps the selection and submission working.

Validate the plan on the server

The browser sends a string chosen by the client. Treat it as untrusted input.

const allowedPlans = new Set(['starter', 'team', 'business']);

if (!allowedPlans.has(request.body.plan)) {
  return response.status(400).send('Choose a valid plan.');
}

Look up the current price and entitlements on the server. Do not accept a price from a hidden field or query string. A visitor can edit client-side values before submitting the form.

Test the complete pricing path

Before saving the page, test these cases:

Tab to the selected option and move through the group with arrow keys.
Zoom the page and confirm the cards reflow without hiding content.
Click every part of each card.
Submit each plan and confirm the server receives the expected value.
Disable JavaScript and confirm selection and submission still work.
Use a screen reader to check that the group legend and plan labels are announced clearly.

A pricing page is a decision form. Native controls give that decision a reliable base, while the visual cards help people compare the options.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

Core Web Vitals for SaaS Landing Pages: Fix the First Visit

Uriel Bitton — Wed, 23 Sep 2026 17:40:54 +0000

A SaaS landing page should load its main message quickly, respond without delay, and stay still while a visitor reads or clicks. Measure the real page first, find which Core Web Vital is failing, and fix that path before running a general “speed optimization” project.

What are the three Core Web Vitals?

Google's current Web Vitals guidance defines three Core Web Vitals:

Largest Contentful Paint (LCP) measures loading performance. A good result is 2.5 seconds or less.
Interaction to Next Paint (INP) measures responsiveness. A good result is 200 milliseconds or less.
Cumulative Layout Shift (CLS) measures visual stability. A good result is 0.1 or less.

Evaluate the 75th percentile of page visits, split by mobile and desktop. A fast laptop test is useful for debugging, but it does not replace field data from real visits.

Start with field data

Open the deployed landing page in PageSpeed Insights. Check the “Discover what your real users are experiencing” section before the lab score.

Google's Core Web Vitals tools workflow recommends using field data to find the pages and metrics that need attention, then using Lighthouse and browser performance tools to diagnose the cause.

Ask three questions:

Is the failing data for this exact URL or the whole origin?
Does the problem affect mobile, desktop, or both?
Which one of LCP, INP, or CLS is outside the good range?

This keeps the work tied to a user problem. It also prevents a team from shrinking every icon while the real delay comes from the server or a large hero image.

Fix LCP: make the main content easy to find

On a SaaS landing page, the LCP element is often a hero heading or image. Inspect the element reported by PageSpeed Insights or Chrome DevTools instead of guessing.

If the hero image is the LCP element:

include it in the initial HTML;
avoid lazy-loading it;
serve an image close to its displayed size;
use a modern compressed format where it works;
give it high fetch priority when it is clearly the main visual.

<img
  src="/dashboard-hero.avif"
  width="1200"
  height="675"
  fetchpriority="high"
  alt="Dashboard showing a completed weekly report"
/>

Do not preload every image. That makes resources compete with each other. Google's LCP optimization guide recommends making the LCP resource discoverable in the HTML and prioritizing it without taking bandwidth away from other critical files.

If the LCP element is text, inspect server response time, blocking stylesheets, and web fonts. A fast image cannot repair a slow HTML response.

Fix INP: reduce work after a click

INP covers interactions across the visit. On a landing page, common problems include a pricing toggle, signup modal, chat widget, or menu that waits behind a long JavaScript task.

Start by recording a slow interaction in the browser Performance panel. Look for a long task that begins near the click or key press.

Then reduce the work:

load optional widgets after the main page is ready;
split large tasks so the browser can update between them;
remove JavaScript shipped for components the page does not use;
keep event handlers small;
avoid rebuilding a large part of the page for one simple interaction.

A delayed pricing toggle is not only a technical score problem. It makes the visitor wonder whether the control worked.

Fix CLS: reserve space before content arrives

CLS problems often appear when a hero image, embedded demo, cookie banner, or web font changes the layout after the visitor starts reading.

Give images and videos an intrinsic size or an aspect ratio:

.hero-demo {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

Reserve space for banners and embedded tools when their size is known. Avoid inserting a signup bar above content that is already visible. Google's CLS guide lists images without dimensions and dynamically injected content among the common causes of layout shifts.

Test the page beyond its initial load. Some shifts happen only after a visitor accepts a cookie notice, opens a menu, or waits for a widget.

Retest the same path

After each change:

Run a local performance trace to confirm the intended cause changed.
Deploy the fix.
Check the live page with PageSpeed Insights.
Monitor field data as new visits are collected.

Keep a short note with the page, metric, suspected cause, change, and result. This gives the next developer evidence instead of a vague instruction to “make the site faster.”

Core Web Vitals are useful because each metric points to a different part of the first visit. Fix the failed experience the metric describes, and keep the landing page's main promise visible throughout the work.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

SaaS Loading States: Tell Users When Work Is Really Finished

Uriel Bitton — Sun, 20 Sep 2026 02:19:49 +0000

A useful SaaS loading state tells people what is happening, whether they can leave, and what they can do next. Show success only when the promised result is ready. Accepting a request and finishing the work are different events.

Consider a fictional app that imports a contact list. The browser can finish uploading the file while the server is still checking rows. A cheerful “Done” at that point makes the screen describe a result the app hasn't produced yet.

Name the stage the user is waiting for

Give each stage a plain label. For this import, that might be “Uploading file,” “Checking rows,” and “Adding contacts.” Keep the label close to the action or result it describes.

Avoid showing a percentage unless it represents measured work. If the app knows that 80 of 200 rows have been checked, it can report that count. If it only knows that a job is waiting to start, “Waiting to start” is more honest than a slowly moving bar.

MDN's progressbar reference explains that an indeterminate progress bar has no current numeric value. It also recommends native HTML progress elements where suitable. Match the accessible value to the progress you can actually measure.

Define what finished means

Before choosing an animation, write the success condition in a sentence. For our example: “The accepted contacts are saved and available in the contact list.”

Then decide how the screen describes a partial result. If 190 rows were added and 10 need changes, show both counts and a way to inspect the rejected rows. Calling the entire job successful hides work the person still needs to do.

Treat these as separate states in the product design:

Waiting for work to begin.
Work in progress.
Finished with the full result.
Finished with items that need attention.
Failed, with a clear next action.

The exact states depend on the task. A payment, file upload, and report build should each describe their own real outcome.

Explain whether leaving is safe

Only say “You can close this page” if the job will continue and the person has a reliable way to find the result later. In the import example, that could be an import history page with the same job and its latest status.

If closing the page cancels an upload, explain that while the upload is running. Once the server has accepted the file and taken over the job, update the message to reflect that change.

A reload should restore the actual state when the product supports background work. Replacing an active job with an empty screen gives the user no useful account of what happened.

Make status changes available to screen readers

W3C's guidance on status messages covers changes such as waiting, progress, success, and errors that do not move focus. These messages need to be available to assistive technology through appropriate roles or properties.

Announce meaningful changes and test the result with a screen reader. Avoid moving keyboard focus merely to point at an ordinary progress update. Also avoid turning every tiny progress change into a stream of announcements.

Test the awkward endings

Try a slow connection, a failed request, a reload during processing, and a job with some invalid rows. Check what happens when someone clicks again because the first click appeared to do nothing.

For each case, ask whether the screen tells the truth and offers a safe next step. If a retry could repeat completed work, fix that behavior before presenting retry as the answer.

The final message should name the result: “190 contacts added. Review 10 rows.” Now the person knows where the work stands and what remains.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

SaaS CSV Exports: Give Users a File They Can Actually Use

Uriel Bitton — Fri, 18 Sep 2026 16:57:06 +0000

A useful SaaS CSV export lets a customer finish a job outside your app without guessing what the rows mean. Define the job, include clear labels and stable record IDs, and test the downloaded file in the tool the customer will use next. The download button is only the start of that handoff.

For a small product, one reliable export can be more useful than a menu of formats nobody has checked.

Start with the next task

Ask what happens after the file is downloaded. Does someone review overdue work in a spreadsheet, move records to another app, or keep a copy for later?

Imagine a fictional project tracker. Its customer wants to review open tasks with a client. An export of every database field would include more than that conversation needs. A focused file could contain task ID, title, status, owner label, and due date.

Make the scope visible before export: this project, open tasks, and the selected date range. A customer should not have to count rows to discover that only one screen of results was included.

Give every column a clear meaning

Choose headers that make sense without the app beside them. If a date includes a time, explain its timezone. If a value is an amount, name the currency or provide a currency column. Define whether a blank means unknown, not set, or not applicable.

Keep a stable record ID when people may need to match the file back to the product. A task title can change; a matching process needs a more dependable reference.

Write a short field guide beside the export control or in help content. For the project tracker, explain whether the due date is a calendar date and which statuses count as open. These are product choices you should make explicitly.

Use a CSV writer and test awkward values

RFC 4180 documents common CSV conventions, including consistent field counts and quoting fields that contain commas, quotes, or line breaks. It is an informational document, not a guarantee that every spreadsheet program behaves identically.

Use an established CSV library for your runtime instead of joining values with commas by hand. Then check a small sample with a comma in a title, a quotation mark, a line break, a blank field, and non-English text.

Open the result in the destination your customers actually use. Confirm that one task remains one row and the values stay in the intended columns. Keep those samples as regression checks when the export changes.

Treat spreadsheet formulas as a separate risk

Correct CSV quoting does not settle every spreadsheet risk. OWASP describes CSV injection, where untrusted values can be interpreted as formulas when a spreadsheet opens the file. It also notes that there is no single sanitization strategy that suits every spreadsheet and downstream use.

Choose protections for the destination and test them, including saving and reopening the file. Document any transformation that changes the underlying value. A file meant for human review and a file meant for another program may need different handling.

Keep exports subject to the same access rules as the records on screen. Test with an account that has limited access as well as an owner account.

Check the handoff from a fresh download

Run the export as a normal user. Check the filename, scope, row count, headers, and sample values. Repeat with no matching records and enough records to cross the app's page limit.

For a long export, explain whether it is still running, finished, or failed. Give the user a clear way to retry without mistaking an old download for a new result.

The acceptance check is concrete: can the customer open this exact file, understand what it contains, and complete the task they came for?

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

SaaS Empty States: Help a New User Finish the First Task

Uriel Bitton — Thu, 17 Sep 2026 13:27:30 +0000

A useful SaaS empty state explains what belongs on the screen and gives the user one clear next step. First check why the screen is empty. A new account, a search with no matches, and a failed request need different messages and actions.

Treat the empty state as part of the first task. Its job is to help someone create a real result they can come back to.

Name the state before writing the message

Imagine a small app for collecting customer interview notes. A blank list might mean the account has no interviews yet. It might also mean a filter hides every saved note, or that the app could not load the list.

Carbon's empty-state guidance separates first-use, user-action, and error situations. Use that distinction in your rendering logic before polishing the copy.

Keep the loading state separate too. Showing “No interviews yet” while a request is still running tells the user something you have not established.

Give the first screen one useful action

For a new account, try a heading such as “Your interview notes will appear here.” Add a sentence explaining the result: “Create an interview to keep its notes and follow-up questions together.”

The primary action could be “Create an interview.” That label tells the user what will happen. “Get started” leaves more guessing to do.

Do not put five setup tasks into this one panel. If creating an interview needs a project first, make the next action create the project and explain that dependency. The right button is the first step a new user can actually complete.

Make each recovery action fit the problem

When a filter returns no matches, preserve the user's search and offer a way to clear the filter. Sending them to the create form would answer the wrong question.

When loading fails, say that the notes could not be loaded. Offer a retry if retrying is supported. Keep any data the user already entered while they recover.

For a permission problem, explain who can grant access if your product has that information. Do not show a create button that the current role cannot use.

A short set of named states can make these choices easy to review:

Loading: wait for the current request.
Load failed: retry the same request.
No saved interviews: create the first interview.
No matching interviews: adjust the current filter.
Access unavailable: use the supported access process.

These are example product states. Adapt them to your app's real behavior instead of adding branches that cannot occur.

Continue the task after the click

Test the whole path with a new account. Click the action, complete the smallest valid form, save, and return to the list. Check that the new item appears and can be opened.

Then cancel halfway through. The app should return to a state that still makes sense. Try a failed save as well; a friendly first screen cannot compensate for losing the user's first set of notes.

Use a sample item only when it teaches something that the empty screen cannot. Label it as sample content, and make the difference from saved customer work clear.

Review the screen without its illustration

Temporarily ignore the artwork and read only the heading, explanation, and action. You should still understand what is missing and what to do next.

Check the screen with keyboard navigation, long button labels, a narrow window, and the roles your product supports. Record whether the user completed the first task, rather than only whether they clicked the button.

The useful test is simple: can a new user turn this empty space into one saved result, and find that result again?

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

Carbon Design System: Empty states

SaaS Signup Forms: Make Errors Easy to Fix

Uriel Bitton — Wed, 16 Sep 2026 17:12:32 +0000

Make a signup error useful by naming the field, explaining the problem, and showing the next action. Keep valid entries in place and test the path from a failed submission to a successful one. The recovery path deserves its own review before you send more traffic to the page.

A form can look finished when every test uses correct input. The more revealing test starts with a mistake.

Write the correction before styling the error

For a fictional workspace signup, imagine that the visitor enters a workspace name with spaces, but the product needs a short URL segment. A red border alone does not explain the rule.

A useful message could say: “Use letters, numbers, and hyphens for your workspace address.” Only use that wording if it matches your actual rule. Show the rule before submission too, so the visitor has a chance to get it right.

W3C's form notification guidance recommends clear error descriptions with instructions for correction. It also describes linking an error summary to the affected controls.

Use the same field name in the label and message. A visitor should not have to work out that “tenant identifier” means the field labelled “Workspace address.”

Connect the message to the field

The error should be available to people using assistive technology. W3C shows how aria-describedby can associate a field with its error message. Here is a small markup example for an error that has already been found:

<label for="workspace">Workspace address</label>
<input
  id="workspace"
  name="workspace"
  value="my team"
  aria-describedby="workspace-error"
>
<p id="workspace-error">
  Use letters, numbers, and hyphens for your workspace address.
</p>

This snippet shows the relationship between a field and a message. It does not validate input or implement the full submission flow. When you change the message, keep that relationship intact and test what is announced in the finished interface.

Let the browser help, then check the server

Start with HTML controls and constraints that match the data you need. For example, required marks a mandatory field, and type="email" provides an email-format check. MDN's form validation guide explains these built-in features and when JavaScript can add custom behavior.

An email-format check does not establish that someone owns an address. Also, browser checks can be bypassed. MDN recommends validating submitted data on the server as well.

Keep the two layers consistent. If the browser accepts a workspace address that the server rejects, show the server's reason in language the visitor can act on.

Test recovery as a complete task

Use a few deliberate scenarios in your review:

Leave a required field empty, submit, and correct it.
Enter an address that fails the product's real format rule.
Submit a valid form while the service is temporarily unavailable.
Correct one field and check that the other valid entries remain.
Complete the same task using the keyboard.

For each scenario, record the starting input, the response, and the next action. Do not record real passwords or customer data in a shared test note.

A service failure needs a different message from invalid input. If the server cannot respond, telling the visitor to “check your details” sends them toward the wrong repair.

Confirm the actual next state

After a successful submission, explain what happened. If an account exists, say so. If the visitor still needs to confirm an email address, explain that step. W3C includes success feedback alongside error feedback because both tell the user whether the task is complete.

Review the words against the product's real behavior. A clear success message is the last part of the same recovery path: the visitor should know when they can stop fixing the form and move on.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

SaaS Demo Data: Show One Complete Workflow

Uriel Bitton — Tue, 15 Sep 2026 14:41:37 +0000

A useful SaaS demo gives visitors a small, believable task they can finish with sample data. Start with one coherent scenario, keep its records consistent across screens, and make it easy to return to the starting state. A crowded dashboard can show features while leaving the product's purpose unclear.

For an early product, demo data is part of the explanation. It tells the visitor who they are, what needs attention, and what a successful result looks like.

Choose the task before generating records

Write the task in one sentence. For a fictional client-review tool, it might be: find the design waiting for feedback, leave a comment, and mark the review complete.

That sentence tells you which data you need. You need a project, a reviewable file, a pending status, and a place for feedback. You probably do not need fifty customers or a year's worth of activity.

Use the same task to check the demo later. If the visitor cannot reach its result, more realistic names and avatars will not repair the missing path.

Keep the sample story consistent

Create a small set of records you control. The following JavaScript object is an illustrative fixture, meaning a repeatable set of sample data. It is not a complete application or a production data model.

const demo = {
  project: { id: "project-demo", name: "Sample studio website" },
  review: {
    id: "review-demo",
    projectId: "project-demo",
    fileName: "Homepage draft",
    status: "waiting_for_feedback"
  }
};

The names and IDs are fictional. The useful part is the relationship: the review belongs to the project, and its status gives the visitor a reason to act.

Use those same records on the project list, review screen, and activity view. If one screen says the review is waiting while another calls it complete, the visitor has to solve a data puzzle before understanding the product.

Include the state that explains the value

Perfectly finished data leaves nothing to do. Give the scenario one clear open task and enough surrounding context to make it believable.

For the sample review tool, include a prior comment and a design that still needs a decision. After the visitor completes the task, show what changed. The new status and comment should be visible where a person would look for confirmation.

Keep an empty state available as a separate example when it matters. A visitor should also be able to understand what starting a new project would involve. Do not mix unrelated states into the same story merely to fill every component.

Make the demo easy to reset

Choose a reset approach that fits the implementation. A local interactive demo might rebuild its state from the fixture. A hosted demo could create a separate sample workspace for each session. Treat those as design options, not interchangeable security solutions.

Define what the reset restores: records, comments, statuses, and any sample uploads. Then try the whole task twice. A second visitor should not inherit a confusing half-finished review from the first.

Keep demo actions separate from real customer operations. If a button would normally send an email or charge a card, explain what it does in the demo and prevent it from triggering the real operation.

Label the limits of what people are seeing

The GOV.UK guide to making prototypes distinguishes realistic interactions from production-ready code. Apply that distinction clearly: a convincing sample screen is not evidence that every underlying service is ready.

Tell visitors that the workspace uses sample data. Label simulated actions and show which parts they can actually try. Avoid using real customer exports as a shortcut to a busy-looking screen.

Before sharing, open a fresh session and complete the task without your usual explanation. Check the links, reset behavior, and final state. The demo is ready when the sample story still makes sense after someone interacts with it.

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.

Sources

GOV.UK Service Manual: Making prototypes

Track SaaS Signups in GA4 Without Counting Every Click

Uriel Bitton — Mon, 14 Sep 2026 16:38:10 +0000

Track a SaaS signup when a new account has been created successfully. Keep the signup button click, the completed account, and the first useful product action as separate events. They answer different questions, and combining them can hide where people stop.

Before adding tracking code, write down the exact state that counts as success. A dashboard is easier to trust when its event names describe real changes in the product.

Define the completed signup in plain words

For a sample app, the definition might be: a new account exists, the creation request succeeded, and the user can continue into setup. If your product requires verified email before the account is usable, decide which stage you need to measure and name it clearly.

Google's recommended event reference defines sign_up for account signup and allows a method parameter. Use that event for a completed signup, with a simple value such as Email or Google to describe the method.

Do not send it from the button's click handler. A person can click and then fail validation, hit a network error, or discover that the account already exists.

Trigger the event from a confirmed result

Put the tracking call in the part of your app that handles successful creation. The following small example shows the analytics call only; it assumes the Google tag is already configured and any required consent is in place.

gtag('event', 'sign_up', {
  method: 'Email'
});

Google's event setup guide explains how these calls fit into a tagged website. Connect this call to your app's confirmed result rather than copying it into a generic page-load effect.

Choose one place that owns the event. If both the signup component and the welcome page send it, one account may produce two events. If an authentication callback runs again, it should not automatically mean a second account was created.

Keep your application's account records as the source for whether creation succeeded. An analytics event is a report about that outcome, not the operation that creates the account.

Keep first value separate from account creation

A new account does not tell you whether the person reached the result your landing page promised. Pick a second event for the first useful task.

For a sample file-checklist app, that might be a checklist created with at least one requested file. Write the definition before choosing the name. Explain whether the event means the first occurrence per account or every completed checklist.

Use an existing recommended event when its meaning fits. Otherwise choose a clear custom event and document it. Do not force every product action into an onboarding event merely because that event already exists.

Test the paths that create misleading counts

Run a small set of cases before using the report to judge marketing:

A valid signup creates one account and sends one signup event.
Invalid input sends no completed-signup event.
An existing user signing in does not count as a new signup.
A failed request followed by a successful retry does not count twice.
Refreshing the welcome page does not create another signup event.

Inspect the events and parameters in GA4's Realtime or DebugView tools, as described in the setup guide. Compare what appears there with the outcome you observed in the app. This is a check of the tracking path, not a guarantee that every future event will arrive.

Keep private information out of event fields

Use a short list of approved parameter values. An account email, a person's name, or a support message does not belong in a signup method field. Google's guidance on avoiding personally identifiable information is the relevant starting point when reviewing what your implementation sends.

Also inspect page addresses and query strings. A harmless event name does not make a URL containing personal details safe to collect.

When you share progress publicly, label the measure precisely: completed accounts, first useful tasks, or paying customers. That small writing habit forces a useful engineering question: does the event actually prove what the sentence says?

Sources

Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.

Subscribe for more stories on growing your audience by building in public.

Join us on Buildside: the social network for founders building in public.