We don’t build to sell.
We build because you asked.
Every integration in our catalog began with a single provider saying “I wish Cerbo did this.” Then we built it. Then we made it available to every other practice. That’s the entire story.
We are modular because
we grow with you.
FxMedSupport doesn’t have a static product roadmap drawn up by a marketing team in a conference room. We have a living catalog that grows every time a real practice comes to us with a real workflow problem and asks us to solve it.
That’s not a marketing line. That’s literally how every single application we offer came to exist. Auto Encounter Pro started as one provider asking if we could pre-build her chart notes from Cerbo data. Portal Scheduler started with a clinic that wanted patients to book without logging in. QuickBooks Online started with a practice that was tired of manually keying transactions twice. Every. Single. One.
The one of you. The two of you. The ten of you. The three hundred of you who came before — each of you said “I wish Cerbo did that.” And that’s where it all came from.
This is why we’re called The DreamMakers of Cerbo — not because we picked the name, but because Cerbo and our clients did. Because we’re the team that turns “I wish” into “It works.”
The Request for Development process.
Simple, transparent, and built for partnership. Here’s exactly what happens when you submit a Request for Development.
You submit your “I wish.”
Through our Request for Development form, you describe the workflow, integration, automation, or feature you wish FxMedSupport offered. The more context, the better — but we’ll work with whatever you can share.
We review & scope.
Our team evaluates the request, asks any clarifying questions, and works through the technical and operational details needed to scope the build accurately. For requests that require deeper analysis — researching third-party APIs, mapping data flows, designing integration architecture — a scope fee is applied to cover that work.
The scope fee is quoted upfront before any analysis begins, so you always know what you’re committing to at each step.
We propose a per-project fee.
If we move forward, we issue a clear, fixed project fee covering the scope of the build. Not hours. Not retainers. Not unknowns. One number for one delivered project — so you know exactly what you’re committing to before we start.
We build, you benefit, everyone benefits.
We build the application or feature. You get it first. And then — because of how our platform works — every other practice on a tier that includes that capability gets it too, at no additional cost to them. Your “I wish” becomes the next practice’s standard feature.
Why per-project, not per-hour.
Two clear fees. No surprises.
Each Request for Development moves through two transparent steps: a scope fee when deeper analysis is needed to understand the project (researching APIs, mapping data flows, designing architecture), then a fixed project fee for the build itself. You see each number before that step begins — no hourly creep, no scope-of-work gymnastics, no “the developer ran into something.”
By the hour. By the meeting. By the keystroke.
We don’t bill development time, and we don’t pad estimates against unknowns. If we say a project is $4,000, it’s $4,000 — even if it takes us 30 hours, even if it takes us 80. Our incentive is to ship great work efficiently, not to drag time.
We don’t take Requests for Development to make money on development. We take them to grow the platform. The project fee covers the work; the value compounds across every practice that benefits afterward.
What’s your “I wish”?
See an integration we don’t have? Use a tool we haven’t connected to yet? Have a workflow you wish Cerbo could automate? Tell us. Our entire catalog started exactly this way.
Submit a Request for Development →