Any CMS, any stack: how we start when the brief is messy

Start with the user job and the running system. The language is a detail.

Start with the job

Start with the user job and the running system. The language is a detail. A messy brief often arrives as a list of technologies, old vendors, half-known problems, and nervous deadlines. That is normal. We do not need perfect documentation before we can be useful. We need to know what people are trying to do and what currently stops them.

Avoits starts there. Who uses the system. What action matters. What breaks when that action fails. Then we open the site, repo, CMS, plugin list, hosting panel, or admin screen and let the real system teach us. Skill-first work means reading the situation before selling a stack opinion.

The stack is evidence, not identity

Some teams introduce a project by saying it is Laravel, WordPress, Shopify, React, Django, or something older nobody wants to name. That matters. It is not the whole story. A clean WordPress build may be easier to extend than a custom app with hidden business logic. A modern JavaScript app may be fragile if nobody owns deploys. An old PHP tool may be boring and dependable.

We treat the stack as evidence. It tells us where risk may live, what skills should join, and how fast change can happen. It does not decide the business answer by itself.

What we ask first

We read before we rename

A messy brief often tempts people to tidy language too early. The team may call one thing a portal, platform, dashboard, app, plugin, or integration depending on who is speaking. We do not correct that on day one. We listen for the work underneath the words.

If the sales team says portal and operations says spreadsheet, both may be right. The customer sees one entry point. Staff finish the job in a sheet. The build has to respect both truths before changing either one.

Renaming too early can also erase useful disagreement. If finance and support use different words, the product may need to show both or help the company choose one. That choice belongs in scope, not in a rushed database field. The language people use is a map of responsibility.

The running system tells the truth

Documentation helps, but the running system is louder. We look at the production path, the admin path, and the failure path. We test the form. We follow the checkout. We inspect the content model. We check the deployment story. We look for logs, backups, queues, cron jobs, and the quiet integrations that nobody mentioned in the first call.

This is the same practical habit behind choosing a partner for any stack. A studio that can move across systems still has to respect the one in front of it.

We also ask what the system does when nobody is watching. Imports, email jobs, subscription renewals, scheduled posts, nightly exports, cache clears, and failed webhooks often carry more risk than the visible page. A messy brief rarely names those jobs. Production does.

A first pass we can stand behind

1. Name the user job in one plain sentence.
2. List the live systems involved in that job.
3. Confirm access to code, hosting, CMS, domains, and logs.
4. Run the key path as a user and as an admin.
5. Record what is stable, fragile, unknown, and blocked.
6. Find recent changes that may explain the current pain.
7. Separate urgent repair from longer improvement.
8. Choose whether the first move is a fix, spike, audit, or scoped release.
9. Write the risks in business language.
10. Agree what success looks like for the next week.

Unknown code needs a spike

When a repo is a mystery, we do not sell certainty. We sell a short learning step. A spike may answer whether the app can run locally, where the payment logic lives, why the CMS is slow, how deploys work, or whether a plugin can be extended cleanly.

The point is not to admire the code. The point is to turn unknowns into decisions. After a spike, we can say repair this, replace that, leave this alone, or scope a first release. That is cleaner than giving a fixed number on a system nobody has opened.

A good spike has a finish line. We do not wander through the codebase for sport. We pick the question that blocks the next decision and answer it with evidence. If the question is deployment, we inspect deployment. If the question is checkout risk, we follow checkout. That keeps discovery useful and affordable.

Messy does not mean bad

Many useful systems look messy because they have survived real use. They carry old campaigns, staff workarounds, abandoned plugins, emergency fixes, and integrations added under pressure. Some of that should go. Some of it contains business knowledge.

We are careful not to delete context in the name of cleanliness. A strange field may support a finance export. A hidden page may serve a partner. An old cron job may keep stock in sync. We learn before we cut.

The best first improvement may be boring. Document deploy. Remove one dead integration. Fix form delivery. Add a backup test. Give editors a safe field. Those moves do not look dramatic, but they reduce the cost of every later decision. Messy systems often need ownership before architecture.

Where our service lines meet

A messy brief may start anywhere on our services. It may need web and ecommerce, software and platforms, cloud infrastructure, automation, or support and growth. The service label matters less than the skill mix.

If the system is public-facing and content-heavy, web craft leads. If the core pain is workflow, software engineering leads. If the failure is uptime, deploy, or monitoring, cloud skills lead. If the team is drowning in repeat work, automation may lead. Avoits stays practical about that mix.

What this means if you talk to us

You do not need a polished brief to start. Bring the current system, the job that matters, and the failure you want gone. Bring the access you have and the access you do not have. Bring the awkward history. We can work with that.

We may begin with a call, a short audit, or a spike. We may point you to how we work as a studio before we quote. The first useful output is clarity: what is happening, what is risky, what can be fixed now, and what deserves a proper build.