DEV Community: Ceptor Labs

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?

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 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?