Updated October 2026 · Written and maintained by the Progression Agency strategy team
Remote patient monitoring software development is the design and engineering of the software that collects readings from home devices such as blood pressure cuffs, scales and pulse oximeters, routes out-of-range values to a care team and records the days of data and minutes of management a practice needs for RPM billing. Progression builds remote patient monitoring software for health systems, medical practices, RPM service companies, digital health startups and device makers: device integration, a clinician dashboard, a patient app, EHR integration through HL7 FHIR and the HIPAA safeguards around all of it. Progression Agency is based in New York City and works with clients across the United States and worldwide.
On this page · 17 sections
- What is remote patient monitoring software development?
- Should you build an RPM platform or license one?
- Comparing remote patient monitoring vendors before you decide
- Remote patient monitoring platform architecture
- Connecting devices: Bluetooth, cellular and vendor clouds
- EHR integration through HL7 v2 and FHIR
- RPM billing logic: CPT 99453, 99454, 99457, 99458 and the 2026 codes
- Remote patient monitoring vs remote therapeutic monitoring: what changes in the software?
- HIPAA compliant RPM software: the safeguards we build in
- Is remote patient monitoring software a medical device?
- Is remote patient monitoring profitable for a practice?
- Remote patient monitoring solutions for each kind of buyer
- How health organizations ask AI assistants about RPM vendors, and what gets cited
- How to choose an RPM software development partner
- How much does remote patient monitoring software development cost?
- How we build an RPM platform, phase by phase
- Related services for digital health teams
The short answerA custom RPM platform takes readings from Bluetooth or cellular devices, applies thresholds the clinician sets, routes alerts to the right person, shows trends on one dashboard and writes data and notes back to the EHR. It counts days of data and management minutes against the 2026 RPM and RTM code rules, logs every access and runs on HIPAA-eligible hosting under a business associate agreement. A typical build runs in phases over six to nine months, and every build is quoted after a written scope.
Builds are quoted after a written scope; the dollar band shown is the published US market figure on our healthcare software page, not a Progression rate card. Code rules come from the CY 2026 Physician Fee Schedule final rule, safeguards from the HIPAA Security Rule and device software points from FDA guidance, each named where it applies. Not legal or regulatory advice.
What is remote patient monitoring software development?
It is building the system that turns home readings into clinical work a team can act on and a practice can document. The device takes the reading; the software decides where it goes, who sees it and what gets recorded.
What remote monitoring software does every day
Remote monitoring software in healthcare receives readings, matches each one to the right patient, checks it against that patient’s thresholds, raises alerts, shows trends to the care team, records the calls and notes that follow, and totals the days and minutes the practice needs. Most of the engineering effort goes into the parts patients never see.
How does remote patient monitoring work, step by step?
A patient is enrolled and given a device. Readings travel to the platform, out-of-range values open an alert, staff review and contact the patient, and the time spent is logged. At the end of the period the software shows which patients have enough days of data and minutes for the practice to consider billing.
Which readings RPM usually covers
CMS describes remote physiologic monitoring as monitoring parameters such as weight, blood pressure and pulse oximetry to watch a patient’s condition and inform their management. Which other readings a program adds depends on the devices it chooses.
Remote patient monitoring software development sits inside our wider healthcare software development practice, which covers portals, care-coordination tools and EHR integration.
Should you build an RPM platform or license one?
License an RPM platform if standard devices, a standard workflow and a per-patient fee suit you; many practices should. Build when your devices, care model or business model do not fit what vendors sell, or when you need to own the platform.
When licensing is enough
A single practice monitoring blood pressure or weight with common devices is often best served by an established platform. It can be live quickly, the vendor handles device logistics, and nobody on your side has to run software. We say so when that is the honest answer.
When a custom remote patient monitoring software build wins
Custom remote patient monitoring software makes sense for a device maker that needs its own clinician view, an RPM service company serving many practices under its own brand, a health system with workflows that have to sit inside its EHR, or a startup whose care model is the product. In each case the platform is a core asset, not a utility.
Open source, SaaS and white-label starting points
Between full licensing and a ground-up build sit white-label platforms and open-source components such as FHIR servers and identity tools. They shorten the build but bring their own limits, licenses and upgrade paths. We compare them in discovery rather than assuming one route; our guide to custom software vs off-the-shelf sets out the general trade-off.
| Question | Licensed platform | Custom build |
|---|---|---|
| Time to first patient | Weeks | Months, in phases |
| Devices | The vendor’s supported list | Any device with an accessible data path |
| Workflow | The vendor’s, with settings | Yours, designed with the people who do it |
| Cost shape | Fees per patient or per month | Build cost, then hosting and maintenance |
| Data and code | Held under the vendor’s terms | Yours, including code, data and cloud accounts |
| Branding for client practices | Limited or white-label tier | Fully your own |
| Roadmap | The vendor decides | You decide |
Comparing remote patient monitoring vendors before you decide
Ask remote patient monitoring vendors the same questions you would ask a development partner: which devices, which EHRs, how billing time is counted, who owns the data and how you leave. The answers decide whether licensing fits.
Questions for remote patient monitoring vendors
Which devices are supported today, and how are new ones added? How are readings matched to patients when a device is shared or replaced? How are management minutes captured, and can staff edit them with an audit trail? Which EHRs receive data, and in what format? What does the business associate agreement cover?
Data exit terms
Before signing, ask how you get every reading, note and time entry out if you leave, in what format and at what cost. A platform that holds years of monitoring history without a clean export is expensive to leave, whatever the monthly fee.
Remote patient monitoring companies versus software vendors
Some remote patient monitoring companies sell a full service, with nurses doing the monitoring, rather than software alone. That suits practices without staff to spare. This page is about the software; if you run the clinical side yourself, or sell it to others, the software is what you are choosing.
| What to compare | Why it matters |
|---|---|
| Supported devices and connectivity | Decides which patients can take part, including those without smartphones |
| Alert rules and routing | Decides whether alerts reach a person who can act |
| Time and day tracking | Decides whether billing documentation holds up in an audit |
| EHR delivery | Decides whether clinicians must log in to a second system |
| Business associate agreement | Required before a vendor handles ePHI for a covered entity |
| Data export on exit | Decides what leaving costs |
| Pricing model | Per-patient fees grow with the program; build costs do not |
Remote patient monitoring platform architecture
A remote patient monitoring platform has six layers: devices, ingestion, rules, alerts, the clinician dashboard and the EHR connection, plus a patient app where the design needs one. Each is a design decision, not a default.
Ingestion and normalization
Readings arrive in different formats, units and time zones. The ingestion layer validates each one, converts units, matches it to a patient and stores it in a consistent model. We model readings on the HL7 FHIR vital signs profile, which uses LOINC codes such as 85354-9 for a blood pressure panel and 29463-7 for body weight, so data leaves the platform in a form EHRs recognize.
Thresholds and alert routing
Thresholds are set per patient by the care team, not hard-coded. An out-of-range value opens an alert in a queue, assigned by role, with escalation when nobody acts within the time the program sets. Every alert records who saw it, when, and what they did.
The clinician dashboard
One screen per patient with trends, recent alerts, notes, calls and the running count of days and minutes for the period. A worklist shows which patients need attention today and which are short of readings, which is where staff spend most of their time.
The patient app, or no app at all
For Bluetooth devices a phone app usually relays readings, using Apple HealthKit or Android Health Connect where the design calls for it. For patients without a smartphone, cellular devices send readings with no app involved. We design for both, because the patients who most need monitoring are not always the ones with the newest phones.
| Layer | What it does | Decision to make early |
|---|---|---|
| Devices | Take readings at home | Bluetooth through a phone, cellular, or both |
| Ingestion | Validates, converts and matches readings | Data model and how duplicates are handled |
| Rules | Applies per-patient thresholds | Who may set and change thresholds |
| Alerts | Routes out-of-range values to people | Roles, escalation times, after-hours handling |
| Dashboard | Trends, worklist, notes, time log | How time is captured without slowing staff down |
| EHR connection | Sends data and notes to the chart | HL7 v2 feed, FHIR API, or both |
| Patient app | Relays readings, shows messages | Needed at all, and which platforms |
Connecting devices: Bluetooth, cellular and vendor clouds
Devices reach the platform in three ways: Bluetooth Low Energy through a phone, a cellular connection built into the device or a hub, or the device maker’s own cloud API. Most programs end up supporting more than one.
Bluetooth devices through a phone
Bluetooth Low Energy devices pair with the patient’s phone, and the app relays readings. It keeps device costs down but depends on the patient keeping the app installed and the phone nearby, which the dashboard should flag when readings stop.
Cellular devices and hubs
Cellular devices send readings directly, with nothing for the patient to pair. They suit older patients and those without smartphones; their device and data plan costs differ from Bluetooth models, so price both. The platform receives these readings from the device maker’s service.
Remote patient monitoring API integrations
Many device makers expose readings through a cloud API rather than directly from the device. A remote patient monitoring API integration pulls or receives those readings, maps them to patients and keeps working when the maker changes its format. We confirm each vendor’s current API terms before naming it in a scope. Our API development and IoT app development pages cover the engineering in more depth.
Running RPM on a licensed platform that bills well but will not fit your workflow?Tell us the devices, the EHR and where the current platform gets in the way. We reply with a free proposal comparing a custom build against staying put, with a written scope.
EHR integration through HL7 v2 and FHIR
Clinicians should see monitoring data in the chart they already use. We integrate through HL7 v2 feeds, FHIR APIs and SMART on FHIR apps, subject to each EHR vendor’s access programs.
Sending readings and notes to the chart
Readings can be filed as FHIR Observations or HL7 v2 results, and monitoring notes as documents. We agree with the practice which readings go to the chart at all, since a reading every few hours can bury the record.
Enrollment and orders from the EHR
In a health system, enrollment often starts with an order in the EHR. The platform can receive that order, create the patient and start the device process, so staff are not keying the same patient into two systems.
Launching the dashboard from inside the EHR
A SMART on FHIR launch lets a clinician open the RPM view for the patient already open in the chart, signed in with the same identity. Our EHR software development page covers the integration work in detail.
RPM billing logic: CPT 99453, 99454, 99457, 99458 and the 2026 codes
The software has to count two things correctly: days of data in a 30-day period and treatment management minutes in a calendar month. For 2026, CMS adopted new codes for shorter periods, so the counting logic changed.
Counting days of data: 99445 and 99454
The CY 2026 Physician Fee Schedule final rule describes 99445 for device supply with 2 to 15 days of data in a 30-day period and 99454 for 16 to 30 days. CMS says these are not additive: a practice bills only one of them for the days of data transmitted. The software therefore needs an exact, auditable count of days with a valid reading per patient per period.
Counting management minutes: 99470, 99457 and 99458
Treatment management codes describe the first 10 minutes (99470, new for 2026), the first 20 minutes (99457) and each additional 20 minutes after 99457 (99458). CMS states that 99470 and 99457 are not additive; the practice chooses the code that fits the time spent that calendar month. CMS describes the new codes as covering less than 20 minutes of interactive communication a month.
Setup and education: 99453
CPT 99453 covers initial setup and patient education on using the equipment. The platform records when setup happened and who did it, so the episode start is documented.
| CPT code | What it describes | What the software must record |
|---|---|---|
| 99453 | Initial setup and patient education on the equipment | Setup date, staff member, device assigned |
| 99445 | Device supply, 2 to 15 days of data in 30 days (new for 2026) | Days with a valid reading in the period |
| 99454 | Device supply, 16 to 30 days of data in 30 days | Days with a valid reading in the period |
| 99470 | Treatment management, first 10 minutes (new for 2026) | Minutes by staff member and date, with notes |
| 99457 | Treatment management, first 20 minutes | Minutes by staff member and date, with notes |
| 99458 | Each additional 20 minutes after 99457 | Further minutes in the same calendar month |
What the billing logic should never do
It should never submit a claim on its own or round time up. It shows the count, the evidence behind it and any gaps; coding decisions stay with the practice and its billing advisers. CMS also reminds practitioners that these services must be reasonable and necessary for the patient.
Remote patient monitoring vs remote therapeutic monitoring: what changes in the software?
Remote physiologic monitoring tracks body measurements such as blood pressure and weight. Remote therapeutic monitoring tracks adherence to and response to at-home therapy. The software differs mainly in what it collects and which codes it counts.
What RTM covers
CMS describes RTM as monitoring adherence to at-home therapeutic interventions, with separate device supply codes for the respiratory system, musculoskeletal system and cognitive behavioral therapy. What is collected depends on the therapy being monitored, so the patient app often carries more of the work.
The RTM codes for 2026
The RTM family includes 98975 for setup, device supply codes 98976, 98977 and 98978 for 16 to 30 days, new 98984, 98985 and 98986 for 2 to 15 days, and management codes 98979 (first 10 minutes, new), 98980 (first 20 minutes) and 98981 (each additional 20).
| Point | RPM (physiologic) | RTM (therapeutic) |
|---|---|---|
| What is monitored | Physiologic parameters such as weight, blood pressure, pulse oximetry | Adherence to at-home therapy |
| Typical data | Device readings | Data on the therapy being monitored |
| Device supply codes, 16 to 30 days | 99454 | 98976, 98977, 98978 by therapy type |
| Device supply codes, 2 to 15 days | 99445 | 98984, 98985, 98986 by therapy type |
| Management, first 10 minutes | 99470 | 98979 |
| Management, first 20 minutes | 99457 | 98980 |
| Each additional 20 minutes | 99458 | 98981 |
A platform built with a clean data model can support both families; the counting rules are parallel, while the data collected and the patient experience differ.
HIPAA compliant RPM software: the safeguards we build in
We design to the HIPAA Security Rule from the first sprint: access control, audit logs, integrity, authentication and transmission security, on HIPAA-eligible hosting under a business associate agreement. Compliance also depends on how the platform is operated.
Technical safeguards
The Security Rule’s technical safeguards require unique user identification and an emergency access procedure, audit controls that record activity in systems holding ePHI, integrity protections, person or entity authentication and transmission security. Automatic logoff and encryption are addressable specifications; we implement both.
Business associate agreements
A covered entity may let a business associate create, receive, maintain or transmit ePHI only after obtaining satisfactory assurances, under 45 CFR 164.308(b). In practice that means a BAA with the practice and with each HIPAA-eligible cloud service the platform uses.
Audit logs, retention and export
Every view, edit, alert action and time entry is logged with the user and time. Separately, the Security Rule asks covered entities and business associates to keep their required policies and documentation for 6 years, under 45 CFR 164.316. Medical record retention follows state law and the practice’s own policy, so we make retention configurable and exports complete.
Risk analysis before launch
The Security Rule requires an accurate and thorough assessment of risks to ePHI. We document the architecture, data flows and controls so the practice’s own risk analysis has what it needs. Our HIPAA compliant software development page goes deeper.
| Safeguard | Where it comes from | How we implement it |
|---|---|---|
| Unique user identification | Security Rule, access control (required) | Individual accounts, no shared logins |
| Emergency access procedure | Security Rule, access control (required) | Documented break-glass access, logged |
| Automatic logoff | Security Rule (addressable) | Session timeouts on dashboard and app |
| Encryption | Security Rule (addressable) | Encrypted storage and encrypted transport |
| Audit controls | Security Rule (standard) | Activity log for every view, edit and alert |
| Person or entity authentication | Security Rule (standard) | Multi-factor sign-in for staff |
| Business associate agreements | 45 CFR 164.308(b) | BAAs with the practice and cloud services |
Is remote patient monitoring software a medical device?
Software that only transfers, stores, converts or displays device data is generally not a device under FDA’s guidance. Software that analyzes physiological signals or patterns to drive clinical decisions can be. Where a platform sits depends on what it is intended to do, and that is a question for regulatory counsel.
Transmitting and displaying data
FDA’s medical device data systems guidance says software functions solely intended to transfer, store, convert formats or display medical device data and results are not devices and are not subject to FDA regulatory requirements. Much of an RPM platform’s core, ingestion, storage and display, falls into that description.
Where analysis and alerts change the picture
FDA’s clinical decision support guidance, issued January 29, 2026, says software that acquires, processes or analyzes a signal or pattern from a signal acquisition system does not meet the first non-device CDS criterion. Its examples include software analyzing signals from wearables to detect a heart attack, which it treats as a device function that supports time-critical decisions.
How we handle it in a build
We document the intended use of every rule and alert in discovery, keep display-and-route logic distinct from any analytic function, and flag features that may move the analysis so your regulatory counsel can review them before they are built. We do not give legal or regulatory advice.
Is remote patient monitoring profitable for a practice?
It depends on enrollment, how many patients reach the day and minute thresholds, staff time and payer mix, not on the software alone. The software’s job is to make the work efficient and the documentation complete.
What the software can influence
Flagging patients who are short of readings early in the period, making time capture quick and accurate, keeping alerts from flooding staff and sending clean records to the EHR. Each of those changes how much staff time a monitored patient takes.
What it cannot promise
No platform guarantees revenue or clinical outcomes, and we make no such claims. Payment depends on the practice’s patients, payers and documentation, and on rules CMS revises each year.
Reading the rules every year
CMS changes payment policy annually; the 2026 rule added the shorter-period codes described above. We build counting rules as configuration, not code scattered across the platform, so a rule change is an update rather than a rewrite.
Building an RPM service and need the software behind it?Share the conditions you will monitor, the devices and how many practices you will serve. You get a free proposal for the platform, the integrations and the billing logic.
Remote patient monitoring solutions for each kind of buyer
Remote patient monitoring solutions look different for a health system, a single practice, an RPM service company, a startup and a device maker. The core layers stay the same; the priorities change.
Health systems
EHR-first design, single sign-on, enrollment from orders and reporting across clinics. The platform has to fit an existing security review and integration engine.
RPM service companies serving many practices
Each client practice’s data kept separate, branding per client, staff who work across practices with permissions to match, and billing reports per practice. This is where a custom build most often beats a license.
Startups and device makers
Startups usually begin with a focused MVP for one condition and one device, then add integrations as contracts arrive; our MVP development page covers that approach. Device makers need a clinician-facing view of their own data and a clean path into EHRs; wearable app development covers the device-side apps.
How health organizations ask AI assistants about RPM vendors, and what gets cited
Practice administrators and digital health founders now ask ChatGPT, Claude, Perplexity, Gemini, Copilot and Google’s AI Overviews which RPM platform to use, what the 2026 codes changed and who builds custom monitoring software.
What buyers ask
Questions sound like which remote patient monitoring vendors integrate with a given EHR, what is the best remote patient monitoring software for a cardiology practice, or what a custom RPM build costs. Assistants tend to cite CMS and FDA pages, vendor comparison articles, review directories and developer pages that answer the question in plain text.
What an RPM company should publish to be cited
Supported devices and EHRs named in text, the codes the platform tracks, security and BAA terms stated plainly, and dated pages that are updated when CMS changes the rules. Our AEO for healthcare page covers how health organizations get named in AI answers.
How to choose an RPM software development partner
Choose a partner for RPM software development that asks about your devices, EHR and billing workflow before it talks about screens, signs a BAA when it handles PHI, and gives you the code, data and cloud accounts. Healthcare experience matters more than a generic portfolio.
| Requirement | How to check it |
|---|---|
| Knows the current code rules | Ask how the platform counts days and minutes under the 2026 codes |
| Designs HIPAA safeguards in | Ask to see how access, audit logs and encryption are designed |
| Signs a BAA where PHI is handled | Ask for the BAA terms before the scope is final |
| Has EHR integration experience | Ask which of HL7 v2, FHIR and SMART on FHIR they have built |
| Handles devices without smartphones | Ask how cellular devices are supported |
| Separates display from analysis | Ask how they flag features for regulatory review |
| Gives you ownership | Get code, data and cloud accounts in your name in the contract |
| Plans for maintenance | Ask what ongoing security updates and rule changes cost |
Questions to ask in the first call
How do you stop alerts overwhelming staff? What happens to the minute count if a staff member edits a note? How do new devices get added after launch? Where does our data live, and how do we take it with us? Concrete answers predict a sound build.
Red flags
Promises of revenue or outcomes, billing logic that submits claims automatically, no BAA, shared staff logins in a demo, and a platform hosted in the developer’s own cloud account with no path to yours.
How much does remote patient monitoring software development cost?
We quote every build after a written scope. For context, the published US price band on our healthcare software page for a remote monitoring platform is $150,000 to $350,000 over 6 to 9 months, a market figure rather than a Progression rate card.
| Cost driver | Lower effort | Higher effort |
|---|---|---|
| Devices | One device type, one data path | Several devices, Bluetooth and cellular |
| Clinical scope | One condition, simple thresholds | Several conditions, RPM and RTM |
| EHR integration | One EHR, one-way data | Several EHRs, orders and SMART launch |
| Tenancy | One practice | Many client practices with branding |
| Patient app | None, or relay only | Full app with messages and education |
| Reporting | Monthly counts | Program, staff and payer reporting |
| Work | Price | Notes |
|---|---|---|
| Custom RPM platform build | Quoted after a written scope | Priced from devices, integrations and tenancy |
| Remote monitoring platform, published US price band | $150,000 to $350,000; 6 to 9 months | Market figure on our healthcare software page, not a Progression rate card |
| Ongoing maintenance, published band | Commonly 15 to 20 percent of build cost a year | Market figure on our healthcare software page |
| Marketing website, 5 to 8 pages | From $9,500 | 6 to 8 weeks |
| SEO retainer, small | $1,500 to $2,500 a month | We do not work below about $1,500 a month |
| Analytics and conversion tracking implementation | From $2,400 | One-off project |
| Initial audit | Free initial audit: $0 | A starting review before any proposal |
Website prices come from our website design and development table, retainers from SEO services and one-off projects from SEO services pricing. Device costs, cellular data plans and cloud hosting are paid to those providers directly.
How we build an RPM platform, phase by phase
Discovery first, then device ingestion and alerts, then the dashboard and patient app, then EHR integration and billing logic, then security testing and a pilot. Each phase ends with something clinicians can test.
- Discovery with the clinicians and staff who will use it, plus a data and rules map
- Classification of data and intended use, with features flagged for regulatory review
- Architecture and HIPAA-eligible hosting under a BAA, in your cloud account
- Device ingestion for the first device, with patient matching and validation
- Thresholds, alert queues and escalation rules
- Clinician dashboard with worklist, trends, notes and time capture
- Patient app or cellular-only path, depending on the population
- EHR integration through HL7 v2 or FHIR, tested with the practice
- Day and minute counting against the current code rules
- Security testing, a pilot with a small patient cohort, then launch and monitoring
Two-week sprints with clinician feedback
We build in two-week sprints and put working software in front of clinicians at the end of each, because workflow problems are cheap to fix in week four and expensive in month eight.
After launch
Security updates, device and EHR interface changes, rule updates when CMS revises the codes, and new features as the program grows. Our DevOps services and cloud hosting pages describe the operations side.
Get an RPM platform scoped around your devices, EHR and billing workflow
Tell us the conditions, devices, EHR and how many practices you serve. We reply with a free proposal and a written scope.
Related services for digital health teams
These pages cover the software, compliance and growth work around an RPM program.
- Healthcare software development: portals, care tools and integrations
- HIPAA compliant software development
- EHR software development and HL7 FHIR integration
- Healthcare app development company
- Telemedicine app development
- Wearable app development
- IoT app development for connected devices
- API development
- Enterprise app development
- Medical device marketing agency
- Healthcare lead generation
- Healthcare website design
- AEO for healthcare
- MVP development company
- UI and UX design for clinical software
Getting found in search
AI, AEO and what is changing
Paid media and lead generation
Websites and design
Choosing and working with an agency
Software and app development
Website design by industry and type
Web development, platforms and hosting
Social, content and brand
By industry and by situation
Frequently asked questions
What does remote monitoring software do for a care team?
How does remote patient monitoring work for a patient at home?
What is the difference between remote patient monitoring and remote therapeutic monitoring?
Is remote patient monitoring profitable for a medical practice?
How much does remote patient monitoring software development cost?
Is a licensed RPM platform enough, or do we need our own?
What changed in RPM billing codes for 2026?
How many days of readings does RPM device supply billing need?
What timeline should we expect for a custom RPM build?
Which devices can a custom RPM platform connect to?
Does RPM software have to be HIPAA compliant?
Can alert thresholds make RPM software a regulated medical device?
How do remote monitoring readings get into the EHR?
Do patients need a smartphone for remote patient monitoring?
Can one RPM platform serve many client practices?
Who owns a custom remote patient monitoring platform?
How should an RPM platform record management time?
What makes the best remote patient monitoring software for a practice?
Where does AI fit in a monitoring program, and where does it raise FDA questions?
How long do audit logs and records need to be kept in RPM software?
What does remote patient monitoring software development include from Progression?
Running RPM on a licensed platform that bills well but will not fit your workflow?Tell us the devices, the EHR and where the current platform gets in the way. We reply with a free proposal comparing a custom build against staying put, with a written scope.
Get a free marketing proposal
Tell us what you are trying to grow and we will come back with a plan, not a pitch deck. Same-day reply on weekdays.