The RadWorks Handbook
What it is, why a business your size does it, the exact clicks to get started, what month one looks like, and how it keeps going. Ten minutes, plain English, nothing to install.
Already a client? Using RadWorks is the day-to-day manual: signing in, asking for changes, your data, and what it can and cannot do.
What RadWorks is
A custom web application, built for one business, for $1,500 a month. You describe how your business runs. You get a written plan. If it reads right, you subscribe and the app gets built, hosted, tested and improved every month, with no project quote, no hourly bills and no change orders.
It is not a template with your logo on it and it is not a replacement for the software you already pay for. It is the tool that sits beside your systems and does the parts they never did: the spreadsheet you keep re-typing, the whiteboard only one person can read, the question that gets asked from the driveway every week.
Three things it is not
Not an agency engagement. Nobody writes you a $40,000 proposal and disappears for four months. The plan is written in front of you, for free, and the first version is live in month one.
Not rip and replace. Your accounting, your scheduling, your point of sale stay exactly where they are. The app connects to them or works from their exports.
Not a one-time build. The part that matters is month two onward: you ask for changes in your own words, from inside the app, and they get built.
Why a small business does this
Most businesses under fifty people run on three or four pieces of software that almost fit, plus the gaps between them: a spreadsheet, a group text, a person who remembers. The gaps are where the hours go. Off-the-shelf software cannot fix them because the gaps are specific to how you work. Custom software used to be the answer only for companies that could spend six figures on it.
What you get for the money
A tool shaped to your week. Version one is built around the most expensive gap between the systems you already run, in your words, not a feature list.
Live in month one. Not a demo. Your team signs in and uses it.
Unlimited changes after. File them from inside the app. One is built at a time; most are live within a day or two.
Tested on every release. A browser test drives your app the way a person would, before and after every change. A failed test takes the change back out automatically.
Hosted, secured, backed up. Your own address, encryption, nightly backups. You never think about a server.
A record of what shipped. Every change, the day it went live, its test score, and who confirmed it. You always know what the month bought.
How to judge it. Take the hand-off or the spreadsheet you would put in the interview. Count the hours a week it costs across everyone who touches it. If that number times your loaded hourly cost is above $350 a week, month one pays for itself.
Before you start
Nothing to install, nothing to sign. The interview is free and you read your plan before you pay a cent. Two things are worth having in your head:
The work that happens around your systems
Not a feature list, and not a replacement for your ATS, your EHR or your accounting. The moment in the week where work leaves one system and gets re-typed into another, chased by phone, or kept in a spreadsheet beside the system. Version one is built around the most expensive of those and everything else waits. A tool that fixes one real problem in month one beats one that half-fixes six.
The software you already run, which stays
Your accounting, your scheduling, whatever holds your customer list. We assume it stays; the interview names it and asks what happens around it. If you know whether a vendor offers a way in (an API key, an export), say so; if you do not, that is a normal answer and it holds nothing up.
Getting started, click by click
This is exactly what happens on screen. About three minutes for the interview, on a phone or a laptop.
Press "Start your build interview"
One short form: your website, your email, your name, your company. Press Start the interview. We read your website first so the questions are about your business, not generic.
Answer eight questions
Each question comes with answers to tap. Tap every one that fits. If none fit, write it your way in the box under them; that answer is worth more than a wrong tap. The first two are about you: which part of the business is yours, and where your week goes. You answer them while we read your website. The rest start from the software a business like yours already runs and ask about the gaps around it, written for your role. They follow your earlier answers, so the last one is about your business, not a script.
Read your blueprint
The page writes your plan while you watch: what the tool is, the three to five things version one builds, a week-by-week month, what is deliberately left for later and why, and the questions we will confirm with you. The same plan is emailed to you with a link back to this page, so you can read it again on any device or show it to a partner.
Press "Subscribe and start the build"
A secure payment page opens (Stripe). Enter a card and press Subscribe. You are brought back to a page that says You are in. No setup fee, no contract term.
Your app is created and the build starts
Payment landing is the trigger. Your app gets its own web address, its own secure database, and its own working copy of the code, and the first milestone of your plan goes into the build queue. You get an email confirming it. Nobody at Rad has to press anything.
Month one
Your blueprint's plan is built in order, one milestone at a time, usually one every day or two. Each milestone is planned from your own words, built, run against your app's own tests before and after it goes live, and put back automatically if anything goes red.
You do not sit in meetings. If a milestone needs an answer only you have (which of two readings did you mean, which staff should see what), the question comes by email and the work waits for your reply. Otherwise you hear nothing until the reveal.
The reveal. When every milestone is delivered and the tests are green on the finished version, Chris at Rad opens the finished app and looks at it himself. Then you get two emails: one saying what the app does, and your sign-in link. There is no password: enter your email on the sign-in page any time and a fresh link is sent. It works on a phone.
Why you are not shown the half-built app. A tool seen at 40 percent teaches you what it cannot do yet. You see it when it does the whole job it promised.
Inside your app
Every RadWorks app has the same four screens on the left, plus whatever your plan built.
Home
Your app's own screens, and about once a week, one idea: a single proposed improvement, grounded in what you asked for and what your team has said on requests. Yes, build this files it in your name. No thanks is remembered and not repeated.
Requests
Broken, works-but-should-be-different, or something new. Say it in your own words, add a link to a screen recording if it helps, press File it. Screenshots attach in your RadWorks portal. Watch the status move from filed to planned to built to live.
Your app
What the app does today, what it is connected to, what is being built, what is up next. Rewritten every time something ships.
Settings
Paste a key for a system that offers one. It is tested against that vendor before it is saved, stored encrypted, and never shown again, to you or to us. For a system not listed, name it and say what the connection should do; we work out how to reach it and tell you on the request if anything is needed from you.
How your existing software connects
Nobody is asking you to throw anything out. Every system you name goes into one of three groups, and your blueprint says which before you pay.
Direct connection
You paste your own key under Settings. Your app then reads and writes there directly. Rad never handles the key.
File and email bridge
Your existing exports come into the app. You can upload one under Settings from day one. In month one we set them to arrive on their own, by email or a shared folder, on the schedule your system already sends them. The same file sent twice never doubles anything, and any rows that cannot go in come back to you as a file to fix and resend. Nothing about your current system changes. This is the common case for small-business software, and it is a normal way to run, not a downgrade.
Not connected
When that is true we say so plainly, in your blueprint, before you pay.
Getting API access from a vendor can take weeks. Your month one never waits on it. We build on the bridge, and when the direct connection is granted you paste the key and it moves over.
Asking for changes
Open Requests in your app and say what you want in your own words. You pick one of three kinds, and how much it is holding you up.
| Kind | Use it when |
|---|---|
| Broken | Something does not work the way it clearly should. |
| Works, but | It works and it is wrong for how you actually operate. |
| Something new | A screen, a report, or a feature that does not exist yet. |
What the status means
| Status | What is happening |
|---|---|
| New | Filed. Not looked at yet. Usually minutes. |
| Planned | Understood and queued. Not started. |
| In progress | Being built now. |
| Client to reply | We asked you a question on this one. It waits until you answer, and moves the moment you do. |
| Client to confirm | It is live. Look at it and confirm, or say it is still not right. |
| Done | Finished. If you still see the old behaviour, reload the page. |
| Not planned | Not going ahead. The reason is written on the request. |
Only the person who filed a request can close it. If it is not right, one click reopens it and the fix goes back in the queue. You never have to re-explain it.
How long it takes
Most changes are live within a day or two of being filed; small ones the same day. Changes that touch sign-in, messages to your customers, money, or deleting data are usually held for a person to review first, on purpose.
Keeping it going
The subscription is the improvement engine. The habits that get the most out of it:
File it where you noticed it
The moment someone says "I wish it did X", open Requests and type that sentence. Do not batch, do not polish. A one-line request in the words of the person who hit the problem is the best input this system gets.
Confirm what ships
When something goes live you are asked to check it. A two-second confirm is the signal that the queue can move on; "still not right" sends it straight back. Unanswered, we ask again at three days and seven, then close it, and one comment reopens it.
Say yes or no to the weekly idea
One proposal a week, on Home. Yes files it. No is remembered. Either answer makes the next idea better.
Connect a system when you are ready, not before
Settings waits for you. A connection made in month three is as good as one made in month one; nothing else depends on it.
Add your team
Tell us who should have access and we add them. Each person signs in with their own email and can file requests. It is priced per app, not per person.
Emails you will get
| When | What it says |
|---|---|
| After the interview | Your blueprint, with a link to read it again. |
| After you subscribe | Your build has started, and what happens next. |
| During month one, only if needed | A question only you can answer. Reply to the email. |
| When version one is done | What your app does, then your sign-in link. |
| Every time a request ships | Live now: what changed and where to check it. |
| When a request needs your answer | The question, with a link to reply on the request. |
| Three and seven days after a delivery you have not confirmed | Did it work? Then a closing note if we never hear. |
| About once a week | One idea for your app. |
| The 1st of each month | What went live last month. |
Every one of them is also on the request or the screen it is about. The email is the doorbell, not the record. Replying to any of them reaches a person.
Questions people ask
What if I do not like what gets built?
If month one doesn't save you more than it cost, tell us within 30 days and we refund it. After that it is month to month and you can stop whenever you like.
Who owns the data?
You do, always. Rad Consultants builds, hosts and runs the platform, and your data is yours to take with you.
Do I need anyone technical on my side?
No. If a vendor key is needed, the app tells you where to find it in that vendor's own settings.
What if my software has no API?
Very common, and not a problem. You go on the file and email bridge, and that is live in month one either way.
How many changes can I ask for?
As many as you like. One is built at a time, so the queue is visible and you can see what is next. If the order is wrong, say so and it changes.
What happens if a change breaks something?
Every release runs your app's own tests before and after it goes live. If they fail afterwards, the change is removed automatically within minutes. You are not the one who finds out.
Can more than one person use it?
Yes. Tell us who, and we add them. Your whole team can sign in and file requests, at no extra cost.
Is a person involved at all?
Yes, at the moments that deserve one. Anything about who can sign in, anything that reaches your customers, money, and deleting data wait for a person at Rad to say yes, and so does anything you flag when you file it. Everything else runs on its tests.
Ready to see your blueprint?
8 questions, about 3 minutes, in your own words. Free, and yours to keep whether or not you go ahead.
Start your build interview