Methodology — Full Beard Solutions

You have built something, and now you need to decide what is next

Most businesses that have been running for a few years are running on software that has accumulated. Not one system, necessarily. A handful of tools, picked up at different moments to solve different problems, customized in places where the off-the-shelf version did not quite fit. A spreadsheet that nobody calls load-bearing but everyone treats as load-bearing. An integration set up by someone who has since left. A workflow that depends on three tools talking to each other through a fourth tool that nobody has looked at in eighteen months.

This is normal. It is how almost every small and mid-sized business actually runs. The accumulation is not a failure. It is the record of a business that has been doing real work and has made real decisions along the way about how to do it.

But there comes a point when the accumulation is making the next decision harder. The owner is being told to do something with AI and is not sure whether that means rebuilding everything, adding a layer to what they have, or ignoring the noise for another year. The key staff member who knows how the operational stack actually fits together is approaching retirement, and nobody has ever written down what they know. A vendor is sunsetting one of the tools, and replacing it will touch six other things. Software costs have crept past what they should be, and consolidating them would be smart, but nobody knows what would break.

In each of these situations, the next decision needs to be made against the truth of what is actually there. Not against what the owner remembers about the system. Not against what the staff describe when asked. Against the system itself, read carefully.

The methodology described here is the work of doing that reading.

When the methodology applies

There are three kinds of situations. The methodology applies to two of them.

Brownfield. A working operational reality already exists, and the question is what to do with it. Modernize it. Extend it. Replace a piece of it. Audit it before a major decision. The methodology applies directly. The work is reading what is there, surfacing what the reading reveals, and helping the owner decide what comes next.

Insertion. A new component is being built or bought, and it has to land inside an existing operational reality. The new thing is, in itself, greenfield — its requirements are still being worked out, its shape is still being decided. But the context it is landing in is not greenfield. It is whatever has accumulated already, and the new component has to fit. The methodology applies to the existing reality, not to the new component. You read the substrate so the new thing fits the business as it actually is, rather than fits a description of the business that is approximately right and wrong in the places that matter.

Greenfield. A genuinely new operation, with no prior operational reality to read. The methodology as described on this page does not apply — there is nothing accumulated to surface, and the requirements have to be discovered through interview because there is nothing else to read. Greenfield work is a different kind of engagement than the audit-led work the methodology describes, with a different rhythm and different deliverables, but the same standards apply: senior judgment, sustained attention, honest scope, durable documentation. If you are starting something new, the closing of this page applies to you the same as anyone else.

If you are not sure which of these you are, you are probably in one of the first two. Greenfield is rarer than it sounds. Most "new" projects are insertions, and insertions need the methodology more than the people commissioning them usually realize.

The cycle

The methodology is a cycle. The audit produces a substrate — a structured reading of the operational reality. The substrate produces reports, each a different lens on the same picture. The reports inform decisions. Each decision points the work in one of five directions — fix what is broken, modernize what you have, migrate to off-the-shelf software, rebuild on a different foundation, or build something adjacent — and the work that follows flows back into the substrate. The system changes. The substrate refreshes against it. The cycle continues.

This shape matters because the relationship between a business and its operational software is not a transaction. It is not a project with a beginning and an end. It is a continuous practice. The technology around the business keeps evolving. The business itself keeps evolving. Keeping them in alignment requires attention that does not stop after a deliverable ships. Most small and mid-sized businesses do not have the internal capability to maintain that practice. The methodology provides it from outside, in a form structured for the long run.

The audit, in five stages

The audit is the part of the methodology that produces the picture. It runs in five stages, in order, because each stage depends on the substrate the prior stages have built.

1. Read the system. Whatever the system can describe about itself becomes the foundation everything else reads from.

