For firms whose real system is a spreadsheet

The file that runs the business. Eleven tabs, one person who understands it, no two people able to edit it at once. Nobody will approve a project to replace it, because it works.

This page is about replacing it anyway — and about the thing here that will bite you first: an application we host cannot reach out to arbitrary third-party systems. That is below, in its own section, before you start rather than after.

RunMyB is in closed beta, by invitation. There is no self-service sign-up — the access page explains how access works.

Our whole business runs on one Excel file — how do we replace it?

The eleven-tab spreadsheet survives because the alternatives are an agency build, a freelance build, or a first developer hire — and no 25-person firm approves any of those for one internal tool. RunMyB builds the replacement from a description of how the work actually runs: a real application with its own isolated database, real per-user accounts so two people can work at once, and data proven to survive a restart. RunMyB runs it, so nobody at your firm owns a server.

What you are weighing that against, with the qualifiers attached: an agency web-app build runs $15,000–50,000 for a simple MVP and $75,000–250,000 and up for mid-complexity work, on North-American agency figures — plus post-launch upkeep at 15–20% of the build cost a year. Where the team sits moves the hourly rate a long way: $150–250 and up in San Francisco, $100–175 in Canada, $30–80 for Eastern-European and South-Asian teams. A first technical hire, meaning a software developer, costs roughly $100,000–150,000 fully loaded in the first year. We do not publish our own price; that is further down, with the reason.

You bring your history across yourself. A new product's database starts empty — see the old records.

How do I build a client portal for a small firm without hiring a developer?

Most firms stay on email attachments because a real client portal is agency-priced work: the same $15,000–50,000-and-up build band, then 15–20% of that cost a year to keep it alive. RunMyB builds the portal instead — sign-up and sign-in with email and password, passkeys, time-based multi-factor codes, per-user isolation proven across accounts, and a document library behind it. Everything on that list is ours and built.

Can an AI-built app have real user accounts — and can one client see another's data?

Apps built here with user accounts get real authentication — email and password, passkeys, TOTP two-factor, account-linking safety — and every build must clear a seven-core floor whose cores include 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 and refuted it: both records belonged to one account, and the real defect was that the app never showed who was signed in. Generated auth now carries an identity contract.

Between products — your firm's app and someone else's on the same platform — the isolation is a separate question, and the answer is a proof rather than a promise. Every hosted product gets its own Postgres database and its own sandbox, not a shared schema with a customer column. A cross-tenant read returns not-found rather than a permission error. A seven-family proof module runs against that boundary and has already found and closed two real authorisation bypasses. If your compliance officer wants that in writing before a law firm's matters or a clinic's records go in, asking for it is the right instinct.

A portal's sign-in and account mail is its own subject, and this page is not where we are precise about it. What RunMyB sends, from which domains and on whose behalf, is set out on the email page — read it before you plan around a portal's mail.

Can the app connect to our ERP, our accounting system or our practice-management system?

Products we host run in a governed sandbox. Anything can call in; calls go out only through declared doors — your product's own database and an AI model. So the integration runs in the direction that is safe: your ERP, your shop platform or your practice-management system pushes into your product over its own API, and your product answers them. It will not dial an arbitrary address on the internet. You are reading that boundary before you build, not discovering it after.

That is a real constraint and worth being blunt about. A dispatch tool that has to poll a courier API on its own initiative, or a scheduler that has to go and read your practice-management system by itself, is not something we host today. It is what makes running many separate businesses side by side responsible rather than hopeful. If dialling out is the entire point of your tool, you own the source and can export it to infrastructure you control (Terms §12.1) — that export pushes a fresh single-commit history, so the build history itself does not travel with it.

What happens to eleven years of records in the old system?

Your history is not a migration project, because we do not run one. The database starts empty and takes the shape your app needs. We run no migration service and we do not lift another vendor's system; producing the export out of your old vendor is your side of the line, and we say which half is yours before you start rather than after.

What does not change either way: a hosted product's database is born empty, and nothing is carried across for you.

Can we change it ourselves afterwards, or do we go back to a developer every time?

Changing a product you own never re-enters a paid queue. Post-launch upkeep with an agency runs 15–20% of the build cost a year, and every small edit goes back into a queue and onto an invoice. Here 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. No invoice, no two-week window, no negotiation.

Re-certified means the build is put through the checks again, not just regenerated. The product must serve, load and run without crashing. If it stores data it must survive a write, a restart and a read-back. If it has accounts it must pass the seven-item authentication floor. That is the exact failure where one small fix silently breaks the login and nobody notices for a week.

