By the

About a year ago, several of us realized we had quietly accepted something ridiculous as normal: our phones were being interrupted by unwanted calls almost every day. Sometimes it was one. Sometimes it was several. Sometimes the phone displayed a nearby area code. Sometimes the caller ID looked familiar enough to create a moment of doubt. Other times there was no subtlety at all.

Like most people, we had already tried call blockers. Some were genuinely useful. Some were clearly built around enormous reputation databases. Some wanted permissions or information that felt disproportionate to the simple thing we were asking them to do: stop unwanted calls from wasting our time.

Then we noticed something that became much more important than we expected.

A call could be marked as blocked. The phone could remain silent. The screen could stay dark. Yet ten minutes later, there it was: another useless voicemail from the caller we had supposedly blocked.

That produced the question that eventually shaped JustBlocked:

If the caller still gets to occupy your attention afterward, what exactly did “blocked” mean?

At first, this sounded like a product-design detail. It turned into a year-long investigation of how unwanted calls behave from the receiving side of the phone. We studied the numbers. We studied the timing. We studied what happened when calls were rejected, silenced, allowed to ring, answered and immediately disconnected, or handled under different rules. We deliberately exposed development devices to far more unwanted calling than anyone on the team would normally tolerate.

And the deeper we got, the less convinced we became that the phone number itself should sit at the center of the solution.

The one-year lesson The hardest part of modern spam-call protection may not be finding every bad number. It may be deciding, reliably and privately, what your own phone should do when a call does not deserve your attention.

This article is the long version of that story: what we expected, what surprised us, what our testing could and could not prove, how the “Answer + Hang-up” idea emerged, and why JustBlocked gradually evolved from a blocklist app into something closer to a user-controlled call policy engine.

First, an important caveat: this was product development, not a national telecom study

Before describing the patterns we saw, it is important to separate observation from proof.

We were building and testing an Android app. We were not operating a carrier network. We did not have access to the internal dialing systems used by callers. We did not know which calls came from the same organization, which displayed numbers were spoofed, which were short-lived VoIP numbers, which came from automated systems, or which were handled by human agents.

When the volume of spam calls to a test number changed, we could observe the change. We could not see why the caller's system changed its behavior. If a number disappeared from a campaign, we could not see whether it had been removed from a lead list, deprioritized, scored as unproductive, cycled out automatically, or simply reached the natural end of a campaign.

That distinction matters because the call-blocking industry is full of claims that sound much more certain than the underlying evidence allows. A phone can tell you what arrived. It cannot reveal the complete machinery on the other side of the network.

So think of what follows as a product team's field notes: repeated observations that influenced our design, combined with public telecom and consumer-protection information that provides a broader context.

That wider context is substantial. The Federal Trade Commission reported more than 2.6 million Do Not Call complaints in fiscal year 2025, with more than 258 million active numbers on the National Do Not Call Registry. The FTC also makes recent complaint data available to industry partners who use it in call-blocking and call-labeling systems. Those complaints are useful signals—but the FTC explicitly notes that the reported call information is not independently verified. FTC National Do Not Call Registry Data Book, FY2025.

The Federal Communications Commission describes the fight against illegal calls as a multi-layer problem involving rules, enforcement, caller-ID authentication, traceback, network blocking and consumer tools. In other words, there is no single switch that solves every unwanted call. FCC guidance on unwanted calls and texts.

The first surprise was semantic: “blocked” can mean several very different things

To a normal person, the word blocked sounds final. A blocked doorway is closed. A blocked account cannot proceed. A blocked user cannot message you. So it is reasonable to assume that a blocked phone call has been stopped in the same absolute sense.

Telephony is messier.

Depending on the Android device, carrier, voicemail configuration, call-screening method and calling service, several different outcomes can all be described casually as “blocking”:

Those are not equivalent experiences.

If the goal is simply “do not make noise,” silencing may be enough. If the goal is “do not let an unknown number interrupt a meeting,” a stronger rejection policy may be appropriate. If the problem is repeated voicemail from blocked calls, the user may care less about the ringtone and more about what happens after the network sees the call being rejected.

