• A dating app in Australia typically costs between AUD 15,000 and AUD 300,000, depending on features and team.
• Feature scope, team location and platform choice decide most of the price.
• Hosting, moderation and maintenance add 15% to 25% of the build cost every year.
• The cheapest quote often becomes the most expensive build once fixes start.
• A phased build with a fixed scope per phase is the safest way to control the budget.

Dating app development cost is the first question every founder asks, and the honest answer is a range. A simple app with profiles, swipes and chat is a different build from one with AI matching and video calls. This guide gives you Australian numbers, explains what moves them, and shows where budgets quietly blow out.

Dating app development cost by complexity

Most projects fall into three bands. These figures assume a blended team billing in Australian dollars, covering both iOS and Android.

A basic MVP has sign-up, profiles, photo upload, swipe or browse matching, in-app chat, push notifications and an admin panel. Expect AUD 15,000 to 50,000 and three to five months. The low end usually means a tight feature list and a cross-platform build.

A mid-level app adds video profiles, in-app calls, filters, subscriptions, verification badges and analytics. Budget AUD 50,000 to 150,000 over five to eight months.

An advanced app adds AI-driven matching, behaviour-based recommendations, icebreaker suggestions and photo safety checks. That means AUD 150,000 to 300,000 and eight to twelve months.

To see how a specific feature set prices out, this breakdown of the dating app development cost for a premium relationship-focused product is a useful reference point.

What drives dating app development cost up or down

Four things move the number more than anything else.

1. Feature scope. Every extra feature (video, voice notes, stories, events) adds design, build and testing time. Cutting three features from a first release can save 20% or more.
2. Team location. Australian agencies typically charge AUD 120 to 200 per hour. Offshore rates are often AUD 40 to 80. Many founders split the work, with strategy and design close to home and engineering delivered by a larger team.
3. Platform choice. Two separate native apps cost more than one cross-platform build in Flutter or React Native. For most dating apps, cross-platform is enough and saves around 25% to 35%.
4. Backend complexity. Real-time chat, location matching and media storage need a backend that handles traffic spikes. Weak architecture is cheap at launch and expensive at 50,000 users.

Design matters more than people expect. Dating apps live or die on first impressions, and a polished onboarding flow often pays for itself in retention.

How to choose a dating app development company in Australia

The cheapest quote is rarely the best one. Founders who pick the lowest bid often spend double fixing a chat system that cannot handle concurrent users.

Use this checklist when comparing teams:

• Have they shipped consumer apps with real-time chat, not just brochure sites?
• Can you speak to a past client?
• How do they handle moderation, reporting and blocking?
• Will you own the source code, design files and cloud accounts from day one?
• How do they price change requests once the prototype exists?

A team that answers these clearly usually delivers clearly. That is the standard 7 Pillars works to, starting with your niche and budget and recommending the smallest product that can prove demand. If you are considering AI matching, this guide from a dating app development company that publishes its stack and costs openly shows what a transparent estimate looks like.

Hidden costs Australian founders miss

The build quote is only part of the spend. Plan for these from the start.

• Cloud hosting and storage: AUD 500 to 3,000 a month, depending on user numbers and video use.
• App store fees: Apple charges USD 99 a year and Google charges a one-time USD 25.
• Third-party services: SMS verification, push notifications, email and maps APIs usually bill per use.
• Moderation: automated photo screening plus a human review process.
• Maintenance: 15% to 20% of the build cost each year for updates, OS changes and bug fixes.

Compliance is the other cost. The Privacy Act 1988 and the Australian Privacy Principles apply to the personal data you collect, and dating apps collect sensitive information such as sexual orientation. The Online Safety Act 2021 also gives the eSafety Commissioner powers over harmful content, so reporting tools and clear takedown processes are worth building early. Get legal advice on your privacy policy before launch, not after.

Ways to keep dating app development cost under control

You can control the budget without gutting the product. These moves work in practice.

Start with a niche. An app for a specific community, city or interest needs fewer users to feel alive and makes early marketing cheaper.

Launch with matching, chat and profiles only. Add video, AI features and premium tiers once you have real usage data. Retention after 90 days will tell you what to build next far better than a guess.