Every operational system has a self-description, even if nobody has ever asked it for one. A custom database has a schema, scripts, relationships, layouts. An off-the-shelf SaaS has a configured workspace, automations, integrations to other tools, fields and views and permissions that have been arranged over time. A stack assembled from multiple tools has all of those, distributed across the tools, plus the connective tissue that holds them together — the Zapier flows, the scheduled exports, the shared spreadsheets that act as the seam between systems.

The first stage gathers all of this into one place. For a single system, this means parsing the system's structural metadata directly. For an assembled stack, this means reading each tool's self-description and stitching them together — what fields exist in this tool, what automations move data between these two tools, what the calendar of scheduled jobs actually contains.

The substrate that this produces is the foundation. It is also where the methodology is honest about its limits. The substrate includes what the systems can describe about themselves, plus whatever surrounding code, configuration, and integration is accessible. It does not include what the systems cannot describe — knowledge held only in the heads of the staff who use them, processes that happen entirely outside the software, edge cases that are handled by hand once a quarter without being documented. The substrate is necessary but not sufficient. What it does not contain is what later stages have to surface through other means.

2. Pattern analysis. The substrate gets read with exhaustive coverage. Every script, every automation, every field, every connection — all of it receives the same attention.

The patterns that emerge from a careful reading include outdated approaches that were appropriate when they were written and have since fallen out of best practice; undocumented indirection where the system depends on something not visible from the surface; hardcoded logic that may or may not still serve a purpose; missing observability in places where it would catch problems early; and workflow complexity that the structure of the code reveals before the people who use it have to articulate it.

The role of AI in this stage is worth being precise about, because the language around AI in consulting has become loose. AI is not finding things in the substrate that a senior practitioner could not find with enough time. A human practitioner, given unlimited hours, could read every script, every automation, every field, and recognize the same patterns. What AI provides is the economic possibility of looking at everything within an engagement budget that a client can actually afford. Without it, the practitioner has to sample, prioritize, and accept that the analysis will be incomplete. With it, the practitioner can ask what is in the entire system and get a real answer back, fast enough to be useful and exhaustive enough to be trustworthy. The judgment about what the patterns mean is still the practitioner's. What changed is that coverage no longer has to be sacrificed to fit the engagement.

This is a smaller claim than AI-in-consulting marketing usually makes. It is also the true one. The methodology does not depend on AI being smarter than a senior practitioner. It depends on AI being faster, applied with discipline, grounded in source material the practitioner can verify.

3. Workflow tree. A complete map of what the system does — not just what it contains — gets built from the patterns the second stage has surfaced.

The static structure of the system is one half of the picture. The other half is what the system actually does — how scripts call other scripts, what triggers fire on what events, what workflows execute when a user clicks a particular button or when a scheduled job runs at three in the morning. The workflow tree produces a complete map of behavior, not just contents.

The workflow tree is where the operational complexity becomes visible. A system can have a clean structure and complex workflows; a system can have messy structure and simple workflows; the relationship is not predictable from the surface. The workflows are also where the friction the system creates for the people who use it tends to live. A workflow that requires three context switches between screens to complete a single sales order is a workflow that the staff will work around if they can, will complain about constantly if they cannot, and will probably break in subtle ways during the workarounds. The workflow tree surfaces these conditions structurally, before the people involved have to articulate them.

4. Focused questions. Short, specific questions go to the people who use the system. Not "tell us what you do." Specific questions, generated by the substrate, that the substrate cannot answer on its own.

With the structural picture and the workflow map in hand, the methodology turns to the people who use the system. Not to ask them to describe what they do — which is what most discovery processes do, and which produces vague, incomplete, sometimes wrong answers — but to ask short, specific questions where the substrate is not enough.

The questions are not "tell me about your business" or "walk me through how you process an order." They are "we see this automation that has not fired in what appears to be at least three years, but it is still active — is that intentional, do you know what it is for, can we safely retire it?" The substrate has produced the question. Only the human can produce the answer.

