DrayBase
Sign inJoin the Waitlist →

RoadmapNo dates

The DrayBase roadmap, with nothing rounded up

Three columns. The left one runs against a live database and a dispatcher could sit in front of it. The middle one is half written. The right one is not written at all. Most vendor roadmaps blur those three into one screenshot; this page keeps them apart because the difference is the entire question you are trying to answer.

What built means hereA line sits in the first column only if there is code behind it reading real records. A design file is not built. A screen that renders sample data is not built. A table sitting empty in the schema is not built — it is in the middle column, where it belongs. DrayBase has not launched, has no outside customers, and the carrier we are building alongside has not been migrated yet.
Running today

Built

Written and running against a live Postgres database — the board behind a signed-in session, the forms and the status page in the open. Where the arithmetic is unforgiving, unit tested. This is what exists.

  • The dispatch board reading live loads: status, driver, customer, pickup, delivery, container, chassis, last free day, dollars at risk and the next appointment
  • Six KPI tiles counted across the whole operation, not across the page you happen to be looking at
  • Board status derived from the active move rather than stored in a column — sixteen states, with a container hold outranking whatever the driver is doing until the box is gated out
  • Per diem and demurrage counted in calendar days on East Coast port time rather than on the server clock, and priced from the steamship line with a per-container override
  • Demurrage and per diem kept apart, because a box in the terminal past its last free day and a box on the street are two different bills and never both at once
  • Thirty-two unit tests over that arithmetic and the status derivation — fifteen on the money, seventeen on the states — including the day the clocks change: a container marked expired one day early is a phone call you cannot take back
  • Last free day stored and served with the source it came from and the moment it was last refreshed, so the record never holds a terminal fact it cannot attribute — the API carries both today; the board prints the date and not yet the source beside it
  • Row multi-select and select-all on the board, with the action bar it will drive
  • Tenant isolation enforced by Postgres row-level security, not by a WHERE clause someone has to remember; the seed refuses to finish if one carrier can see another
  • The active company read from the session and never from the request, with the role re-read from membership on every call so revoking access takes effect immediately
  • A permission matrix of eight roles against twenty-two permissions, and per-person overrides that do not require inventing a new role
  • The waitlist and contact forms — stored, mailed to a founder, honeypotted and rate limited by hashed IP
  • A status page that reports only the two components it actually probes and says, in grey, why it cannot speak for the other six

Read path only. See the section below.

Started

The schema or the endpoint is there; the part a dispatcher touches is not. Short on purpose — if everything were in build, in build would mean nothing.

  • Writing from the board: assign a driver, advance a status. The read path is done; the mutations are notIn build
  • Filters and search. The API already takes status, driver, customer, terminal, free text and LFD-critical; the bar above the table does not send them yetIn build
  • Bulk actions on a selection. Selecting works today, acting on the selection does notIn build
  • Permission checks per endpoint. The matrix and the middleware are written; no endpoint demands a specific permission yet, because nothing behind the login touches an operational record yetIn build
  • The audit log. The table is in the schema and nothing writes to it — that gets closed with the first write endpoint, not after itIn build
  • Problem containers. Exceptions are stored and counted into a tile; there is no queue to work them down fromIn build
  • Appointments. The next window shows on the board; booking, moving and confirming one does not existIn build
  • Documents. The table and its twelve document types are modelled, down to the checksum that settles a disputed POD; nothing uploads, captures or reads oneIn build

Half a feature is not a feature.

Planned

Designed, argued over, and not written. The order below is the order we intend to build in, and a carrier telling us we have it wrong is a good enough reason to change it.

  • Saved views and per-dispatcher columns, kept between sessionsPlanned
  • A load detail drawer instead of a second screenPlanned
  • The driver app: voice status, POD capture, offline queuePlanned
  • GPS and ELD ingest, live map, dwell timersPlanned
  • Terminal integrations — free time, holds, availability and appointment booking arriving with a source instead of by handPlanned
  • Street turn matching against open exportsPlanned
  • Double moves and dual transactions at the same terminalPlanned
  • Chassis pool reconciliation and split cost priced before dispatchPlanned
  • Tariffs, charge rules and a place to test them before they go livePlanned
  • Invoicing, aging, and accounting syncPlanned
  • Driver pay, deductions and settlementsPlanned
  • The six agents and command-K, every suggestion carrying its evidence and waiting for a personPlanned
  • The migration importer — customers, lanes, rates, equipment and open loads out of the system you run todayPlanned
  • Public API, webhooks and EDIPlanned
  • Billing for DrayBase itself. There is no way to charge you today, which is exactly why the pricing page has placeholders instead of numbersPlanned

Not a commitment. Not a date.

The honest limitRead only

The board reads. It does not write yet

Today the only things in the entire system that change a record are the two public forms on this website and switching which company you are looking at. You cannot assign a driver from the board, and we would rather you read that here than find it out on a call.

Why that orderIn drayage the expensive part to get wrong is the read: deriving what a load is actually doing from its moves, running two different clocks on two different bills, and making sure one carrier can never see another. Those are done. Driver assignment writes on top of them.
What lands with the first writeThe audit row and the permission check, together, not afterwards. A system that can change an operational record without recording who did it and reversing it is a system you cannot defend a dispute with.
What that means for you todayThere is nothing to trial. Access opens one port at a time so migrations get done properly, and NY / NJ is first because that is where the operation we build alongside runs.

The orderA sequence, not a schedule

What we build next, and why that one

Read this as an order, not a timetable. Each row is chosen because it unblocks the one under it — the write path has to exist before bulk actions mean anything, and the audit trail has to exist before the write path is allowed to ship.

#NextWhat it changes on the boardStatus
01The write pathAssign a driver and advance a status from the board, with the permission middleware finally doing somethingIn build
02Audit and undoEvery write landing in the audit table with the actor attached, and every write reversiblePlanned
03Filters and viewsThe filters the API already accepts, wired to the bar and remembered per dispatcherPlanned
04Problem containersThe exceptions already being stored, turned into a queue you work down instead of a number you look atPlanned
05AppointmentsBooking, moving and confirming a terminal window from the load it belongs toPlanned
06DocumentsPOD and BOL captured on a phone and attached to the move, not texted to a dispatcherPlanned
07Terminal dataFree time, holds and availability arriving on their own, each with a source and a timestampPlanned
08The agentsSuggestions as rows on the board, each with the record it was built on and a person to approve itPlanned
No dates

You will not find a quarter or a month anywhere on this page. Nothing has been delivered to an outside carrier, so any date we gave you would be a guess in a suit. When a port opens, the people on the waitlist hear it as a date, not as a slide.

Built means running

Nothing moves into the left column because it was designed, demoed or nearly finished. It moves when it reads or writes real records for a real user. That is the only promotion rule this page has.

This page moves backwards too

The roadmap changes when the code changes, and things get cut. When something drops off, it drops off here as well instead of quietly disappearing between two redesigns.

A roadmap you can check is worth more than one you can admire.

Every line in the first column was written against the code that backs it, not against a deck. If you want to see it work, ask — we will screen share the board reading a seeded operation and you can watch us fail to assign a driver.

Early access

Tell us which column matters to you

If the thing that would decide it for you is sitting in the third column, say so. The order is not sacred, and a carrier with real lanes describing a real loss is the best argument for moving something up.

Join the waitlist →Talk to us

More detail on the parts that exist: the dispatch board, containers and the clocks, how carriers are kept apart. On the parts that do not: the agents, migration and pricing.