On technical language, objectivity, and the responsibility of a senior software provider.
Get concise advice on choosing the right CMS, understanding migration costs, and avoiding expensive implementation mistakes before they become roadmap problems.
No spam. Unsubscribe anytime.
On technical language, objectivity, and the responsibility of a senior software provider.
A few weeks ago, I found myself in a familiar situation.
We were taking an existing frontend prototype and turning it into a production website. The design was already there. The components existed. The client was working toward a launch, and several developers were involved in the implementation.
Then a technical question emerged.
Should we keep the existing CSS, or rewrite the components using Tailwind?
It sounds like a perfectly ordinary engineering decision. And it is.
But it also exposed something I think we underestimate in client work: how easily technical preferences can become business decisions without the client fully understanding what they are agreeing to.
Imagine sitting in a meeting with two developers.
One says:
"We should use Tailwind. It's the modern, standard approach, and it will make the codebase more maintainable."
The other says:
"We should preserve the existing styling. Rewriting everything introduces unnecessary work and risks breaking the design."
Both statements can sound reasonable.
Both can also be misleading.
The first associates a particular technology with modernity and maintainability. The second associates changing technology with waste and risk.
Neither statement tells the client what they actually need to know.
How much work is involved? What problems exist in the current implementation? Which problems would the proposed change solve? Does the change affect the launch date? What happens if we do nothing? What happens six months later?
Terms such as best practice, modern, clean, scalable, and technical debt carry considerable persuasive weight.
They aren't necessarily wrong. But without context, they can substitute for an explanation.
A client who cannot independently evaluate the underlying engineering arguments may reasonably interpret "this is the industry standard" as "this is what we need to do."
That's a significant amount of influence to exercise with a few words.
In this particular project, the existing prototype already had an established styling system.
The question wasn't whether Tailwind was good or bad. The project already used Tailwind in some capacity.
The actual decision concerned how much existing styling should be converted, when that work should happen, and whether it should become a prerequisite for launch.
Those are very different questions.
A developer might prefer working with utility classes because they are familiar, productive, and consistent with their usual workflow.
Another developer might prefer keeping the existing CSS because it preserves the design and avoids an immediate conversion.
Both preferences are legitimate.
But neither is sufficient justification for asking the client to spend money or accept additional delivery risk.
The client's business objective wasn't to have a website written entirely in Tailwind.
The objective was to launch a functioning website that preserved the approved design, supported the required content workflows, and could be maintained after delivery.
That distinction changes the conversation.
Instead of asking, "Which styling approach should we use?"
We can ask:
"What work is necessary to deliver the website, what improvements are worth making now, and what can safely happen afterward?"
The technology becomes a means to an outcome rather than the outcome itself.
There is an uncomfortable part of this conversation that applies to me as much as anyone else.
I had my own preferred implementation approach.
I wanted to preserve the existing design and styling during the initial integration, connect the components to the CMS, and then improve selected components incrementally.
I believed that would protect delivery momentum.
But believing an approach is appropriate doesn't make my explanation objective.
I could easily have described a full Tailwind conversion as an unnecessary rewrite, expensive duplication, or premature optimization.
Those phrases would strengthen my argument.
They would also risk exaggerating the disadvantages of the alternative.
A full conversion could have genuine benefits. It might simplify the development team's workflow, reduce inconsistencies in certain parts of the codebase, and make future contributions easier for developers who already work primarily with Tailwind.
Likewise, retaining existing CSS isn't free of consequences. It can preserve complexity, inconsistent conventions, and maintenance problems that deserve attention.
The challenge is to acknowledge those possibilities even when they weaken your preferred argument.
Objectivity doesn't mean pretending you have no opinion. It means separating the evidence, the assumptions, and your professional recommendation.
You can say what you would do.
You should also be able to explain what would make you change your mind.
Technical discussions have a tendency to become binary.
Rewrite or retain.
Replace or keep.
Modernize or accept technical debt.
But many implementation decisions are not binary. They are sequencing decisions.
In our case, I proposed three phases.
First, bring the existing components into the production application without changing their visual presentation.
Second, connect them to the CMS so the website becomes functional.
Third, improve the implementation, including the styling architecture and selected interactive components.
This follows the preserve-first, vertical-integration sequence I detail in How to Take Over a Frontend: A 4-Step Production Framework and Vertical Slices: Stop Starting From Scratch. When you evaluate when CSS Modules help versus utility-first CSS, scoping changes to discrete, data-connected features keeps momentum high.
This made it possible to discuss the styling decision independently from the work needed to connect the website.
It also created an opportunity for the client's internal development team to contribute without duplicating work already underway.
The advantage wasn't that we had somehow discovered a universally superior CSS architecture.
It was that we had separated work that needed to happen now from work whose timing still needed to be justified.
There are circumstances where a full rewrite is the right choice. If the existing implementation is fundamentally unsuitable, preserving it may simply postpone an expensive problem.
But that needs to be demonstrated, not assumed.
And if we can deliver the required functionality while improving the architecture incrementally, we should evaluate that option too.
A recommendation doesn't exist in isolation.
The same architecture decision can be appropriate for one client and inappropriate for another.
A company launching a new product in six months has different constraints from a company trying to replace a vulnerable legacy website before an approaching deadline.
A team of experienced frontend developers has different needs from a marketing department that depends on external providers for implementation.
A business that expects to maintain a system for ten years may reasonably invest more in its foundations than one building a temporary campaign.
In our project, the client had an existing design, an active development team, a new CMS foundation, and a launch to coordinate.
A full styling conversion might improve the codebase, but it would also consume implementation capacity and require visual verification.
Leaving every styling issue untouched might protect the immediate timeline, but it could transfer avoidable problems to the people maintaining the website later.
My responsibility was to consider both.
A senior provider shouldn't simply ask, "What is the technically preferable solution?"
They should also ask, "What is the technically responsible solution given this client's current situation?"
As discussed in Technical Leadership Is More Than Having the Answer, technical depth is only valuable when translated into business constraints. And When Helping Creates More Work explores what happens when teams push premature code without shared clarity.
Those questions can produce different answers.
When a non-technical decision-maker asks for your recommendation, they are delegating part of the analysis, not surrendering ownership of the decision.
You don't need to teach them every detail of CSS architecture.
You do need to explain the consequences in terms they can evaluate.
For example:
| Option | What the client needs to understand |
|---|
The table doesn't make the decision.
It makes the trade-offs visible.
It is also important to be transparent about commercial implications.
If my recommendation creates additional billable work for me, that is relevant.
If my preferred approach reduces the work I personally need to do but transfers more responsibility to the client's internal team, that is relevant too.
A recommendation that ignores those interests isn't necessarily dishonest, but it is incomplete.
Getting agreement in a meeting isn't proof that the decision was well understood.
A client may agree because the explanation sounded convincing, because several developers appeared aligned, or because they trusted the person presenting the recommendation.
That trust creates a responsibility to make the decision clear enough to revisit.
What did we decide? Why? What assumptions were we making? What risks did we accept? What would cause us to reconsider?
These questions matter because circumstances change.
A deadline can move. A dependency can disappear. A prototype can reveal unexpected complexity. Another developer can uncover a better implementation.
Changing direction in response to new evidence isn't necessarily indecision.
It's part of responsible engineering.
The important thing is that the change follows an explicit reassessment rather than whichever argument was most persuasive in the latest meeting.
The longer I work with clients, the more I think the distinction between a developer and a senior technical provider lies partly in the decisions they help other people make.
Writing good code and choosing appropriate tools matters.
Understanding architecture, performance, and maintainability matters.
But none of those skills automatically makes someone good at advising a business.
That requires understanding what the client is trying to accomplish, recognizing the constraints they are operating under, and being willing to recommend an approach that might not be your personal preference.
Sometimes that means challenging the client's assumptions.
Sometimes it means challenging another developer's recommendation.
And sometimes it means questioning your own enthusiasm for a technically interesting solution.
The client hired you to help them achieve an outcome, not to give you an opportunity to build your preferred architecture.
Explore related perspectives on technical consulting, frontend migration, and architectural strategy:
If your organization is evaluating frontend frameworks or planning a CMS transition, learn more about my CMS Architecture Review advisory and B2B Website Strategy guidance.
| Convert the existing styling now | What specific improvements it delivers, what additional work it requires, and how visual fidelity and delivery will be verified. |
| Retain the existing styling | What can be delivered sooner, which existing limitations remain, and how those limitations affect future maintenance. |
| Convert incrementally | Which improvements happen before launch, which happen afterward, and how responsibility for the remaining work is handled. |
