Startup Ideas Bank
A clever developer tool that sits one policy letter away from getting crushed.
AI roast score: 58/100 (D)
The idea
This is a tool for turning someone else’s app into your own API client. That’s elegant until the app, the lawyers, or the proxy settings decide you are the product.
In the founder's own words
littledivy/mimic — Intercept any app, then call it from Python like a library
mimic
Intercept any app, then call it from Python like a library.
from hinge_client import Hinge
acc = Hinge () # reuses your captured session
recs = acc . get_recommendations ()
acc . like ( subject_id , comment = "hi lol" )
You don't write hinge_client.py . mimic captures your own app traffic and an AI
generates the client from it.
How it works
Most apps authenticate every request with the same bundle of values: a bearer
token, some device ids, a session id, cookies. They're stable across calls.
Capture them once from a real request you made, and you can replay them on new
requests to the same API.
capture traffic -> extract auth -> generate client
(mitmproxy) (mimic.Session) (claude reads the
captured endpoints)
The generated client is plain Python on top of mimic.App , and you edit it like
any other file. It gives you named methods, body templates, and the multi-step
call chaining mobile APIs tend to need (fetch a token in one call, spend it in
the next).
Install
sh install.sh
Installs uv if you don't have it, then mimic in an
isolated tool env. mitmproxy isn't a separate install; mimic launches it via
uvx on first record . (Manual: uv tool install mimic-client .)
mimic doctor # confirm proxy + claude are ready
Use it (iPhone)
mimic record # starts the proxy, prints the iPhone steps
record fills in your Mac's LAN IP and walks you through it:
iPhone -> Wi-Fi -> Configure Proxy -> Manual -> <your-mac-ip>:8080
Safari -> http://mitm.it -> install the Apple profile
Settings -> General -> About -> Certificate Trust Settings -> turn on full
trust for mitmproxy. This step is easy to miss and nothing works without it.
open the app, use it normally
Then:
mimic hosts # list captured hosts; pick your API host
mimic learn prod-api.hingeaws.net # see the endpoints mimic saw
mimic gen prod-api.hingeaws.net # generate hinge_client.py
Then from hinge_client import Hinge; Hinge().get_recommendations() .
The library
Three ways to build a session by hand, if you don't want codegen:
from mimic import Session
Session . from_mitm ( "prod-api.hingeaws.net" ) # pull auth from mitmweb
Session . from_curl ( open ( "copied.txt" ). read ()) # paste "Copy as cURL" from devtools
Session ( base_url = "https://x.com" , headers = {...}) # explicit
.get(path) , .post(path, json=...) , and the other common HTTP verb helpers
return parsed JSON and raise requests.HTTPError for failed responses. If your
token rotates, a 401 on an idempotent request triggers one re-pull from
mitmweb and a retry. Non-idempotent requests are not retried unless you explicitly
pass refresh=True .
Capture backends
mitmproxy for iOS apps (the default)
The roast
The core idea is genuinely sharp: “Intercept any app, then call it from Python like a library” is a real painkiller for developers who want a quick client without hand-writing every endpoint. The problem is that the pain is narrow, and the upside is fragile. You are betting that enough developers want to automate third-party mobile apps, and that those apps stay stable long enough for your generator to keep working. Your own pitch admits the weak spot: you are relying on captured traffic, stable auth bundles, and replaying requests from “a real request you made.” That is not a moat. It is a moving target. As soon as an app changes its device checks, rotates tokens harder, adds certificate pinning, or blocks proxy traffic, your nice Python wrapper turns into a broken demo. The product feels like infrastructure, but the failure mode is babysitting every target app. The bigger issue is trust and regulation. You say your biggest unknown is regulators, and that is not paranoia; it is the obvious risk. A tool that helps people replay private app traffic can be framed as a developer convenience or as a bypass kit, depending on who looks at it. That makes distribution, payments, and platform relationships messy from day one. Speed is your only stated moat, and speed is not a moat when the other side can change one header and kill your product.
Red flags
- The product depends on target apps keeping their auth and request patterns stable, which is exactly what apps change whe
- Your biggest unknown is regulators, but the product itself is built around intercepting and replaying app traffic, which
- You are a solo founder with no funding in a developer market that expects reliability, support, and constant compatibili
Verdict
Build it only if you can prove developers will pay for repeated access to a small set of stable targets; otherwise this is a clever demo, not a durable business.
Start with your own startup idea →
More ideas roasted by AI
- ZYFT's lofty vision falls flat without a clear execution plan. 58/100
- AI candidate assessments: Another solution looking for a problem? 58/100
- A clever plugin shell is not a company until someone cares enough to switch. 58/100
- A useful health kiosk, but the business is trying to sell hardware, software, ads, and trust to four different buyers at once. 61/100
- أنت تريد تصنع أصلًا ثقيلًا جدًا، ثم تصدّره بأمل وسعر «تنافسي» وكأن المصنع نفسه لن يلتهمك قبل أول طلب. 18/100
- This is a sticky note with a printer bolted on, not a business yet. 32/100