Ensemblo opens at the end of September. The exact day is still open. I first moved the date off 1 September to 2 September on 23 August, and then, on 24 August, moved it again to the end of the month. That second decision also came a day before the decision date, and for the same reason as the first: the answer was already arithmetic.
Ensemblo is a marketing team you do not have to hire: specialists who run your marketing over email and Slack, where everything that goes out is something you approve with one click. This is the run-up to opening that up, including the parts a launch post usually cuts. The worst of it sits in my own approval queue.
The date is not a feeling, it is a criterion written down in advance
The go/no-go on 25 August is not me reading the room on the day. The go-to-market plan put the conditions on paper in advance, so the decision could not be talked into existence later.
| Condition | Where it stood on 20 August |
|---|---|
| Two tenants running ten days | One tenant: PlainConsent, my own product, since 28 July |
| No P0 | The machinery is clean: 26 jobs, all done, zero errors, scheduler ticking again. The output is not: one open P0, below |
| Activation works | The core loop runs, from task to piece to approval request to decision to delivery. The path from the site to an account has never run end to end |
| Payment flow tested | No |
| Test companies (MVP week, decided 11 August) | Did not happen. There is one app user |
Those lines come out of a read-only measurement against the production database on 20 August. Not out of a backlog, where things get marked done by the same hand that wrote them.
Why the decision fell before the decision date
Ten days with two tenants means the second tenant had to exist by 15 August. It does not exist. You cannot make up ten days of running time in the five that were left, so by 20 August the answer to the 25 August question was already arithmetic.
That is the quiet benefit of writing your criteria down before you need them. By the time the date on the calendar arrived, it was a formality.
The advice in my own decision document does not lean on the tenant count either. It says move to 15 September, and the reason is not the counting. It is that nobody outside of me has ever worked with this product.
The count is a proxy. The proxy is not the point.
That held twice. A fresh measurement against production on 24 August, six read-only checks run in parallel, came back with none of the five criteria met and one clear reason: the bottleneck is not the machinery. The clock had ticked 3,309 times since 13 August without a single failure, all 34 jobs had finished, and nothing was dead or stuck. What was missing was use. The two new tenants had existed for four days with zero artifacts and zero active tasks, no human decision had been taken since 14 August while thirteen requests sat waiting, payments were still running on test keys, and the number of people outside my own company who had used the product was zero. So the launch moved to the end of September, and the dogfood tenants went on that same evening.
The mirror I did not enjoy
The second pillar of this product is that you keep control. Everything that goes out, you approve with one click.
So look at my own approval queue on 20 August. Sixteen pieces made, ten of them still waiting, and nothing approved since 13 August. Five of those ten had already expired, because approval requests lapse after fourteen days on every route: mail, Slack, and inside the app while you are logged in.
The expiry page advised you to ask your team to submit the piece again. Nothing in the product could do that. No button, no route, no job. A dead end with a friendly sentence in front of it.
A product whose entire promise is that you decide has to make deciding possible on the worst day, not the good one. A separate UX review the same day found that approving inside the app cost more than approving from the mail: six waiting pieces meant twelve page switches. Both are rebuilt and live since 23 August, the resubmit button included. Reminders on day 10 and day 13 are still open.
A product whose entire promise is that you decide has to make deciding possible on the worst day, not the good one.
The bug that hits the pillar it should defend
Until 20 August, a Dutch customer was getting English work. The onboarding scan derives your market from your website, writes it into the brand profile, and that value quietly decides the writing language. Patrick's blog on 18 August and Katrina's LinkedIn post on 20 August came out fully in English.
That account is my own product, so the only person it embarrassed was me. On a paying customer it would have been pillar four, Dutch and findable in AI, broken in public.
My first diagnosis was that the scan overruled the market the customer had chosen. Wrong. The customer had never been able to choose anything: the field for it was a database default that nothing wrote and nothing read. One setting decided everything, and the customer could neither see it nor set it.
There is a language picker on the brand page now, with a test that pins the list in the app to the list in the worker. Three mutations were run against that test and all three failed, which is how you know a test is doing something. The production value was corrected from EN to NL the same day.
The scoreboard
| What | Where it stands |
|---|---|
| Paying customers | 0 |
| Cases | 0 |
| Email list (my own newsletter list, last scanned 30 June; the Ensemblo waiting list is separate) | 1 subscriber |
| Public pages live on ensemblo.nl | 13 |
| Pieces waiting for a decision on 20 August | 10 of 16, five of them expired |
| Payment confirmation after checkout | Ignored by the page. Open |
When I handle the five pieces that can still be decided, this system gets its first real ratio. The advice I wrote per piece says two approved, one change requested, two rejected. That is a prediction, not a result: nothing has been decided yet. If it holds, both rejections trace back to a bug rather than to the writing, the same five would score 80 percent approved without that bug, and the approval rate lands on 40 percent with it. My own plan calls a reject rate over 30 percent a product problem instead of a customer problem.
What the offer is, and what it is not
Fixed prices: 49, 149 and 349 euro a month. No credits, because in the Dutch mid-market credits are a sales blocker: nobody knows what they will end up paying. Founding deal is half price for the first three months plus an onboarding call with me, for anyone who starts before 31 October. Pay yearly and you pay ten months.
No cap and no seat counter. The waiting-list theatre stays off too. If sign-ups outrun what I can process, admission gets phased by order of sign-up, and that is an operational knob rather than a marketing promise.
Now the part that is not an offer. Sign up on ensemblo.nl today and you land on a waiting list in the mail tool. The app never hears about it. Turning that form into an actual door is the same decision as the date, and it sits with me.
What has to happen before the doors open, in order
- Decide on 25 August. If the answer is move, the public opening goes to 15 September and early September becomes a closed beta. That escape route was in the risk table before anyone needed it.
- Make the sign-up page a real door. Since 4 August the page already says plainly that Ensemblo opens in September and that what you get today is the free scan, so the honest copy is not the open part. The open part is the switch from waiting list to account.
- Fix the payment confirmation. Checkout sends you back with a parameter the page does not read, so you pay, see an unchanged dashboard, and find settings still claiming you have no subscription. That is an invitation to pay twice. The cancel route, of course, is handled perfectly.
- Decide the trial policy. Settings says free trial, checkout charges immediately, and one of those has to give.
- Verify iDEAL in the payment dashboard before the first Dutch payment runs through it.
- Get someone from outside into the product. Not because two tenants is the rule, but because the rule is a proxy for this.
The delay has a price, and it lands on the offer. The founding discount on the site ran "before 30 September", which was a 28 day window from 2 September and close to nothing from the end of the month. So the end date moves with the launch: the discount now runs to 31 October. That is the real cost of moving, and it is lower than the cost of opening a door I would not walk through myself. The FAQ covers how this way of working holds up day to day, the PlainConsent build log covers the product that got there first, and the team page covers my own 18 agents, the team that does the building.