Isar Aerospace reaches orbit: lessons for React developers

Isar Aerospace's first rocket flew for about 30 seconds and fell into the Norwegian Sea. On the second flight, it reached orbit and released the payloads it was carrying. That's the news, and it's big news for Europe. You might be wondering why it shows up on a blog about code. Here's why: the way Isar Aerospace handled failure is exactly what I'd like to see in more React teams.

I'll explain what happened first. Then I'll pull out the part that matters for your day-to-day work.

What Isar Aerospace achieved on its second flight

Isar Aerospace is a German startup founded in 2018 near Munich. Its rocket is called Spectrum. It has two stages, stands about 28 meters tall, and has nine Aquila engines on the first stage and one on the second. It can carry around one ton to low Earth orbit. It's a small rocket built for small satellites, which make up most satellites today.

It launches from Andøya, in northern Norway. According to the official press release, Spectrum reached orbit and deployed its payloads on the second flight. For Europe, that carries weight. The continent relied almost entirely on Arianespace, and a private orbital rocket lifting off from continental Europe had never happened before.

Why a 30-second first flight wasn't a failure

In March 2025, Spectrum lifted off, lost attitude control, and the flight termination system kicked in. The rocket fell into the water near the launch site. The easy headline would be "German rocket explodes." The company said something else. The flight produced real data on engines, structure and software under flight conditions. That was what they wanted from the first test.

It sounds like PR talk. But the second flight worked, and now the claim has evidence behind it. They didn't spend five more years running simulations. They launched, measured, fixed and launched again.

Failure with data is progress. Failure without data is just noise.

Two details from the first flight apply to any software:

• The rocket knew it was failing. It had sensors to detect the deviation.
• There was a plan for when it failed. The termination system exists so that one error doesn't turn into a bigger disaster.

Now think about your React app in production. Does it know when it's failing? And when it fails, what happens?

What a rocket has to do with React

More than you'd think. SpaceX's Crew Dragon capsule has touchscreens with an interface running on Chromium and JavaScript. Mission control telemetry dashboards are increasingly web applications. In other words, there are React screens (or something close) in places where an error is expensive.

Luckily, your Friday afternoon deploy won't fall into the Norwegian Sea. But it can take down the whole checkout because of an undefined in a recommendations component. And in most projects I see, nobody finds out until a customer complains on WhatsApp.

The comparison is straightforward:

• The flight termination system is your error boundary. It isolates the failure.
• Telemetry is your error reporting and metrics. It tells you what happened.
• The second flight is your next deploy, which only gets better if the first one produced data.

How to use error boundaries the right way

Here's the strong opinion in this post: a single error boundary around the whole app is almost the same as having none. If the sales chart breaks, the entire screen turns into "Something went wrong." The user loses the form they were filling out because of a widget that didn't even matter.

The right approach is to isolate by region. Every part that can fail on its own gets its own boundary. With the react-error-boundary library, it looks like this:

import { ErrorBoundary } from 'react-error-boundary'

export function Dashboard() {
  return (
    <main>
      <Summary />
      <ErrorBoundary
        fallback={<p>Chart unavailable right now.</p>}
        onError={(error, info) => report(error, info.componentStack)}
      >
        <SalesChart />
      </ErrorBoundary>
      <OrderForm />
    </main>
  )
}

If the chart breaks, the rest of the page stays up. Orders keep coming in. It's the rocket shutting down one engine instead of blowing up the mission.

Two practical rules I follow:

1. Put a boundary around anything that depends on external or third-party data: charts, embeds, recommendations, widgets.
2. Write fallbacks in the user's language. "Chart unavailable right now" beats a blank screen, and it's far better than a stack trace.

An honest reminder: error boundaries don't catch errors in event handlers, async code or SSR. For those you still need try/catch and proper handling in your data layer. A boundary is a safety net, not a shield against everything.

Telemetry comes before new features

Isar could only fix Spectrum because it knew exactly what went wrong. In React 19 you get a native hook for this when you create the root:

import { createRoot } from 'react-dom/client'

const root = createRoot(document.getElementById('root')!, {
  onCaughtError: (error, info) =>
    report('caught', error, info.componentStack),
  onUncaughtError: (error, info) =>
    report('uncaught', error, info.componentStack),
})

root.render(<App />)

onCaughtError fires when a boundary caught the error. onUncaughtError fires when nothing caught it. The report function can send data to Sentry, to your own endpoint or even to a Postgres table. The destination matters less than the habit. Every production error needs to leave a trace, with the componentStack attached.

Here's a real example of how this changes things. In an app I maintained, about 3% of sessions had errors and we had no clue why. After turning on reporting with component stacks, we found that 80% came from a single address component. It broke whenever an address had no unit number. The fix was two lines. We went months without finding it because we weren't measuring.

If you can only do one thing this week, do this. Shipping new features without telemetry is like launching a rocket with your eyes closed.

What actually changes for you

Nothing in your package.json changes because of a German rocket. It would be dishonest to say otherwise. What changes is the argument you bring to your next planning meeting.

When someone asks to hold the release until "everything is perfect," remember Spectrum. The team that ships small, measures and fixes usually goes further than the team waiting for the perfect version. But it only works with both pieces in place: failure isolation and data about the failure. Shipping fast without them isn't iteration. It's just luck.

To sum up the checklist:

• Error boundaries per region, not just one at the top.
• onCaughtError and onUncaughtError wired up and sending data somewhere.
• Fallbacks that keep the rest of the screen working.

Isar Aerospace needed two flights to reach orbit. Your app might need two deploys to stop breaking in the same place. What matters is that the first one teaches you something. If you want to see how I apply this in my own apps, take a look at the projects I maintain.

Isar Aerospace's first rocket fell into the sea after 30 seconds. The second one reached orbit.

There was no magic between the two flights. There was data. The rocket knew it was failing, and it had a plan for when that happened.

A lot of React apps in production have neither. Checkout breaks because of an undefined and nobody finds out until a customer complains on WhatsApp.

One error boundary per region, not just one at the top. onCaughtError and onUncaughtError sending errors somewhere. A fallback that keeps the rest of the screen working.

Failure with data is progress. Failure without data is just noise.

I wrote the full comparison, with code, on the blog. If it makes sense for your team, the link is in the comments.

#React #Frontend #Observability #SoftwareDevelopment #JavaScript