Development Preview · Not yet generally available

Development

Engineering progress recorded as it happens, newest first, setbacks included. Each entry describes the platform as it was when the entry was written.

1. November 2026

   A new build of Ledgeron

   Ledgeron has a new build. It replaces the one the earlier entries in this feed describe, and it keeps the name. The product status now describes the new build, and the older entries carry a note saying which build they were written about.

   Some areas the old status called implemented are planned again, because the new build does not have them yet. Staff accounts and permissions, re-authentication before sensitive actions, and the communications foundation are among them.

   Three databases

   The new build runs on MySQL, MariaDB or PostgreSQL. Every change is tested on MySQL 8.4, MariaDB 11.8 and PostgreSQL 18, and older supported versions are tested nightly. It is written in PHP 8.3 to 8.5.

   Billing came first

   What is implemented today: clients, the product catalog, pricing and exchange rates, promotions, ordering, services, billing documents, automation, payments through Stripe, and an audit log. Issued tax invoices can’t be changed, and the database enforces it. Numbering has no gaps, and credit notes are the only correction. Payments have not yet run against live Stripe. Tax is in development now.

   No screen exists yet. The admin and client screens are planned, after the REST API and staff permissions. Provisioning modules for cPanel/WHM, Plesk, DirectAdmin and Virtualizor/Proxmox are being designed, with more to follow soon.

   How it is tested

   • Over 5,300 automated tests, run on each of the three databases for every change.
   • Money is kept as whole minor units (cents), never floating point, and the money rules have property tests.
   • Each rule is proved by breaking it on purpose and checking that a test fails.
   • Every task gets an independent review before it merges.
   • Concurrency is tested under load, with several clients’ work running at once.

   The roadmap lists the stages from here to controlled early access in 2027.

2. September 2026

   Billing moves forward

   This entry describes an earlier build of Ledgeron. A new build has since replaced it under the same name, and some areas this entry calls implemented are planned again. Current status is on the product page.

   Ledgeron can now create governed draft invoices and transition eligible invoices to issued state. Invoice numbering, issue timestamps, due dates and customer snapshots are server-owned and protected by the platform’s authorization and audit boundaries.

   What this means in practice:

   • A draft invoice is a real record with a defined lifecycle, not a form that becomes an invoice on save.
   • Issuing an invoice is a transition with preconditions. Ineligible drafts are refused, and the transition is recorded as an audit fact.
   • The customer snapshot on an issued invoice is fixed at issue time, so later changes to the account do not rewrite history.

   The broader billing lifecycle, including payments, is still ahead. The roadmap lists it as the current milestone.

3. September 2026

   AI-assisted development governance

   This entry describes an earlier build of Ledgeron. A new build has since replaced it under the same name, and some areas this entry calls implemented are planned again. Current status is on the product page.

   Ledgeron’s development repository now includes formal operating rules for AI coding agents, module boundaries, testing requirements and security constraints. AI-assisted changes follow the same issue, review and CI workflow as human contributions.

   The rules are written down so they can be enforced:

   • Which modules an agent may change for a given issue, and which boundaries it may not cross.
   • Which tests must exist and pass before a change is reviewable, including PostgreSQL-native verification for critical behavior.
   • Security constraints that apply regardless of who or what wrote the code: authorization checks, audit events, fail-closed defaults.

   Nothing merges without review and a passing CI run. That was already true; the change is that the expectations are now explicit.

4. August to September 2026

   Core hosting workflows

   This entry describes an earlier build of Ledgeron. A new build has since replaced it under the same name, and some areas this entry calls implemented are planned again. Current status is on the product page.

   Product Catalog, Orders, client-account context, service lifecycle, communications and Settings have progressed from prototype surfaces into governed runtime slices.

   “Governed runtime slice” is a deliberate phrase. It means the capability exists in the running platform with its authorization boundaries, audit events and lifecycle rules in place and verified in CI. It does not mean the commercial module is complete; the product status says which parts are still in development.

   Across these slices:

   • Client-account context is enforced for staff actions, so operations happen inside an explicit account rather than across all of them.
   • Orders link catalog, pricing and the resulting service records as one traceable chain, and clients can review their order history.
   • Settings changes and communications are governed like every other record: deliberate, recorded, reviewable.

5. August 2026

   getledgeron.com goes live

   This entry describes an earlier build of Ledgeron. A new build has since replaced it under the same name, and some areas this entry calls implemented are planned again. Current status is on the product page.

   The Ledgeron site is live. It is a static Astro site with a single server endpoint for early-access registrations. That endpoint is separate from the Ledgeron platform itself and has no access to client accounts.

   What exists today:

   • The product overview, security positioning, roadmap and development status, with each capability labelled by its current state.
   • An early-access registration form with explicit consent capture.
   • This feed, where we will record progress as it happens, setbacks included.

   On the platform side: authentication and authorization, the staff and public Product Catalogs, pricing lifecycle and client-account context are implemented. Ordering, service management and invoicing are in development.