What the programme actually is
I spend ninety days with a team building on Strapi, I commit nothing to their repository, I configure nothing on their behalf, and the entire value of the engagement is catching the decision that will be expensive in eighteen months while it's still a conversation.
I'm writing this because it's the part of the product nobody can evaluate before they buy it. You can read the docs for every feature. You cannot read what a person does. So here's the shape of it.
It starts when the contract does, and the target is to get you and your team onboarded inside ninety days. There's a kick-off call, then as many feature sessions and demos as the project actually warrants, then check-ins. The objective is that you reach something useful quickly and can then run the platform without me.
I should be honest about the ninety days, because it's the number on the tin and it's softer than it looks. It's the ideal window, not a shutter that comes down. Projects slip, go-live dates move, the person who was going to build it leaves. Much to my manager's mild irritation, I'm usually more flexible about the boundary than the programme description implies: if a team is three weeks past the window and about to make an expensive mistake, the useful thing to do is obvious.
The kick-off does three jobs
It's thirty minutes and it's the highest-leverage half hour in the engagement. Three things are supposed to come out of it.
One: you know how to get help, and what's expected of you when you ask for it. Unglamorous and probably the most valuable. By the end of the call your team is on the support portal, you know which channel carries which kind of problem, you know how to escalate and what escalating actually does. Just as importantly, you know what a support request needs to contain for it to move: version and patch state, what you expected, what happened, a reproduction if there is one. A well-formed ticket gets resolved in a fraction of the time a vague one does, and nobody tells customers this, so I do.
Two: I learn what you're actually building. Not the sales version of it, the specifics. Architecture, stack, integrations, who's writing the content, what's already built, what's fixed and what's still open.
Three: I tell you where I can help, and start giving best-practice guidance against what I just heard. Some of that is "here's the feature you haven't found". Quite a lot of it is "the thing you just described will hurt in a year, here's why".
The rest of the ninety days is downstream of that third one.
The questions I ask, and what I'm listening for
"What are you replacing, and why now?" I'm trying to find out whether the risk in this project is the migration or the model. A team escaping a legacy CMS has content shaped by a system they hated, and they will reproduce that shape unless somebody says so out loud.
"What's your go-live date, and what's fixed about it?" A date tied to a campaign, a contract or a conference behaves completely differently from a date someone wrote on a roadmap. It tells me how much of the ninety days is available for thinking versus how much is already spent.
"Who is actually going to build this?" Internal team, agency, system integrator, or the increasingly common all three. This changes who needs to be in every subsequent session, and it's where implementations quietly go wrong: the people in the kick-off are frequently not the people who will make the decisions.
"Who writes the content, how many of them are there, and in how many languages?" Editor count, locale count and workflow requirements between them determine most of the architecture. Locales especially: the difference between five and fifty isn't a configuration setting, it's a different design.
"Who owns the schema?" The question I most often get a pause on. In Strapi the content model is code in your repository, so this is a real governance question and not a philosophical one. No answer is itself the answer.
"Which of the paid features do you expect to use, and who asked for them?" "Who asked" is the operative half. A feature requested by a security reviewer is a gate on your launch. A feature someone saw on the pricing page is optional. These get treated identically on a project plan and they shouldn't be.
"What does your environment setup look like today?" Usually a short answer, and the short answer is usually "one". Worth knowing in week one rather than in go-live week.
"What does done look like?" Astonishing how often this produces disagreement between two people on the same call. Better to have it in week one, in front of me, than in month four in front of their stakeholders.
None of these are clever. Their value is entirely in being asked early, by someone with no stake in the answer being comfortable.
Then we run demos, and the demos are the actual work
The kick-off sets the direction. The sessions after it are where most of the value lands, and I push hard for teams to book more of them than they think they need.
The obvious ones are the Enterprise features you've just paid for: SSO, review workflows, audit logs, content history, releases. What matters here is that these are two different demos, not one. The developer session is configuration, environment behaviour and the gotchas: where SSO setup actually lives, why the callback URL is wrong, what audit log retention is configurable to. The content-editor session is a completely different conversation about how a review stage feels to the person moving an article through it, and what happens on the day someone publishes something they shouldn't have. Running one session for both audiences produces a call where half the room is lost and the other half is bored. It's the single most common thing I'd change about how teams use the engagement.
The less obvious ones are the bespoke sessions, and they're the ones I most enjoy and most under-advertise. If your team wants to walk through implementing a middleware, building a custom field, packaging something as a plugin rather than wiring it inline, or the shape of a specific integration, that's a session. We'll sit in the code together and work through how it should be built.
That last category is worth pulling out, because it's where the line sits between what I do and what I don't. I'm not going to write your integration. I will absolutely spend an hour with your developer on how it should be structured, which extension point is the right one, and why doing it as a plugin now saves an ugly merge in eighteen months. Guidance, in the room, against your actual problem, not a link to the docs.
What I won't do, and why
Some of this is policy and some of it is judgement, so I'll separate them.
The policy version: I don't do technical troubleshooting, that's support, a different team with different tooling and an actual SLA. I don't handle contracts, licensing or billing. And I don't build your project for you.
The judgement version of that last one is more interesting, and it's the one people push back on, usually politely, usually around week three when a deadline is close and it would be so much faster if I just did it.
It's partly that it doesn't scale, which is true and the least interesting reason. It's partly liability: if I build your content model and it's wrong in a year, we've created an argument neither of us wants.
But the real reason is that if I configure it, your team doesn't learn it. At some point I stop being on your calls, and you're left with a system nobody in the building understands and a dependency you didn't buy. The engagement is supposed to leave you self-sufficient. Quietly doing the work for you is the most reliable way to fail at that while looking helpful the entire time.
I'll go as deep into your project as you want, right down to the code, as long as your hands are on the keyboard.
What I do when a customer won't show me anything
This comes up more than you'd expect, and the reasons are usually good ones: regulated industry, air-gapped environment, an NDA that doesn't cover vendors, an agency that quite reasonably doesn't want the CMS vendor reading their client's repository.
The common assumption is that the choice is binary: hand over the codebase or get no help. It isn't, and the ladder of things you can do instead is longer than most teams realise:
- Share the schema, not the content. Your
schema.jsonfiles describe your model and contain none of your data. For a content-model review that's frequently sufficient on its own. - Build a sanitised reproduction. A minimal project that exhibits the behaviour, with your content replaced by nonsense.
- Generate a dataset at the same shape and scale. For anything performance-related this is usually better than your real data, because we can both run it.
- Logs only, from a sandbox, with query logging on. Slower, and it works.
- A live session where you drive and I watch. Nothing leaves your machine. This is the one I'd suggest first for most teams, and it's the one that occurs to people last.
When a team tells me they can't show me anything, what they usually mean is that they can't give me access. Those are different problems and only one of them is actually blocking.
Deciding whose problem it is
A significant part of the job is routing: is this a product defect, a configuration mistake, an architectural decision that's now expensive, or a case of asking the software to be something it isn't?
Roughly how I work it out. Can I reproduce it on a clean project at the same version? If yes, it's ours, and it goes to engineering with a reproduction attached. If not, what's different: configuration, data shape, scale, or code that isn't ours? Deep nesting and recursive relations account for a lot of the "it's slow" cases and almost none of them are bugs. And the version question comes before all of it, because a meaningful share of problems are ones already fixed several releases ago.
The failure mode I care most about avoiding is calling something a configuration problem when it's actually a defect. It's the comfortable answer, it closes the conversation and it puts the work on the customer, and when it's wrong it delays a fix for everyone else hitting the same thing. I've got this wrong. The correction is worth making loudly when you do.
The obvious objection
I work for the vendor. I have a commercial relationship with the outcome of every conversation in this post, and you should read everything I say with that in mind.
So, plainly: where I'm useful is that I've watched a lot of Strapi implementations and you're doing one. I know which decision shows up as a support ticket three months later, because I sat in the kick-off and then read the ticket. That pattern library is genuinely hard to get any other way, and it isn't in the documentation.
Where I'm not useful is that I will never tell you to buy something else, I'm not neutral about the product, and my view of your project is the view you choose to give me. If you want an assessment that includes "maybe don't use this CMS", you need someone who doesn't get paid by us.
Both of those things are true at the same time. I'd rather say so than have you discover it.
A for-rent technical lead who has seen this before
That's the most honest description of the role I've been able to come up with, and it's better than anything that would fit on a pricing page.
Not an architect, because I don't own your architecture and at some point I hand it back. Not a consultant, because I'm not billing you by the day and I'm not producing a deliverable. Not support, because I'm not fixing your incidents. What I am is a technical lead you've borrowed, who has no stake in your internal politics, who will say the unwelcome thing about your content model in week two, and who has seen this specific mistake enough times to know what it costs.
What separates the projects that get value from the ones that don't
After enough of these, the strongest predictor isn't team size, budget, or technical sophistication.
It's whether the person who will actually build the thing is in the kick-off. When the kick-off is attended by a project manager and an account sponsor, the advice is accurate, well-received, and reaches the developer as a summary, third-hand, two weeks later, without the reasoning. When the developer is in the room, they push back, we argue about it for ten minutes, and the decision holds.
Second: teams that treat the window as something to spend rather than something to receive. Most of the engagement past the kick-off is optional, and optional things get skipped by busy people, and the busiest teams are usually the ones who most need to stop and think about the content model. The teams that get the most out of me are the ones who book the awkward session: the one about the integration they haven't started, or the feature they suspect they've configured wrong.
Third, and least comfortable: the teams that got the most out of me are the ones who let me see the state of things rather than the presentation of it. That takes trust I haven't earned yet in week one, which is a genuine structural problem with the job and not one I've solved.
Teams that use the first ninety days to get the content model and the environment strategy right spend the following year shipping. Teams that skip it spend that year refactoring.
The one-line version
That's the whole product. The SLA is nice. The ninety days is worth more.