DEV Community: Arun

Introducing ReMOAT: Remote Debugging Without the Headache

Arun — Wed, 07 Oct 2026 11:52:41 +0000

Ever tried debugging a website that isn't running on your machine?

Maybe it's on a client's browser.

Maybe it's running on a Smart TV.

Maybe the bug only happens in a specific environment that you can't easily reproduce.

And then comes the usual process:

"Can you send me a screenshot?"

"Can you open DevTools?"

"What does the console say?"

"Can you try it again?"

Five minutes later, you're still trying to figure out what actually went wrong.

That's the problem ReMOAT is trying to solve.

What is ReMOAT?

ReMOAT is a remote debugging tool that lets developers debug browser-based applications remotely in real time.

Instead of asking someone to explain what they're seeing, you can connect to the browser and investigate the problem yourself.

You can inspect what's happening, check console errors, look at network activity, interact with the page, and troubleshoot issues while the problem is actually happening.

Debug the actual environment

One of the frustrating parts of debugging is that:

"It works on my machine."

The application might work perfectly in your local browser but fail on another device or environment.

ReMOAT is designed to let you debug the actual browser session instead of trying to recreate the problem from screenshots and descriptions.

The workflow becomes:

User encounters a bug
        ↓
Connect to the browser
        ↓
Inspect the actual environment
        ↓
Find the problem
        ↓
Fix it

Much less guessing.

No more screenshot debugging

Screenshots are useful, but they rarely tell the whole story.

A screenshot can't show you:

What happened in the console
Which network request failed
What the page state was
What the browser was actually doing
Whether the issue is reproducible

With remote debugging, you can investigate the problem directly.

Built for real-world debugging

ReMOAT is useful for more than just normal websites.

It can help with browser-based applications and environments where reproducing the exact issue locally can be difficult.

You can use it for things like:

Remote browser debugging
Console error investigation
Network debugging
Local storage inspection
Reproducing frontend issues
Real-time collaboration
Debugging applications on remote devices

The goal is simple:

See the problem. Don't just hear about it.

Why ReMOAT?

Tools like browser DevTools are excellent when the browser is right in front of you.

The problem starts when the browser is somewhere else.

That's where remote debugging becomes useful.

Instead of sending instructions back and forth, ReMOAT gives developers a way to get closer to the actual environment where the bug is happening.

You can check out ReMOAT here:

https://remoat.dev/

And I'd genuinely like to hear from other developers:

What's the most painful remote debugging problem you've had to deal with?

Was it a browser issue, a Smart TV, a client's device, or simply a bug that refused to reproduce locally?

Introducing CallCeptor: Turn Your Website Into a Call Button

Arun — Wed, 07 Oct 2026 11:49:07 +0000

You visit a website because you have a question.

You find the phone number.

Then you have to take out your phone, type the number, navigate a menu, explain which page you were looking at, and hope someone answers.

For a lot of businesses, especially financial firms, that's still how a website call works.

We thought there had to be a simpler way.

Meet CallCeptor

CallCeptor turns the phone number on your website into a Call button.

A visitor clicks it, gives a little context, and talks to the right person directly from their browser.

No app to install.

No number to type.

No leaving the page.

The agent can also see which page the visitor was on and where the visitor came from before answering.

Why does this matter?

Consider someone reading an IPO article on a brokerage website.

They have a question about the IPO.

With a normal phone number, the journey might look like:

Read article
    ↓
Find phone number
    ↓
Take out phone
    ↓
Dial
    ↓
Navigate IVR
    ↓
Explain the question
    ↓
Hopefully reach the right person

With CallCeptor:

Read article
    ↓
Click "Call"
    ↓
Select the topic
    ↓
Talk to the right desk

The context travels with the call.

That's the part we wanted to fix.

What happens when nobody answers?

This is where things get interesting.

A missed website call shouldn't simply disappear.

CallCeptor can turn a missed call into a callback task, with a deadline and escalation. Calls, missed calls, and callbacks are also recorded as leads with information such as the page, referrer, and campaign.

So instead of:

"Someone called earlier. Does anyone know who it was?"

You have:

"This person called from this page, from this campaign, and needs a callback."

One script is enough

Adding CallCeptor to a website is designed to be simple.

<script
  src="https://callceptor.com/callceptor-sdk.js"
  data-site-key="YOUR_SITE_KEY"
  async>
</script>

Then you can configure departments, agents, business hours, holidays, and routing rules.

The calling code is loaded when someone actually clicks Call, rather than loading everything upfront.

Built for more than just calling

The call itself is only one part.

