RESTFlags
Feature flags over plain HTTP, with no SDKs or agents.
Tagline
Feature flags over plain HTTP
Infrastructure, not a platform tax.
The API-first alternative to bloated flag tools.
Add kill switches to any runtime in minutes.
The feature flag service for teams that want infrastructure, not a platform tax.
The page repeatedly attacks SDKs, agents, per-seat fees, and contract friction. Positioning it as a lean infrastructure primitive fits the product truth and differentiates it from heavyweight incumbents.
An alternative to LaunchDarkly and CloudBees for API-first teams.
The pricing table explicitly contrasts RESTFlags against an incumbent at roughly $45 per million versus $5 per million, and the product’s plain-HTTP approach is a sharp wedge against SDK-centric enterprise flag vendors.
The fastest way to add kill switches and gradual rollouts to any runtime.
The combination of one POST evaluation, three-step integration, ten-second propagation, and one-click rollback makes it ideal for teams whose biggest need is safe release control, not experimentation bureaucracy.
Primary user
Backend engineer or platform engineer at a small-to-mid SaaS company shipping flags into services without wanting another SDK stack
ICP #1
Founding engineer at a B2B SaaS startup under 20 people
Pain
They need to gate launches, roll back bad releases, and do cohort-based rollouts, but every mainstream flag tool feels heavy: SDK installs, streaming agents, and a pricing model that gets expensive before the product has revenue.
Why this solves
RESTFlags gives them a single HTTP call to evaluate flags, so they can ship in minutes from any stack and avoid introducing infrastructure they must maintain or upgrade.
ICP #2
Platform engineer responsible for a mixed stack of legacy services, cron jobs, and edge workers
Pain
Their systems are spread across languages and runtimes, so adopting an SDK-based flag vendor means inconsistent implementation, dependency drift, and operational risk from background agents or sockets.
Why this solves
Because RESTFlags is plain HTTP, every runtime can call the same endpoint, and stateless evaluation avoids warm-up, sidecars, and cascading failures.
ICP #3
Technical product manager or engineering manager at a scaling SaaS team
Pain
They want controlled feature rollouts, a reliable kill switch, and auditability for every flag change, but they do not want per-seat pricing or a procurement process that slows adoption.
Why this solves
RESTFlags bundles targeting, percentage rollout, audit logs, RBAC, and webhooks into one usage-priced service, so the team can collaborate freely without seat-based cost pressure.
Strengths
- +The page is unusually concrete: it shows an actual curl example, actual latency, actual pricing, and a real API shape.
- +The messaging is crisp and differentiated: plain HTTP, no SDKs, no agents, no per-seat fees.
- +The feature list is credible for engineers because it names practical primitives like audit logs, RBAC, webhooks, rollouts, and a kill switch.
Weaknesses
- −It over-indexes on cost and anti-incumbent rhetoric; that may attract bargain hunters but undersells trust, control, and simplicity as the real reasons to buy.
- −The product surface area is not fully explained: there is no visual of the dashboard, no rule builder example, and no explanation of how targeting logic actually behaves.
- −The launch copy is very startup-y and AI-SaaS-specific in places, which narrows perceived applicability even though the product is broader than AI apps.
- −The security/compliance story is thin despite claiming signed audit logs and role-based access; there is no detail on retention, encryption, or access model.
- −The benchmark table is persuasive but framed as illustrative, which weakens credibility if not backed by a methodology.
Fix these
- Add a concrete workflow example showing create-flag, target-cohort, evaluate, and rollback in one screen or one code sample.
- Create a comparison page against LaunchDarkly, Flagsmith, Unleash, and CloudBees that explains why HTTP-native integration matters.
- Replace some of the pricing-heavy copy with proof points about uptime, propagation behavior, and operational simplicity for real engineering teams.
- Add an "works with any runtime" section featuring Python, Go, Node, cron, Cloudflare Workers, and legacy services to broaden the audience beyond AI startups.
- Show the audit log and rule editor UI so buyers can see whether the product feels lightweight or merely minimal on the surface.
Drop-in replacement copy
Headline
Feature flags over plain HTTP
No SDKs, no agents, no sockets.
Ship flags from any runtime
If it can make an HTTPS call, it can evaluate a flag. That covers backend services, cron jobs, edge workers, shell scripts, and legacy systems without introducing a new SDK stack.
Roll out safely without ceremony
Use rules, segments, percentage rollouts, and scheduled releases to control exposure. Changes propagate in about ten seconds, so rollbacks stay fast and predictable.
Kill bad releases instantly
A one-click global kill switch gives you a blunt, reliable escape hatch when something goes wrong. Signed, hash-chained audit logs keep every change traceable.
Keep access tight and simple
Scoped API keys, role-based access, and three environments make it usable for real teams without turning flagging into a procurement project.
FAQ
Do I need to install an SDK?
No. RESTFlags is built around plain HTTP requests, so any runtime that can make an HTTPS call can use it.
How fast do flag changes propagate?
Changes are typically picked up in about ten seconds. That keeps rollouts and rollbacks fast without requiring streaming infrastructure.
Can I use this in legacy services or cron jobs?
Yes. That is one of the main reasons this exists. If the runtime can call an API, it can evaluate a flag.
What kinds of flags do you support?
Boolean, string, number, and JSON flags, plus rule-based targeting, segments, percentage rollouts, and scheduled releases.
How is this different from LaunchDarkly or Flagsmith?
The wedge is the integration model. RESTFlags is HTTP-native, so you avoid SDK sprawl, agents, and language-specific drift across mixed stacks.
RESTFlags is feature flagging over plain HTTP. No SDKs. No agents. No sockets. If your service can make an HTTPS call, it can evaluate flags. Built for backend, edge, cron, and legacy systems that don't need another dependency.
RESTFlags is the feature flag service for teams that want infrastructure, not a platform tax. Plain HTTP evaluation. Scoped keys. Audit logs. Kill switch. The boring way to ship releases safely.
I kept seeing the same problem: teams wanted rollouts and kill switches, but didn't want SDK sprawl. So I built RESTFlags around one idea: if a runtime can call HTTPS, it can use feature flags. That includes cron jobs and edge workers.
Feature flag changes propagate in about 10 seconds. Fast enough for real rollouts. Slow enough to stay simple. No streaming infra. No background agents. Just stateless HTTP evaluation.
Feature flags should reduce risk. But SDKs, agents, and sockets often do the opposite. RESTFlags keeps it simple: one API, one auth model, one way to evaluate flags from any runtime.
Not every system is a shiny Node app. Some are Python jobs, Go services, workers, cron, or ancient monoliths. RESTFlags works anywhere HTTPS works. That's the whole point.
Create flag. Set rules. Evaluate over HTTP. Then flip a global kill switch when something breaks. RESTFlags was built to make rollout control feel like an API primitive, not a project.
curl the flag. Get back boolean, string, number, or JSON. Target by rules, segments, or percentage rollout. Same endpoint works from backend services, edge workers, and scheduled jobs.
The most common feedback so far: "We just want a kill switch." "We don't want another agent." "We can't justify enterprise pricing for a startup." RESTFlags is for those teams.
I care less about making feature flags fancy. I care about making bad deploys reversible. If you can stop a broken release with one HTTP request, that's useful software.
Angle: HTTP-native infrastructure
Most feature flag tools assume every service should install an SDK, keep a connection open, and sync state in the background. That works until you have a mixed stack. Legacy services. Cron jobs. Edge workers. Small teams. I built RESTFlags around a simpler idea: if a runtime can make an HTTPS call, it should be able to evaluate a flag. No SDKs. No agents. No streaming sockets. Just plain HTTP for: - boolean, string, number, and JSON flags - rule-based targeting - segments - percentage rollouts - scheduled releases - global kill switches - signed audit logs The point is not to make flags fancy. The point is to make rollouts boring, portable, and hard to break. If you're shipping across multiple runtimes, that's the difference between adopting flags in an afternoon and adding another platform project.
Angle: trust and operational simplicity
A lot of feature flag products lead with pricing. I think the real buying criteria are simpler: Can I trust it? Can I roll back fast? Can I use it everywhere? RESTFlags is built for that. One HTTP API. Scoped keys. Role-based access. Three environments. Signed, hash-chained audit logs. A one-click kill switch. That matters more than a slick dashboard. Because the flag service is not the product. The ability to stop a bad release is the product. Teams don't need more ceremony around release control. They need less friction and fewer dependencies. That's the wedge: infrastructure, not a platform tax.
Angle: broad applicability beyond AI startups
Feature flags are not just for AI apps. They are useful anywhere you need controlled rollout and fast rollback: - SaaS backend services - cron jobs - edge workers - old monoliths - internal tooling RESTFlags is intentionally boring in the best way. It works over plain HTTP, so the same flag evaluation flow can live in Go, Python, Node, a shell script, or a worker at the edge. That portability is the product. Not another SDK. Not another agent. Not another thing your team has to upgrade later. If you have more than one runtime, you already know why this matters.
No visuals for this kit yet.
Tagline
Feature flags over plain HTTP
Description
RESTFlags lets any runtime evaluate feature flags with one HTTPS call. No SDKs, no agents, no sockets — just targeting, rollouts, scheduled releases, and a kill switch for backend and edge teams.
Maker's first comment
I built RESTFlags after watching teams do the same awkward dance over and over: they wanted safe rollouts, but they didn't want to install yet another SDK, keep a streaming connection alive, or bring in a heavier platform than the problem deserved. The design goal was simple: if a runtime can make an HTTPS request, it should be able to use feature flags. That meant supporting backend services, cron jobs, edge workers, and legacy systems without forcing a new dependency model. The best feedback so far has been from engineers who said, "I just need a kill switch" or "I need this to work in a mixed stack." That's exactly the use case I wanted to hit. I'm especially interested in hearing from people who have lived with LaunchDarkly, CloudBees, Split, Flagsmith, or Unleash and decided the SDK/agent model was more than they wanted to carry.
Pinned maker comment
Would love feedback on the balance between simplicity and trust: does the HTTP-native model feel compelling enough for real rollout control, and what security/compliance details would you need before using it in production?
Meta
SDKs are the wrong abstraction.
Hypothesis: backend teams with mixed runtimes will adopt feature flags faster if they can evaluate them over plain HTTP instead of installing SDKs or agents. RESTFlags gives you targeting, rollouts, scheduled releases, and a kill switch from any HTTPS-capable service.
Google Search
Feature flags without SDKs
Hypothesis: teams searching for LaunchDarkly alternatives want lower operational overhead, not just lower cost. RESTFlags is an HTTP-native feature flag API for backend, edge, cron, and legacy systems. One call. Fast propagation. Audit logs.
Reddit Promoted
Our stack had too many flag SDKs.
Hypothesis: indie SaaS teams in r/SideProject and r/indiehackers will respond to a feature flag tool that works anywhere HTTPS works. RESTFlags avoids agents, sockets, and language-specific SDK drift. If you need rollout control, it stays boring.
Subreddits
r/SideProject
Show the exact curl flow: create flag, target cohort, evaluate, then kill switch
Rules: Self-promo is allowed only when genuinely relevant; be transparent; show the product and the problem, not hype.
r/indiehackers
How I built a feature flag service that works without SDKs
Rules: No spam; share lessons, numbers, and the build story; comments matter more than drive-by promotion.
r/microsaas
Micro-SaaS launch control for small teams that do not want enterprise flagging
Rules: Focus on small SaaS problems; avoid broad marketing claims; keep it tactical and concrete.
r/EntrepreneurRideAlong
Build log: shipping an HTTP-native flag API from scratch
Rules: Story-driven posts do well; keep the tone honest and detailed; no pure link drops.
r/devops
Plain HTTP feature flags for mixed stacks, cron, and edge workers
Rules: Technical depth required; emphasize operational simplicity, failure modes, and architecture.
Communities
Post a build story with screenshots, pricing rationale, and one technical lesson about stateless evaluation. Then reply to every comment with specifics.
Submit with a technical title, not marketing. Lead with the API design choice and the reason SDKs were rejected.
Write for engineers: architecture, tradeoffs, and why HTTP-native evaluation reduces operational risk.
Cold outreach template
Hey {firstName} — saw you mentioned {context}, and RESTFlags might fit. It does feature flags over plain HTTP, so you can use it from any runtime without SDKs or agents. If you want, I can send a 2-minute curl demo.
Product Hunt timing
Launch Tuesday morning PT, then stay active through the first 12 hours; PH traffic is strongest when makers can reply quickly, and this product needs explanation in comments because the HTTP-native angle is the differentiator.
Indie Hackers post ideas
- 01I built feature flags without SDKs: why plain HTTP won for mixed stacks
- 02The kill switch mattered more than the dashboard
- 03How I priced a feature flag API for startups before they need enterprise software
Competitor alternatives
Current tone of voice
Confident, anti-bloat, engineer-first, and a little provocative; for example: "No SDKs, no streaming sockets, no language lock-in" and "No time-based contracts, no procurement cycle, no minimum spend."
Your kit is ready. Sign up free to unlock, takes 10 seconds.
7 more X posts · 2 LinkedIn · Product Hunt copy · ad hooks · 100-user playbook · landing critique