Use proven services for solved problems. Authentication, payments and push notifications do not need to be built from scratch.

Set a fixed budget per phase and agree the scope in writing. A working release every four to six weeks lets you stop or redirect before money is wasted.

Plan monetisation early. Subscriptions, boosts and super likes are cheaper to design in than to retrofit.

This phased, scope-first method is how 7 Pillars runs dating app projects, and it is the reason founders leave a first call with a feature list and a realistic estimate rather than a vague quote.

FAQs

How much does it cost to build a dating app in Australia?

Most Australian projects cost between AUD 15,000 and 300,000. A basic MVP sits at the low end, while apps with AI matching, video and heavy moderation sit at the high end.

How long does it take to build a dating app?

An MVP takes three to five months. A mid-level app takes five to eight months, and an advanced app can take up to a year.

Is it cheaper to hire an offshore team?

Usually, yes. Hourly rates can be half or less. The risk is communication gaps and time zones, so many founders keep product and design local and outsource engineering.

What ongoing costs should I expect after launch?

Hosting, third-party services, moderation, app store fees and maintenance. A safe planning figure is 15% to 25% of the initial build cost each year.

How can I get an accurate estimate for my dating app idea?

Share your niche, must-have features and budget with a development team and ask for a phased estimate. 7 Pillars offers scoping calls where you get a feature list and phase-wise costing before you commit.

Dating App Development Cost in Australia: 2026 Guide was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before We Begin

You’ve shipped features. Fixed bugs at 2 a.m. Reviewed a mountain of pull requests.

Then the interviewer smiles and asks, “So, what’s the temporal dead zone?”

And your brain returns… undefined.

Or it’s closures. Or Promise.race. Or starvation. Or inversion of control.

Quick check: if you just answered all of those in your head, congratulations. Close this tab and go get a coffee, you’ve earned it. Still here? Welcome. You’re in very good company.

This isn’t a knowledge problem. It’s a recall problem. We use these things every day. We just stop calling them by their names.

So here’s your cheat sheet, in two parts. Part 1 is how JavaScript thinks: 11 fundamentals, each with a one-line answer, a tiny example and a picture.

Five minutes before the interview? Just read the one-liners at the top of each section and the Remember it lines.

Let’s go.

1. JavaScript and the Execution Context: Where It All Begins

In one line: JavaScript is a synchronous, single-threaded language, and all code runs inside an execution context.

Picture JavaScript as a chef with one pair of hands. One dish at a time, in order. No multitasking, no skipping ahead.

The kitchen: execution context

Every program gets one big kitchen, the Global Execution Context. It’s set up in two phases:

1. Memory phase (gather the ingredients): variables and functions get memory as key-value pairs. Variables start as undefined.
2. Code phase (start cooking): code runs one line at a time.

Call a function, and a new mini kitchen opens inside the big one. When the function returns, it closes.

var n = 10;

function square(num) {
  var ans = num * num;
  return ans;
}

square(n);

Memory side = Variable Environment. Code side = Thread of Execution. (The diagram shows n: 10, which is memory after the code has run.)

Remember it: Two phases, memory then code. Every function call gets its own execution context, which disappears when it returns.

2. Hoisting: Using Things Before You Write Them

In one line: variables and functions get memory before the code runs, so you can use them before they’re declared.

Think of a restaurant that reserves your table before you arrive. The table is ready, but the chair is empty. That empty chair is undefined.

Functions are the VIP guests. They arrive fully seated, so calling them early works.

console.log(n);   // undefined
greet();          // "Hello!"

var n = 10;

function greet() {
  console.log("Hello!");
}

Remember it: Hoisting = memory first, code later. var gives undefined early, functions work fully.

3. let, const and the Temporal Dead Zone: The Waiting Room

In one line: let and const are hoisted too, but you can't touch them until their line runs.

var is the relaxed guest: "I'm here, I'm just empty."

let and const sit in a waiting room from the moment they're hoisted until their line runs. That waiting room is the temporal dead zone. Call them out early, and JavaScript throws an error.

console.log(a); // undefined
console.log(b); // ReferenceError: Cannot access 'b' before initialization

var a = 10;
let b = 20;

Interview trap: two errors that look alike