That is where our product thinking changed. Instead of asking only, “Is this number on the blocklist?” we started asking two separate questions:

  1. Should this call be allowed access to the user?
  2. If not, what call-handling action should the phone take?

That separation sounds obvious in retrospect. It was not obvious at the beginning.

Our first instinct was the same as everyone else's: identify the bad numbers

Phone numbers are convenient because they are visible, concrete and easy to store. A spam call arrives. You block the number. Problem solved.

Except the next call may come from another number.

During our testing, we repeatedly saw what looked from the receiving device like a stream of changing caller IDs. The exact same number was not always returning. A number would appear once, perhaps twice, and vanish. Another would follow. Then another.

We cannot determine from the handset alone that every changing number was spoofed. Some could have been legitimate numbers controlled by a calling platform. Some could have been temporarily provisioned VoIP lines. Some could have been recycled caller IDs. Some could have been altered or spoofed. From the user's perspective, however, the practical issue was the same:

Yesterday's list of blocked numbers was not necessarily a useful description of tomorrow's unwanted call.

This is one of the central weaknesses of number-first protection. A reputation system becomes strongest after it has seen enough evidence. But the first calls from a newly rotated number happen before that history exists.

The FTC's own Do Not Call data illustrates why complaint-based systems are inherently historical. Consumers report the number displayed on caller ID, the time, the subject and other details. That information is then released to carriers and other partners to improve call-blocking systems. It is valuable, but by definition the report comes after the call happened. FTC Do Not Call reported-calls data.

This does not make reputation databases useless. Far from it. Stable repeat offenders can accumulate powerful negative reputation. Complaint data can reveal campaigns, callback numbers and infrastructure. Carrier analytics can identify calling patterns that no individual handset can see.

The problem is treating reputation as if it were the only layer that matters.

We explored that issue in more detail in Why Spam Number Databases Fail Modern Call Screening, but the short version is simple: a database is excellent at remembering known history. It is not a time machine.

Caller ID felt less like identity and more like a claim

Modern phone interfaces encourage a subtle mental shortcut. A number appears on screen, and we instinctively treat it as the identity of the caller. That is not always justified.

Caller ID is information associated with the call. In many modern networks, authentication systems can provide additional evidence about whether the originating provider is authorized to present the number. The STIR/SHAKEN framework was created to make fraudulent spoofing harder and to provide more trustworthy caller-ID information across supported IP networks.

That is important progress. It is not the same as proving that a call is safe.

The FCC has said explicitly that caller-ID authentication does not mean the call itself is legitimate. A properly authenticated number can still belong to an aggressive marketer, an unwanted business caller, a compromised account or a person the recipient simply does not want to hear from. FCC consumer information on STIR/SHAKEN.

For product design, that distinction was liberating.

We did not need to make JustBlocked pretend it could answer an impossible question—Who is this caller really, and are they morally trustworthy? We could instead focus on a narrower question the device could answer much more reliably:

Based on the user's rules, does this call deserve access to the user's attention?

That can be decided with contacts, explicit allowlists, exact block rules, prefixes, selected patterns, hidden-number handling, schedules and temporary overrides. None of those mechanisms requires us to claim omniscience about the human being on the other end of the network.

The phone became the control boundary

Once we stopped trying to solve the entire telephone network from one Android app, the problem became smaller and more practical.

We cannot control which number an outside caller chooses to present. We cannot control whether a call center changes numbers. We cannot control a carrier's entire anti-abuse stack. We cannot control overseas gateways, robodialing software, lead brokers, data breaches, scam scripts or the economics of fraudulent calling.

But there is one part of the system we can influence directly: what happens on the user's device after a call reaches it.

That became the core design philosophy behind JustBlocked.

Instead of trying to know everything about the caller first, the app can enforce the owner's boundaries. A saved contact can be treated differently from an unsaved number. A hidden caller can follow one policy while a trusted allowlist follows another. A work schedule can differ from sleep hours. A temporary override can open the line while someone waits for a delivery or medical callback.

The phone does not need to solve the caller's identity in every case. It needs to apply the user's policy consistently.

A smaller problem is sometimes a better product We cannot make every unknown caller become knowable. We can make the phone's reaction more predictable.

