The first 10 customers for this idea are hiding in plain sight, but getting to 100 is a different problem entirely.
There's a specific kind of pain that this idea targets, and it's real. You're an integration engineer at a fintech company. Some vendor hands you an Android SDK with zero documentation. Your job is to figure out what API calls it's making, what it's sending, and whether any of it conflicts with your own backend. So you fire up jadx, start grepping for URLs, and spend the next two days building a mental model of someone else's code. It's awful work. It doesn't require creativity. It just requires patience and caffeine.
The Automated Android App Reverse-Engineering Toolkit exists to automate that exact workflow and spit out an OpenAPI spec and a Postman collection at the end. That's the pitch. And honestly, the pitch is good.
But let's talk about the first 10 customers, because that's where the theory gets tested.
The go-to-market plan here is reasonable: post a Show HN, drop a Loom demo in r/androiddev, DM integration engineers on LinkedIn, and offer a free one-APK pilot. That's a solid sequence. The question is what you're optimizing for in those first conversations.
The HN post will generate interest. It always does when the demo is concrete and the pain is obvious. A 3-minute video showing APK-to-Postman versus a 4-hour manual process is a compelling artifact. You'll get upvotes. You'll get comments. Some of those commenters will be exactly the people you want.
The problem is converting that interest into paying customers. This is where the idea's structural tension becomes visible.
The target customer, an enterprise integration engineer who regularly receives third-party APKs with no documentation, is a real person. But they're rare. The data in this idea estimates 80,000 to 120,000 globally, which sounds big until you factor in how many of them are senior enough to have budget authority, work at companies where APK analysis is frequent enough to justify a subscription, and aren't already solving this with an internal script.
My honest read: your first 10 customers probably come from three buckets.
Bucket one is mobile security consultancies. These are the people who analyze APKs for a living, charge clients by the hour, and would genuinely benefit from a tool that cuts a 12-hour engagement down to 90 minutes. The white-label reseller arrangement mentioned in the go-to-market plan is smart here. A boutique AppSec firm could sell APKMap as part of their methodology and make the $299/month look cheap against their billing rates.
Bucket two is fintech and logistics companies with Android apps in production. These companies have integration engineers who touch third-party SDKs constantly. The compliance angle matters here too: documenting what an SDK is doing before you ship it is increasingly a legal requirement, not just good practice. That framing changes the conversation from 'this saves time' to 'this helps us not get fined.'
Bucket three is the solo security researcher who doesn't have enterprise budget but will pay for the Team plan because $299/month is nothing compared to their consulting rate. These customers are easier to close but harder to retain, because their APK analysis is episodic by nature.
This is the part of the analysis I keep coming back to. Most SaaS tools justify their monthly fee because you use them constantly. Monitoring tools, CRMs, analytics dashboards. The value is continuous. APK analysis isn't like that. A team might process three APKs in a quarter. Maybe five if they're busy.
At $299/month, that's $100 per APK. Not crazy, but not obviously cheap either, especially when the alternative is a senior engineer spending a day on it. The math works if your team's time is worth money to someone. It doesn't work if the engineer doing the analysis is already paid a salary and the APK work is just part of their job.
A per-APK credit model at $15-25 per run probably converts better at the top of the funnel. It makes the purchase decision feel lower-stakes. The tradeoff is that your ARR becomes lumpy and hard to forecast. There's no clean answer here. You'd need to talk to 20 potential customers to figure out which pricing model they actually prefer, which is exactly what the validation test in this idea recommends.
I want to spend a moment on something that gets mentioned as a risk but deserves more weight. The DMCA exposure here is real. If a customer uses this tool to reverse-engineer a competitor's app and that competitor sues, the tool itself could end up in the lawsuit. DMCA §1201(f) has an interoperability exemption, but it's narrow and requires that the intent actually be interoperability, not competitive intelligence gathering.
This isn't a hypothetical. It's the kind of thing that causes an enterprise legal department to block a purchase without even talking to the engineering team. One unfavorable news story about an APKMap-related legal dispute could freeze the entire pipeline overnight.
The mitigation in this idea, a ToS clause placing liability on the user and a mandatory legal acknowledgment at signup, is standard and probably insufficient on its own. The smarter play is to explicitly position for 'apps you own, license, or have written authorization to analyze' from day one, in every piece of marketing copy, not just the terms of service. Make the legitimate use case so visible that ambiguous use cases feel obviously out of scope.
If you follow the validation sequence here, the success metric is five enterprise contacts who confirm they analyze five or more APKs per year and express willingness to pay $3,000 or more annually, before any code is written. That's the right bar.
Those five conversations will tell you things no amount of market research can. They'll tell you whether the on-prem requirement is table stakes or a differentiator. They'll tell you whether OpenAPI export is the thing they actually want or whether PDF reports for auditors matter more. They'll tell you whether security consultancies are the real distribution channel or whether it's direct outbound to engineering leads.
The proof of demand is already there. That Reddit thread in r/androiddev with 23 upvotes and 11 comments confirming manual workflow fatigue is not a big number, but it's specific. And the consistent feedback in MobSF reviews about missing export formats is exactly the kind of gap that turns into a product.
The ceiling here is probably a lifestyle business, not a venture-scale outcome. The market analysis puts a realistic 1% capture at somewhere between $2.4M and $9.6M ARR. That range is wide because the assumptions are uncertain, which is honest. For a solo founder who builds this and runs it lean, that's a genuinely good outcome. For someone who raises money expecting to compete with NowSecure, it's not.
The first 10 customers are findable. Whether they turn into 100 depends on how frequently the people who need this tool actually need it, and the answer to that question is sitting in those first 10 conversations.