Development journal

What was actually built

The official FleetRan development record. Entries describe work that happened, not work that was planned. A week with no visible release says so — inventing progress would make every other entry worthless.

Current milestone
M1Foundation
Entries
16
Latest
September 8, 2026
  1. PlatformM1

    Accounts exist, and the administrator cannot get in with a password alone

    Almost everything still unbuilt in the specification was waiting on the same thing: knowing who someone is. That now exists. Passwords are hashed with scrypt, and the cost parameters live inside the hash, so raising the cost in two years quietly re-hashes each password at the next sign-in rather than locking everyone out. Two-factor is not optional for administrators — an admin password on its own opens nothing. Recovery codes exist and are spent once each, because without them a lost phone ends with somebody turning two-factor off "temporarily", which is the exact failure it was there to prevent. Sessions are revocable immediately rather than at expiry; a lost laptop cannot wait an hour. The sign-in form never reveals whether an address has an account: a wrong password and an unknown address return the same sentence, and an unknown address still pays the hashing cost so the response time does not answer the question either. The audit log has no edit and no delete anywhere in the code that touches it — the same rule the product applies to compliance records.

    Completed

    • Accounts with the five roles from the specification
    • Two-factor for administrators, verified against the standard’s own test vectors
    • Sessions that can be closed immediately, stored only as hashes
    • Sign-in that does not disclose whether an account exists
    • Rate limiting that survives serverless hosting
    • Audit log, and an admin portal to read it
    • A guardrail that fails the build on a design token that does not exist

    Next

    • Milestone editing from the admin portal
    • Investor room and fleet portal
    • Transactional email
  2. PlatformM1

    The load runs end to end, and the paperwork asks for itself

    Until now the demonstration could show a fleet but not a job. It can now: a load moves through all fifteen states in the specification, from assigned to completed, and the terminal shows one action at a time rather than a menu of everything a driver could theoretically do. Two of those states are the point of the whole thing. After the truck is loaded, nobody presses "documents" — the terminal has already moved to "Scan BOL". After delivery, the same for the POD. If that took an extra tap we would be demonstrating a form, not a workflow. What the system reads off a captured document is shown as extracted, beside a line saying the original scan is kept unchanged and remains the record; that is not decoration, it is the rule the product is built on. Every step raises the same named event the fleet side consumes, so a driver scanning a POD appears in the Command Center feed in the same second. The paper itself is simulated. The scanner that would produce it in a real cab is a separate question and still open.

    Completed

    • All fifteen load states from the specification, in order, with the delivery-side check-in and unloading steps that had been collapsed
    • Context-driven document steps: the terminal asks, the driver does not go looking
    • Captured documents shown as extracted, with the original marked as the record
    • Driver actions raise the shared fleet events, visible in the Command Center
    • Five more tests; twenty-one now pass

    Next

    • Hosting, database, email and authentication
    • Legal review before publication
  3. PlatformM1

    Four demo scenarios, and the timeline moved out of the code

    The specification is blunt about this: the demonstration must not be hardcoded into the interface. It was — a single fixed timeline sitting in the same file as the fleet, which made adding a second scenario impossible without touching components. Scenarios are now data. There are four, each answering a question a visitor actually has: what an ordinary day looks like, what happens when the hours run out, what a fault looks like before it becomes a tow, and how a missing document gets caught before invoicing. A fifth is a file edit, not a rewrite.

    Completed

    • Scenarios extracted to data, with per-scenario starting state
    • Four scenarios selectable in the simulator
    • Four more tests, including one that scenarios do not leak into each other

    Next

    • Hosting, database, email and authentication
    • Legal review before publication
  4. GovernanceM1

    The progress bar now covers the whole website, not a summary of it

    The milestone listed thirteen deliverables while the website had far more parts than that, so the bar was measuring a summary rather than the work. It now lists all forty-five: foundation and governance, brand, every public page, the interactive demonstration, the truth and compliance content, the quality gates, and the nine things still missing before this site can be published. Thirty-six are done, which puts the real figure at eighty per cent — lower than the old list implied, and correct. The homepage shows the six outstanding items rather than the thirty-six finished ones, because the question a visitor has is what is not ready yet.

    Completed

    • Forty-five deliverables covering the full website build
    • Favicon, app icon and social share image, which were missing entirely
    • Homepage shows what remains; the full list lives on the roadmap

    Next

    • Hosting, database, email and authentication — the nine remaining items
    • Legal review before publication
  5. WebsiteM1

    The site was breaking sideways on a phone

    Testing at 360, 414 and 768 pixels found the navigation pushing 758 pixels past the edge of the screen on every page, and the hardware scene pushing 1,184. Two causes, both instructive. The navigation had no mobile treatment at all — it now wraps onto its own row instead of running off. The hardware labels get their position from an inline style, and inline styles beat stylesheets, so switching them to static positioning was the only thing that would make the browser ignore those offsets. Touch targets were 14 to 15 pixels tall in the footer and navigation; they are now tappable on a coarse pointer, while links inside sentences stay inline where they belong.

    Completed

    • Navigation, hardware scene and page transition fixed at phone widths
    • Standalone controls enlarged for touch, from 19–38 undersized down to 3
    • Confirmed no route scrolls sideways at 360, 414 or 768 pixels

    Next

    • Database and authentication
    • Legal review before launch
  6. WebsiteM1

    The homepage was loading the whole simulator. It no longer does

    Measuring rather than assuming turned up three things. The simulator was mounting on the homepage, so every visitor downloaded it whether or not they wanted a demo — a dynamic import does not help when the component mounts immediately, so it now sits behind the same click as the demo page. All eight terminal screens were loading at once for images shown one at a time; they now arrive as the cycle reaches them. And the WebM version of the hero video turned out to be larger than the H.264 one at this resolution, while being listed first — so browsers that preferred it were served the worse file. It is gone.

    Completed

    • Initial page weight down from about 4.5 MB to 2.6 MB
    • Requests on first load down from 22 to 14
    • Accessibility checked on thirteen routes: one h1 each, no missing alt text, no unnamed controls, no skipped heading levels, every field labelled

    Next

    • Database and authentication
    • Legal review before launch
  7. ProductM1

    Exception-first, shown instead of explained

    The Command Center page had three fixed numbers making an argument about scale. It now has a control that moves a fleet from 10 trucks to 1,000 and lets a visitor watch what happens: the list of exceptions grows, the wall of trucks does not. Two decisions kept it honest. Small fleets never round down to zero, because reporting "no problems" at ten trucks would be a lie by rounding. And the closing argument changes below fifty trucks — at that size you really can look at every truck yourself, and claiming otherwise would be a sales line rather than a demonstration.

    Completed

    • Fleet scale control from 10 to 1,000 trucks
    • Deterministic counts from declared rates, shown on the page
    • Three tests, including one that the argument holds sublinearly

    Next

    • Database and authentication
    • Accessibility and performance verification
  8. PlatformM1

    Demo controls completed: skip ahead, and change role

    The simulator now has the two controls it was missing. Next event jumps forward to the moment something happens instead of asking a visitor to sit and wait, and the jump runs through the same tick as normal playback — a shortcut that skipped it would produce a state the system could never actually reach, which a test now guards against. View as switches emphasis between the fleet owner and the driver, but keeps both surfaces on screen on a wide display, because the point being demonstrated is that an action in one appears in the other.

    Completed

    • Next event, with the control disabling itself when the timeline is spent
    • View as: both, fleet owner, driver
    • Three engine tests, including one proving the jump equals continuous play

    Next

    • Fleet scale demonstration
    • Database and authentication
  9. ProductM1

    Every capability published with its real status

    Fifty-five capabilities are now listed on one page, each with the status it actually has. Thirteen can be touched in the demo today. Six are in development. Twenty-nine are planned. Seven are still open research questions with no answer. Publishing that distribution is uncomfortable and is the point — a fleet that discovers the gap at installation is a fleet you never get back. Where a status alone could mislead, the entry says why: the hours-of-service view is a demonstration and not a compliant record, failure prediction is deliberately not called predictive maintenance, and parking availability needs a data provider that is not contracted.

    Completed

    • Feature explorer with filtering by status and by area
    • Truth notes attached to the entries where a label is not enough
    • Every capability mapped to the milestone that delivers it

    Next

    • Keep the statuses honest as milestones land
    • Database and authentication — the gate on every portal
  10. WebsiteM1

    Legal pages, search rules and the full homepage story

    Shipping the registration forms created an obligation the footer had already made: policies published before the site accepts anything. They are written from what this site actually does rather than copied — it sets no cookies, runs no analytics, stores nothing in your browser and serves its own typeface, so the privacy page can say so plainly. Privacy and terms are marked as drafts until counsel reviews them, because a legal document nobody has checked should not present itself as final.

    Completed

    • Privacy, terms, demo disclaimer, accessibility and security contact
    • Sitemap, robots and canonical domain on fleetran.com
    • Homepage completed to the specified structure: what FleetRan is, the eight-systems comparison, the three surfaces, the journal and a closing call
    • Homepage roadmap condensed now that the full roadmap has its own page

    Next

    • Legal review before the site goes public
    • Database and transactional email
  11. HardwareM1

    Hardware presented as an installed system, not a catalogue

    A grid of product cards read like a parts catalogue. The hardware section now leads with the truck itself, with each component anchored where it is actually installed — terminal on the dash, gateway on the vehicle bus, cameras at the windshield and mirrors, node on the trailer. Hovering a component highlights its place on the vehicle. The cards remain underneath as the technical drill-down, each one opening what is settled and what is still an open question. Statuses are now the Product Bible terms — candidate, planned, research required — shown as a small indicator rather than a coloured band.

    Completed

    • Interactive hardware scene with component anchors on the truck
    • The three real communication paths: vehicle, cameras, detached trailer
    • Per-component detail panel: what it does, what is settled, what is open
    • Truth badges reduced to an indicator and a word

    Next

    • Consistent hardware renders on transparent backgrounds
    • Fleet Power Module render — the component has no photograph yet
  12. WebsiteM1

    Founding Fleet and investor registration

    Both registration paths are live, with the full field sets from the website specification. One decision is worth stating plainly: the FleetRan database is a later milestone, so until it is connected these forms do not pretend to succeed. A form that shows a green tick while saving nothing loses the lead and tells no one — so when storage is unavailable the page says so and gives an address that reaches a person.

    Completed

    • Founding Fleet page, waitlist form and application stages
    • Investor page, watchlist form and a written list of what is not claimed
    • Server-side validation with per-field errors
    • Submission storage that either persists or reports failure honestly

    Next

    • Database and transactional email
    • Founding Fleet and investor portals
    • Admin milestone management
  13. WebsiteM1

    Roadmap and development journal published

    The roadmap is now public with all twelve milestones, their target dates and their real status. Progress is counted from deliverables that are finished, not typed in by hand — a percentage without a definition of what 100% means is an impression presented as a measurement. The roadmap is versioned, and revisions stay on the page rather than being quietly overwritten.

    Completed

    • Public roadmap with twelve milestones and per-deliverable progress
    • Complete / in progress / next breakdown for every milestone
    • Roadmap revision history, additive only
    • Development journal
    • Shared navigation and footer across the site

    Next

    • Founding Fleet registration
    • Investor registration and watchlist
    • Admin milestone management
  14. WebsiteM1

    Homepage runs the real Driver Terminal screens

    The terminal on the homepage is no longer an illustration. Eight product renders of the Driver Terminal — Home, Active Load, Navigation, HOS, Vehicle Health, Trailer, Arrival and Maintenance — are cut from the same canonical screen rectangle and mounted over one device plate, so the bezel never flickers and only the software changes. The truck is a looping video rather than a still.

    Completed

    • Eight Driver Terminal screens cycling on the device
    • Screen crops verified against a canonical rectangle before they ship
    • Hero truck as a looping, muted, reduced-motion-aware video
    • Layout locked to the viewport from 1180px upward

    Next

    • Driver Terminal page with the interactive workflow
    • Command Center page
  15. WebsiteM1

    Public website foundation

    First public surface for FleetRan: homepage, ecosystem view, hardware inventory with honest status badges, the commercial release countdown and the interactive demo shell. Every hardware component carries the status it actually has — candidate, prototype, research required — because a website that overstates the hardware is the fastest way to lose a fleet operator.

    Completed

    • Homepage, countdown and ecosystem sections
    • Hardware inventory with truth badges
    • Interactive demo shell, loaded on demand
    • Design tokens shared between site and product

    Next

    • Roadmap and updates pages
    • Founding Fleet and investor registration
  16. GovernanceM1

    Repository, development rules and guardrails

    The monorepo is set up with the domain model, the design token package and a guardrail script that runs in CI. The guardrails are not style checks: they fail the build when retired palette values reappear, and they exist so that the product rules survive contributors who have not read the Product Bible.

    Completed

    • Monorepo with workspaces and CI
    • Domain model and release target governance
    • Design tokens as the single source of colour
    • Guardrails enforcing the retired-colour registry
    • Branch protection, CODEOWNERS and PR rules

    Next

    • Authentication and organizations
    • Driver Terminal and Command Center shells
Development journal — FleetRan