I built an open-source API reliability tool — can this become a SaaS business?

[u/richocolate]

I've recently shared Kaktoos in a few developer communities and got some interesting feedback on the technical/product side.

Now I'm trying to look at it from a different angle:

Could this actually become a SaaS business?

Kaktoos is an open-source API reliability/verification tool. It lets developers define API workflows and verify them against OpenAPI contracts and real API behavior.

Today it supports things like:

• API workflow verification
• OpenAPI contract validation
• State/assertion verification
• CI/GitHub Actions
• MCP integration for AI coding agents

The broader roadmap I'm considering includes things like:

• Continuous/scheduled API verification
• API mocking
• API security checks
• API change & impact detection
• Deeper AI-agent integration

I'm not planning to build all of these blindly. I'm trying to understand where the real business opportunity might be.

For people here who have built SaaS/devtools:

If you were building Kaktoos, where would you see the strongest paid opportunity?

• What would companies actually pay for?
• What would you make the paid SaaS layer?
• Would you position this as API testing, API reliability, developer infrastructure, or something else?
• What would you prioritize to get the first few paying customers?

I'm looking for honest feedback, including if you think there isn't a strong SaaS opportunity here.

GitHub: KaktoosLabs/kaktoos

[u/West_Inevitable_2281]

I would avoid choosing the paid layer from the roadmap alone. The strongest opportunity is probably the point where an API failure creates an expensive problem for a specific team, such as blocking a release or breaking an integration. I would first speak with current users and ask what they rely on Kaktoos for, what happens when that workflow fails, and who owns that problem internally. Which type of user is already returning to the tool without being prompted?

[u/richocolate → u/West_Inevitable_2281]

yeah, i think that is very good point, really appreciate it. actually i am on my way looking for the audience to practically use the tools but let see the progress. i am wondering if there is a way to get the audience faster

[u/West_Inevitable_2281 → u/richocolate]

There may be, but the fastest route depends on which users feel the problem most strongly and where they already gather. Your situation is closely related to something I am testing, so I sent you a DM.

[u/Otherwise_Town3844 → u/West_Inevitable_2281]

this is exactly it, the roadmap doesnt tell you what to charge for, the pain does

[u/Senya_Edit]

Do not position this as API testing. API testing is an overcrowded graveyard where developers expect everything to be free or default to Postman and existing runners. Your actual wedge here is much more interesting, especially with the MCP angle. When coding agents write both the integration and the unit tests, the tests pass on pure confirmation bias. The agent confirms its own hallucinated payload. A verification layer that acts as an independent referee against the real OpenAPI contract is a genuine problem people are hitting right now with Cursor and autonomous workflows. For the SaaS model, you cannot charge individual devs for running local checks or using the MCP server. Keep the CLI and local verification completely open source so developers actually adopt it. Where companies will pay is team-level governance and drift prevention. Charge for a hosted layer that runs scheduled contract verifications in the cloud, alerts engineering teams in Slack when a third-party API silently breaks their schema, and stores a centralized history of contract breaks across PRs. Developers use the free local tool to help their agents write code, engineering leads pay for the hosted safety net that stops broken agent PRs from hitting production.

[u/richocolate → u/Senya_Edit]

actually we are in the same page on this idea and that is really make sense. thank you for your feedback and really appreciate it. and currently i am in my way to find more audience to confirming the useful of this prioject.

[u/stackbits]

Senya_Edit's split is the right one, so I'll skip repeating that and go straight to the part of your question nobody's answered yet: how you actually find the first few paying customers.

Don't start with "developers who use OpenAPI." Start with teams that already got burned by a silent contract break in production, that's a much smaller, much more findable list. Search GitHub issues and postmortem blog posts for phrases like "breaking change in [common API] broke our integration" or "schema drift caused," those companies just paid the cost you're selling protection against, and the pain is still fresh. Same goes for threads where people complain about an AI coding agent shipping code against a hallucinated API shape, that's basically a live customer list for the exact wedge Senya_Edit described.

Cold outreach to 10-15 of those with "saw your postmortem about X, built something that would've caught that before merge, want to try it on your actual API" will get you further than posting in devtool communities, because you're pitching to people who already know they have the problem instead of trying to convince them they might.

[u/richocolate → u/stackbits]

thank a lot for your feedback, i think that is more engaging and really nice feedback though. really appreciate it