Then we noticed the calls had a rhythm

One of the more interesting patterns during development had nothing to do with phone numbers.

The unwanted calls we observed did not appear evenly distributed across every hour of every day. Activity often felt heavier during ordinary weekday and business-hour windows. Late nights were quieter. Weekends often felt different. The pattern was noticeable enough that it became part of our internal discussion.

We need to be precise here: timing alone does not prove who or what was behind those calls.

It would be easy to tell an overly neat story: business-hour calls must mean human operators sitting in call centers. That conclusion would go beyond what a receiving device can establish. Automated systems can run on schedules. Campaigns can be configured around time zones. Compliance rules can affect calling windows. Lead-generation teams may operate during staffed hours. Human agents may be involved in some stages but not others.

Still, the pattern changed the way we thought about spam calls. They stopped looking like an abstract cloud of random numbers and started looking more like an economic process.

Someone, somewhere, is paying for infrastructure. Telephone capacity, software, data, routing, staff, lead acquisition, payment processing, hosting and support are not free. Even a heavily automated campaign exists because somebody expects enough successful outcomes to justify continuing it.

That led to a much more interesting question than “How many spam numbers can we collect?”

What happens when a phone number becomes consistently unproductive to call?

Spam calling is an attention business before it is a phone-number problem

Mass calling only needs a small percentage of useful outcomes. One person answers. Another presses a key. Someone calls back. Someone reveals that the number is active. Someone stays on the line long enough to be transferred. Someone believes the story. Someone pays.

The campaign does not require every call to succeed. It needs the expected value of all successful calls to exceed the cost of making them.

This is why the recipient's attention matters so much.

A phone number is one routing identifier in the process. The economic resource the caller actually wants is access: access to a voice, a decision, a callback, a confirmation, a purchase, a transfer, a credential, a payment or simply enough engagement to keep the campaign viable.

From that perspective, many familiar anti-spam tools are ways of reducing access:

Seen that way, JustBlocked's job is not to “defeat every spammer.” That is far too grand a claim for an Android app. The job is to make unwanted access to one user's attention more difficult and more predictable to control.

The strangest observation of the year: eventually, the calls dropped

During development, we intentionally subjected test devices and numbers to a large amount of unwanted calling. We needed repeated real-world behavior to test screening paths, call states, logging, aggressive handling, schedules, contacts and edge cases.

Over time, something happened that we did not expect.

The volume of spam calls to some of those test numbers dropped dramatically.

Not after one blocked call. Not overnight. Not in a clean before-and-after pattern that would qualify as a controlled experiment. But after large numbers of unwanted attempts repeatedly produced essentially no useful interaction, the devices became noticeably quieter.

Our first reaction was skepticism. Seasonal changes happen. Campaigns end. Lists age. Carriers change filtering. Call volumes fluctuate. A particular source might simply move on. Any of those could explain some or all of what we observed.

We could not inspect the callers' systems, so we could not determine whether our numbers had been:

So we do not claim that JustBlocked scientifically proved a mechanism that makes spam networks stop calling.

What we can say is that the correlation was strong enough to influence our product thinking. If repeated calls yield nothing useful, it is at least plausible that some calling systems will eventually spend their resources elsewhere.

The FCC has made a related point at the network level: bad actors adapt around blocking, and as long as a small number of consumers continue to fall for scams, the economic incentive to keep calling remains. The Commission therefore treats blocking as one part of a wider strategy that also includes caller authentication, traceback and enforcement. FCC 23-37, call authentication and robocall mitigation.

Our device-level takeaway was more modest:

Maybe call protection should not only ask, “Can we recognize the spammer?” Maybe it should also ask, “Can we make this phone a poor place to spend another attempt?”

That question led directly to “Answer + Hang-up”

The voicemail problem kept bothering us.

If a blocked call was merely rejected and then routed to voicemail, the caller had still accomplished something. They had created a notification. They had put audio into an inbox. They had left something the user might later need to review and delete. The interruption had been delayed rather than eliminated.

So we experimented with a more active behavior for calls that had already matched a user-defined blocking rule:

Answer the call, then terminate it immediately.