This stage is also where the human dimensions of the work surface. The owner of a system is not a neutral evaluator of evidence about their own system. They are often the system's builder, its champion, the person whose career or business is intertwined with it. The questions, and the conversations they produce, have to be conducted with that awareness. The methodology is not trying to catch anyone out. It is trying to fill in what the analysis cannot reach without help, and to do so in a way that respects what the people involved have built.

5. Reports, one substrate. From everything above, the methodology produces reports — three lenses on the same picture, designed to be read together.

The first report is the state of the system. What is actually there. What is working. What is degraded. What is at risk. Where the complexity sits. What is fragile and what is durable. This report sometimes contains findings the client did not ask for and may not want to hear. A system that feels fine to its operators can be sitting on debt that will make the next round of change twice as expensive as the last. A system that has run smoothly for years can be one staff retirement away from being undocumented and unmaintainable. The methodology produces these findings whether the client asked for them or not, because not producing them would be malpractice. The report respects the client's autonomy to disagree, defer, or accept the risk — but the findings exist on the page, in evidence, for the decision to be made openly.

The second report is what the system tells you about your business. The system is a record of decisions about how the business actually runs, accumulated over the years. The freight calculation that handles seven different exception cases is a record of the business's actual freight policy, which may or may not match what anyone would describe if asked. The credit-hold logic that fires under certain conditions is a record of how the business has actually handled customer credit risk over time. The report surfaces what the system has materialized as business logic. It also surfaces what the system does not tell you that it could — places where adding observability or extending what the system captures would produce real business intelligence that is currently invisible.

The third report is what the path forward looks like. Three directions, described in concrete terms: keep developing what you have, migrate to off-the-shelf software designed for your situation, or rebuild on a different foundation. The methodology does not recommend a direction. It describes what each path would entail — what would be preserved, what would be lost, what the work would actually require, where the risks sit, what the order of operations would be. The recommendation is the client's. The evidence supporting whichever recommendation is what the report provides.

These reports come out of one substrate. They are different lenses on the same picture. A client who reads only the state-of-the-system report has answers to one set of questions. Reading all three answers a much larger set. The reports are designed to compose.

The continuing work

The audit produces the substrate. What happens next is the work the practice and the client do together with it.

The default opening posture is triage. Most operational systems, when read carefully, have a small number of things that are actively causing pain — bugs firing, integrations failing, workarounds that have ossified into the daily rhythm of the business. These get addressed first. The triage is surgical, not transformative. It is short. The point is to stop the bleeding so that the rest of the work can proceed against a stable foundation.

Triage is the default opening, not a universal rule. Some engagements start somewhere else. A business that wants to add a new component to an existing setup — the insertion case — may begin with the specification of the new component rather than with triage of the old one, if the old one is not actively in distress. A business being audited before a sale may receive the substrate and the reports as the entire engagement, with no work that follows on the practice's side. The methodology adapts. The triage-first default is the most common starting point, not the only one.

After triage, the work is decision-by-decision. The reports surface what the system tells the business about itself, what is at risk, what is possible. The client decides what to do with that picture. If the decision is to keep developing what they have, the substrate produces the specification for the changes — step by step, with estimates calibrated against the actual complexity of what is being changed. If the decision is to modernize, the substrate produces the modernization plan with the same character. If the decision is to migrate to off-the-shelf software designed for the situation, the substrate becomes the inventory the migration works against, so nothing has to be re-discovered through interview. If the decision is to rebuild on a different foundation, the substrate produces the rebuild specification. If the decision is to build something adjacent to the existing setup, the substrate produces the design for the new component, with the existing reality as a constraint the design has to satisfy. Each decision produces its own document. Each document is grounded in the substrate.

The work that follows the document can be done by the practice, or by the client's internal team, or by another firm the client chooses. The practice does the work when the work fits the practice's scope; the practice writes the specification regardless, so the work is doable by whoever does it. The deliverable is honest enough to be implementable by a competent practitioner who was not the one who wrote it.

