DEV Community: Arun

I'm building Mocxam: a white-label mock test platform for coaching institutes

Arun — Fri, 23 Oct 2026 04:05:18 +0000

At Ceptor Labs, we build software for problems we see up close. Today we're introducing Mocxam, a platform that lets coaching institutes launch their own branded online test series, without building software themselves.

The problem we set out to solve

Preparing for SSC, Banking, Railways or UPSC means taking a lot of mock tests. Behind most of those tests, a coaching institute is doing manual work:

Questions live in documents and spreadsheets.
Tests run on generic form tools with no real exam feel.
There's often no negative marking, no section timers and no proper question palette.
Students get a score, but no idea why they lost marks.
The institute's own brand barely shows up.

Large test-prep platforms cover parts of this, but the institute ends up promoting someone else's brand. Small and mid-sized institutes want their own name, their own students and their own data. Mocxam is built for them.

What Mocxam gives an institute

Each institute gets a coaching dashboard for staff and a branded student portal for candidates.

The coaching dashboard

Control Room: plan usage, student seats and quick actions on one screen.
Mock Test Studio: create tests, set duration and marking, and publish or disable them with one click.
Question bank and editor: tag each question by exam, subject and difficulty, with a live preview of what students will see.
AI Paper Setter: draft question papers with AI. Institutes can bring their own Gemini key. [Add: how this works in practice.]
Bulk imports: enrol students with one CSV (name, email, password) and import questions by CSV, with a row-by-row validation report.
Exam syllabi and marking: set the marking scheme once per exam and it applies to every mock.
Faculty and role-based access: staff accounts with different permissions.
Audit trail and academy settings: a record of changes, plus logo, colours and font.

The student portal

Candidates sign in to a portal that carries the institute's name and colours. They can:

Take full-length, sectional or topic-wise tests with real timing and negative marking.
Use a distraction-free test player with a question palette, flags and a live timer.
See instant results with accuracy per section and topic.
Review step-by-step solutions for every question.

Mistake analysis: the feature we care about most

A score alone doesn't help a student improve. After each test, Mocxam labels wrong answers so students know what to change:

Silly mistakes: they knew it, but slipped.
Concept gaps: the topic needs another look.
Time sinks: questions that used too much of the clock.

This turns a mock test from a scoreboard into practice.

Design decisions behind it

One institute, one portal. Every institute gets its own student portal on its own subdomain, with separate admin and student entry points. Candidate data is kept isolated per institute, which matters when institutes compete with each other.

White-label by default. Logo, colours, favicon and font are settings, not custom work. Higher plans can remove "Powered by Mocxam" entirely.

Imports come first. Institutes already hold thousands of questions and hundreds of students. If onboarding means retyping them, nobody switches. So we made CSV import with clear validation errors a core feature.

Exam-faithful practice. A mock test only helps if it feels like the real exam, so marking schemes and timers are configured per exam.

Plans

Plans start with a free pilot (up to 25 students and 2 mock tests) and scale through Starter, Academy Pro and Institution Scale.

What we learned building it

Onboarding is the product. Bulk import was the first thing institutes asked about.
White-label is mostly small details. Favicons, footers, emails and login pages all need to carry the institute's brand.
Students want the "why". Per-topic accuracy and mistake labels get more attention than the raw score.

Try Mocxam

Mocxam is free to start. If you run or work with a coaching institute, we'd love your feedback.

Website: https://coaching.mockbazaar.com/
Demo video: https://youtu.be/NGCjtl30bWI?si=Un5-oa9Yi-Odlx9m
Contact: proxyceptor@gmail.com

Have you built something similar, or taken these mock tests as a student? Tell us in the comments what you'd want most.

Mocxam is built by Ceptor Labs.

Your API Works. But Have You Tested What Happens When It Fails?

Arun — Wed, 21 Oct 2026 02:48:10 +0000

Every developer has tested an API that returns 200 OK, checked the response, and moved on to the next task.

But production is rarely that predictable.

An API returns a 500. A response is missing a field. A request takes too long. A video stream fails on a smart TV, even though it works perfectly in your browser.

These are the scenarios where QA testing becomes more than just verifying that a feature works.

1. The Problem With Happy-Path Testing

Consider a frontend that fetches user details from an API.

async function getUser() {
  const response = await fetch("/api/user");
  const data = await response.json();

  document.getElementById("username").textContent =
    data.user.name;
}

This might work perfectly when the backend returns the expected response:

{
  "user": {
    "name": "Test User"
  }
}

But what happens if the server returns an error, the user property is missing, or the request fails because of a network issue?

The application might crash, display an empty screen, or leave the user waiting indefinitely.

A reliable application should handle these cases deliberately.

