Put the right things first, and everything downstream gets safer, clearer, easier to change, and more cost-effective to grow.

AI. Audience and Accessibility. Data and Content. Design and UX. Findability and Search. Goals and Requirements. Scope and Standards. Safety and Security.

Focus on Firsts

Every provider talks about what they can build. Fewer talk clearly about what must come first. Or, what it even means for this or that to be "First".

The order of decisions shapes the quality, usability, maintainability, portability, and cost of everything that follows.

And yet, that said, First, is not just about the sequence of pending steps. More often than not, it's also about what comes Conceptually First. Or, what "firsts" or "foundationals" should always be considered throughout every implementation and care phase. In fact, Conceptually First often trumps "Sequentially First" in weighing importance, sequence, priorities, severities, and more.

“Client First.” “Data First.” “AI First.” “Design First.” Some of these ideas are useful. Some are marketing hype. We focus on the ones that actually elevate quality, improve delivery, reduce waste, protect future options, and make your projects easier to live with after launch.

Not Every “First” Gets Built First

Modern digital work is full of “First” language. Some of it is helpful. Some of it is a slogan looking for a budget.

“Client First” matters, but that does not mean saying yes to chaos.

“AI First” can be wise in the right workflow, and expensive nonsense in the wrong one.

“Design First” can clarify a project beautifully, or outrun content, accessibility, scope, and maintainability.

When we say "First", we don't mean ideology alone, and we certainly don't mean just in terms of sequence. We mean prioritized implementation decisions with conceptual and practical consequences that are shaped by whatever it actually means to be "AI First" or "Data First", etc.

Sometimes, a "First" really will get built before other requirements are implemented. For example, this often happens in "Data First" commitments, when creating custom databases. Since everything that needs to live within the database won't have anywhere to go until your new and shiny "Data First" database is actually built, that build really does happen among the first steps.

Other times, a "First" is revisited again and again even up to the very end of the project, when nothing really feels first anymore. Continuing with the "Data First" example, we'll often make data-centric decisions about specialized publishing interfaces that only get added near the end of a project. For example, a companion mobile app that only gets meat on the bone after the website is already live, the AI Web Assistant has been servicing end user requests for several weeks, and multiple other deliverables are also already in play. These are still "Data First" decisions; they just happen to be far from the first things we're implementing.

The Firsts We Use to Strategic Advantage and Distinction

So, what does it mean to actually be "First" in this sense? And how does being a "First" in this sense affect our actual practice?