• Cannot access 'b' before initialization: it exists, it's just still in the waiting room.
• b is not defined: it was never declared at all.

Remember it: The temporal dead zone is the time between hoisting and initialization of let and const. Access them there, and you get a ReferenceError.

4. Scope and the Scope Chain: Who Can See What

In one line: scope is where a variable can be used, and it’s decided by where the code is written.

Think of rooms inside rooms. A child room can peek into its parent’s room, all the way out to the front door. But a parent can never peek into the child’s room.

“Lexical” sounds fancy, but it only means where the code physically sits.

• Lexical environment = local memory + a reference to the parent’s lexical environment.
• Scope chain = the path JavaScript follows to find a variable: own room, then parent, then all the way to global.

function a() {
  var x = 7;

  function c() {
    console.log(x); // 7, found in the parent's room
  }

  c();
}

a();

Fun fact: even an empty JavaScript file gets a global execution context. In the browser, you also get a free window object and a this that points to it.

Remember it: Lexical environment = local memory + parent’s reference. Following those references upward is the scope chain.

5. Block Scope and Shadowing: What Happens Inside { }

In one line: let and const stay inside the curly braces. var escapes.

A block is code wrapped in { }, also called a compound statement. It lets you put many statements where JavaScript expects just one, like after an if.

Inside a block, let and const get their own private memory space. var doesn't care about walls. It walks right out.

{
  var a = 10;
  let b = 20;
}

console.log(a); // 10, var escaped
console.log(b); // ReferenceError, let stayed inside

Shadowing: the inner one wins

Same name inside and outside a block? Inside the block, the inner variable “shadows” the outer one. Outside, the outer one is untouched.

let b = 100;

{
  let b = 20;
  console.log(b); // 20
}

console.log(b); // 100

Illegal shadowing: when var breaks the rules

let a = 10;

{
  var a = 20; // SyntaxError: Identifier 'a' has already been declared
}

var tries to escape the block and crashes into the let that already lives outside. (The reverse, var outside and let inside, is perfectly legal.)

Remember it: Block = code in { }. Shadowing = the inner variable hides the outer one. Shadowing a let with a var is illegal.

6. Closures: The Function With a Backpack

In one line: a closure is a function bundled together with its lexical environment.

When a function leaves home, it packs a backpack with every variable it could see. Even after its parent function is long gone, the backpack stays on.

function x() {
  var a = 7;
  function y() {
    console.log(a);
  }
  a = 100;
  return y;
}

var z = x();   // x is done and gone
z();           // 100

Plot twist: it prints 100, not 7. The backpack holds references, not photocopies. Change the value, and the closure sees the change.

The famous setTimeout loop

for (var i = 1; i <= 3; i++) {
  setTimeout(() => console.log(i), i * 1000);
}
// 4, 4, 4

for (let i = 1; i <= 3; i++) {
  setTimeout(() => console.log(i), i * 1000);
}
// 1, 2, 3

With var, all three callbacks share one i. With let, every loop round gets its own fresh i.

Data hiding: a secret only the closure knows

function createCounter() {
  let count = 0;
  return () => ++count;
}

const counter = createCounter();
counter(); // 1
counter(); // 2
// nobody outside can touch count

Where you’ll meet closures: the module pattern, currying, once, memoize, async state, setTimeout and iterators.

One caution: a backpack you never take off gets heavy. Closures keep variables alive, so careless use can hold memory longer than needed.

Remember it: A closure remembers the variables from where it was written, even after the outer function has returned. It holds references, not copies.

7. Currying: One Argument at a Time

In one line: currying turns f(a, b) into f(a)(b), and it works because of closures.

Ordering coffee: “Size?” Large. “Milk?” Oat. “Sugar?” None. One question at a time, and the barista remembers every answer. That memory is a closure.

const add = a => b => a + b;

add(2)(3);             // 5

const addTwo = add(2); // a = 2 is remembered
addTwo(10);            // 12

Where it helps: reusing a function with some arguments already fixed, like addTwo above.

Remember it: Currying = one argument at a time, powered by closures.

8. The this Keyword: It Depends Who’s Asking

In one line: this is decided by how a function is called, not where it is written.

this is like the word "here". Where "here" points depends on where you're standing when you say it.

Where does this point?