2. Test Failure Scenarios, Not Just Successful Responses

Before shipping a feature, consider testing scenarios such as:

Server errors: What happens when an API returns 500 Internal Server Error?
Missing data: Does the UI handle absent or unexpected JSON fields?
Authentication failures: What happens when a session expires?
Network interruptions: Does the application recover when a request fails?
Unexpected endpoints: Does the application behave correctly when a request goes to the wrong environment?

You can simulate some of these conditions directly in code. However, modifying application code for every test scenario can become repetitive, especially when working with large applications or debugging issues on physical devices.

That is where API mocking and network interception become useful.

3. API Mocking Makes Testing More Predictable

Instead of depending on a live backend, you can control the responses your frontend receives.

For example, you can simulate an API error using a mocked response:

const mockResponse = new Response(
  JSON.stringify({
    message: "Internal server error"
  }),
  {
    status: 500,
    headers: {
      "Content-Type": "application/json"
    }
  }
);

Your application can then be tested against this response to verify that it displays an appropriate error message rather than crashing.

The same approach can be used to test missing fields, unexpected values, authentication failures, and other edge cases.

The important idea is simple: control the conditions under which your application runs.

4. What If You Could Modify Requests Without Changing Application Code?

Sometimes the problem is not the API response itself, but the request being sent.

You might want to redirect an API call to a staging server, change a request payload, rewrite a URL, or modify a nested JSON field to reproduce a bug.

Doing this manually through application code introduces unnecessary changes and may require rebuilding or redeploying the application.

Network interception offers another approach.

With a suitable interception tool, you can modify selected traffic during testing while leaving the application's source code unchanged.

Where Proxyceptor Fits In

Proxyceptor is a network debugging and API testing tool designed to help developers and QA engineers capture and manipulate requests across supported environments.

Here are a few ways it can fit into a testing workflow:

Request and payload modification

Change request parameters or JSON payloads to test how your application handles different inputs.

URL rewriting and redirection

Redirect outgoing requests to staging environments or local mock servers without changing the application's endpoint configuration.

JSON deep editing

Modify nested response or request fields to reproduce edge cases and verify frontend behavior.

Smart TV debugging

Investigate network-related issues in applications running on Android TV, Fire TV, Samsung Tizen, and LG webOS. These environments can be more challenging to debug than ordinary browser applications, especially when traditional proxy setups require certificate configuration.

Browser and framework workflows

Use network manipulation alongside development workflows involving Chrome, Edge, React, Next.js, Vue, and other supported environments.

Explore the capabilities at proxyceptor.com.

5. A Practical QA Workflow

Here is a straightforward workflow you can adopt for your next feature:

Identify a critical user journey, such as login, checkout, or video playback.
List possible failure scenarios, including invalid data, server errors, and unexpected responses.
Use mocks or network interception to reproduce those scenarios.
Verify that the frontend handles errors, displays useful feedback, and recovers appropriately.
Document the bug and repeat the same test after implementing a fix.

For larger projects, combine this workflow with automated tests so that important failure scenarios are checked during regression testing.

Remember that modifying a request is not the same as verifying the final outcome. Your tests should still assert that the application behaves as expected.

Final Thoughts

Good QA is not about checking whether everything works when conditions are perfect. It is about discovering how your software behaves when they are not.

API mocking helps create predictable test conditions. Network interception adds another level of control by letting developers modify requests, redirect traffic, and reproduce issues without repeatedly changing application code.

If you regularly debug APIs, test frontend error handling, or investigate issues on connected devices, Proxyceptor is worth exploring.

Build for the failures you can anticipate, not just the successes you expect.
checkout this website for completely free proxyceptor.com.

CallCeptor: Making Website Calls Smarter with Browser-Based Calling

Arun — Tue, 20 Oct 2026 02:31:10 +0000

A visitor lands on your website, finds a product they are interested in, and wants to speak with your team. Usually, they have to copy a phone number, dial it, navigate a menu, and explain what they were looking at.

There is a simpler way to handle this.

CallCeptor turns a website's contact option into a browser-based Call button, helping visitors connect with the right person without installing an app or manually dialing a number.

Let's look at the features that make this approach useful.

1. Browser-Based Calling

Visitors can start a call directly from your website on desktop or mobile. Calls use WebRTC, so there is no separate application to install.

The widget requests microphone permission only when the visitor clicks Call. If browser calling isn't available, visitors can use the callback option instead.

2. Smart Call Routing

Not every enquiry belongs to the same department.

Someone reading an IPO page may need the IPO team, while a visitor exploring wealth management may want to speak with a relationship manager.

CallCeptor can route calls using the page URL, selected topic, customer type, language, and department availability. This helps visitors reach the relevant team without navigating a long IVR menu.

