Building One Technical Identity Across Two Sites

Eldritch IT ended up needing two websites because one site was being asked to do two different jobs.

The business site needed to explain services, establish trust, and give a potential client a clear next step. Field Notes needed room for long technical articles, experiments, failures, opinions, and the kind of detailed reasoning that would make a service page miserable to navigate.

Splitting them solved the content problem. It created a brand problem.

If the sites looked and sounded unrelated, the separation would feel accidental. If they were identical, there would have been little reason to separate them at all.

The useful lesson was not really about running two websites. It was about deciding which parts of an identity should stay consistent and which parts should be allowed to change with the job.

I separated purpose before design

The first useful distinction was not visual. It was functional.

The business site needs to answer a short set of questions quickly:

• What does Eldritch IT do?
• Who is the work for?
• What kinds of problems fit?
• What should someone do next?

Field Notes answers a different set:

• What have I built?
• What failed?
• How did I reason through it?
• What did the work change about my process?
• What would I do differently next time?

That difference sounds obvious after it is written down, but it is easy to ignore during a build. A business homepage can slowly become a technical blog with pricing attached. A technical journal can slowly turn into a collection of sales pages wearing Markdown.

I wanted neither.

So the business site became concise, outcome-focused, and deliberately shallow in navigation. Field Notes could support categories, series, search, related posts, long guides, and the occasional article that exists because I learned something worth preserving rather than because it maps cleanly to a service.

Purpose came first. Layout followed it.

I needed a routing rule for content, not just two URLs

The original version of this article explained the purpose split, but it did not answer the practical question that comes up every time I write something new:

Which site owns this?

Without a routing rule, the two-site model can drift back into duplication. A useful technical idea gets summarized on the business site, then copied into Field Notes, then edited in one place but not the other. Eventually the sites disagree about the same subject.

I now think about content ownership like this:

Content type	Primary home	Why
Service definition	Business site	It explains what a client can buy and what outcome the service is meant to produce
Process summary	Business site	A potential client needs the operating model without reading a long technical essay
Pricing, engagement terms, contact path	Business site	These belong to the commercial decision
Detailed implementation guide	Field Notes	The reader needs depth, context, commands, architecture, and caveats
Failure analysis / troubleshooting lesson	Field Notes	The value is in the reasoning and evidence, not the sales message
Architecture decision record	Field Notes	The tradeoffs deserve enough space to explain the choice honestly
Proof behind a service claim	Field Notes, linked from business site when useful	The business page makes the claim; the article can show the thinking behind it
Announcement that changes what clients can buy	Business site first	The commercial source of truth should change before supporting editorial material
Editorial lesson that happens to relate to a service	Field Notes	Relevance to the business does not automatically turn an article into marketing

That table prevents one of the easiest mistakes in a two-site setup: publishing the same responsibility twice.

If the business site says what I offer, it owns that statement.

If Field Notes explains why I work a certain way, it owns that reasoning.

The sites can reference each other without both becoming authoritative for the same fact.

When something belongs on both sites, the jobs still need to be different

Some subjects genuinely touch both properties.

Documentation is a good example.

On the business site, the useful message might be that documented support is part of the service model. A visitor should be able to understand the benefit quickly: clearer ownership, easier handoff, fewer mysteries later.

On Field Notes, the useful article can go much deeper into what I document, why I separate public and private records, how validation evidence gets preserved, or why a recovery procedure is not complete until it has been tested.

Those are not duplicate pages.

They are two different layers:

Business site: What the practice means for the client
Field Notes:   How the practice works and what I learned from using it

That distinction is much easier to maintain than trying to keep two versions of the same paragraph synchronized.

The shared identity is smaller than the shared website

I initially thought consistency meant reusing a lot of the same interface. That turned out to be the wrong level of abstraction.

The sites do not need the same page structure. They need the same recognizable decisions underneath it.

For Eldritch IT, that shared layer includes:

• a consistent visual palette;
• related typography and spacing;
• direct, practical language;
• the willingness to show the work instead of hiding behind claims;
• repeated visual motifs without cloning whole layouts;
• clear links between the business and editorial sides;
• the same standards for privacy, accuracy, and disclosure.

Those anchors do more for identity than copying a hero section from one site to another.

A visitor should be able to move from a service page to a Field Notes article and feel that the same operating philosophy is behind both, even though the page is serving a different purpose.

That philosophy is the same one I described in Order from Complexity as an Operating Standard. The brand becomes more credible when the visual language, writing, technical process, and client-facing promises all point toward the same idea.

The shared identity can fit on one small specification

The more useful version of a brand guide for these two sites is not a giant design document.

It is a small set of decisions that should survive implementation changes.

A practical version looks like this:

Shared rule	Business site expression	Field Notes expression
Core visual language	Strong brand recognition, restrained layout, clear calls to action	Same palette and motifs, optimized for long-form reading
Tone	Concise, outcome-focused, plain language	Direct and practical, with room for uncertainty, failure, and deeper reasoning
Claims	Only claims I can support and explain	Evidence, tradeoffs, and lessons behind those claims
Privacy	No unnecessary operational or client detail	Same rule, even when technical depth increases
Accuracy	Commercial facts must stay current	Technical claims should distinguish observed evidence, reconstruction, and current documentation
Disclosure	Clear about what the service is and is not	Clear about AI assistance, sanitized examples, and unresolved outcomes where relevant
Cross-linking	Link to depth when it helps a buyer evaluate the work	Link to the business only when it gives the reader a genuinely useful next step

That is enough to keep the identity recognizable without forcing the sites into the same layout or content model.

The important distinction is between shared standards and shared components.

Shared standards should be stable.

Shared components are optional.

The first versions were more generic than I realized

Generated layouts helped me move quickly. They also introduced a problem that is easy to miss when a site first starts looking polished.

Some sections could have belonged to almost any technology company.

There were oversized claims, decorative metrics, vague trust language, and blocks that looked complete because the template expected them to exist. The problem was not that any one component looked bad. The problem was that the page could look professional without becoming more specific.

That is dangerous for a small technical business because specificity is a large part of the trust signal.

I started removing claims I could not support, replacing broad marketing language with concrete descriptions, and deleting sections whose main job was to make the page feel full. The result was less theatrical and more believable.

The same standard carried into Field Notes.

An article does not become better because it has more headings, diagrams, callout boxes, or words. A guide should be long when the subject requires depth. A lesson should be short when the lesson is simple. Visual structure should help the reader understand the material, not help the page impersonate completeness.

That is also why I have become more aggressive about the draft backlog itself. A Backlog Is Not Finished Until the Ideas Are Distinct came out of the same realization: quantity is not a useful editorial goal if several drafts are trying to say the same thing.

Evidence connects the sites better than branding does

A logo can tell someone that two properties are related. Evidence can tell them why that relationship matters.

The business site can say that Eldritch IT values documentation, controlled changes, recoverability, and clear ownership. Field Notes can show those ideas being applied to real technical reasoning.

That connection is much stronger than repeating the same tagline in two headers.

A service claim such as “documented support” is easy to write. A body of articles showing how I think about recovery, evidence, public documentation, validation, and troubleshooting gives the claim weight.

The journal therefore has a business function without needing to become a sales funnel.

Its job is not to turn every article into a pitch. Its job is to make the underlying work visible enough that the reader can judge it.

That distinction matters to me. I would rather have the business site make the offer and Field Notes provide the evidence than make every technical article end with a forced call to action.

Evidence also has to remain honest about where it came from

The relationship between the sites gets weaker, not stronger, if Field Notes becomes a machine for manufacturing proof after the fact.

If I preserved a real configuration fragment, log, screenshot, benchmark, test result, or troubleshooting sequence and it is safe to publish, that can support a strong article.

If I did not preserve the original evidence, I would rather publish a clearly labeled sanitized reconstruction than create a clean-looking transcript and imply it is historical evidence.

That matters to the business identity too.

A company that promises disciplined technical work should not need embellished case studies to look competent.

The standards on the evidence site have to be at least as strict as the claims on the business site.

Privacy has to be part of the shared identity too

A technical journal creates a specific branding temptation: publish enough detail to prove the work is real.

That can go too far.

The details that make an article technically useful are not always the same details that identify the environment where the lesson was learned. Real hostnames, addresses, account identifiers, internal paths, management URLs, customer names, ticket numbers, and screenshots full of operational metadata rarely make the reasoning clearer.

They often only make the publication riskier.

I use the boundary described in What Goes in Public Documentation, and What Stays Private: preserve the technical relationship, the failure mode, the decision, and the lesson. Generalize the identifiers that are not necessary to understand them.

That privacy standard belongs to both sites. A business site should not expose more operational detail simply because it is shorter, and a technical article should not get a pass simply because detail feels authentic.

Trust includes knowing what not to publish.

Separate sites create separate maintenance work

The split is not free.

Navigation, footer links, metadata, accessibility, privacy language, analytics decisions, visual changes, and cross-site references now have two implementations. A branding change can drift if it is updated in one place and forgotten in the other.

That makes memory a poor synchronization mechanism.

The solution is not to force the sites back into one codebase or one layout. It is to treat the shared identity as a small specification.

I also separate shared standards from site-specific state.

The shared specification can record:

• core colors and their intended roles;
• typography choices;
• logo treatment;
• tone and terminology;
• privacy and disclosure rules;
• cross-link behavior;
• what each site is responsible for explaining.

The individual sites still own their own:

• navigation structure;
• metadata implementation;
• build/deployment configuration;
• analytics configuration;
• accessibility implementation details;
• content taxonomy;
• page components;
• calls to action.

That boundary matters because synchronization should be intentional.