• Global scope: the global object (window in the browser).
• Inside a regular function call: undefined in strict mode, window otherwise.
• Inside a method, obj.fn(): the object before the dot.
• Inside an arrow function: it has no this of its own, so it borrows one from the surrounding code.
• With call, apply or bind: whatever you choose.
• Inside an event listener (regular function): the element that received the event.

const user = {
  greet() {
    console.log(this === user);
  }
};

user.greet();            // true, called with user before the dot

const greet = user.greet;
greet();                 // false, the object got left behind

Interview trap: copy a method into a variable, and it forgets its object. this is not stored with the function, it's decided at every call.

Remember it: this is decided at call time. Quick trick: look left of the dot.

9. Arrow Functions: Short, Sweet, and Borrowing Their this

In one line: arrow functions are a shorter way to write functions, and they don’t have their own this.

// Regular function
function square(n) {
  return n * n;
}

// Arrow function
const squareArrow = n => n * n;

An arrow function is like a guest who never brings their own umbrella. When it rains, they share yours. Their this is whatever this was around them when they were written.

Where that actually helps

const timer = {
  seconds: 0,
  start() {
    setTimeout(function () {
      console.log(this.seconds); // undefined, this is not timer
    }, 1000);

    setTimeout(() => {
      console.log(this.seconds); // 0, borrowed from start()
    }, 1000);
  }
};

timer.start();

How arrows are different

• No own this. It comes from the surrounding code. This is called lexical this.
• call, apply and bind can't change it.
• No arguments object. Use rest parameters, (...args), instead.
• Can’t be used with new. They are not constructors.
• Not hoisted like function declarations. They live in a variable, so a const arrow sits in the temporal dead zone until its line runs.

Interview trap: don’t write object methods as arrow functions. They won’t see the object as this.

Remember it: Arrow functions are shorter, and they borrow this from where they are written.

10. call, apply and bind: Choosing Your this

In one line: call and apply run a function right now with the this you choose. bind gives you a new function with this locked in.

Now that this makes sense, here are the three ways to take control of it.

const person = { name: "Sonia" };

function greet(greeting, mark) {
  console.log(greeting + ", " + this.name + mark);
}

greet.call(person, "Hello", "!");    // Hello, Sonia!
greet.apply(person, ["Hello", "!"]); // Hello, Sonia!

const later = greet.bind(person);
later("Hi", "!");                    // Hi, Sonia!

The ABC trick:

• Call = Comma-separated arguments.
• Apply = Array of arguments.
• Bind = Brings back a new function for later.

Bonus: give bind some arguments up front, and you get partial application, currying's close cousin.

const multiply = (a, b) => a * b;
const double = multiply.bind(null, 2);
double(5); // 10

Remember it: call and apply run now, bind returns a function for later. None of them can change an arrow function's this.

11. Prototypes: JavaScript’s Family Tree

In one line: every object has a hidden link to another object, its prototype, and JavaScript follows that chain to find properties the object doesn’t have itself.

Your wallet is empty, so you ask your parent. Their wallet is empty too, so they ask your grandparent. That’s the prototype chain.

Ever wondered where push comes from? You never wrote it.

const arr = [1, 2, 3];
arr.push(4); // push lives on Array.prototype, not on arr

The chain: arr → Array.prototype → Object.prototype → null. When the chain reaches null, JavaScript gives up and returns undefined.

Building your own family tree

const animal = {
  eat() { console.log("Eating"); }
};

const dog = Object.create(animal); // animal is dog's prototype
dog.bark = () => console.log("Woof");

dog.bark(); // found on dog itself
dog.eat();  // not on dog, found on its prototype

This is prototypal inheritance: objects inheriting directly from other objects.

Sound familiar? It works just like the scope chain. The scope chain finds variables, and the prototype chain finds properties.

The two names that confuse everyone

• __proto__ is the link every object has to its prototype. (The modern way to read it is Object.getPrototypeOf(obj).)
• prototype is a property on functions and classes. Objects created with new get linked to it.

class Person {
  greet() { console.log("Hi"); }
}

const sonia = new Person();
Object.getPrototypeOf(sonia) === Person.prototype; // true