3. Mobile Fallback

What happens when an agent isn't sitting at their dashboard?

CallCeptor can ring an agent's verified mobile number when they aren't available in the browser. Teams can also configure timeouts and overflow rules to handle unanswered calls.

4. Quick Caller Intake

Before connecting a visitor, the widget can collect basic details such as their name, mobile number, whether they are a new or existing client, and the reason for calling.

Optional OTP verification helps reduce spam, while consent information can be displayed before a call starts.

This gives agents useful context before they begin the conversation.

5. Agent Console

The agent console provides context before an agent answers.

Agents can see who is calling, which page they came from, and relevant campaign information. They can also manage availability, mute or hold calls, transfer callers, and add notes or client details.

The goal is to make conversations more informed from the very beginning.

6. Callbacks and Lead Management

Missed calls shouldn't disappear into a forgotten log.

CallCeptor converts missed calls into callback tasks with deadlines and escalation rules. Visitors can select a callback slot and receive a confirmation.

Its lead inbox also tracks calls, missed calls, and callbacks alongside page details, referrers, and campaign tags. Teams can filter leads and export data through CSV or send events to their systems using webhooks.

7. Recording and Compliance

For financial services businesses, maintaining call records is especially important.

CallCeptor supports configurable recording rules, consent workflows, retention policies, legal holds, and audit logs. Recordings are encrypted at rest, with data hosted in Indian cloud regions.

These capabilities help teams manage calls with greater visibility and accountability.

8. Website Customisation and Integrations

The CallCeptor widget can be placed in a website header, displayed as a floating button, or embedded inline on a page. Its label and colours can be customised to match the website.

Integration starts with a script tag, making it suitable for sites built with React, Angular, WordPress, Webflow, or plain HTML.

For teams that need to connect call activity to their existing workflows, signed webhooks and scheduled CSV exports are available.

Who Is It For?

CallCeptor is designed primarily for Indian financial services businesses, including stock brokers, asset management companies, wealth firms, investment advisers, mutual fund distributors, insurers, and lenders.

It is particularly useful when different website pages serve different audiences and every enquiry needs to reach the right team.

Final Thoughts

A contact number is only the beginning of a customer conversation. The experience around that call matters just as much.

By combining browser calling, intelligent routing, mobile fallback, callback management, lead tracking, and compliance features, CallCeptor aims to make website communication more direct and organised.

Explore the platform at https://callceptor.com/.

What do you think matters most in a website calling experience: faster connections, smarter routing, or better follow-up?

Your Website Gets Visitors. But Can They Actually Reach Your Team?

Arun — Wed, 14 Oct 2026 05:59:39 +0000

A visitor lands on your website, reads your pricing page, explores a product, and has one question before making a decision.

They look for a phone number.

Then comes the usual process: pick up a phone, dial the number, navigate an IVR menu, explain the reason for calling, and hope they reach the right person.

That's a lot of friction for someone who is already interested in your business.

The gap between website traffic and real conversations

We spend a lot of time optimizing websites for conversions.

We improve page speed, redesign landing pages, run A/B tests, optimize forms, and track every click. But one important interaction often remains unchanged: connecting a visitor with a real person.

A contact page might tell visitors how to reach you, but it doesn't necessarily make that interaction easy.

For businesses where conversations influence decisions, such as financial services, insurance, consulting, and sales, this gap matters.

What if calling worked like clicking a button?

Imagine a visitor reading about an investment product. Instead of leaving the page to find a phone number, they click a call button directly on the website.

They select a topic, provide the necessary context, and connect with the appropriate team from their browser.

That's the idea behind CallCeptor.

Instead of treating calling as a separate activity, CallCeptor makes it part of the website experience.

Context makes the difference

A phone call becomes much more useful when the receiving team understands why the visitor is calling.

For example, consider these two scenarios.

Traditional calling

A visitor finds a phone number.
They dial and navigate the IVR.
They explain which product or page they were exploring.
The agent starts gathering context.

Context-aware website calling

A visitor explores a specific product page.
They click the call button.
They choose the relevant topic.
The receiving team gets useful information about the visitor's journey.

The conversation can start with more context instead of repeating the same questions.

What happens when nobody answers?

Missed calls are another problem worth solving.

A visitor who is ready to speak with your team might not try again after an unanswered call. Without proper tracking, the opportunity can disappear into a call log.

A better workflow treats missed calls as follow-up tasks rather than forgotten interactions.

CallCeptor supports callback management and lead tracking, helping teams understand who reached out, where the interaction originated, and what needs attention next.

This turns a missed interaction into something the team can act on.

What does implementation look like for developers?

One interesting aspect is that website calling doesn't have to mean rebuilding your existing website.

