There's a saying that the cobbler's kids have no shoes. For web developers, the equivalent is having no website of your own. I didn't want to be that guy. So when I started Orlov Digital, one of the first things I did was build my own site from scratch.
Not with WordPress. Not with Squarespace. Not with a template I found online. I wrote every line of code myself using PHP and Tailwind CSS. And I want to walk you through why I made that choice, what went right, what went wrong, and what I learned along the way.
Why I Chose to Hand-Code It
I build websites for a living. If I can't build my own, why would anyone trust me to build theirs? That was the starting point. But beyond proving a point, there were real practical reasons.
Speed was the big one. A hand-coded site doesn't carry the weight of a CMS, a database, a theme engine, and 30 plugins all loading at once. When someone visits orlovdigital.com, the server sends the files and that's it. No database queries. No plugin overhead. The page just loads.
Control was the other reason. I wanted to decide exactly what goes on every page, exactly how it looks, exactly how it performs. With a template or a page builder, you're always working within someone else's constraints. You want to move a section? Hope the builder lets you. You want to optimize an image? Hope the theme doesn't override it. I didn't want to fight the tools. I wanted the tools to be invisible.
And then there's bloat. Most WordPress themes ship with features you'll never use. Sliders you don't want. JavaScript libraries for animations you turned off. CSS for layouts you'll never build. All of that code still loads. It still slows things down. My site only loads what it actually needs.
The Technical Decisions
Every website involves hundreds of small choices. Here are the ones I thought about the most.
Self-Hosted Fonts
Most sites load their fonts from Google Fonts. It's convenient. You add one line of code and you get access to hundreds of typefaces. But every time your site loads, it makes a request to Google's servers. That's an extra network round-trip that slows down the page. And it means Google gets data about every visitor to your site.
I downloaded the Inter font files and host them directly on my server. Five font files, different weights, all in the modern woff2 format. No external requests. No tracking. Faster load times. It took maybe 20 minutes to set up, and it was worth every one of them.
Compiled CSS
I use Tailwind CSS for styling. A lot of developers use the Tailwind CDN, which means the browser downloads the entire Tailwind library (it's big) and then figures out which styles your page actually needs. It works for prototyping, but it's slow for production.
Instead, I set up a build process. When I finish editing, I run a command that scans my PHP files, finds every Tailwind class I actually used, and generates a tiny CSS file with only those styles. The result is a CSS file that's a fraction of the size. It loads almost instantly.
The Contact Form
This is where I probably spent more time than I should have. I didn't just want a form that sends an email. I wanted a form that works properly. That means AJAX submission (no page reload when you hit send), honeypot spam protection (a hidden field that tricks bots), CSRF tokens (so only real visitors can submit), rate limiting (5 submissions per IP every 15 minutes), and server-side validation on every field.
I used PHPMailer with Gmail SMTP for delivery, with a fallback from port 587 to port 465 if the first connection fails. Overkill for a contact form? Maybe. But I know it works. I know spam bots aren't getting through. And when a real customer reaches out, I get that message every single time.
The Mistakes
Here's where it gets honest. Because I definitely did not get everything right on the first try.
The LCP Problem
LCP stands for Largest Contentful Paint. It's a metric Google uses to measure how quickly the main content of your page becomes visible. On my site, the hero section (the big headline you see first) was waiting for JavaScript to load before it became visible. That's because I had a "reveal" animation that fades content in as you scroll. The hero section was set to be invisible by default, waiting for the JS to trigger the fade-in.
The fix was simple but I didn't catch it right away: I added an inline CSS override that makes the hero content visible immediately, before the JavaScript even loads. The rest of the page still has the scroll animations, but the first thing you see is instant. That one change bumped my mobile performance score significantly.
Contrast Issues
I designed the site with a dark theme. Dark backgrounds, light text. Looks great. But "looks great" doesn't mean "readable by everyone." I ran accessibility tests and found that some of my text colors didn't have enough contrast against the background to meet WCAG AA standards. That's the accessibility guideline that ensures people with visual impairments can read your content.
The fix was straightforward. I swapped my muted gray text from one shade to a slightly lighter one. It's a subtle difference visually, but it brought every piece of text on the site into compliance. My accessibility score went to a perfect 100.
The Favicon Saga
This one still makes me shake my head. I designed a clean SVG favicon (the little icon in the browser tab) with a gradient "O" on a dark background. It looked perfect in Chrome. Then I tested it in Safari, and it was broken. Turns out my SVG was importing a font from Google Fonts, which doesn't work in the favicon context. I had to switch to a local font stack. Then the ICO fallback version (for older browsers) had transparency issues that made it look wrong on certain backgrounds. It took more iterations than I'd like to admit for something that's 16 pixels wide.
The Results
After all the fixing and optimizing, here's where the site landed on Google Lighthouse (the tool Google provides to measure website quality):
- Performance: 93 on mobile, 98 on desktop
- Accessibility: 100
- Best Practices: 100
- SEO: 100
I'm proud of those numbers. But I want to be honest about something: they didn't start there. The first time I ran Lighthouse, the performance score was lower, the accessibility score flagged issues, and there were best practice warnings I hadn't thought about. Getting to those scores was a process of testing, finding problems, fixing them, and testing again.
What I Actually Learned
Building my own site taught me more than any client project has. When it's your own business on the line, you care about every detail differently. You test things you'd normally skip. You question decisions you'd normally just ship.
The biggest lesson: no website is perfect on day one. Not mine. Not yours. Not anyone's. It's a living thing that you improve over time. The important thing is having something out there, something that represents your business, something potential customers can find.
The second lesson: the fundamentals matter more than the fancy stuff. I could have spent weeks adding parallax effects and animated backgrounds. Instead, I spent that time on font loading, image optimization, contrast ratios, and form security. Nobody notices those things. But everybody notices when a site is slow, hard to read, or broken.
Should You Build Your Own?
If you're a business owner reading this, probably not. And I say that as someone who builds websites for a living. Your time is better spent running your business. But you should care about the things I've described here. Whoever builds your site should be thinking about performance, accessibility, security, and speed. Not just making it look pretty.
If you want to see what a hand-built, properly optimized site looks like, you're on one right now. And if you want one for your business, let's talk.