Interview trap: classes in JavaScript are syntactic sugar. Under the hood, it’s prototypes all the way down.

Remember it: Every object links to a prototype. JavaScript walks that chain to find properties, ending at null.

Two-Minute Revision: Read This in the Elevator

All of Part 1 in 16 lines. Screenshot it, save it, read it on the way in.

• JavaScript: a synchronous, single-threaded language.
• Execution context: built in two phases, memory creation and code execution.
• Function call: creates a new execution context, deleted when the function returns.
• Hoisting: memory is given before code runs, so var gives undefined early and functions work fully.
• Temporal dead zone: the time between hoisting and initialization of let and const.
• Lexical environment: local memory plus a reference to the parent’s lexical environment.
• Scope chain: the chain of lexical environments JavaScript follows to find a variable.
• Block scope: let and const stay inside { }, var leaks out.
• Shadowing: an inner variable hides an outer one. Shadowing a let with a var is illegal.
• Closure: a function bundled with its lexical environment. It remembers references, not copies.
• Currying: f(a, b) becomes f(a)(b), powered by closures.
• this: decided at call time. Look left of the dot.
• Arrow functions: shorter, with no own this. They borrow it from where they're written.
• call, apply, bind: comma-separated, array, and a new function for later.
• Prototype chain: objects link to prototypes, and JavaScript walks the chain to find properties, ending at null.
• Classes: syntactic sugar over prototypes.

One Last Thing

If a word slips away mid-interview, don’t panic. Your brain didn’t delete it. It’s just in the temporal dead zone for a moment.

Take a breath. Picture the boxes, the backpack and the VIP line. Start with the one-liner, and the rest will follow.

Coming up in Part 2, How JavaScript Waits and Reacts: callbacks, event bubbling, promises, the event loop, async/await, and a peek under the engine’s hood.

Save this. Share it with someone who has an interview this week. Come back whenever your memory returns undefined.

You’ve got this.

You Know JavaScript. Your Brain Just Forgets. (Part 1: How JavaScript Thinks) was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been experimenting with different ways to make my coding agent waste fewer tokens and stay focused on the task. Here’s what I’ve found.

Your coding agent wastes more tokens in two directions at once.

1. It reads too much: dumping the entire output of npm install or a 500-test pytest run straight into its context.
2. Then it writes too much, burying the one line you needed under three paragraphs you didn't ask for.

Both halves are fixable. A surprising number of people have built tools for it, and here are five that each attack a different point in the loop.

1. i-have-adhd

The name is blunt and so is the tool. It’s a skill that stops your agent burying the answer.

Basically it applies ten rules to how the agent responds: action first, numbered steps, concrete time estimates, no preamble. Ask it something and the answer arrives at the top instead of after a warm-up paragraph.

It only changes what the agent writes back to you. It doesn’t touch what the agent reads. But if your main complaint is scrolling past filler to find the command you asked for, it’s the smallest possible fix.

At 48.7k stars it’s one of the most-starred agent skills on GitHub, and the repo is active.

Try here: github.com/ayghri/i-have-adhd

2. RTK

RTK works the other side of the problem. It shrinks shell output before your agent ever sees it.

It’s a CLI proxy — a single Rust binary, no dependencies, sitting between the terminal and the agent, applying truncation, grouping and deduplication to whatever comes back.

It covers over 100 commands: ls, cat, grep, git, pytest, jest, cargo, Docker, kubectl, pnpm, pip, the AWS CLI, Pulumi.

The project reports 60–90% reduction in bash output. The repo is unusually honest about what that means . it says it measures output reduction, not bill reduction, and that its token estimates are bytes divided by four, so “percentages are reliable but absolute token numbers are approximate.”

Install is one line: brew install rtk. 81k stars, 2,000+ commits, five named core contributors.

Try here: github.com/rtk-ai/rtk

3. context-mode

context-mode goes after the thing that actually kills long sessions: tool results flooding the active context.

It runs as an MCP server and sandboxes tool output so raw data never enters the context window. It also tracks the session file edits, git operations, errors, decisions in a local SQLite database. When the conversation compacts, it searches that history and pulls back only what’s relevant instead of losing everything.