CallCeptor is designed to integrate through a website SDK. A basic installation looks like this:

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

Replace YOUR_SITE_KEY with your configured site key and follow the platform's setup instructions.

From there, teams can configure their calling workflow, including departments, agents, working hours, and routing rules.

As with any communication feature, developers should also consider consent, recording policies, accessibility, and the behavior when an agent is unavailable.

A different way to think about conversion

Not every website visitor wants to fill out a form. Not every customer wants to wait for a callback. Sometimes, the fastest way to answer a question is to have a conversation.

Forms, chat, email, and phone calls can all serve different purposes. The goal isn't to replace every existing channel. It's to make the right interaction easier to start.

That's the problem CallCeptor is trying to address: reducing the distance between a visitor's question and the person who can answer it.

Explore it here: https://callceptor.com/

Question for developers and product teams: If you could remove one point of friction from your website's contact flow, would it be forms, chat, IVR menus, or missed calls?

I'd be interested to hear what has worked for your product.

What 508 Users Taught a Tiny Startup About Its Own Product

Arun — Sun, 11 Oct 2026 03:19:07 +0000

Last month, 508 people used Proxyceptor for the first time.

We're a small team, so that number means a lot to us. But the numbers that taught us the most weren't the flattering ones. This post walks through our first 30 days of data from Microsoft Clarity, what surprised us, and what we're fixing next.

The setup

Clarity is free, privacy-friendly, and takes about five minutes to install. It gives you session recordings, heatmaps, and behavior signals like rage clicks and dead clicks without sampling your data.

For an early-stage product with no analytics budget, it was an easy choice.

[Add 1-2 lines: what Proxyceptor does and what stack you built it on.]

The headline numbers

Metric	Value
Unique users	508
Total sessions	623
Sessions from new users	534 (85.7%)
Sessions from returning users	89 (14.3%)
Most engaged user	38 sessions

Two things stood out:

Most traffic is new. At 85.7% new-user sessions, people are discovering us, but we have a retention story to build.
Some people came back. Returning sessions are only 14.3% of the total, but one user visited 38 times. We're watching those recordings closely to learn what kept them coming back.

Where users come from

India made up 82.15% of sessions (511), the US 11.58% (72), and the rest 6.27% (39). Our top cities were Mumbai, Meerut, Surat, Ludhiana, and Chandigarh.

One caution: a few of the US sessions come from Ashburn, Virginia, which is a major data center region. If you see that in your own data, some of it may be crawlers or automated traffic rather than people. It's worth segmenting before you celebrate.

Performance: an 80/100 with one clear problem

Clarity scored us 80/100 across 302 pageviews:

Core Web Vital	Our result	Status
LCP (Largest Contentful Paint)	2.4s	Good
CLS (Cumulative Layout Shift)	0.001	Good
INP (Interaction to Next Paint)	320ms	Needs improvement

Roughly 56% of pageviews were rated good, 40% needed improvement, and 4% were poor.

LCP and CLS are fine. INP is the one to fix. At 320ms, interactions feel slower than they should. Google's "good" threshold is 200ms or less, so we're in the needs-improvement range. INP is also the metric that replaced FID, so it's worth watching if your product is interaction-heavy.

Our plan for INP:

Profile long tasks in the browser Performance panel
Break up heavy JavaScript work on interaction handlers
Defer anything non-critical until after first paint

The uncomfortable numbers

Clarity also surfaced these:

Dead clicks: 36.17% of sessions (225 sessions)
Rage clicks: 7.23% of sessions (45 sessions)
Quick backs: 12.70% of sessions (79 sessions)
Excessive scrolling: 0%

A dead click rate that high means people are clicking things that don't respond. Sometimes that's a bug, and sometimes it's a design problem, like an element that looks clickable but isn't. Either way, it's a to-do list sent to us by our own users.

The quick backs (people who land and leave almost immediately) tell us something about first impressions too.

What we're doing next

Watch recordings of sessions with rage clicks and dead clicks, and fix the top offenders first
Reduce INP below 200ms
Filter out probable bot traffic so our numbers are cleaner
Dig into what the returning users have in common

Lessons for other small teams

Instrument early. Free tools like Clarity make it painless to see real behavior from day one.
Read the recordings, not just the dashboard. The percentages tell you something is wrong, but the recordings tell you what.
Don't hide the ugly metrics. A 36% dead click rate hurts, but it's also the most useful number we have.
Treat early numbers as a baseline. 508 users isn't a finish line, it's the starting point we'll measure against.

Our next goal is 5,000 users, and I'll share a follow-up on what moved the numbers.

If you've used Clarity or fixed a high INP, I'd love to hear what worked for you. Drop it in the comments. 👇

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