Status and roadmap

The changelog lists every change by day, and the feature list says what exists now. Development of the product surface ran to February 2026. Work resumed in September 2026 with an explicit staging plan. Each stage has an entry plan and a closeout report in the repository’s improvement-plans/ directory; this page is the summary.

Stage 1: Stabilization (complete, 6 September 2026)

Twelve tickets (STAB-01 to STAB-12) turned a feature-complete prototype into a candidate that can be verified:

One supported database engine (PostgreSQL 18) for development, tests and CI.
Zero TypeScript errors, clean lint and format, production assets build.
Server-side authorization on every protected endpoint, with a role matrix test.
Tenant boundaries tested, including negative side-effect assertions.
Provider credentials encrypted and never serialized, logged or flashed.
Zero dependency advisories.
A check-only CI with quality, tests and audit jobs.
Browser verification with production assets, which found and fixed two cross-host login defects.

A short closeout patch (Stage 2 PR 0, 7 September 2026) resolved the carryovers: sole-owner account deletion is blocked, supply prices are hidden from staff and viewers, provider exception text is redacted, and the deploy is gated by CI.

Stage 2: Business-rule validation (complete, 14 September 2026; final merge `56e4f13` on 15 September 2026)

Goal: an order’s price, composition, state, allocated stock and cost stay consistent through confirmation, assembly, edits, cancellation, repeated requests and competing purchases, and every change in batch stock can be explained from recorded business actions.

Progress: BRV-01 done (12 September 2026) with the baseline on Stock and money today; BRV-02 done (13 September 2026): the Business rules are accepted, with three owner decisions recorded as ADR-008 to ADR-010. BRV-03 done (13 September 2026): exact server-authoritative totals with the delivery fee, currency snapshot on orders and carts, per-currency exponents, the workspace currency lock, and a delivery-fee field on the order forms. BRV-04 done (13 September 2026): immutable order revisions with flower composition snapshots, optimistic version checks on edits, a frozen-order guard, deletion protection for products in recorded orders, and a migrated revision 1 for legacy orders. BRV-05 done (13 September 2026): the inventory ledger is the only stock writer (ADR-011); every stock change is an append-only movement with projections kept in step; allocation, transition and idempotency tables are in place; legacy balances were documented and unbatched stock preserved as review batches; a read-only reconciliation command checks the books. BRV-06 done (14 September 2026): confirming an order reserves its whole composition FEFO from batches eligible for the delivery cutoff, all-or-nothing with a per-flower shortage message; cancellation releases; repeated confirmations apply once (idempotency keys); a race suite proves exactly one winner across real connections. Workspace timezone setting added. BRV-07 done (14 September 2026): the transition matrix is enforced for every role, starting assembly rechecks and consumes reservations exactly once with actual batch costs, every status change is recorded, failures roll back, repeats apply once, and cancelling after assembly keeps the loss. BRV-08 done (14 September 2026): confirmed orders can be amended with atomic re-reservation, shortages keep the previous agreement, date changes recheck eligibility, frozen orders refuse, orders with history are cancelled rather than deleted, and the complete golden scenario (steps 1 to 10 plus the write-off) passes end to end with the agreed values. BRV-09 done (14 September 2026): write-offs and supplier returns are explicit reasoned movements per batch, batch expiry or status changes that would strand reservations are refused naming the orders, consumed costs are never rewritten, a write-off racing a confirmation cannot oversell, and server-side messages now follow the interface language with Ukrainian translations enforced by a test. BRV-10 done (14 September 2026): estimated versus actual material cost, unknown never zero, material profit, margin and markup correctly named and labelled as excluding labour and delivery, cancelled assembled orders shown as a loss, custom bouquets costed; visible to managers and above. BRV-11 done (14 September 2026): read-only reconciliation that separates corruption from operational exceptions and checks orders against their revisions, a manager-only Attention page listing orders needing reallocation and batches needing a person, the same warning on the order page with a one-click re-reserve, and reserved counts on flower and supply pages. BRV-12 done (14 September 2026): the golden scenario and the race suite are named CI gates, the demo data must reconcile in CI, a pre-stage database was migrated in rehearsal without inventing history or consuming stock twice, browser journeys in Ukrainian at phone width pass, and the closeout (improvement-plans/BRV-12-Closeout.md) records invariants before and after, the decision register, known limitations and the Stage 3 requirements. Suite: 598 passed, 1 skipped. Alongside, the team gained a documentation site, signed single-use login links for browser testing, and a fix for control-panel form URLs found with them.