Its own benchmarks put a Playwright snapshot at 56 KB down to 299 bytes, and a full session at 315 KB down to 5.4 KB. Those are the project’s numbers, not independently measured ones.

And it works with Claude Code, Cursor, Gemini CLI and VS Code Copilot. 23.7k stars, MIT/ELv2.

One thing to know before you go looking: there are a lot of forks with identical descriptions floating around. The original is mksglu/context-mode.

Try here: github.com/mksglu/context-mode

4. Caveman

This was a popular tool initially. Caveman does one thing, with a very specific sense of humour. It makes your agent talk like a caveman.

It provides Fewer articles, filler words and hedges. The project reports a 65% average cut in output tokens. It ships as both a skill and a proxy, and exposes MCP tools for compressing and retrieving content.

The more interesting part is caveman learn. It reads your local agent history, ranks your worst token sinks from the top down with a one-line fix behind each, and can apply those fixes, automatically reverting any change that doesn't lower tokens per turn.

Like i-have-adhd, it only affects output, not input. It doesn’t rewrite your prompts.

Try here: github.com/juliusbrussee/caveman

5. Headroom

Headroom is the broadest of the five. It sits between your agent and the model provider and compresses everything passing through. The tool outputs, logs, files and RAG chunks.

You launch your agent through it and every read gets compressed on the way to the model. It works with Claude Code, Codex, Cursor, Aider, Copilot and OpenClaw, and runs as a wrapper, proxy, SDK call or MCP server depending on how you want to wire it in.

The project reports roughly 20% fewer tokens for coding agents and 60–95% for JSON, with compression that’s reversible.

If the others are point fixes, this is the one covering the whole inbound stream.

Try here: github.com/headroomlabs-ai/headroom

Read this before you try these tools:

One thing i would like to address here is the Compression mechanism has also a failure mode, and it’s worth knowing before you install three of these at once.

Trim a tool response too aggressively and the model may notice something is missing and go get it, reopening the original output, or just rerunning the command. Now you’ve paid for the compressed version, the original, and an extra turn. The task takes longer and costs more than if you’d left it alone.

This comes from developers reporting it rather than a controlled benchmark, so treat it as a caution rather than a measurement. It does suggest starting with one tool, not five.

Takeaway

These split cleanly into two groups. i-have-adhd and Caveman change what your agent writes. RTK, context-mode and Headroom change what it reads.

If you’ve never touched any of this, start on the reading side, that’s where the volume is. RTK is the easiest first install: one Homebrew command, covering the commands you already run all day.

Every number above comes from the projects themselves. None has been independently benchmarked, so treat the percentages as claims rather than guarantees, and check your own usage before and after.

Top 5 tools that stops your Coding Agent from rambling. was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

A practical, copy-paste guide to catching the promise rejections your app is currently swallowing without you knowing it

Have you ever had a user tell you “the button just didn’t do anything” — and when you checked the console, there was a red error sitting there that nobody ever saw? That’s usually an unhandled promise rejection, quietly failing in the background while your app pretends everything is fine.

By the end of this article, you’ll know how to:

• Catch every unhandled promise rejection in a browser app, globally, in one place
• Understand exactly what triggers unhandledrejection versus a regular try/catch
• Wire this into an Angular app using the new control flow syntax and signals
• Wire this into a React app using a clean custom hook
• Write unit tests for both so this doesn’t silently break later
• Avoid the handful of mistakes that make this “solution” useless in production

If you’ve ever shipped a feature, felt good about your error handling, and then found out three weeks later that a whole class of failures was never being logged anywhere — this one’s for you.

If this kind of “here’s the gap in your error handling” deep-dive is useful, go ahead and hit follow — I write one of these every week, and the next one is about a related blind spot in error boundaries.

Before we dive into the examples, a quick note: the code snippets here are meant purely for understanding the concept. Some syntax may reflect patterns from earlier Angular or React versions by the time you’re reading this. Always check the official docs for the current API and syntax.

What “Unhandled Promise Rejection” Actually Means

A promise rejection is “unhandled” when a promise fails and nothing in the chain has a .catch() or a try/catch around an await to deal with it. JavaScript doesn't throw immediately — it waits until the current microtask queue drains, and if the rejection still has no handler attached, the runtime fires an unhandledrejection event on the global object.