The intent was not to keep callers connected, record them, argue with them, waste their time theatrically or retaliate. It was simply to create a different network outcome from a conventional reject path.

From the calling side, the call can appear to connect and then end. On some Android, carrier and voicemail configurations, that can reduce the path by which a rejected call continues into voicemail.

This became the basis of JustBlocked's optional Answer + Hang-up capability.

Technically, this was much more interesting than maintaining a static list of phone numbers. It involved Android telecom behavior, default-dialer requirements, call states, safe fallbacks, device differences and the need to make sure the aggressive action happened only after the app had already decided the call matched the user's rules.

It also forced us to be careful with language. No Android app should promise universal voicemail prevention. Carriers differ. Devices differ. Visual voicemail systems differ. Wi-Fi calling and third-party calling services can behave differently. Software updates can change telecom behavior.

So the feature is best understood as a call-handling strategy designed to reduce the opportunity for some matched calls to proceed to voicemail—not as a magical switch that controls every carrier network.

For the detailed technical and product explanation, see Why JustBlocked Is Different: A Privacy-First Spam Call Blocker Built for Android.

Why voicemail changed our definition of success

Voicemail seems like a small detail until you measure annoyance instead of ringtone volume.

A user does not care which telecom layer technically “handled” the call. The user experiences a sequence:

  1. The unwanted caller attempts contact.
  2. The phone may or may not ring.
  3. A notification may or may not appear.
  4. A call-log entry may or may not remain.
  5. A voicemail may or may not be created.
  6. The user may later spend time deciding whether the voicemail matters.

Traditional blocking often optimizes step two. We became more interested in the entire sequence.

If the phone stays silent but the user later opens voicemail and hears a six-second recording of dead air, the unwanted call still consumed attention. If ten similar calls create ten voicemail entries, the user still has cleanup work.

That insight broadened our product goal from “stop ringing” to “reduce the downstream cost of unwanted calls.”

Sometimes the correct action is silence. Sometimes it is reject. Sometimes the user wants unknown calls to ring because they are waiting for a doctor, contractor, recruiter or delivery driver. Sometimes a stricter policy is appropriate overnight. The right behavior changes with context.

This is why a serious call-control app needs more than one global switch.

We stopped trying to build an oracle and started building rules

There is a seductive product promise in caller ID: “We will tell you exactly who is calling and whether they are good or bad.”

Sometimes services can provide genuinely useful identity and reputation information. But the absolute version of that promise is impossible to guarantee. Numbers can be spoofed. Businesses change ownership. Numbers are reassigned. Legitimate organizations make annoying calls. Fraudsters can control legitimate numbers. An unknown number can belong to someone important.

We became more comfortable building a product that says something simpler:

You decide the boundary. The phone enforces it.

That is why JustBlocked gradually accumulated controls that look less like a giant blacklist and more like a policy system:

None of these controls is individually revolutionary. The value comes from combining them so the user's own definition of “wanted” can be more useful than a universal score assigned by someone else.

The number-first problem also became a privacy problem

Once a product depends heavily on shared reputation, a natural incentive appears: collect more data so the reputation system becomes richer.

There are legitimate reasons to build crowdsourced anti-abuse networks. Large-scale data can reveal patterns no individual phone can see. But users should understand the tradeoff. A call-protection system that relies on central intelligence must obtain that intelligence from somewhere.

Our project started from a different comfort level. We did not want the core decision about whether a call should ring to require uploading a user's personal block rules, contacts or call history to a shared caller database.

That made local rules attractive for two reasons.

First, they are deterministic. If the user says “allow my contacts” or “block this number range,” the app does not need to ask a server for an opinion.

Second, they reduce the amount of personal calling context that needs to leave the device for core screening.

This does not mean “the Internet never exists.” Google Play handles distribution and purchases. Support and website functions can use network services. Android and carriers have their own network behavior. The narrower commitment is what matters: the call-control rule itself can be evaluated locally.

Our privacy policy remains the authoritative description of current data handling. The broader design principle is simple: a privacy product should not become more valuable by learning everything about the people asking it for privacy.

What the business-hour pattern did—and did not—teach us

People often ask whether spam calls are “all bots now.” Our testing made us less interested in that binary question.

