By the time they decide to build one, they’ve already aligned on the problem, secured funding, debated priorities, and maybe even started planning delivery. At that point, the prototype is only serving engineering.

I think the most valuable prototypes also serve leadership.

Their job isn’t to prove that software can be built. That’s never the question anymore. The real question is whether the organization should build it in the first place.

That distinction matters even more as leaders try to figure out where AI fits into their teams.

In regulated industries, those conversations often stall before they really begin. Questions about security, compliance, governance, procurement, and privacy arrive almost immediately…and they should. Those organizations carry responsibilities that startups don’t.

But I’ve noticed that teams often treat experimentation and delivering the tool in production as the same decision.

They’re not.

Before deciding whether an AI solution belongs in production, leaders need to be aligned on the problem they’re trying to solve.

Too many organizations skip that big step. They compare vendors before they’ve validated a workflow. They debate architecture before stakeholders have experienced the idea. They spend months discussing a tool that exists only in PowerPoint.

That’s a problem because on their own, slide decks are terrible tools for making product decisions. They create the illusion of alignment. Everyone leaves the meeting believing they agreed, when in reality each person imagined a different product.

I’ve seen how quickly those differences surface when teams are asked to make even a simple product decision. The Toast exercise is a two-minute example that gives people the same problem and you’ll quickly discover that they’re often approaching it with very different assumptions.

A prototype changes the conversation. It makes those assumptions visible and gives the team something concrete to discuss.

Instead of debating opinions, people react to something concrete. A compliance leader spots a real concern. A customer support manager notices that the workflow doesn’t reflect how the team really works. An executive who was skeptical suddenly understands the opportunity because they can see it instead of imagining it.

The prototype isn’t valuable because it looks polished.

It’s valuable because it replaces our assumptions with evidence.

That’s why I think prototypes are leadership tools before they’re product development tools. Their greatest value isn’t accelerating delivery of a product. It’s accelerating understanding of a problem.

Those are different things.

In fact, some of the most valuable prototypes don’t become products.

I’ve written before about building prototypes using today’s no code tools to move from an idea to something people can actually experience remarkably quickly. But speed isn’t valuable only because it gets us to a product faster. It’s even more valuable when it gets us to learning faster.

If a three-day prototype prevents an organization from spending nine months building the wrong thing, it has done its job. Nothing was wasted. It improved a decision.

That’s particularly important in regulated industries, where innovation isn’t usually constrained by a lack of ideas. It’s constrained by a lack of evidence.

Compliance teams aren’t trying to stop innovation. Security teams aren’t resistant to change. They’re asking the right questions like, “show me enough to understand the risks.”

A thoughtful prototype can often answer that question far better than another steering committee or another strategy deck.

To be clear, organizations should not skip governance or rush AI into production. I believe that they should separate learning from deployment. Those are different decisions, and they deserve different processes.

A prototype doesn’t need production infrastructure, enterprise integrations, or sensitive data. It needs just enough fidelity to help the right people have a better conversation.

Because that’s what a prototype really is…a conversation that helps an organization decide what to do next.

Move fast and break things may have been a popular mantra for startups, but the nature of healthcare software demands no room for breaking things while still moving fast.

We commissioned a third-party research firm to survey tech leaders at established healthcare and health tech organizations about the tensions they are experiencing when it comes to software delivery. We wanted to learn what’s working, what isn’t, and what’s next.

A few things stood out:

• 68% say speed and risk are in constant tension. When we asked why, we learned that the top blocker isn’t what most teams assume.
• 58% report spending more time navigating approvals than actually building product.
• 94% of leaders say they’d rather work with a team that ships reliably than one that simply ships fast.

Check out our (ungated) report to see the stats that jumped out at us. Plus learn how your team compares to the industry average as well as other useful resources.

• npm: @thoughtbot/react-native-social-auth
• Github: github.com/thoughtbot/react-native-social-auth

import {
  GoogleSignIn,
  GoogleSignInButton,
} from '@thoughtbot/react-native-social-auth';

GoogleSignIn.configure({
  webClientId: 'YOUR_WEB_CLIENT_ID.apps.googleusercontent.com',
  iosClientId: 'YOUR_IOS_CLIENT_ID.apps.googleusercontent.com',
});

<GoogleSignInButton
  onPress={async () => {
    const credential = await GoogleSignIn.signIn();
    console.log(credential.user.email);
  }}
/>

That’s the whole surface for a happy-path sign-in.

Google has been modernizing its Sign in with Google stack on both Android and iOS.

On Android, the legacy GoogleSignInClient API from Google Play services is deprecated and will be removed in a future release. Google recommends migrating authentication flows to Credential Manager, a unified API for passwords, passkeys, and federated identity providers, including Sign in with Google. It is the recommended approach for new Android apps implementing authentication.

On iOS, version 8 of the Google Sign-In SDK added Firebase App Check support, which helps verify that sign-in requests originate from an authentic instance of the app. Version 9 added support for supplying a custom cryptographic nonce. When the nonce is validated by the server, it helps bind the ID token to a specific authentication request and protect against replay attacks. Together, these features strengthen the security of the authentication flow. See Google’s iOS SDK release notes and OpenID Connect documentation.

Many existing React Native libraries still target the previous generation of Android APIs or older versions of the iOS SDK. Although they may continue to support basic Sign in with Google flows, Android integrations built on the deprecated API will eventually need to migrate. Apps using older integrations also miss newer platform capabilities such as Credential Manager’s bottom-sheet interface, automatic sign-in, and structured error handling.

We built react-native-social-auth to close that gap.