That’s the key detail most people miss: it’s not the same mechanism as a thrown synchronous error, and window.onerror will not catch it. These are two separate reporting channels, and a lot of "global error handling" setups only wire up one of them.

Here’s the plain vanilla JS version, no framework involved:

window.addEventListener('unhandledrejection', (event) => {
  console.error('Unhandled promise rejection:', event.reason);

// Optional: stop the browser from also logging its own default message
  event.preventDefault();
  // This is where you'd send it to Sentry, LogRocket, your own logging endpoint, etc.
});

You can also assign it as a property instead of an event listener:

window.onunhandledrejection = (event) => {
  console.error('Unhandled promise rejection:', event.reason);
};

The event-listener version is generally the better choice, because onunhandledrejection gets overwritten if two parts of your codebase both try to set it. addEventListener lets multiple listeners coexist.

There’s also a companion event worth knowing: rejectionhandled. It fires if a promise was initially unhandled but later got a .catch() attached (common with async timing quirks). If you're building serious error tracking, you'll want to listen for both so you don't log false positives.

Wiring This Into an Angular App

In Angular, zone.js patches Promise under the hood, which means unhandled rejections inside the zone still bubble up to the same window unhandledrejection event — so the approach above works without modification. The cleanest way to use it is a small injectable service that exposes the last error as a signal, so any component can react to it.

// error-tracking.service.ts
import { Injectable, signal } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class ErrorTrackingService {
  readonly lastError = signal<string | null>(null);
  constructor() {
    window.addEventListener('unhandledrejection', this.handleRejection);
  }
  private handleRejection = (event: PromiseRejectionEvent) => {
    const message = event.reason?.message ?? String(event.reason);
    console.error('Unhandled promise rejection:', event.reason);
    this.lastError.set(message);
    event.preventDefault();
  };
}

And a small component that surfaces it, using the new @if control flow and an input() signal for styling flexibility:

// error-banner.component.ts
import { Component, inject, input } from '@angular/core';
import { ErrorTrackingService } from './error-tracking.service';

@Component({
  selector: 'app-error-banner',
  template: `
    @if (errorTracking.lastError(); as error) {
      <div [class]="bannerClass()">
        {{ error }}
      </div>
    }
  `,
})
export class ErrorBannerComponent {
  protected errorTracking = inject(ErrorTrackingService);
  bannerClass = input('error-banner');
}

Because ErrorTrackingService is providedIn: 'root', its constructor runs once, the first time it's injected anywhere — which in practice means as soon as your app bootstraps and something requests it. Drop <app-error-banner /> near the root of your app and you have a working global catch-all.

Unit Testing the Angular Version

The tricky part of testing this is that PromiseRejectionEvent isn't something you can construct with a plain object — you have to build a regular Event and attach a reason property to it, then dispatch it on window:

// error-tracking.service.spec.ts
import { TestBed } from '@angular/core/testing';
import { ErrorTrackingService } from './error-tracking.service';

describe('ErrorTrackingService', () => {
  let service: ErrorTrackingService;
  beforeEach(() => {
    TestBed.configureTestingModule({});
    service = TestBed.inject(ErrorTrackingService);
  });
  it('captures an unhandled promise rejection from window', () => {
    const rejectionEvent = new Event('unhandledrejection') as PromiseRejectionEvent;
    Object.defineProperty(rejectionEvent, 'reason', {
      value: new Error('Something broke'),
    });
    window.dispatchEvent(rejectionEvent);
    expect(service.lastError()).toBe('Something broke');
  });
});

Quick, answerable one for you: have you ever shipped a “silent” promise rejection to production and only found out about it from a confused user report instead of your monitoring tool? Drop the story in the comments — I want to hear how you eventually tracked it down.

Wiring This Into a React App

React doesn’t patch promises, so the pattern is simpler: a custom hook that attaches the listener on mount and cleans it up on unmount.

// useUnhandledRejection.js
import { useEffect, useState, useCallback } from 'react';