AI First
When products, strategies, and workflows are built around AI capabilities, so that AI can naturally and in-process participate in design and implementation (and even care), we begin to see the true benefits of "AI First". Add RAG, Custom AI Skills, regression loops, etc, to the production process itself (rather than just to specified deliverables), and the "AI First" strategy deepens. Rather than bolting on AI experiences to existing processes (especially when all we're doing is asking our favorite robot for a summary or an idea), "AI First" implementations turn certain aspects of production over to AI, thereby promoting the humans in the mix to a supervisory role of sorts. AI graduates from being a fun new tool that helps us check what we're doing anyway, into a new member of our multispecies team.
Data First
Granular data models address high performance retrieval, caching, and output with flexible storage schemas that allow the same content to be served across multiple presentation surfaces. This approach also allows redesigns to occur, even at high frequency, with little or no rebuilding of data or application infrastructures. While there is nothing about this sort of strategy that requires one form of reporting or another, it is certainly the case that detailed reporting that even allows for trending and forecasting, all become easier. This level of attention to the way in which data are constituted, stored, retried, cached, etc, is "Data First".
API First
Often seen as part of "Data First", or, at very least, a companion strategy that depends upon "Data First", building around expected API queryability is especially valuable when a project must support multiple channels, future front ends, integrations, or automation layers. Your "Data First" project is also "API First" when all the careful planning that has gone into your data modeling is also accounting for external and cross-interest use of your data via API programming techniques.
Design First
As soon as a project is found to require customization that cannot be provided by a cookie-cutter template that spawns a full project simply by filling out a form or two, the challenge of how to communicate what is to be delivered shows itself in all it's enormity. Design then becomes a powerful internal communication tool, rather than just a means to a deliverable end product. And when used in this way, as long as designs are refreshed and updated as appropriate throughout the lifecycle of the project, we have a "Design First" experience that can clarify hierarchies, user journeys, interaction flows, and much more.

There are many other "Firsts" that folks sometimes talk about. In our experience, the above are especially worth calling out as strategic commitments because they are not inherently required by any minimalist implementation or care plan. They are simply great strategic ideas that make everything better when done right.

The Firsts That You Have the Right to Expect

Some "Firsts" are real strategic commitments that change the way we work. Some cost extra. Some actually reduce costs.

And, regrettably, some are hype. Some providers know the value of the "Firsts" language, and are not shy about seeking benefit for themselves in using this terminology to excite and recruit you, even if the "Firsts" they are pitching should really be there always, regardless of strategic packaging.

We usually try very hard not to cast aspersions upon other concepts or strategies, even if they appear suspect or trivial to us. But this is one of those few unique cases in which we have a hard time keeping sharper opinions to ourselves. We see buyers and stakeholders pitched on basic requirements as though they are special "First" strategies, when in fact they are not. Rather, some of these "Firsts" are nothing more than the basics that should be included in any project, or every project, dressed up with fancy wordage that is designed to add competitive value where perhaps there just isn't enough true value:

Goals First. Well, yes, we should know what success looks like before building any machinery, and then hoping that what we build delights stakeholders... But isn't this the basic job that is needed in every buildout?
Audience First. Same as "Goals First", albeit with a slightly more human-centric focus. So, yes, by all means, define who the work must serve before build or delivery... But, again, isn't this the basic job that is needed in every buildout?
Scope First. Clear boundaries protect budgets, schedules, relationships, and sanity. We say this a lot. We say it so much that we cannot regard it as optional or special in any way. Probably not a strategic "First", as much as a basic aspect of every buildout.
Standards First. Standards reduce total cost of ownership, improve portability, and help keep projects supportable by more than one provider. We say this a lot too. And here again, this is neither optional nor special in any way, so probably not a strategic "First", as much as a basic aspect of every buildout.
Security First. We've actually seen this "First" claimed as a significant and differentiating strategy, because "a feature that creates avoidable risk is not a real win". This is not really a strategic "First", as it should really be basic business-as-usual thinking, and it is fully and completely accounted for when we build with standards (also something that should not require any special strategic commitments, as it should always be there).
Accessibility First. Not a strategic "First", and fully accounted for within a combination of "Goals First", "Audience First", and "Standards First", which should also all be there even without any special strategic commitment. And if building with a "Design First" doctrine (which actually a genuine strategic commitment), this would be covered there as well.
Client First. Yet another faux "First". Understanding client goals, constraints, obligations, users, and commercial realities clearly enough to recommend what actually helps, should not be a special additional or differentiating strategy.

There is one more "First" that some providers pretend is some sort of brilliant strategic thought: "Search First" (or "Findability Search"). Like all of the above non-First "Firsts", this one should really be included in most projects as a feature (whether core or addon), rather than a standout special strategic commitment. But this is not always the case, and there is at least one common reason that actually sets this case apart from the other non-Firsts in an often interesting way: Compatibility. Or, more precisely, incompatibility. When systems are built of multiple components that come from multiple origins, incompatibilities between them can introduce limitations at the systemic level. Search is often one of the biggest manifestations of this issue because it tends to span multiple subsystems (the same, therefore, applies to any feature that must leverage search to work well).

We won't get on people's cases when referring to any of the above as "Firsts" in a casual way. We simply see the need to point out that all of these are deliverable commitments that you should really have the right to expect in any project, even if no real "Firsts" strategic commitment has been undertaken.

Different Projects, Different Firsts

The right firsts change with the nature of the work. The disciplines do not disappear. The priorities shift.

In AI

Quality baseline first. Guardrails first. Prompt framework first. Knowledge flow first. Then scale.

In Coaching

Orientation first. Action plans first. Resource packs first. Progress review first. Then expansion.

In DO/IT

Access control first. Release discipline first. Backup and recovery first. Logging first. Recovery readiness first. Then optimization.

In Marketing

Audience first. Offer framing first. Asset and access clarity first. Then campaign motion.

In Product Management

Goals first. Success metrics first. Requirements first. Queue and roadmap first. Then acceleration.

In Web

Accessibility first. Search first. Security first. Analytics first. Design system first. Performance first. Then extensions, enhancements, and superchargers.

And because real projects are multi-disciplinary, the right firsts often borrow from more than one Area of Interest. That is normal. Good projects do not care much about org charts.

What Comes First Changes as the Project Matures

In discovery, the firsts are goals, audience, constraints, dependencies, and scope.

In implementation, the firsts become standards, structure, accessibility, design discipline, security, content or data modeling, and guardrails where AI is involved.

At launch, the firsts shift again: release readiness, performance, logging, backups, rollback confidence, and communication clarity.

In ongoing care, the firsts become tested updates, regression checks, reporting, compatibility, vendor or model review, and the disciplines that keep the work reliable instead of merely alive.

Good providers know how to change priorities without losing the plot.

The Payoff Is Not Philosophical

Putting the right things first changes outcomes.

You get less rework.
Cleaner scoping.
More stable launches.
Better handoffs.
Stronger portability.
Better user adoption.
More trustworthy AI behavior.
Easier future enhancements.
Fewer expensive surprises.
Lower total cost of ownership over time.

This is not abstract. It is what happens when projects are built in the right order instead of in whatever order happened to win the loudest meeting.

Related Commitments

The right firsts do not stand alone. They connect directly to the rest of our future-proof posture.

If you care about standards, you should also care about portability.
If you care about reliability, you should also care about continuity.
If you care about AI, you should also care about governance, searchability, and supportability.

That is why this page belongs beside the others in this cluster, not in place of them.

Let’s Decide What Belongs First

If your team is juggling competing priorities, unclear requirements, shiny tools, legacy constraints, and pressure to move quickly, that is normal.

It is also exactly where bad build order creates expensive downstream pain.

Bring us the pile.

We will help you determine what truly belongs first, what belongs later, and what never belonged on the list in the first place.