Your billing platform knows what you billed. Nobody knows what you earned.

Every morning the team pulled the day's orders out of Brightree and worked them by hand. Brightree told them what was billed. It could not tell them what an order actually earned, because there was nowhere to put what the equipment cost and what was eventually collected on it, side by side, per line item. Its reports are built for a billing department, not a warehouse floor. “Where are all my wheelchairs going today, and with which driver” was a twenty-minute exercise and a phone call.

The usual fix is a spreadsheet. It works until someone types over a formula.

The owner posted the job as a profitability dashboard. After two conversations about how his operation actually ran, it was clear the dashboard was the last thing to build, not the first. If the daily entry wasn't fast and couldn't be wrong, nothing downstream would be worth reading.

Four things, in the order the money depends on them.

Order entry built for speed and for not being wrong. A 17-field form for keying the morning's orders from Brightree. Nearly every field is a dropdown sourced from the database: no misspelled boroughs, no three versions of the same driver's name. Selecting a product fills the HCPCS code and the cost from the client's price list. Required fields are enforced and named on failure, all at once. Keyboard-first, type-ahead product search, sticky defaults between consecutive entries. Every record shows who entered it, who changed it, and when.

A delivery board that answers the question in the owner's words. Every order in one list with eleven stacking filters: borough, driver, product, product family, date range, status, payer, destination, delivery vs. pickup, patient, sales order. “Every wheelchair, Queens, Driver 3, this week” is a URL you bookmark, not a report you request. Orders are marked delivered from the list without opening them. Stacked filters return in under a second.

Cost, billed, collected, and profit on every line. Cost is snapshotted at entry so a later price-list change never rewrites history. Billed and collected are entered as the order advances. Profit is computed, never typed, and rolls up by day, product, borough, driver, payer, patient, referral source, and branch.

Inventory that keeps itself honest. On-hand decrements as orders are keyed and reverses on void. Every movement is a ledger entry with a reason. Entering an order for a short product warns with the real numbers, saves anyway, and flags the line Backordered until stock is received. Purchasing gets a live view of what the shelf owes and how long the oldest order has waited.

Plus the dashboard he originally asked for: KPI tiles, a 14-day trend, status breakdown, pipeline view, and Excel export on every filtered view, with the export matching what's on screen.

These are the choices a developer without DME background would have gotten wrong, and they're where the build effort actually went.

Price on the variant, not the code. Every Standard wheelchair size bills as K0001, but an 18-inch and a 24-inch chair don't cost the same. The price lookup keys on the specific variant; the HCPCS code is derived and displayed for reference. Get this backwards and every profit number in the system is wrong by a size.

Profit is a generated column. It exists in the database as collected minus cost, computed by PostgreSQL. There is no field to type into and no formula to overwrite. This is the spreadsheet failure mode removed at the schema level rather than the UI level.

Money fields are gated by status. An order moves Open → Delivered → Billed → Collected, and the amount fields open as it moves. Collected cannot be entered on an undelivered order. Every transition is logged with who, when, from, and to.

Inventory is a ledger, and the count is derived from it. Storing a count and a history separately is how two numbers drift apart. Here every movement (order, void, receipt, physical count, correction) is a row, and “why is this number what it is” always has an answer. A negative count isn't an error; it's backorder demand, tracked deliberately.

Warn, don't block. The trucks don't wait for the software. A short product warns and saves, and the flag clears itself when stock arrives. Nobody has to remember to un-flag anything.

One filter source. The delivery list, the dashboard, and every export consume the same WHERE clause. A filtered delivery URL pasted onto the dashboard shows that slice's numbers. The dashboard is a different rendering of the same query, never a parallel one.

Today means New York's today. All user-visible dates derive from the business timezone. An order keyed at 9 p.m. is today's order, not tomorrow's. This sounds trivial until a warehouse in New York is reading a server in Virginia.

DME operators have been burned by all-in-one promises, so this says plainly what it doesn't do. It is not billing or claims. It is not accounting. It has no integrations in version one, by design. It is not a purchasing system, not multi-warehouse, not patient-facing, and it carries no AI features riding on the invoice. Brightree keeps doing billing. QuickBooks keeps doing accounting. This does the one thing neither of them does.

Fixed price, five milestones, each reviewed and approved before the next began. The client had a working login and his own catalog with real prices inside the first week, which bought patience for the longer middle stretch.

Machine verification was necessary but not sufficient. Before the delivery-management milestone shipped, a human end-to-end pass working the app the way the owner would (filter to a borough, read profit, drill, export) found five bugs the automated checks had missed, including a default date filter that was applied but invisible and a “today” computed in UTC. That pass is now a standing rule before every milestone.

Client data loaded in one pass with an idempotent importer: products and variants from the price list, and referral facilities and sales reps from a spreadsheet. Managed lists (referral sources, marketers, branches, drivers) are maintained by the client's own admin. Adding a driver is configuration, not a support ticket.

The client runs a DME company, not an IT department, so I run the infrastructure. But he shouldn't have to take on faith that the system stays available to him.

Every view exports to Excel, and the admin screen exports the full database in one click. A complete backup lands monthly in a folder he owns. He holds a copy of the source code with a permanent right to use, host, and modify it for his business. The application lives on his domain. Standard PostgreSQL, standard hosting, nothing only I can operate. A backup was restored into a scratch database before go-live was called go-live.

• Per-line profit visible the day the money lands, a number the client's billing platform had never shown him
• Stacked multi-filter queries in under a second at realistic volume
• Referral sources and sales reps loaded from the client's spreadsheet in a single import
• Something reviewable in week one; live at the client's address in about nine weeks
• Zero formulas for staff to overwrite

The client's capital equipment is rented monthly and capped at 13 months, after which the patient owns it. A unit returned early re-rents to a new patient with a fresh clock, and once its cost is recovered, later rentals are nearly all margin. Phase 1 captures the serial number on every order, which lays the groundwork. Full unit lifecycle (receiving by serial, assignment from an available-units list, return and inspection, per-unit cost recovery across patients) is the designed Phase 2 build. The database has been lifecycle-ready since day one.

Behind that: Brightree API order import, QuickBooks integration, and a driver-facing delivery confirmation app.