A modern unwanted-call campaign can combine automation and people. Software can select numbers, schedule calls, play recordings, detect responses and route interested recipients. Human agents can join only when a call reaches a valuable stage. Artificial intelligence can add speech recognition, synthetic voices or dynamic scripts. The caller does not have to be either “a robot” or “a person.”

The business-hour pattern we observed is compatible with many operating models. It may reflect staffed call centers. It may reflect campaign schedules. It may reflect regulations, time-zone targeting or lead availability. It may reflect automated dialing that is deliberately concentrated when human recipients are likely to answer.

What it taught us was not “we found the call center.”

It taught us to think about spam as a managed process with constraints.

Processes can adapt. That helps explain why static defenses often age poorly. If one number becomes ineffective, another can be used. If one script stops working, it can change. If one call window produces fewer answers, another can be tested.

That adaptability is another reason we became skeptical of any solution that assumes the attacker will keep presenting the same identifier forever.

The scale is real, even when the individual call looks trivial

One spam call can feel like a minor annoyance. Millions of them become infrastructure.

The FTC received more than 2.6 million Do Not Call complaints in FY2025. Those complaints are only reports submitted by consumers; they are not a complete measurement of every unwanted call placed in the country. A person can receive many calls and file none. Another can report a single incident. The data therefore should not be treated as a total call count.

But it shows the persistence of the problem.

The FTC also reported that imposter scams across communication channels produced billions of dollars in reported consumer losses in 2025. Phone calls are only one entry point among text, email, social media, search results and other channels, so those loss figures should not be described as phone-only losses. They do show why fraud operations continue to experiment with ways to reach people. FTC data on 2025 imposter-scam losses.

For the recipient, however, the design question remains surprisingly personal: what should happen when this call arrives on this phone?

National enforcement, carrier filtering and caller authentication operate at enormous scale. Device-side control operates at the last meter.

Both matter.

What failed during the year was often more educational than what worked

Building call-control software produces an uncomfortable kind of bug: the system is interacting with something people rely on for real communication.

Overblocking is not a cosmetic problem. A rule that is too broad can suppress a wanted call. A schedule error can remain active too long. A number normalization bug can cause a mismatch. Device-specific telecom behavior can make an action succeed on one phone and behave differently on another.

That pushed us toward several design principles:

1. The app must fail predictably

If an advanced action is unsupported, falling back to a simpler reject path is safer than pretending the advanced action succeeded. Call control should degrade gracefully.

2. Contacts and allow rules need priority

A powerful blocker that cannot reliably preserve trusted exceptions is not useful. The stricter a rule becomes, the more important the escape hatch becomes.

3. Time matters

The correct call policy at 2:00 p.m. on a workday may be wrong at 2:00 a.m. Scheduling turns blocking from a permanent wall into a boundary that can adapt to the user's routine.

4. “Unknown” is not the same as “spam”

A hospital, school, contractor, delivery driver, recruiter or neighbor may call from an unsaved number. Users should be able to choose how much uncertainty they tolerate rather than having the app pretend every unfamiliar caller is malicious.

5. The product should explain what it cannot know

We would rather say “this call matched your rule” than “we know this caller is a scammer” when the software does not have evidence for that stronger claim.

Five assumptions we believe differently after one year

Assumption 1: “If I block enough bad numbers, eventually the problem ends.”

That can work against a persistent caller using a stable number. It works less well when numbers rotate faster than the blocklist grows. Number blocking remains useful; it simply is not the whole strategy.

Assumption 2: “If caller ID looks legitimate, the call probably is.”

Caller authentication improves trust in the number presentation, but a verified number is not a guarantee of honest intent. The displayed identity is evidence, not permission to suspend judgment.

Assumption 3: “If the phone did not ring, the spam problem is solved.”

Not necessarily. Voicemail, notifications, call-log clutter and follow-up decisions can still consume attention. Effective call control should consider the entire experience after the incoming attempt.

Assumption 4: “A call blocker needs to know who every caller is.”

Identity is useful, but policy can work without perfect identity. A user can decide that certain categories of calls should not ring during certain times even when the caller's true identity remains unknown.

