The portal as first principle.

Every consulting practice has a default order of operations for new engagements. The standard order — discovery call, scope document, quote, contract, kickoff, slowly-improving status updates — puts the operator's process first and the client's experience last. The reversed order — provision a portal, send the link, then have the conversation — puts the client's experience first and shapes the operator's process around it.

I run the reversed order. Every engagement starts with a portal already provisioned by the time the first conversation happens. Most consultants find this strange. The few clients who notice find it disarming.

The default order

Picture the standard onboarding flow at a typical consulting firm. The prospect makes contact. There's a discovery call. The firm writes a scope document. The scope document becomes a proposal. The proposal becomes a quote. The quote, after some negotiation, becomes a signed contract. A kickoff meeting is scheduled. Slack channels and shared folders are created in the firm's tools. Status updates come via email, batched into Friday weekly reports. Hours are tracked in the firm's project management system, visible to the firm. Invoices are generated monthly, also from the firm's system, and emailed as PDFs.

By the time the client has anything tangible representing the engagement, the contract has been signed and a meeting has happened. The infrastructure, such as it is, lives in the firm's tools. The client's view of the work is whatever the firm chooses to expose, in whatever format the firm finds convenient.

This is the default because it is the path of least resistance for the firm. It is also what produces the slow, opaque consulting experience that most buyers have come to expect — and to dislike.

The reversed order

The reversed order looks like this. The prospect submits an intake message. I read it. If it's a good fit, the next thing they receive is not a discovery-call link or a proposal — it's a portal URL with their account already provisioned, a welcome message in the conversations thread, and a view of the workspace where the engagement will run.

The discovery call happens, but it happens inside the portal context. We're already on the same surface. There is something to look at together. The conversation is not abstract — it is grounded in the actual environment where the work will run.

The contract follows the conversation, not the other way around. By then the prospect has already seen what the engagement infrastructure looks like, how their data will be partitioned, how hours and invoices will surface, what the conversations panel feels like to use. The contract is a confirmation of something they have already touched, not a leap of faith based on a sales pitch.

What gets provisioned on day zero

The portal that exists on day zero, before any contract:

• An account on the client portal we build with a partitioned workspace for this prospect's data.
• An empty conversations thread, with one welcome message from me describing what to expect from the engagement.
• A subscription tier slot — either selected by the prospect during intake or marked "TBD pending conversation."
• An empty hours log, ready to start filling once work begins.
• An empty invoice list.
• A view of the milestones that the engagement will track, populated from the intake brief.
• An audit log that has captured exactly when the workspace was provisioned, what plan was assigned, who created it, and what data shape exists.

Provisioning takes about ninety seconds, run by Polaris from the intake form on the public site. By the time the prospect's email is in my inbox, their portal exists. The welcome message is queued and ready to send. The first conversation has somewhere to happen.

Why the order matters

The portal is not a productivity tool. It is a trust mechanism.

Trust requires verification. Verification requires visibility. Visibility requires infrastructure that exists outside of the operator's word. Without the portal, "trust" reduces to "take my word for it" — which is the structural definition of the thing trust is supposed to replace.

The portal is first principle because trust is first principle. You build trust by making the work visible. You make the work visible by building the infrastructure first.

Provisioning before the contract is also a small but significant signal of capability. It says: I have the engineering chops to run this kind of infrastructure. It says: I am not going to send you weekly status emails from a Gmail account; I have built a place for the work to live. Most prospects do not consciously process this. All of them feel it. The signal lands as this person seems prepared, which is the right first impression for the kind of work I want to do.

Why other consultants don't do this

Three reasons.

Building the portal is real engineering work. Most consulting practices, especially the smaller ones, do not have the engineering capacity to build and run client-facing infrastructure. They use email, spreadsheets, off-the-shelf project management tools, and curated PDF reports. The infrastructure work is "someday" — usually never.

Off-the-shelf doesn't fit. Generic tools — ClickUp, Asana, Notion, the rest — solve the operator's project-management problem, not the client's visibility problem. They are built for internal team coordination, not for cross-organizational transparency. Repurposing them for client-facing use produces a friction-filled experience that exposes the seams of the underlying tool.

The path of least resistance pulls the other way. Sending a status email is faster than building a dashboard. Generating a quote in Google Docs is faster than building a pricing surface. The path that produces a worse client experience is also the path that takes less time today, and most operators take that path repeatedly until "we'll build the portal eventually" becomes "we never built the portal."

The infrastructure investment is real. It is also the difference between a consulting practice that scales on continuity and one that scales on capacity. (See capacity versus continuity for the structural argument behind that distinction.)

What buyers should ask

If you are evaluating a consulting practice, the test question is simple:

Will I have a workspace I can log into during this engagement, or will I be receiving emails?

If the answer is "you'll get weekly status updates," you are buying capacity work with no visibility infrastructure. That can be fine if the work is short, transactional, and well-scoped. It is genuinely insufficient for any engagement where you need to understand what's happening to your money, your codebase, or your customers in real time.

If the answer is "yes, you'll have a portal where every change is visible, every hour is logged, and every invoice surfaces in real time" — and the operator can show it to you before you sign — that is a different category of practice. It is also the practice you should hire for any engagement where the cost of opacity is more than the cost of building the infrastructure.

The closing argument

Most consulting starts with a sales process and ends with infrastructure. The reversed order starts with infrastructure and ends, occasionally, with a sales conversation that is no longer adversarial because the thing being sold is already partially in the buyer's hands.

The portal is first principle because the work that follows is built on top of it. You cannot retrofit transparency onto a relationship that started in opacity. You can build a relationship that started in transparency and let it deepen over years, until the portal is just the surface of a much larger shared context.

Every engagement I take on inherits the portal on day zero. It is the foundation. Everything else — the contract, the conversations, the work itself — sits on top of it. The order is not optional. The order is the practice.

— Mikkel, Bangkok