As the system changes, the substrate updates. The substrate is not a snapshot the audit produced and then froze. It is a living record that refreshes as the system evolves. When a change is made, the substrate reflects it. When a new component is added, the substrate grows to include it. When the system is re-read against a fresh export, the analysis produces a diff that shows what has changed, what has been fixed, what has drifted, and how far the system has come.

Observation is continuous. The system's own logs are part of the substrate, and where the system has insufficient logging the practice can install what is needed. But automated observation is only part of it. The practice reads the logs. The practice collects feedback from the users who actually run the system day to day. The reading and the feedback together are what make the substrate trustworthy as a current picture of how the system is actually being used, not just how it is structured.

The relationship is open-ended. The default is that the practice and the client continue working together as long as the work is useful — through fixes, through new components, through modernization decisions, through eventual rebuilds, through whatever the operational reality requires next. The rhythm of engagement varies. Sometimes the work is intensive. Sometimes it is a quarterly substrate refresh and a short conversation about what has changed. The cycle does not have a fixed end. The substrate stays current. The decisions the client makes today are made against a system that has just been read, not against memory.

After decisions are made

The same substrate that produced the audit produces the work that follows. Whatever the decision was — keep developing what you have, extend it with something new, migrate to a different foundation — the work proceeds against a known system, with the documentation and the workflow maps and the report archive already in place to inform every change.

What this means in practice is that estimates are real. The work has been read carefully enough to know what it will cost, and the cost reflects the actual complexity of what is being changed, not a guess against a description of the system. The changes that look small are confirmed small. The changes that look small but are entangled with something else show up entangled before the work begins.

For a client extending an existing setup with something new — what the audit framing called the insertion case — the substrate does additional work. The new component is designed to fit what is actually there, with the existing reality as a constraint the design has to satisfy, rather than as a surprise the new component discovers mid-build.

For a client migrating to a different foundation, the substrate becomes the inventory the implementation team works against. Nothing has to be re-discovered through interview; the source operational reality is already documented. The migration's risk is the work, not the discovery.

What the methodology is honest about

A methodology that does not name its own limits is a methodology that has not been tested seriously. The places this one strains are worth naming.

The substrate is bounded by what the systems can describe about themselves. Spreadsheets used as databases. Browser automations running on individual workstations. Knowledge held only by individual staff members. Processes that happen entirely outside the software. These are visible only through the focused-questions stage, and only if the questions surface them. The methodology surfaces what it can. It does not always find everything.

The pattern analysis is bounded by the patterns the practitioner can recognize. AI extends the coverage; experience extends the recognition. A pattern that has not been encountered before may not be flagged. The methodology improves with each engagement, but at any moment it carries the limits of what has been seen.

The focused questions are only as good as the answers. Clients sometimes do not know what they do not know. A workflow described as standard may be a personal workaround that one staff member developed. A process described as well-established may have been failing intermittently for years. The methodology surfaces these conditions when it can. It cannot always tell, in the moment, whether the answer is correct.

The methodology is also bounded by what the practice can absorb. Some operational realities are too large or too complex for a single engagement at a senior-practitioner-led scope. When that condition appears, the methodology adapts — through staged engagement scopes, prioritized analysis, honest conversation about what can be accomplished in what time. It does not pretend every situation is tractable in the same way.

What the methodology produces

A clear picture of the operational reality, in a form the client owns, designed to serve whatever decisions the client faces.

A living record of institutional knowledge that updates as the systems update.

Reports — on the state of the system, on what the system tells about the business, and on what the paths forward would entail.

Executable next steps with honest estimates, in whatever direction the client chooses.

A continuing analytical capability that lets the work of the past inform the work of the future.

These are the outputs. The methodology is the work that produces them. The work serves the decision, whichever decision the evidence supports.

If you are running an operation on something that matters, you deserve a clearer picture than memory can provide. I would like to hear about it.

↑ Back to the top