Assumption 5: “The strongest blocker is the one that blocks the most.”

A blocker that stops important calls is not strong; it is reckless. The useful metric is closer to control: stopping what the user does not want while preserving access for what the user does want.

What a practical anti-spam strategy looks like today

After a year of development, we do not believe one app should be the entire defense. The most resilient setup is layered.

Use carrier protections. Major carriers operate network-level analytics and blocking systems that can stop or label suspicious traffic before it reaches the device.

Keep caller-ID skepticism. A familiar-looking number is not proof. If a caller asks for money, passwords, one-time codes or urgent account action, independently contact the organization using a number or app you already trust.

Use the National Do Not Call Registry for its intended purpose. It can reduce lawful sales calls and provides a reporting channel, but scammers who already ignore the law will not become legitimate because a number is registered.

Report illegal or suspicious calls when useful. FTC and FCC complaints provide information that can support enforcement, traceback and industry filtering.

Use device-side rules for your personal boundary. If you know that hidden callers should never ring, or only contacts should reach you overnight, that is a policy the phone can enforce immediately without waiting for a reputation score.

Be careful with blanket blocking. Unknown numbers can be important. When waiting for a doctor, repair technician, school, job interview or delivery, temporarily adjust strict rules or use an allowlist when possible.

Review voicemail behavior separately. If your main frustration is spam voicemail, ordinary rejection may not produce the result you expect on your carrier. Test the behavior on your actual device.

How this year changed JustBlocked itself

JustBlocked began with the obvious idea: block unwanted phone numbers.

It gradually became a different product.

The blocklist is still there because exact-number blocking is useful. But the center of gravity shifted toward rules, schedules, trusted exceptions, patterns and call-handling choices.

That shift mirrors the larger lesson of the project.

A number is a clue. A reputation score is a clue. Verification is a clue. Time of day is context. Contact membership is context. The user's own rule is a decision.

We wanted the decision to remain with the user.

That is also why the privacy model matters. If the product's value comes from enforcing the owner's choices locally, the product does not need to turn the owner's entire calling life into a central dataset just to perform the core action.

And it is why the aggressive call-handling feature matters. The word “block” is not enough if different users actually want different network outcomes.

The result is less glamorous than promising perfect AI-powered caller truth. It is also more honest.

Your phone cannot know everything about the caller. It can know what you told it to do.

What we still do not know

A year of building the app answered some questions and created better ones.

We still do not know how widely different spam systems score call outcomes. We do not know how often a rapid answer-and-disconnect changes future campaign behavior. We do not know whether the business-hour pattern we observed generalizes across regions, carriers, industries or scam categories. We do not know how quickly increasingly capable voice AI will change the economics of human-assisted calling.

We also do not know how far carrier-level mitigation will improve over the next several years. STIR/SHAKEN, traceback, robocall mitigation databases, enforcement actions and analytics continue to evolve. The better the network becomes at stopping obviously abusive traffic, the more the remaining unwanted calls may shift toward numbers and behaviors that look legitimate enough to pass network checks.

That possibility makes user-side policy more—not less—interesting.

If the future unwanted call comes from a properly provisioned number with valid caller-ID authentication, the network may have done its job correctly. The remaining question is whether you want that caller to interrupt you.

The next phase is not “find every bad number”

Our future work on JustBlocked is guided by a simple hierarchy.

First, protect wanted calls. A call-control app that breaks legitimate communication has failed.

Second, make rules understandable. Powerful filtering is useless if people cannot predict what it will do.

Third, keep the core decision local and responsive wherever practical. A call arrives in real time; the phone should not need a complicated round trip merely to remember the user's own preference.

Fourth, handle outcomes—not just labels. Ringing, rejecting, silencing, logging and voicemail are different parts of the experience.

Fifth, avoid absolute promises. Telecom behavior varies. Spam operations adapt. No app can guarantee that every unwanted call will disappear forever.

That final point is not a weakness. It is the foundation for building something people can actually trust.

One year later, the biggest lesson was not about spam numbers

It is tempting to describe call blocking as a giant sorting problem:

Find the bad numbers → put them in a database → block them.

After a year of building JustBlocked, we think that model is incomplete.

