"You are not selling servers. You are selling the software your client already wanted — running on infrastructure they own, with no per-seat bill attached."
There is a large, growing and badly-served market of small businesses paying monthly per-seat fees for software they do not control. A ten-person team pays for ten seats of a project tool, ten seats of a chat tool, ten seats of a knowledge base. The bill rises every time they hire. Their data lives in someone else's account. When they ask "can we just run our own?", the honest answer has always been "yes, but it will take a developer a week and someone to maintain it".
You are the person who makes that answer "yes, by Thursday." RAD gives you a catalogue of production-grade Google Cloud modules — the open-source alternatives to those paid tools, already packaged with database, storage, networking, TLS, backups, secrets and monitoring wired in. You deploy one through a guided form. The client ends up owning the result outright, in their own Google Cloud account.
"I set up self-hosted alternatives to the software you're currently renting — your own private Notion, Slack, Trello or CRM — running in your own Google Cloud account. You own it, there are no per-user fees, and I hand it over working with documentation."
"I do cloud deployment / DevOps / Terraform / infrastructure-as-code." Every one of those puts you in a bidding war against a thousand people, judged purely on hourly rate. Nobody searches a freelance marketplace for "Terraform". They search for the outcome.
A module deploys in roughly 5–20 minutes. Most of your delivery time is the client conversation, DNS, and handover — not the build. You can quote a two-day turnaround honestly and still have margin.
350+ deployment options and 60+ pre-wired stacks. When a client asks for something adjacent to your last job, you are usually one catalogue entry away from being able to take it.
Every module has a configuration guide and a lab walkthrough on docs.radmodules.dev. Linking a client to real documentation during a sales conversation does more for trust than any amount of profile copy.
Backups, updates, monitoring, adding the second and third app. A one-off gig becomes a monthly retainer precisely because you did not hand over something fragile.
Self-hosting is not automatically cheaper than SaaS, and you should never claim it is. It wins on ownership, data control, no per-seat scaling, and customisation. Cloud resources still cost money every month, and someone has to keep the thing patched. Clients who buy on a false "it'll be free" promise leave one-star reviews when the first invoice lands. Clients who buy on ownership stay for years.
| Service | What the client gets | Good for | Typical shape |
|---|---|---|---|
| Single app deployment | One application, live on their domain, with TLS, a database, backups and an admin account handed over. | Your first 10 orders. Easy to scope, easy to deliver, easy to review. | Fixed price, 2–3 day delivery |
| Solution stack | A bundle of applications wired together — e.g. a support desk, a CRM plus marketing automation, or a full team workspace. | Higher ticket work once you can prove one app went well. | Fixed price, 1–2 week delivery |
| Migration | Moving off a paid SaaS tool onto the self-hosted equivalent, with the data brought across. | Clients with a renewal date coming up. Urgency works for you. | Scoped per job, quote after a call |
| Care plan | Monthly updates, backup verification, monitoring, a support channel, and a small allowance of changes. | Turning one-off delivery into predictable income. | Monthly retainer |
Pulled from the catalogue's own solution bundles. Each of these is a real posted-brief shape you will see on the marketplaces — phrased the way a client phrases it, not the way an engineer does.
Team workspace, knowledge base and documentation stacks.
Secure team communications, self-hosted chat.
Customer support desk with ticketing and a shared inbox.
CRM and sales operations, marketing automation.
Business website and blog, headless content, e-commerce storefront.
Workflow automation connecting the tools they already use.
Documents and e-signature without per-envelope pricing.
Project and task delivery, professional services automation.
Training delivery and course platforms for education clients.
Pick one vertical and one stack for your first month. "I set up self-hosted helpdesks for small e-commerce brands" outsells "I deploy any of 190+ applications" every single time. Breadth is what lets you say yes to the second job — it is not what wins you the first one.
| Fiverr | PeoplePerHour | Freelancer.com | |
|---|---|---|---|
| Model | Buyers browse and buy a fixed "gig". You do not chase work. | Hybrid — publish fixed-price "Hourlies" and send proposals to briefs. | You bid on posted projects. Volume-driven and price-competitive. |
| You need | Keyword-rich gig title, 3 packages, gallery images, FAQ, buyer requirements form. | A strong profile, verified ID, and proposals that survive a limited monthly allowance. | Bid credits, a sharp proposal, and the discipline to skip bad briefs. |
| Ranking driven by | Orders completed, on-time delivery, response rate, review score. Levels unlock visibility. | Reviews, response speed, and proposal quality. Badges signal credibility. | Reviews, completion rate, and relevant skills. Badges and tests help. |
| Biggest trap | Under-scoping a package so revisions eat your margin. | Burning your proposal allowance on briefs you were never going to win. | Racing to the bottom on price against very low-cost bidders. |
| Play to win | Productise ruthlessly. One outcome, one price, zero ambiguity. | Fewer, better proposals. Reference the client's actual brief. | Bid only where you can name something specific nobody else can. |
The fastest way to lose money is an unbounded revision count. Define delivery as "the application running on your domain, with an admin account you control, plus a handover document". Anything else — data migration, custom theming, integrations, training sessions, ongoing changes — is a separate paid item, stated on the gig page before anyone orders. This one sentence protects more margin than any pricing decision you will make.
"I will set up your own self-hosted Slack alternative on Google Cloud"
"I will deploy a private helpdesk so you stop paying per agent"
"I will move your team off per-seat SaaS to software you own"
"I will do DevOps and cloud infrastructure work"
"I will deploy any application to GCP with Terraform"
"Professional cloud engineer, 5 years experience"
The pattern: name the outcome and the pain. "Self-hosted", "you own it", "stop paying per user" are the phrases buyers actually type. "Terraform", "IaC" and "DevOps" are phrases engineers type.
Stop paying per user for software you don't own.
If your team is paying a monthly fee per person for a tool you use every day, there is almost always an open-source equivalent you can run yourself — in your own cloud account, with your own data, with no per-seat bill.
I set that up for you, properly. Not a hobby install on a cheap VPS — a production deployment on Google Cloud with a managed database, automatic HTTPS, daily backups, and monitoring. You get the admin account, the documentation, and full ownership. If you ever want to work with someone else, nothing is locked to me.
What you get: the application live on your domain · managed database · automatic HTTPS · daily backups · admin account · handover document · 14 days of post-delivery support.
Not sure which tool fits? Message me with what you're paying for now and I'll tell you honestly whether self-hosting makes sense for you — including when it doesn't.
Offering to talk someone out of a purchase is the strongest trust signal available to a new seller with no reviews. It also filters out the clients who would have been unhappy anyway.
Stand up three or four applications in your own account. This is your portfolio, your screenshots, and your practice run.
One short case study each: what it replaces, what it costs to run, how long it took. Real numbers beat adjectives.
A three-minute screen recording of the finished product is worth more than a page of copy — and doubles as your delivery template.
| Tier | Scope | Include | Explicitly exclude |
|---|---|---|---|
| Basic | One application, deployed and handed over on a domain the client already owns. | Deployment · HTTPS · admin account · handover doc · 1 revision | Data migration · theming · integrations · training |
| Standard | As Basic, plus the things clients always ask for afterwards. | + backup schedule · email sending configured · 2 revisions · 30-day support | Data migration from an existing tool · custom development |
| Premium | A working system rather than an installed application. | + data migration · a second connected app · a 60-minute training call · 60-day support | Custom feature development · unlimited changes |
Your fee is for the work. The ongoing Google Cloud cost belongs to the client and lands on their account, not yours. Put a plain-English line in every listing — "Google Cloud charges are billed directly to you and typically run a modest monthly amount depending on size; I'll estimate it before you order" — and give a real estimate before they buy. Surprise infrastructure bills are the single most common source of bad reviews in this category.
One-off deployments build your reputation. Care plans build your income. A handful of retainer clients is worth more than a constant scramble for new orders, and it is far less work per pound earned.
Offer it at handover, when the client is happiest and most aware that someone needs to keep this running. Not three months later when something has already broken.
Deployment is fast and predictable. Data migration is neither. Exports are messy, formats disagree, and volumes surprise people. Always scope a migration on a call, always quote it separately from the deployment, and never fold it into a fixed-price gig package.
Who owns the domain? Is there a Google Cloud account and a billing method? How many users? Is there existing data to bring across? Any compliance constraint? Five questions, asked before the order, prevent most disasters.
Restate what you will deliver and what you will not, on-platform, before starting. If the client later asks for something outside it, you have a neutral document to point at rather than an argument.
Deploy the exact module once in your own environment first. You will hit any surprises on your own time rather than the client's, and you will know exactly how long it takes.
Use the module's lab guide as your checklist. Follow it even when you think you remember — the ten minutes it costs you is cheaper than one missed step discovered at handover.
Load the site in a private window. Log in as a fresh non-admin user. Send a test email. Upload a file. Restore a backup. A deployment that returns "success" is not the same as a system that works.
Credentials transferred securely, a short written document, and a screen recording walking through it. This is the artefact that generates five-star reviews and referrals.
In that order, a day or two after delivery, once they have used it. Both asks are reasonable at that moment and awkward at any other.
Write it once as a template. Every subsequent job is a fifteen-minute edit, and clients consistently rate it as the most professional part of the engagement.
345+ step-by-step lab guides, one for each application option. Each walks through a real deployment, what to verify, and what to do when something fails. These are your delivery checklists — not just training material.
Seven Google Cloud certification study guides, each mapping exam domains onto hands-on RAD labs. A certification is a genuine differentiator on marketplace profiles, where most competitors have none.
Associate Cloud Engineer. The right first certification for this work — it covers most of what you do day to day.
Professional Cloud Architect or Cloud Developer, depending on whether you drift toward design or build.
Network, Security, DevOps and Database Engineer tracks, once you know which work you want more of.
Guides at docs.radmodules.dev/docs/certification/ — ACE, PCA, PCD, PCDE, PCNE, PDE and PSE.
When a prospect asks "how do I know this is properly built?", send them the module's configuration guide. Public documentation covering every setting, which you did not have to write, answers the question far better than reassurance does — and it quietly signals that you work from documented systems rather than improvisation.
Work through the Using RAD guide, then the Services GCP lab, then three application modules you would actually want to sell. Screenshot everything as you go.
One service, one vertical, three price tiers. Write the description, take the screenshots, record a short walkthrough. Publish on one platform only.
Respond fast, over-deliver, ask for the review. Send proposals only to briefs that genuinely match your listing. Ten good proposals beat fifty generic ones.
Whatever cost you unpaid time in week three goes into the exclusions list. Then add your second service, or the same service on a second platform.
If you have reviews but no retainers, you are not asking at handover. If you have neither, your listing is probably too broad — narrow it to one outcome for one kind of buyer and try again.