CallCeptor also provides:

Browser-based calling
Routing by page and topic
Mobile fallback
Callback management
Caller intake
Agent context
Call recording
Lead attribution

For regulated businesses, it also includes features around recording rules, consent, retention, audit trails, and data hosting in Indian cloud regions.

Why we built it

A phone number tells a visitor:

"Here is how you can contact us."

A Call button should say:

"We'll connect you to the right person."

That's the difference we're trying to build.

CallCeptor is designed for brokerages, wealth firms, advisers, AMCs, insurance distributors, lenders, and other businesses where a website visitor may want to talk to someone before taking the next step.

If you're curious, you can try it here:

https://callceptor.com/

I'd genuinely like to hear from other developers and product teams:

Would you rather have a phone number on a website, or a button that connects you directly to the right person?

Introducing ProxyCeptor: A Simpler Way to Handle APIs

Arun — Wed, 07 Oct 2026 11:41:53 +0000

_Have you ever wanted to test one small API change, but ended up spending more time setting up the environment than actually testing it?
_
Maybe you want an API to return a 500.

Maybe you want to change one field in a response.

Maybe you want to redirect a request to staging.

Or maybe you just want to see what happens when an API takes 3 seconds to respond.

Usually, you end up changing backend code, creating temporary mocks, deploying something to staging, or setting up a proxy and dealing with certificates.

That is where ProxyCeptor comes in.

Try ProxyCeptor

What is ProxyCeptor?

ProxyCeptor is a developer tool for intercepting and modifying API traffic while your application is running.

Instead of changing your backend just to test a frontend scenario, you can intercept the request and change what happens to it.

For example:

Application
     ↓
  API Request
     ↓
 ProxyCeptor
     ↓
Modify / Mock / Delay / Block
     ↓
    API

You can modify requests, change responses, mock APIs, redirect URLs, inject headers, simulate errors, and introduce network delays.

The idea is pretty simple:

Don't change your application just to test a different API scenario. Change the traffic instead.

A simple example

Imagine your API normally returns:

{
  "status": "success",
  "user": {
    "name": "John"
  }
}

You want to see how your frontend behaves when the API returns an error.

Instead of modifying the backend, you can make the response behave like:

{
  "status": "error",
  "message": "Something went wrong"
}

You can also simulate HTTP errors such as 401, 404, 500, or 503, or add artificial latency to see how your UI handles slow networks.

ProxyCeptor supports these kinds of request and response modifications directly.

What can you do with it?

Some of the useful things you can do are:

Modify request URLs
Change request payloads
Inject or modify headers
Mock complete API responses
Modify only specific JSON fields
Redirect requests
Block network traffic
Simulate API delays
Change HTTP status codes
Transform API responses

One feature I particularly like is JSON Deep Merge.

Instead of replacing an entire response, you can change only the field you care about while keeping the rest of the real API response intact.

That makes testing much less painful.

No backend changes

This is probably the biggest reason to use a tool like this.

Suppose you're working on a frontend feature that needs to handle:

"What happens when the payment API returns 503?"

You shouldn't have to ask the backend team to create a special response, deploy it, test it, and then revert it.

You can simulate that response locally and continue working.

That means frontend developers and QA engineers can test edge cases without waiting for backend changes.

And it isn't limited to browsers

ProxyCeptor can also work with Smart TV environments such as Android TV, Fire TV, Samsung Tizen, and LG webOS.

For environments where installing a root SSL certificate or configuring a traditional system proxy is painful, ProxyCeptor provides an SDK-based approach that intercepts traffic inside the application runtime.

That makes it useful for testing things that are otherwise surprisingly difficult to reproduce on real devices.

The idea behind ProxyCeptor

The goal isn't to replace your existing testing framework.

Unit tests still have their place.

Integration tests still have their place.

Mock servers still have their place.

ProxyCeptor is useful for that layer in between:

"I'm running the real application, making real requests, but I want to control what happens to those requests."

That's where API interception becomes really useful.

You can inspect the traffic, change it, reproduce an edge case, and see how your actual application reacts.

No temporary backend endpoint.

No waiting for another deployment.

Just change the traffic and test.

Give it a try

If you're working with APIs, frontend applications, QA testing, or Smart TV applications, you can try ProxyCeptor here:

https://proxyceptor.com/

There is also a live sandbox where you can experiment with API interception without setting up a project first.

I'd be interested to know how other developers handle this today.

Do you use Charles, Burp, Postman, browser DevTools, mock servers, or something else when you need to change API behavior during development?

