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 three reports, each a different lens on the same picture. The reports inform decisions. The decisions feed a longer arc of work — document, fix, observe, modernize, and only when forced to, rebuild. The work changes the system. The system gets re-read. The substrate updates. 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. Three reports, one substrate. From everything above, the methodology produces three 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 three 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 longer arc

The audit produces the picture. The longer arc is what happens when the picture is put to work. It is also where the continuous-attention framing becomes concrete, because the longer arc is not a phase that runs once. It is the operational rhythm of the relationship between the business and its software, sustained over time.

The sequence below is well-understood in the field of system modernization and confirmed in practice with every system the practice has worked with directly.

1. Document what is there. The institutional knowledge gets captured in a living form that updates as the system updates.

The institutional knowledge that the substrate and the audit have surfaced gets captured in a living form. The documentation that the methodology produces — every script, every workflow, every integration described in human-readable form — becomes the record of the system that has, in most cases, never existed before. It is not a one-time deliverable. It updates as the system updates. It survives any change of practitioner, platform, or direction. The documentation work is where the longest-term value of the engagement is established, because documentation that survives is what makes every subsequent decision possible.

2. Fix what is broken. Stabilize the system. Surgical, not transformative.

Bugs that are actively causing pain get fixed. Hardcoded credentials get rotated. Failed integrations get repaired or removed. Workflows that consistently fail get repaired. The point is not transformation; the point is to stop the bleeding so subsequent work can proceed against a system that is documented and stable. This stage is often shorter than people expect, because most of these are not actively broken in many places — they are working, with accumulated debt around the edges. The fixes are surgical.

3. Restore observability. Selective, careful logging at the points where the business actually needs to see what is happening.

Most systems have less observability than they should. Logging is sparse or absent for workflows that matter. Important business events happen and leave no trace. Adding observability — selective, careful logging at the points where the business actually needs to see what is happening — is preparation for the decisions that may follow. You cannot evaluate a workflow you cannot observe. The methodology installs the observation where it is needed, against the substrate and workflow map the audit has produced.

4. Modernize incrementally. Where modernization is warranted, against the picture the earlier stages have produced.

With the system stable, documented, and observable, the question of modernization becomes tractable. Some of what looked like debt during the audit may not actually warrant modernization — it may be intentional indirection, or it may serve a business purpose the surface did not reveal. Some may be straightforward to modernize incrementally. Some may require larger changes that are now possible because the earlier stages have produced the picture and the documentation that modernization always required and rarely had.

5. Rebuild only when forced to. And only after the earlier work has done its work.

Rebuilding a working business system is sometimes the right answer. Almost never as the first move. The reason is structural: a rebuild forces a translation of institutional knowledge that has, by definition, never been fully translated before. The system is the documentation. The workflows are the specification. The edge cases that have been quietly handled for years are the actual product. A rebuild that has not first surfaced what is actually there is a rebuild that will discover what is actually there during the migration, which is the most expensive possible time to discover it.

The earlier stages, done well, change the rebuild question. The system being considered for rebuild is no longer the same system. The debt that made rebuilding seem urgent has been at least partially paid down. The institutional knowledge has been documented. The rebuild, if it happens, has something to rebuild from rather than starting from interview-derived approximations. The decision becomes less urgent. It also becomes more honest. The client is choosing whether to rebuild a known system, not whether to rebuild a system they have just discovered, mid-migration, was more than they bargained for.

The cycle continues

The substrate is not produced once. It is re-read against fresh exports of the system — six months later, a year later, three years later. The diff against prior runs shows what has changed: what has been fixed, what has drifted, what new patterns have emerged, what old issues have receded.

This is what continuous attention looks like in operation. The picture stays current. The documentation stays current. The reports get refreshed against present reality. The decisions the client makes today are made against a system that has just been read, not against an audit that aged for years in a drawer.

The diff capability is a service the practice offers, not an artifact the client owns. The tooling that produces the substrate is the practice's intellectual property. The output of that tooling — the structured documentation, the workflow maps, the report archive — is the client's. The diff is what the tooling produces when applied to a fresh export and compared against the prior run. It is available as long as the engagement continues.

This structure is the honest one. The artifacts the client owns are durable. They survive any change of practitioner. The analytical capability is a continuing service that depends on the practice. Clients who want both — durable documentation and ongoing analysis — engage continuously. Clients who want only the durable documentation can have that, and walk away with everything they need.

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.

Three 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