Twelve tickets (BRV-01 to BRV-12) deliver, in order: a domain baseline; a written business contract; exact server-authoritative totals; immutable order revisions; an allocation and movement schema; FEFO reservations with concurrency tests; a transactional order lifecycle; amendments, cancellation and recovery; safe supply corrections and spoilage; honest costing and margin; reconciliation; and an end-to-end closeout. The estimate is five to eight focused working weeks.

The Business rules page holds the proposed contract (B01 to B15) and is updated as decisions are accepted.

Production (live, 4 October 2026)

flowery.com.ua runs on Forge with shops on their own subdomains, transactional mail through Resend, a queue worker and scheduler, and required email verification. Deploys run only after the checks pass; before launch the local gate of ADR-012 stands in for GitHub CI and is switched off before the first real shop.

The landing page shows the product (8 October 2026). After a study of about twenty florist and small-business platforms, flowery.com.ua leads with what none of them shows: stems tracked from the delivery to the bouquet, used oldest-first and reserved on confirmation. Real screens follow one order to its margin, and the AI section shows real generated images with their limits. Prices, a public demo shop and the company’s contact details wait on owner decisions (landing page).

Opening soon (7 October 2026): a shop with nothing to sell yet shows its name and contacts on an “opening soon” page instead of an empty catalogue, not indexed; previews and order status links still work (runtime).

Team (7 October 2026): owners and managers invite staff by email from Settings → Team, with roles below their own; admins and the owner change roles and remove members (ADR-021).

Onboarding reminders (7 October 2026): owners who stall get one email per stuck step (confirm the email, create the shop, add flowers, turn on ordering), once each, with a one-click way to stop them (ADR-020).

One-click setup (7 October 2026): Getting started publishes the website as it is and turns on pickup ordering (cash or card on receipt) with one click each (onboarding).

Quick bouquets (7 October 2026): ready recipes from the shop’s own flowers (mono bouquets with the usual stem count, mixes, a flower with a filler), priced at the sum of their stems, created at once (onboarding).

The control panel wears the brand palette (7 October 2026): paper surfaces, ink text and rose actions, light and dark, contrast-checked (brand).

Sign in with Google (7 October 2026). Sign-up and sign-in offer “Continue with Google”, which skips the form and the confirmation email; existing accounts are linked by their verified address (ADR-019).

Onboarding, optimised (6 October 2026), after a walkthrough as a new owner:

name and web address on one screen, so three steps instead of four;
confirmation and password emails in the owner’s language;
a confirm page that shows the address, corrects it and continues by itself;
a welcome email with the shop’s addresses;
quick-add for flowers from the built-in list;
a supplier named on the first delivery;
sign-up pages in the brand;
onboarding:funnel to measure it (onboarding).

Finance (6 October 2026). Managers and above see the shop’s figures for any period:

net sales of completed orders, net of refunds, against the previous period;
material profit and margin, with the same cost as the order page;
a profit and loss statement down to operating profit;
purchases per supplier, write-offs and stock value;
payments by method and what customers still owe;
delivery fees against what Uklon charged.

Rent, wages and other running costs are recorded as operating expenses. Orders and expenses export to CSV for an accountant (ADR-018).

Ukrainian by default (6 October 2026): the control panel, server messages, emails and storefronts use Ukrainian unless a person or shop chooses English, and a page-by-page audit translated the control panel’s remaining English. Storefront settings moved into the main sidebar.

Onboarding and a demo shop (5 October 2026). After choosing the address, a new owner:

gives the shop’s phone, address and opening hours;
starts with a demo florist (catalogue with photos, stock in batches, orders in every state, a storefront) or empty.

The demo is marked record by record. One click removes it without breaking the books, and keeps anything real work already uses (ADR-016). While it is loaded, the storefront says so, and its orders are marked test orders that can be taken through the whole process. The dashboard became a “Getting started” checklist computed from the shop’s own data (onboarding and demo shop).

Flowery’s own brand (5 October 2026): a new tulip logo, a palette and type system, favicons and an app manifest, used on the landing page and in the control panel.

A public landing page (5 October 2026): flowery.com.ua now introduces Flowery to visitors in Ukrainian and English instead of opening on the sign-in page. It covers the storefront, the AI florist (bouquet photos from the bouquet’s own stems, and descriptions), online ordering with Uklon, inventory by batch and orders, in the look of a printed florist’s catalogue, using real storefront screenshots and no invented claims, and it is built for phones first (landing page).

Storefront platform (in progress)

Plan: improvement-plans/Storefront-Platform-Plan.md (approved 4 October 2026). The storefront becomes a platform. It gets:

A public, versioned Storefront API.
Astro storefronts rendered from themes chosen in a catalogue.
A versioned shop configuration (draft, preview, publish) edited in settings and by an internal AI agent over MCP.
Real shop details, categories and occasion tags.

The design anticipates a theme SDK and marketplace, gated on isolating theme code from staff sessions.

Own domains (8 October 2026). A shop can serve its website from a domain it owns (ADR-022): the owner connects it in Settings → Domain, adds a CNAME and a TXT record at the registrar, and Cloudflare issues the certificate; the shop keeps its flowery.com.ua address for staff and as a redirect. The first part (serving a custom host) went live the same day; the second (connecting one from Settings) followed.

Stage 3A, guest checkout with offline payment, has started (5 October 2026):

Decisions: ADR-014 and ADR-015, for Uklon courier delivery.
Done:
- Per-shop checkout settings.
- One order-creation path for staff and storefront, with packaging kept on each order line.
- The checkout API: options, quotes, order requests, the private status link, and emails to staff and the customer.
- Checkout and status pages in Bloom and Noir, with pickup following the shop’s opening hours.
- The staff side: new requests highlighted and filtered, offline payments recorded with reversals, and a new status link on request.
- Uklon courier at checkout: each shop connects its own Uklon account, customers get Uklon’s live price, and Uklon orders are paid by bank transfer.
- Booking the Uklon courier at dispatch, with live courier status from Uklon and the stage on the customer’s status page.
Closed (25 October 2026): the offline golden scenarios G1 and G6 run end to end as a named CI gate, the runbook Switching a shop’s checkout on is written, the whole journey was walked on the production build at desktop and phone width in both languages with the price-change and double-click recoveries, and the exit checklist is ticked (improvement-plans/Stage-3A-Closeout.md). The production request followed on 26 October 2026: one request through a shop on its own domain, confirmed and paid in the control panel (production run).

The internal storefront agent (5 October 2026): an MCP server lets an AI agent read any shop’s storefront and catalogue, edit its draft (profile, theme, sections, images, occasions), preview, publish and revert, under the same validation and honesty rules as the settings page (storefront agent).

Shop addresses follow one rule (5 October 2026): DNS-safe, never a reserved platform name, with a clear reason at onboarding (tenancy).

Phase D: shop storefronts are live on the Astro storefront, on each shop’s own subdomain (5 October 2026). The previous Laravel storefront was retired the same day; if the storefront restarts, visitors see a short “back in a moment” page with the shop’s phone.

The storefront themes were redesigned after the first version looked generated (4 October 2026):

An editorial, catalogue-like look on paper and ink, with real Ukrainian typography.
Label cards for products without photos.
A price list of today’s stems.
An order-slip builder.
A side cart that opens on every add.
Navigation and the phone layout rebuilt from current research: a utility line and an occasions panel on desktop; on phones a menu drawer with contacts, a header that hides on scroll, and the first bouquets and a call link in the first screen.
Demo shops with photos at real prices.