Who looks after it? We have no IT department.

You never touch a server, because you never get one. Each product runs in its own sandbox with its own isolated database, provisioned and released by the platform. Infrastructure changes are policy-checked before they can apply, and rollback to the previous version has been exercised for real. Nobody at your firm has to understand it, and nobody has to be afraid to turn it off — suspending a product and bringing it back is a decision, not an operation.

There is no handover either, because nothing is handed over. The same system that built the product re-certifies it in place and fixes it, so keeping it working is the ordinary way of working rather than a fresh quote. Each product keeps a maintained record of what was decided and why, so the context does not leave when a person does. And the code is yours: it exports to your own GitHub or GitLab (Terms §12.1).

We pay for thirty tools and use twenty. Will this cut our software bill?

Not the way the phrase usually means. The waste is real and measured: 73% of SaaS vendors raised their prices by an average of 12% between 2022 and 2023, and nearly 50% of SaaS licences go unused for 90 days or more. RunMyB does not find that waste. There is no licence discovery, no spend analytics, no SaaS management on the platform, and none planned. Nothing here measures or reclaims your unused seats.

What it does is replace specific line items: a custom internal app, or a point tool bought for one job, rebuilt as exactly the thing you need and run for you. Line-item substitution, not stack replacement. Anyone selling you “cut your SaaS bill with AI” is selling a different product, and you should make them show you the discovery mechanism.

We're a small agency and we turn down builds we can't staff

A 2–9 person studio is capacity-bound, not demand-bound: the build you passed on last quarter was lost to a booked calendar, not to a competitor. Subcontracting it comes out of your own margin at freelance developer rates — $25–60 an hour for an intermediate freelancer and $60–120 and up for an advanced one on Upwork's own guide, $80–140 in North America, $75–95 in the UK, $40–70 in Eastern Europe, $30–55 in Latin America. RunMyB lets you deliver full-stack client apps without hiring or subcontracting: a real isolated database, end-user accounts, and the change-and-re-verify loop afterwards.

And you stop owning the servers. Each product runs in its own governed sandbox — no cloud account, no patching, no 11pm call because a database filled up. The client relationship stays yours: we will not market to clients you introduce and we will not approach them around you (Terms §10.2). The repository exports to your own GitHub or GitLab, so an engagement can still end with a handover.

What does this cost?

We do not publish our pricing yet, and we will not fake one — not even “free during beta”, which is itself a pricing statement. What we can tell you is what you are comparing against: $15,000–50,000 for a simple agency-built web app and $75,000–250,000 and up for mid-complexity work on North-American agency figures, post-launch upkeep at 15–20% of the build cost a year, or $100,000–150,000 fully loaded for a first developer hire in year one.

Not publishing a number is not the same as not having one. The platform's charges are shown to you inside the product — itemised, effective-dated, and before anything is charged (Terms §14). What is not on this public page yet is the rate card, and when it is published it goes on a page, not into a quote form.

Does this work for a firm in Poland or elsewhere in the EU?

It does, and two limits stand in the same breath. The interface is English only, and the platform issues no local invoice, so a firm outside the United States brings its own invoicing and its own accountant.

English only is not a small thing. Every conversation with the platform, and every screen you drive it from, is in English; if the person at your firm who would own this is not comfortable working in English, treat that as a real obstacle rather than an annoyance. The context around it is real too: 44% of EU SMEs use cloud services and about 11% of small firms use AI — which is why “just get someone in to look after it” has nobody to point at.

What we do not do

These are refusals, not a roadmap — except the first, which is a statement about today. They are on this page because a firm needs the boundary before the project starts rather than after the budget is spent. We send you no customers you did not bring. We build no phone apps. We do not move your data. We make no outbound calls out of the sandbox. Each one is set out below with what it actually means for you.

What stays yours

To have something built you have to describe how your firm actually works — the eleven tabs, the exceptions, the rule everyone knows and nobody wrote down. You own that description and the output built from it, we do not train models on your content, and we will not use what you describe to build a product that competes with yours (Terms §10, §10.1, §11). What that clause does not promise, and says so itself: your idea is not exclusive, and someone who independently describes something similar may get something similar.

The code exports to your own GitHub or GitLab whenever you want it (Terms §12.1). Test that early rather than when you are angry.

Where to go next

Access is by invitation and there is no public sign-up today — the access page says how that works and what we send you. The Terms of Service carry every commitment cited above, in force and versioned. Email from RunMyB covers every mail stream the platform runs. To ask about the platform or request an invitation, write to hello@runmyb.com, or start from the home page.