Historical build notes

July 2026 Archive: Roadmap v1.0 and Stripe Build Notes

This records the week ending 4 July 2026, when Roadmap v1.0 and the Stripe billing work were taking shape. The plans, tier limits, release intentions and evaluation offers below describe that week, rather than the current commercial model.

There is always one more feature you can convince yourself is essential before talking to more people. We are trying not to do that.

CertLocker now has enough of the core operational shape in place: certificates, ACME, secrets, scoped tokens, SSH, RDP, MCP agent access, groups, audit events, probes, production HA, and the first public roadmap. The next bit is less glamorous but more important commercially: make the product easier to buy, easier to evaluate, and easier to explain to the people who actually live with this infrastructure.

Roadmap v1.0 is out now

Roadmap v1.0 is the line in the sand. Not because the product is finished, but because the product now has a clear public direction instead of an internal pile of engineering notes.

The shape is still practical: certificates, ACME delivery, private secrets, short-lived access, RDP/SSH workflows, endpoint verification, RBAC, audit trails, and AI agent access through MCP. The roadmap gives us a way to talk about what is already usable, what is being hardened, and what we are deliberately leaving alone for now.

That matters because CertLocker can easily sprawl if every infrastructure pain point becomes a feature. The roadmap forces us to keep the product centred on trust operations: who has access, what changed, what expired, what production is actually serving, and what can be proved later.

Stripe billing work planned in July

Most of the application work this week was around billing and tiers. It is not the kind of thing that makes a good demo reel, but it is the difference between a product people can trial informally and a product teams can actually start using without a manual back-and-forth.

The commits in the main application added the pieces around Stripe checkout, billing summaries, invoice display, cancellation at period end, registration-time checkout, tier lookup, currency and money fields, and back-office visibility for Stripe configuration. The client now has a billing page, a change-plan modal, monthly/yearly interval handling, invoice links, and the first tier-breach notice path that sends users back toward billing when they hit a configured limit.

There is a lot of boring correctness in this work. Amounts need currency. Tiers need monthly and yearly price IDs. Registration needs to know whether checkout is part of the path. Back office needs enough visibility to know which account is on which tier. Stripe subscription dates are not always where you expect them in the API. None of this is novel. All of it needs to be right.

The early-July plan was to release the Stripe path: checkout, billing summary, invoice history, tier changes, cancellation handling, and the registration flow tied back to a clean account state. We will keep it small and testable. The first goal is not a complex pricing machine. The first goal is that a real evaluator can select a plan, pay through Stripe, and land in the right CertLocker account without us manually stitching the state together.

Tier limits started becoming real product behaviour

Tiers are easy to describe on a pricing page and harder to enforce politely in an application. This week added the first explicit tier-breach path: when a limit is hit, the API can return a clear 402-style response and the UI can show a notice that explains what happened instead of pretending something generic failed.

That sounds small, but it is one of those details that decides whether a commercial product feels operational or bolted on. If someone hits a host, secret, certificate, or token limit, the answer should be visible in the product. Not buried in logs. Not sent as a vague exception. Not discovered through a support email two days later.

Desktop host access kept moving

The earlier RDP work also continued underneath the billing work. The commits around desktop roles and desktop hosts keep Windows/browser access inside the same access-control model as the rest of CertLocker: hosts, protocols, roles, credentials, and auditable access.

RDP is a good example of why CertLocker is not just a certificate tool. Real infrastructure estates are mixed. Some access is SSH. Some is RDP. Some is a vendor account into an old Windows server that nobody wants to talk about until an auditor asks who used it last month. We want those workflows governed by the same rules rather than split across three different tools and a spreadsheet.

Deploy and marketing infrastructure got cleaned up

The Ansible repo had a quieter but useful week. Production image pins were updated for the landing site and HA landing image. Live extra vars for production HA deploys were tightened. Landing lead tracking deploy support landed, including Grafana/Prometheus wiring for lead analytics. We also added IAM policy support for video uploads and removed old HAProxy native ACME lab experiments that had already served their purpose.

That cleanup matters because the next month is less about adding another deep product feature and more about getting the product in front of the right people. If we are going to run content, ads, videos, conference follow-ups, free hosted signups, and onsite evaluations, the landing and analytics path has to be dependable too.

We are testing Reddit ads carefully

We are also trialling Reddit ads, but carefully. Reddit is not a place where infrastructure vendors should shout into the room and hope nobody notices. The useful version is smaller: test whether the pain language is right, see which pages people actually land on, measure whether the trial flow works, and learn which objections show up from technical people.

So far the work is more about instrumentation and positioning than spend. We fixed attribution paths, moved campaign traffic toward the normal trial route, and started treating paid Reddit as a learning loop rather than a magic acquisition channel.

The code freeze planned in July

The July plan was to freeze the main product codebase for a month after the Stripe release unless there is a production issue or a genuinely blocking evaluation problem.

That does not mean no work. It means a different kind of work: marketing, networking, conferences, customer conversations, demos, free hosted accounts, and a few one-month onsite evaluations where the product has to prove itself against real environments.

This is the uncomfortable part for an engineering-led company. Building another feature feels productive because the feedback loop is local. Talking to customers, explaining the product clearly, and finding the right buyers is messier. But at this point that is the work.

The July release checklist

The July release target was the Stripe path. The checklist at the time was:

  • Stripe checkout from the CertLocker billing flow.
  • Registration that can carry checkout state cleanly.
  • Billing summary and invoice history in the app.
  • Tier changes with monthly and yearly pricing.
  • Cancellation at period end.
  • Back-office visibility for Stripe configuration and account tier state.
  • A clearer tier-breach path when an account hits a configured limit.

Once that is released, the bar for new feature work goes up. The next month is about proving the current product with real operators, not hiding from the market inside another sprint.

Current workflow discussions

For today's onboarding and commercial terms, use the Services & access page. Bring one certificate, secrets or access workflow to a face-to-face meeting or video call and we will demonstrate hosted CertLocker.

Discuss your current workflow

Bring your inventory or one awkward renewal path. We can show the hosted workflow and discuss the help your team needs.

Arrange a hosted walkthrough