Introducing CeptorLabs: Building Tools for the Problems Developers Actually Debug

Arun — Wed, 07 Oct 2026 06:05:02 +0000

Debugging shouldn't require reproducing the impossible.

There is a certain kind of bug that every developer eventually encounters.

It works locally.

It works on your machine.

It works in staging.

And then someone says:

"It doesn't work for me."

Maybe it's an API behaving differently.

Maybe a browser request fails only under certain conditions.

Maybe a bug appears on a Smart TV but nowhere else.

Maybe the issue disappears the moment you try to debug it.

These problems aren't necessarily difficult because the code is complicated.

They're difficult because reproducing the problem is complicated.

That's the problem we're interested in at Ceptor Labs.

What is Ceptor Labs?

Ceptor Labs is a developer tools company focused on making debugging, testing, and troubleshooting easier.

We're building tools around a simple idea:

Developers should be able to reproduce and understand problems without spending hours trying to recreate the environment where they happened.

Our products are designed around different parts of that problem.

ProxyCeptor

ProxyCeptor — Modern Proxy Interceptor & API Mocking Tool

Intercept, mock, delay, and debug HTTP traffic across Smart TVs and web apps in 1 click. Zero-cert proxy interceptor with cloud rule sync.

proxyceptor.com

API and network debugging without the usual proxy headaches.

ProxyCeptor lets developers inspect and modify network traffic, mock APIs, rewrite requests, change responses, and reproduce difficult API scenarios.

Instead of asking:

"Can someone change the backend so I can test this?"

you can test the scenario directly.

For example:

Real Application
       ↓
   API Request
       ↓
   ProxyCeptor
       ↓
   Modify Response
       ↓
    Application

Want to see what happens when an API returns 500?

Do it.

Want to test a malformed response?

Do it.

Want to simulate a slow endpoint?

Do it.

The backend doesn't need to change.

ReMOAT

ReMOAT — Real-Time Remote Browser Debugging & DevTools

Debug live browser sessions in real-time over WebRTC. Inspect remote console logs, network requests, DOM mutations, and time-travel replay with zero cloud storage.

remoat.dev

Debugging a browser remotely has its own set of problems.

Sometimes the browser isn't on your machine.

Sometimes the issue happens on another device.

Sometimes asking someone to share their entire screen isn't the right solution.

ReMOAT focuses on remote browser debugging.

The goal is simple:

Connect to the browser, understand what's happening, and debug the problem without turning the debugging session into a screen-sharing session.

Call Ceptor

CallCeptor: Click-to-Call for Indian Brokers and AMCs

Put a Call button on your brokerage, AMC or advisory website. Visitors reach the right desk from the browser, and every call becomes a lead. Hosted in India.

callceptor.com

We're also exploring developer communication with Call Ceptor.

Because debugging isn't always just about logs and requests.

Sometimes you need to talk to another developer while looking at the same problem.

We're building tools that bring communication closer to the development workflow instead of forcing developers to constantly jump between unrelated tools.

Why build another set of developer tools?

Because we've experienced the problem ourselves.

Modern applications have become increasingly distributed.

A simple user action can involve:

Browser
   ↓
Frontend
   ↓
API
   ↓
Authentication
   ↓
Multiple services
   ↓
Third-party APIs
   ↓
Device / Browser

When something breaks, knowing where it broke isn't always enough.

You need to reproduce it.

And reproduction is often the hardest part.

That's where we want to help.

What we'll share here

This won't just be a product announcement channel.

We'll share what we're learning while building these tools.

Expect posts about:

API debugging
Network interception
Frontend testing
Remote browser debugging
Smart TV debugging
QA workflows
Reproducing production bugs
Developer tooling
Things that didn't work
Things that surprisingly did

We'll also share technical breakdowns of problems we encounter while building.

Sometimes the solution will be elegant.

Sometimes it will be:

"We spent two days debugging the wrong thing."

Those are probably worth writing about too.

The bigger goal

We're not trying to build another collection of dashboards.

We're interested in the messy part of software development:

Something is broken.

You don't know why.

You need to reproduce it.

And you need to fix it.

Ceptor Labs exists to make that process less painful.

We're starting with ProxyCeptor, ReMOAT, and Call Ceptor.

And we're going to keep building from there.

If you're interested in developer tooling, debugging, QA, or the strange problems that only appear in production, follow Ceptor Labs.

We'll have plenty to share.

Tags: #devtools #debugging #testing #webdev #opensource

Suggested DEV canonical URL/slug:

introducing-ceptor-labs-building-tools-for-the-problems-developers-actually-debug