export function useUnhandledRejection() {
  const [lastError, setLastError] = useState(null);
  const handleRejection = useCallback((event) => {
    const message = event.reason?.message ?? String(event.reason);
    console.error('Unhandled promise rejection:', event.reason);
    setLastError(message);
    event.preventDefault();
  }, []);
  useEffect(() => {
    window.addEventListener('unhandledrejection', handleRejection);
    return () => window.removeEventListener('unhandledrejection', handleRejection);
  }, [handleRejection]);
  return lastError;
}

And a component that uses it:

// ErrorBanner.jsx
import { useUnhandledRejection } from './useUnhandledRejection';

export function ErrorBanner() {
  const lastError = useUnhandledRejection();
  if (!lastError) return null;
  return <div className="error-banner">{lastError}</div>;
}

Mount <ErrorBanner /> once, near the top of your component tree, and every unhandled rejection anywhere in the app surfaces through it.

Unit Testing the React Version

Using React Testing Library, you dispatch the same kind of synthetic event and assert the banner shows up:

// ErrorBanner.test.jsx
import { render, screen, act } from '@testing-library/react';
import { ErrorBanner } from './ErrorBanner';

test('shows the error banner after an unhandled promise rejection', () => {
  render(<ErrorBanner />);
  act(() => {
    const event = new Event('unhandledrejection');
    event.reason = new Error('Something broke');
    window.dispatchEvent(event);
  });
  expect(screen.getByText('Something broke')).toBeInTheDocument();
});

One gotcha worth flagging here: if you’re running tests under jsdom, its support for a real PromiseRejectionEvent constructor is limited, which is why both examples above build a plain Event and manually attach reason rather than trying to construct the browser-native event class directly.

Bonus Tips

A few things that tend to separate a “works in the demo” version of this from one that actually holds up in production:

• Call event.preventDefault() only after you've logged the error somewhere durable — it suppresses the browser's own default console warning, which is convenient once you have your own logging in place, but a footgun if you add it before you're actually capturing anything.
• Pair unhandledrejection with window.onerror (or a window.addEventListener('error', ...) listener) so you're covering both synchronous throws and rejected promises — they are genuinely separate mechanisms.
• Listen for rejectionhandled too if you're building anything resembling real error monitoring, so a late .catch() doesn't get logged as a permanent failure.
• If any part of your stack runs in Node (an SSR layer, an API route, a script), remember the API there is different: process.on('unhandledRejection', handler), not window.
• Route the captured error into whatever tool you already use for monitoring (Sentry, LogRocket, your own backend) rather than leaving it in console.error — the whole point of this pattern is that a developer isn't watching the console when it happens.

Recap

Unhandled promise rejections fail silently by design, and neither Angular’s zone patching nor React’s rendering model catches them for you automatically — you have to opt in with a global window listener. Once that listener is in place, wrapping it in a service (Angular) or a hook (React) makes it reusable, testable, and easy to hook into whatever logging or monitoring tool you already rely on.

Did this approach match how you’re already solving it, or do you have a different take? Drop a comment — I genuinely read every single one.

Found this helpful?
If this saved you even a few minutes of debugging or confusion, hit that clap button so others can find it too. It really does make a difference.

Want more tips like this?
I share one practical dev insight every week. Follow me here on Medium or subscribe to my newsletter so you never miss one.

Let’s connect — find me on LinkedIn or GitHub and let’s keep the conversation going.

Follow Me for More Angular & Frontend Goodness:

I regularly share hands-on tutorials, clean code tips, scalable frontend architecture, and real-world problem-solving guides.

• 💼 LinkedIn — Let’s connect professionally
• 🎥 Threads — Short-form frontend insights
• 🐦 X (Twitter) — Developer banter + code snippets
• 👥 BlueSky — Stay up to date on frontend trends
• 🌟 GitHub Projects — Explore code in action
• 🌐 Website — Everything in one place
• 📚 Medium Blog — Long-form content and deep-dives
• 💬 Dev Blog — Free Long-form content and deep-dives
• ✉️ Substack — Weekly frontend stories & curated resources
• 🧩 Portfolio — Projects, talks, and recognitions
• ✍️ Hashnode — Developer blog posts & tech discussions
• ✍️ **Reddit** — Developer blog posts & tech discussions

Before you go

• Please take a moment to like the post and follow the writer!
• Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here

Stop Losing Errors to the Void: Handling Unhandled Promise Rejections Globally in JavaScript… was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.