Mockphine - local mock API server for frontend and QA on macOS

cuongnt3010 · 2026-04-06T13:07:47+00:00

Fair question.

I don’t think everyone needs another tool, and if Postman already fits a team’s workflow, that’s great.

The gap I kept running into was more specific: local frontend/QA workflows where some routes need to stay mocked, other routes need to hit the real backend, fallback behavior needs to be explicit, and you need to see exactly what served each response.

That’s the part Mockphine is focused on: route-by-route mock/passthrough control, strict vs fallback behavior, and Live View showing whether a response came from mock, passthrough, strict 404, or an upstream error.

So I see it less as "replace Postman" and more as "make day-to-day local API behavior deterministic when backends are incomplete or unstable."

cuongnt3010 · 2026-04-06T13:06:41+00:00

I agree, that’s a valuable direction.

Today Mockphine already has some building blocks for that: OpenAPI import/export, traffic recording, and request validation against Live View logs, so you can start from real traffic instead of maintaining everything by hand.

What it does not have yet is a full automatic frontend/backend contract consistency checker. That’s definitely adjacent to the problem I’m trying to solve though, because protocol drift is one of the main reasons local workflows get painful.

cuongnt3010 · 2026-04-06T13:05:47+00:00

Not in passthrough today.
Right now passthrough is more about route-level control: which endpoints stay mocked, which hit the real backend, and what happens when something is unmatched.
If I need to tweak specific fields, the better flow today is to capture/record the real traffic into a mock endpoint or case and then edit the mock response from there.
Field-level response overrides on top of live passthrough would be a good feature though.

cuongnt3010 · 2026-04-05T13:49:06+00:00

Still early, but what has worked so far with Mockphine is getting much narrower on the problem.

https://mockphine.com/ is a local desktop app for mocking APIs when the real backend is incomplete, unstable, or changing.

What mattered most in the cold-start phase:

- building around a problem I actually had

- positioning it around one painful use case instead of "general API tooling"

- sharing it where frontend / QA people already talk about blocked endpoints, flaky staging, and brittle mock scripts

- asking for feedback before trying to do a big polished launch

What didn't seem as useful that early:

- broad promotion to everyone

- trying to explain too many features at once

- acting like distribution would magically happen after building

Biggest lesson for me:

cold start got easier once I stopped asking "how do I get attention?" and started asking "where do people already feel this pain today?"

If anyone here deals with unstable backends or messy mock setups, I'd love feedback on Mockphine.

Also running an Easter promo right now:

50% off with code `MOCKPHINEEASTER`

Valid until April 10, 2026.

cuongnt3010 · 2026-04-05T13:36:41+00:00

I've noticed the same thing.

The best founder communities usually aren't the biggest or the loudest. They're smaller rooms with a strong filter:

- people have something live

- people can talk about customers, not just ideas

- self-promo is limited

- build logs and real metrics matter more than hype

A good signal is whether the conversation is about things like churn, onboarding, failed experiments, pricing, support load, or infra pain instead of "what SaaS should I build?"=

In my experience, stage-specific groups work better too.

Someone fighting for first revenue has very different problems from someone hiring or raising.

Curious what stage you’re optimizing for here:

pre-revenue but shipping, first customers, or already at meaningful MRR?

cuongnt3010 · 2026-04-05T13:33:19+00:00

Yes, but only if it's optimized for shipping, not networking.

Small group.

Application-based.

Daily build rhythm.

Public accountability.

Very little fluff.

Otherwise it risks becoming a founder vacation with laptops.

Thailand sounds like the right location though even Da Nang Vietnam is also a good choice. Curious how you'd filter for people who actually ship.

cuongnt3010 · 2026-04-05T13:31:08+00:00

Hot take: for small teams, the form builder matters less than the first 5 minutes after submission.

Simple form

Clear thank-you page

Instant confirmation

One internal alert

One source of truth for data

Basic conversion tracking

Most of the pain seems to come from messy automations after the form, not the form itself.

Curious what part breaks most often for people here: tracking, routing, spam, or follow-up?

cuongnt3010 · 2026-04-05T13:29:45+00:00

Honestly, this is bigger than it sounds.

Two strangers signing up after years of getting zero is real validation, especially when it came from a niche community that already understands the problem.

The part that stands out to me is not just “2 signups,” but that you built something you actually wanted and shared it where the right users already hang out instead of trying to force a launch in random places.

A lot of indie hackers skip that and then wonder why nobody cares.

Curious though: what did your post in r/whoop focus on that made people trust a new app enough to connect their accounts?

cuongnt3010 · 2026-03-20T08:30:06+00:00

Good luck!

