For people with a software idea and no way to build it
You can describe the product exactly. You know the job it does, who opens it on a Tuesday morning, and which three things it has to get right, because you have done that job for years. What you do not have is a way to make it exist. Every route runs through someone who only gets paid if you proceed — the agency writing the quote, the freelancer billing the hours, the technical co-founder everyone tells you to go and find.
This page is what RunMyB does about that, and what it does not do. RunMyB is in closed beta, by invitation, and we do not publish our pricing yet: every figure on this page is the cost of the route you would otherwise take. What the platform charges is shown to you in the product, itemised, before anything is charged.
How do I find out if the idea is any good before I spend the money?
Before anything gets built, the idea goes through a market research pass and an explicit go/no-go gate — and the gate is allowed to say no. It is deliberately conservative: it refuses to treat interest as demand, and across the ventures put through it, it has essentially never returned a go for a market that already has an established incumbent. Research produces a read on the opportunity, never a build specification, so the answer cannot quietly become a sales document. A person makes the final call and can overrule the gate. You keep the research either way.
That step is missing everywhere else, and not by accident. The AI app builders start at “build” and will construct whatever you describe. The agency conversation ends in a quote written by people who only get paid if you proceed. Neither is lying to you. Neither is arranged to tell you no.
You have to describe the idea in detail for it to be researched, so the counter-question is fair. Terms §10.1 says we will not use what you describe to build a product that competes with yours, and we do not train models on your content (§10). The same clause states its own limit: that is not a promise of exclusivity, and someone who independently describes something similar may get something similar. Ask an agency or an AI builder to put either half in writing before you describe your idea to them.
Why does a custom app cost so much, and what should I budget?
A simple custom web app quotes at $15,000–50,000 from an agency, and mid-complexity work at $75,000–250,000 and up in North America. Where the team sits moves the hourly rate a long way: San Francisco agencies bill $150–250+ an hour, Canadian ones $100–175, Eastern European and South Asian teams $30–80. A freelance developer is cheaper by the hour and leaves you owning hosting, payments and authentication afterwards. Three quotes for the same idea disagree by an order of magnitude because none of those vendors knows yet what they are pricing: nobody has written the specification.
| Route | What it costs | What you are left holding |
|---|---|---|
| Agency custom build | $15,000–50,000 for a simple custom web app; $75,000–250,000 and up mid-complexity, on North-American agency figures. Post-launch upkeep runs 15–20% of the build cost a year. | The code, if your contract said so. Every later change re-enters a paid queue. |
| Freelance developer | On Upwork's own guide (May 2026): $10–25 an hour for beginners, $25–60 intermediate, $60–120 and up for advanced or specialist development. By region: North America $80–140, UK $75–95, Germany $70–85, Eastern Europe $40–70, Latin America $30–55, senior Polish developers $60–90. | Hosting, payments, authentication, updates, and whatever happens when that person moves on. |
| No-code subscription | Bubble $29 / $119 / $349 a month for a web app billed annually ($32 / $134 / $399 billed monthly), plus metered workload units; Wix $17–159 a month on a yearly plan paid up front. | A subscription, and an application that does not leave the platform it was built on. |
| First technical hire | About $100,000–150,000 fully loaded in the first year for a software developer. | An employee — and the same salary again next year. |
RunMyB does not publish its pricing yet, so there is no row for us in that table. What the platform charges is shown to you in the product, itemised, before anything is charged. What we can compare against here is the route you would otherwise take.
I cannot write a technical spec — can I just describe what I want?
You will not be asked for a specification. You describe the job in plain language, in conversation, and the build starts from that. Every build clears an honest floor before you see it — it serves, it loads, it does not crash; a build with a database additionally proves your data survives a restart. That floor certifies the software works. It never certifies that your domain logic is right. Only you can judge that, and there is a private preview to judge it on.
This is the failure a domain expert should worry about. An agency delivers against the written brief and leaves, so a brief that was subtly wrong surfaces after payment and is priced as change orders. If you know how freight brokers, or hygienists, or claims handlers actually work, the risky step is translating that into a document you have never written before. There is no document here to get wrong.
Do I get a real application with a database and user logins, or just a website?
Three shapes get built here: a tool that runs in the browser, an application with its own isolated database, and an application with its own end-user accounts. An accounts build ships real signup, email verification and password reset, passkeys, TOTP two-factor and account-linking safety, generated as part of the build rather than bolted on afterwards. Every such build must clear a seven-core authentication floor, and one of those cores is cross-user isolation. A build that cannot demonstrate the floor does not pass.
When an apparent cross-account leak was reported in a build here, we investigated it and refuted it: both records belonged to the same account. The defect that was real turned out to be a different one — the application never showed which user was signed in. Generated authentication now carries an identity contract: a build with accounts must show who is signed in. That is what looking properly gets you, the true answer and a fix to the thing that was actually wrong.
One limit, in the same breath. What gets built runs in a browser: we do not build phone apps, there is no app-store submission, and none is planned. If the people who must use the tool are in a yard or a van and will only ever tap an icon, that is a real constraint, and you should hear it in the first conversation rather than the fifth.
How do I see it before anyone else does?
“It works” is not the bar, and we do not claim it is. Every build clears the floor — it serves, it loads, it does not crash; a build with a database proves data survives a restart. None of that judges wording, flow or taste. You are the quality bar. What the platform gives you is somewhere private to be it: a preview only you and the people you send the link to can reach, a loop to change and re-verify what you find, and a publish step that never happens without your word.
Accepting a build and publishing it are two separate acts, and both are yours. Before anything is served to the public we review it as well — a platform that hosts strangers' software and reviews none of it is a platform with a problem.
Who hosts it, and what do I have to set up myself?
Nothing. Every product gets its own isolated database and its own sandboxed runtime, provisioned and operated by the platform, with outbound traffic leaving only through a small set of approved, metered paths. You never open a cloud account, wire a database, request a certificate or point a domain. The usual shape in this category is the opposite: Lovable, Bolt, v0, Replit and Base44 hand you a working application and a second job — connect a database, wire up hosting, point a domain.
- Its own isolated database and its own sandboxed runtime, one per product.
- A private preview, reachable by you and whoever you send the link to.
- Public hosting of a full-stack application — database, end-user accounts and all, at an address you can send people to. (we review a product before it is served publicly)
One thing to plan for: a hosted application's database starts empty. Nothing is lifted out of the spreadsheet, the shared drive or the system you are replacing, and we run no migration service. If eleven years of records have to be in there on day one, that is work someone has to do, and it is better known now than in week six.
Can I change it after launch without going back to a developer?
Changing a product you own never re-enters a paid queue. You describe the change in plain language; the platform makes it, re-certifies the whole build against the floor it passed originally, and stops at an approval gate. Nothing ships until you approve it. On the agency path, post-launch upkeep runs 15–20% of the build cost a year and every small edit goes back into a queue and onto an invoice. Here there is no invoice, no two-week window and no negotiation.
Re-certification matters more than it sounds. Re-prompting an application carries no notion of checking that the change did not break what already worked: you ask for one feature, the login stops working, and nobody notices for a week. Every change here is re-certified against the whole build before it reaches you — it must serve, load and not crash; if it stores data it must survive a write, a restart and a read-back; if it has accounts it must pass the seven-core authentication floor. Only then does it arrive at your approval gate.
It is a floor, not your specification. The rule you added last month is yours to check at the gate, which is exactly why there is a gate.
If I want to leave, do I take my product with me?
Every product built here lives in a git repository, a commit per build step. Export pushes its current code into your own GitHub or GitLab account, under your ownership (Terms §12.1); from there you keep it in two-way sync, or bring a repository you already own and have it managed onward. A full-tree secret scan runs before every push and refuses the push when it finds likely credentials — a safeguard operated on a best-effort basis, not a warranty that every secret is caught (Terms §12.4). You own the output either way (Terms §11) — export changes where it lives, not who owns it.
Two things about that export, said now rather than on the way out. What travels is source: hosting and the database are things you would stand up somewhere else. And the export arrives as a fresh single-commit history — the step-by-step build log stays with us as the operational record we build, verify and serve previews from. A subscription storefront exports your content and never the thing that runs it; this exports the thing that runs it. The week to try an export is a week when everything is fine.
Will you bring me customers?
Not in the sense you are asking, and we will not promise you traffic. We send you nobody you did not bring: there is no ad network and no lead generation here, and finding buyers is yours. If you have no way at all to reach the people who would pay, build that first — we would rather say so than sell you a build.
What does exist is a catalogue. Every product on the platform gets a place on this site — findable, browsable, each entry showing who built it. Today it is small and new. The earlier you are on it the easier you are to see, before the shelf fills up; that is a position on a shelf we control, not an audience we have. A catalogue is worth visiting only if what is in it is worth using, so judge it by what is on it — and plan your own way of reaching people. If ours starts working, it is an advantage on top, not the plan.
What is written down, rather than just said: we will not market to the customers you introduce here and will not approach them with an offer that goes around you (Terms §10.2). More than half of independent creators earn under $15,000 a year (Influencer Marketing Hub, Creator Earnings Report 2025); the ones at the top run several revenue streams. That spread is a distribution outcome, not a tooling one.
How do I get access?
RunMyB is in closed beta. Access is by invitation only and there is no public self-service sign-up. How access works, and what we send you if you are invited, is on the access page. The commitments quoted here are in the Terms of Service in full, and the rest of the platform — including what it does not do — is on the home page. To ask about it or request an invitation, write to hello@runmyb.com.