← Field Notes
Published Last updated 4 min read

Building the First Version of EldritchIT.com

Why I stopped chasing a perfect business website and launched a focused version I could improve with real feedback.

In this article
  1. What the first site needed to do
  2. The temptation to look bigger
  3. Publishing created better questions
  4. Separating the business from the writing
  5. Key takeaways
  6. What I would do differently
  7. AI transparency

The first version of EldritchIT.com did not need to be impressive.

It needed to exist.

That sounds obvious, but it took me longer than it should have to accept. When a website represents a business with your name attached to it, every decision starts to feel permanent. The colors need another pass. The services need better wording. The About page needs to sound confident without pretending the company is larger than it is.

It is easy to spend weeks polishing a site nobody can visit.

Eventually I decided that an imperfect live website was more valuable than a perfect mockup sitting on my computer.

What the first site needed to do

I kept the initial goal narrow. Someone landing on the site needed to understand four things:

  1. What Eldritch IT is.
  2. What kinds of problems it solves.
  3. Where it operates.
  4. How to get in touch.

That led to a straightforward structure: an overview, services, process, information about the company, and a contact path.

The service list focused on work I actually wanted to perform—network design and implementation, managed support, Wi-Fi planning, documentation, monitoring, and related add-ons such as cabling and cameras.

I also wanted the site to feel like Eldritch IT rather than a generic managed-service-provider template. That became the dark obsidian and steel palette, cyan accents, and the phrase Order from Complexity.

Those choices came directly from the kind of company I wanted to build, not from a theme’s default copy.

The temptation to look bigger

Many small-business websites are written to sound like large organizations. They use “we” everywhere, show stock photos of teams that do not exist, and describe capabilities so broadly that the reader cannot tell what the company actually does.

I did not want that.

Eldritch IT is being built intentionally small. The site needed to communicate professionalism without pretending I had an office full of technicians waiting for calls.

That balance was harder than the technical build. I wanted a visitor to see a legitimate business, but also an honest one.

Publishing created better questions

Once the first version was online, it became much easier to improve.

I added clearer service descriptions, San Antonio location details, client-facing process information, contact options, analytics, and a client portal path. I refined the language as the business model became clearer. Each revision answered a real question instead of an imaginary one.

That is the biggest advantage of publishing early: real use gives you better feedback than endless private tweaking.

Separating the business from the writing

The site eventually had another problem: the business information and the technical story behind it were competing for space.

I bought eldritchit.me and gave it a different job. EldritchIT.com remains the business website. It handles services, contact information, and the practical question of whether Eldritch IT can help a client.

Field Notes is for the work behind the business: projects, experiments, problems, lessons, and the process of building the company itself. Giving the publication its own domain lets each site serve one audience clearly.

Key takeaways

  • A first business site needs a clear job, not every possible feature.
  • Honest scope is more credible than copy that makes a small company sound artificially large.
  • Publishing turns vague design worries into specific questions that can be improved.
  • The business site and technical publication work better with separate audiences.

What I would do differently

I would spend less time trying to predict the final version.

The services, language, and visual design were always going to evolve as the company did. I also would have separated the technical publication sooner instead of asking one site to serve clients and readers equally well.

Most importantly, I would remind myself that launching is not the end of the design process. It is the beginning of the useful part.

AI transparency

AI assisted with portions of the site’s copy, layout experimentation, and later editing. I reviewed and changed the output, removed design choices that did not fit, and made the final decisions about the business, services, branding, and structure described here.

JO

Written by

Jessie Owens

I run Eldritch IT and write about the systems, repairs, infrastructure decisions, and business lessons behind the work.