Details are on the design page.

Phase C, the Astro storefront, is done locally (4 October 2026):

The storefront SDK.
The Bloom (light, photo-led) and Noir (dark, editorial) themes.
Draft previews.
A strict Content Security Policy.
Rate limits per visitor.

It reaches customers with the production cutover (phase D).

Phase B, themes and configuration, is done (4 October 2026). It brings:

Theme manifests (Bloom and Noir) in a typed settings language.
A versioned configuration per shop: draft, publish, revert, and preview links.
Settings → Storefront for the shop’s details, theme, home page sections and history.
Safe image uploads and server-side image fetches.

Phase A, the Storefront API v1 with occasion tags, is done (4 October 2026). The API covers the shop, categories, occasions, bouquets, flowers, packaging and the cart. It returns public fields only, availability as labels, and exact server prices. It is protected by JSON-only writes, a hashed cart cookie and rate limits, and checked against an OpenAPI contract by tests.

Phase H, an honesty hotfix, is done (4 October 2026). It:

Removed invented reviews, badges and delivery promises.
Fixed flower and quick-view actions, the bouquet gallery and the packaging total.
Shows stems available to promise instead of raw stock.
Hides the staff link from customers.

Stage 3: Storefront checkout and payments (3A complete, 25 October 2026; 3B remains)

Plan: improvement-plans/Flowery-Stage-3-Checkout-and-Payments-Plan.md (committed 4 October 2026). Checkout calls the same pricing, snapshot, confirmation and inventory services Stage 2 built for the back office. Two milestones, each behind its own workspace switch that defaults to off:

3A, guest checkout with offline payment. A customer submits an order request and gets a reference and a protected status page; staff confirm and reserve it through the existing actions and record offline payment. Includes the login cart merge, server-side quotes with delivery rules, and one order per cart submission however often it is retried.
3B, one online payment gateway. Stock is reserved before any charge, the provider’s authenticated callbacks (never the browser return) mark an order paid, unpaid checkout orders expire after a fixed window and release stock, late payments and full refunds are handled, and unpaid prepaid orders cannot be assembled.

Work starts with six follow-ups from the Stage 2 review (PR 0). Part 1 (4 October 2026) fixed what checking them against the code found:

Provider error text from AI responses no longer reaches the browser or the logs.
Assembly no longer silently reserves a confirmed order that lost its allocations.
The currency locks once any price exists, and catalogue and supply prices are exact in the shop’s currency.
New shops no longer show prices in USD while pricing in UAH.
Reservations are judged against the delivery date, not today.
The timezone is locked while orders are committed.

Part 2 (4 October 2026) gathered production evidence:

The race suite now proves the contenders really competed.
A deploy succeeds only when production reports the deployed commit.
Backup, restore and rollback were rehearsed on a disposable copy of production.
CI runs production’s PostgreSQL 17.
A real password and two-factor login found that a signed-in user could be left on the challenge page; that is fixed.
The owner’s own production login check remains. The gateway is chosen in CHK-01 against the first shop’s merchant eligibility, including whether fiscal receipts are required.

Security and dependencies (26 October 2026)

A review of the measures in place found the boundaries sound (tenant-scoped records, rate limits on every costly or guessable endpoint, safe image fetches, signed webhooks, hashed tokens) and added what was missing at the edge: every answer now carries the browser protections, the application’s own pages a Content Security Policy, and a new password on production is refused when it appears in a known breach (security). Library updates now follow a policy instead of the next red audit: advisories within two working days, in-range updates weekly through Dependabot, majors quarterly one framework at a time (ADR-023).

Later

Ownership transfer, dashboard content, trial and billing enforcement, per-workspace media paths, and the framework majors on the quarterly dependency review (next January 2027: Inertia 3 first, then Laravel 13; Astro 7.4 once the server’s Node is upgraded; Vite 8, TypeScript 7 and ESLint 10 after those).