I do not want a visual tweak to the business site to create an obligation to rebuild the article layout. I do want a change to a core brand color, disclosure standard, or company terminology to trigger a review of both properties.

I use a small cross-site maintenance check

Two sites create drift slowly.

Nothing has to break dramatically. One footer gets updated. One privacy statement changes. One tagline is revised. One link points to an old page. Six months later, the properties still look related but no longer tell exactly the same story.

A lightweight review is enough:

Check	Question
Identity	Are the core brand name, tagline, visual language, and terminology still aligned?
Ownership	Is each commercial fact authoritative on the business site and each technical article authoritative on Field Notes?
Links	Do cross-site links still solve a reader need and point to the current destination?
Claims	Does the business site make any claim that the editorial evidence no longer supports?
Privacy	Are both properties still following the same disclosure and sanitization standard?
Metadata	Are titles, descriptions, canonical domains, and social metadata still correct for each property?
Accessibility	Did a shared visual change create a contrast, focus, or reading problem on either site?
Drift	Did one site adopt a new term, visual rule, or policy that belongs in the shared specification?

That is enough to catch the expensive kind of inconsistency: not a few pixels of difference, but two properties gradually developing different rules about what Eldritch IT is.

Cross-linking should have a reason

Running two sites makes it easy to overdo cross-linking.

A business page does not need to link to every article, and an article does not need to remind the reader that services exist every few paragraphs.

The link should solve a reader problem.

If a service page makes a technical claim, a relevant Field Notes article can provide depth. If an article touches a problem that maps directly to a service, a restrained link can give the reader somewhere useful to go next. If neither condition is true, the sites do not need to force a connection.

The same rule applies inside Field Notes. I cross-link when another article develops an idea that would otherwise require repeating several paragraphs. Good internal links extend the argument. Bad ones interrupt it.

I also avoid using cross-links to create fake authority.

A Field Notes article should not be linked from a service page merely because it shares a keyword. The article should actually help a reader evaluate the claim, process, or technical approach on that page.

The brand became clearer when I removed things

A lot of branding advice focuses on addition: more assets, more components, more messaging, more channels.

My experience has been almost the opposite.

The identity became clearer when I removed generic claims, unnecessary sections, duplicate ideas, unsupported numbers, and decorative complexity. The remaining pieces had more room to mean something.

That is probably the most Eldritch lesson in the whole project.

Order did not come from making both sites match. It came from deciding what each one owned, documenting what they shared, and removing the parts that did not serve either job.

What I would do differently

I would define the role of each site and the shared brand rules before building either layout.

That would have reduced duplicated experiments and made it easier to reject components that did not serve the correct audience. It also would have made the relationship between the sites easier to explain from the beginning.

I would define the content-routing rule at the same time.

Knowing which site owns services, commercial facts, long technical reasoning, evidence, and editorial lessons is more useful than deciding where a particular paragraph happens to look better.

I would also treat cross-site maintenance as a real operational concern much earlier. Two properties mean two places for metadata, accessibility, privacy language, navigation, and identity to drift. A short written specification is cheaper than rediscovering those decisions every time something changes.

The two-site structure works because the sites are allowed to be different.

The identity works because those differences sit on top of the same standards and the same body of work.

The cleanest version of the architecture is simple:

The business site makes the offer. Field Notes shows the work. The shared standards make both recognizably Eldritch IT.

Consolidation note: This retained article now includes the distinct operational material from the earlier Field Note that covered the same reader intent.

Why a .me domain made sense

I considered making the publication a section of the main site. Technically, a /blog route or subdomain would have worked and cost less.

But eldritchit.me communicates the distinction immediately.

The .com is the company.

The .me is the work from my perspective.

It gives the writing enough independence to sound like a person. I can be honest about uncertainty, mistakes, half-finished projects, and lessons learned without making the service website feel unfocused.

The two sites still share a logo, colors, and overall identity. Field Notes is not a second brand. It is a publication from Eldritch IT with a different purpose.

A home for work that does not fit a sales page

A surprising amount of useful technical work does not belong on a company website.

A post about recovering a damaged Windows installation might demonstrate real experience, but it would be awkward between a managed-support page and a contact form. The same is true for notes about UniFi VLANs, Docker storage, game-server troubleshooting, or internal tooling.

Those projects matter because they show the process behind the result.

They also give me a reason to document work while it is fresh. A lesson that feels obvious today is difficult to reconstruct six months later. Writing forces me to explain what happened, what I assumed, and what actually fixed the problem.

That documentation is useful even if nobody else reads it. Publishing makes it available to the next person who runs into the same issue.

AI transparency

AI assisted with organizing and editing the original article and with constructing the explicit content-routing matrix, shared-identity specification, and cross-site maintenance check in the September 14, 2026 revision. The two-site structure, design changes, editorial decisions, and branding conclusions come from building and revising the Eldritch IT sites.