A phone number is an identifier presented during a particular call. It may be stable. It may change. It may be spoofed. It may be verified. It may belong to a legitimate organization making an unwanted call. It may belong to a stranger with a completely legitimate reason to reach you.

The more durable question is:

What should your device do when a call does not deserve your attention right now?

That is the part the user can control.

JustBlocked has gradually become less interested in pretending it can know everything happening on the far side of the telephone network and more interested in enforcing what happens on your side of it.

Your phone. Your contacts. Your allowlist. Your block rules. Your schedule. Your choice about whether an unknown caller gets to ring, gets rejected, or—where supported—gets answered and immediately disconnected.

We did not discover a magical way to eliminate spam calls. We did not prove that one call-handling method makes every spam campaign give up. We did not solve caller-ID spoofing from an Android handset.

But we did answer the question that originally motivated the project:

Can a phone take a more active role in protecting the user's attention without first knowing everything about the caller?

For us, the answer has been worth another year of building.

The question we are still exploring If an unwanted caller cannot reliably get a ring, a conversation, a callback or a useful voicemail outcome, how valuable does your number remain to call?

And there is one thing we would genuinely like to compare with other people's experience: Do your spam calls cluster around weekday or business hours? When you get several unwanted calls, do you see the exact same numbers returning—or does each attempt seem to come from a different number?

Frequently asked questions

Why can a blocked caller still leave voicemail?

On many carrier and device configurations, rejecting or silencing an incoming call does not necessarily terminate every downstream network path. The call may be routed to voicemail. Exact behavior depends on the Android device, carrier, voicemail system, calling service and call-handling method.

Why are spam-number databases sometimes behind?

Reputation systems become most useful after a number has accumulated complaints or suspicious calling history. A newly rotated, newly provisioned, spoofed or short-lived number can appear before enough reputation exists to classify it confidently. Databases remain useful for stable repeat offenders, but they are inherently based on observed history.

Does STIR/SHAKEN or a verified caller mean the call is safe?

No. Caller-ID authentication helps establish what the originating provider knows about the caller's relationship to the displayed number. It does not prove that the call is wanted, honest or harmless. A verified call can still be an unwanted sales call or a fraudulent interaction originating from a number the caller controls.

What is JustBlocked's Answer + Hang-up feature?

On supported Android configurations, JustBlocked PRO can answer a call that has already matched a blocking rule and then disconnect it quickly. The feature is intended to create a different outcome from ordinary rejection and can reduce the opportunity for some matched calls to continue into voicemail. Results vary by Android version, device, carrier, calling service and voicemail configuration.

Did JustBlocked prove that Answer + Hang-up makes spammers stop calling?

No. During development, we observed a substantial decline in unwanted calls to some test numbers after large numbers of calls produced no useful outcome. We did not have access to the callers' systems or a controlled experimental population, so we cannot establish causation. The observation influenced our product direction, but we describe it as correlation rather than proof.

Is blocking every unknown number a good idea?

It depends on the user's circumstances. Hospitals, schools, recruiters, contractors, delivery drivers and other legitimate callers may use unsaved numbers. A strict contacts-only rule can be useful during some periods, but users should create trusted exceptions or temporary overrides when they are expecting important calls.

Does JustBlocked depend on a shared spam-number database?

JustBlocked's core user-controlled screening can operate from on-device rules, contacts context, allowlists, blocklists, schedules and configured policies rather than requiring a shared spam-number reputation lookup for each call. See the current privacy policy for the authoritative description of data handling.

What was the biggest lesson from a year of building JustBlocked?

The biggest lesson was that identifying bad phone numbers is only one layer of call protection. A durable layer is deciding what the phone itself should do when a call does not deserve the user's attention, then applying that policy consistently while preserving wanted calls.

Why Spam Number Databases FailWhy number reputation can lag behind new, rotated and spoofed callers. How Spoofed Numbers and AI Evade Call BlockersCaller ID, STIR/SHAKEN, rotating identities and conversational automation. Why JustBlocked Is DifferentThe product deep dive into local rules, schedules and Answer + Hang-up.

Browse the complete Call Safety research library

Sources and further reading