Over September 6 and 7, we improved everyday workflows, deployed updates to both hosted testing cells, and worked through issues found during paid registration and organization deletion.
September 6: testing and simplifying the interface
We tested a single-model system locally, following the user through navigation, architecture, lifecycle changes, events, and costs.
That testing led to several improvements:
- Event filters preserve the selected model and provide a named return link.
- Model lifecycle updates keep the user on the model page.
- Component saves and related-model navigation retain the system context.
- Model links in the architecture graph open the model workspace directly.
- The graph appears earlier on the page, with advanced controls available on demand.
- Architecture state and component-count differences have clearer explanations.
- Cost views stay scoped to the selected system or model when recording and saving entries.
These changes were verified locally on September 6 and included in the hosted rollout on September 7.
September 7: ownership and operational visibility
We completed architecture ownership improvements. Graph creation now supports a default owner and individual overrides for new elements. Existing graphs have an action to assign missing owners to selected elements without overwriting owners already assigned.
We also improved component configuration presentation, making submitted versions and environment publications easier to distinguish and preventing duplicate submission of unchanged configuration.
Global Control gained registration reporting across cells, including organization creators, user registrations, and invited-user counts. Operators can filter by an inclusive date range and change the destination cell for new registrations from Control.
Paid onboarding and returning customers
After verified payment, paid onboarding now continues automatically without an extra organization-creation click. While confirmation is pending, an animated indicator explains that Hashmedo is waiting for Paddle.
We added a farewell screen after successful organization deletion and sign-out. It confirms that the subscription has ended and provides a return-to-login action.
Testing also exposed two issues that we fixed:
- Re-registering with the same email tried to create a duplicate Paddle customer. Checkout now reuses the existing customer when Paddle explicitly identifies that conflict, while keeping the new organization’s billing account separate.
- Organization deletion could finish but fail during login-routing cleanup. We corrected the missing database permissions and completed the affected cleanup.
Re-registration was confirmed working after the customer-reuse fix. The final routing repair still needs a fresh end-to-end check of deletion, the farewell screen, and re-registration together.
Deployment and verification
The changes were delivered through cell and shared-service releases, with tests appropriate to each change and health checks after deployment. Database checks covered returning-customer isolation and routing cleanup using the actual service role.
Encrypted backups were verified, including a fresh backup before the billing migration. The recorded deployment checks showed both hosted cells and updated shared services healthy.
These checks provide release evidence; complete customer-journey acceptance remains part of the launch work.
Separate staging and production
We agreed on a dedicated production installation with its own Control, billing, onboarding, gateway, Keycloak, cells, databases, and credentials. The existing installation will remain available for staging and testing.
Staging will use Paddle Sandbox; production will use Paddle live payments. The environments will share the image registry and initially share S3 storage, with separate backup paths, access credentials, and encryption keys. Releases will promote the same tested image digests into production.
This is an agreed architecture, not a completed infrastructure rollout.
What comes next
- Provision the independent production installation and configure staging domains.
- Complete signup, billing, deletion, invitation, and permission acceptance checks.
- Verify monitoring alerts, backup restoration, and release rollback.
- Deploy a clearer explanation when component publication requires an independent reviewer.
We also verified that a component version can remain active in staging and production at the same time. Suspending or unpublishing it in production leaves its staging publication intact.