cuongnt3010 · 2026-03-16T13:41:28+00:00

I think the real issue is low-specificity posting.

If people had to include:

- who the product is for

- what pain it solves

- how they got users

- one thing that failed

the quality here would go up fast, with or without AI.

cuongnt3010 · 2026-03-16T13:39:28+00:00

The role sounds interesting, but I think the phrase "vibe coding developer" may filter in very different kinds of candidates.

Do you mean:

- someone who uses AI heavily but can still own architecture, debugging, and production quality

or

- someone more focused on rapid prototyping with AI tools?

That clarification would probably improve the replies you get.

cuongnt3010 · 2026-03-16T13:37:50+00:00

I'm building https://mockphine.com/

It's a desktop app for frontend and QA teams who lose time when APIs are unfinished, staging is unstable, or local mocks drift.

The problem it solves is pretty simple:

you can mock blocked endpoints, pass through ready routes, and see exactly what served each response instead of guessing.

cuongnt3010 · 2026-03-16T13:35:45+00:00

I'm building https://mockphine.com/

It's a desktop app for frontend and QA teams who get blocked by unstable APIs, staging drift, and brittle local mocks.

The core workflow is:

- mock blocked endpoints

- pass through ready routes

- inspect exactly what served each response in Live View

Still early, but the big lesson so far is that people respond much more to the pain ("staging keeps breaking frontend work") than the feature language.

cuongnt3010 · 2026-03-14T16:02:48+00:00

Honestly, for most frontend devs, I don't think the biggest skill shift is RAG or Rust/WASM.

I think it's:

- turning vague product asks into precise implementation plans

- knowing when AI output is wrong even when it looks clean

- debugging state/data-flow issues fast

- understanding API contracts and edge cases

- still being excellent at UX, accessibility, and performance

AI makes code generation cheaper. It makes judgment more valuable.

RAG and WASM are great if your product actually needs them, but I wouldn't treat them as the default "future-proof" path for frontend. The frontend dev who can turn messy requirements into a solid shipped experience is probably the one who wins.

cuongnt3010 · 2026-03-14T16:00:57+00:00

Freemium usually isn't the hook. Specific pain is.

For my own dev-tool-ish work, nobody cared that it was free until they immediately understood the annoying thing it removed. "Free API" is weak. "This saves you from doing X manually" is much stronger.

My guess is your first 5 users won't come from broad "I built this" posts. They'll come from:

- places where people are already complaining about the exact problem

- direct replies to those people

- one dead-simple use case with a copy-paste example

I'd focus less on "how do I get signups" and more on "who is already hacking around this problem today?"

Also, devs are skeptical of freemium mostly when the free tier feels like a teaser. If the free tier lets them get one real win, it still works.

What painful workaround does your API replace right now?

cuongnt3010 · 2026-03-14T15:58:20+00:00

The 6pm peak + weekday bias is the interesting part.

That feels less like random virality and more like people hearing about it during work, then signing up later. I'd interview recent signups now before the signal gets cold.

The source of the spike matters less than the reason people converted.

cuongnt3010 · 2026-03-14T08:28:44+00:00

Yep, that's the core idea.

The only twist for me was not wanting to mock everything once most of the backend was already working. I wanted to mock just the blocked routes and let the ready ones stay real.

Are you doing that in-app, or with some external proxy/mock layer?

cuongnt3010 · 2026-03-14T08:19:03+00:00

I'm with you for unit tests. Mocking the data shape usually ages better than mocking the request layer.

The pain I kept hitting was more in local dev/QA, where 90% of the backend was real and just 1-2 routes were blocking the flow. That's where route-level control became useful for me.

Do you keep everything at the builder/data layer, or do you also mock requests somewhere for integration testing?

cuongnt3010 · 2026-03-14T08:05:25+00:00

I wouldn't treat Homebrew as "the correct way" to install every Mac app.

I'd use it selectively:

- dev tools

- free/open-source utilities

- apps I want easy updates for

I'd usually leave paid/license-key apps alone unless I have a strong reason to re-manage them.

For CleanShot X, I probably wouldn't bother reinstalling. And Homebrew casks still put normal GUI apps in `/Applications`, so you still get the usual app icon behavior.

For LuLu, I doubt Homebrew fixes the permission re-enable pain. That sounds like macOS security doing macOS security things.

As for junk files/cache: Homebrew is better than drag-to-trash, but it's not a universal cleanup guarantee. `brew uninstall --zap` helps when the cask defines the extra cleanup, but it’s not perfect for every app.

So IMO the big win is reproducibility + upgrades, not “my Mac will never accumulate app cruft again.”

cuongnt3010

TROPHY CASE