There's a well-known phenomenon in the design and development world: the cobbler's children have no shoes. The people who build things for others often neglect to build them for themselves.

I'm guilty of this. The version of my website that existed before this one was embarrassingly old. Not broken-old, just dated-old — the kind of dated that happens when you keep meaning to fix it and then a client project comes in and it moves to the back of the queue. Again.

So I rebuilt it. Here's what that was actually like.

The problem with building your own site

Building for clients is relatively straightforward. You have a brief, a scope, a timeline, and someone else's goals to design toward. The subjectivity is manageable because the client is the decision-maker.

Building for yourself is different. You are the client, which means you can change your mind at any point with no one to hold you accountable. You know too much about what's possible, which makes "good enough" feel like a compromise you're making with yourself. And you have to make decisions about your own brand and positioning — which turns out to be genuinely hard even if you do it for other people all day.

The first version I built was technically fine and I hated it within a week. The positioning was vague. The hero section was trying to be too clever. The whole thing felt like a portfolio piece rather than a business development tool.

I started over.

The decisions that actually mattered

Positioning. The hardest thing I had to decide was how to describe what I do and who I do it for. The tempting version is a broad net — "web design and development for businesses of all sizes." The accurate version is narrower and scarier to commit to.

I build custom web applications and websites for small businesses and growing companies. Mostly Laravel and the TALL stack. Mostly with clients who are non-technical and need a partner who can bridge the gap between business problem and technical solution. That's specific enough to be useful and narrow enough to attract the right people.

It took me longer to write that paragraph than most of the code.

Outcome-first copy. My first instinct was to write about what I build. Better instinct: write about what clients get. "Custom web applications" is about me. "A web presence that actually generates leads" is about them. I rewrote the homepage three times before I was happy with the balance.

What to cut. The temptation on your own site is to include everything — all the services, all the technologies, all the possible use cases. I had to remind myself of the same advice I give clients: pick the primary action and build around it. Everything that wasn't pointing toward "get in touch" got cut or de-emphasized.

The technical choices

I built on the TALL stack — Tailwind, Alpine, Laravel, Livewire. Which is what I'd recommend to most clients for this type of site, so it was also a practical test of the stack.

The blog runs on markdown files rather than a database-backed CMS for now. Simple, fast, no admin maintenance. When the post volume grows, I'll add a proper admin interface. Starting simple was the right call.

I obsessed over performance. Core Web Vitals scores are important for SEO and they're a credibility statement — it would be strange to advocate for performance and then ship a slow site. Optimizing images, minimizing JavaScript, getting the LCP score down to under a second. These things took time but they matter.

What I'd do differently

Start with the copy. I designed before I wrote, which meant the design had to flex to accommodate words I didn't know yet. If I did it again, I'd write every headline and body copy block first, then design around it.

Get outside eyes sooner. I sat with versions for too long trying to evaluate them myself. Showing an early draft to someone who didn't know my work would have given me feedback I was too close to see on my own.

Define "done" before I started. I kept the project in "ongoing refinement" mode too long. At some point the website needs to be live and working rather than perfect and in-progress. Shipping something solid and iterating is better than the perfect version that's always a few weeks away.

What it confirmed

Everything I tell clients about their websites is true for mine too.

The positioning work is the hardest and most important part. The copy matters more than the design. The site exists to drive a specific action, and every decision should support that. Simple is almost always better than complex.

The difference is I had to live these truths instead of just recommend them. That's probably good for me.

Take a look around and let me know what you think. And if you're ready to talk about what your website could be doing better, I'm easy to reach.