I spent years building things at scale. Platforms used by millions of people, systems that couldn't go down, codebases maintained by dozens of developers across multiple teams. The kind of environments where a bad deploy on a Tuesday afternoon ruins everyone's week.
Now I build websites for small businesses. Five pages. Ten pages. A contact form and a blog.
People sometimes ask if that feels like a step down. It doesn't. It feels like bringing a sharper set of tools to a job that deserves better tools.
Performance and Scalability Are Built In
When you build for an enterprise, performance is measured constantly. Page load times are tracked. Core Web Vitals are reported on. Someone will notice if a deployment makes the site 200 milliseconds slower. You develop an instinct for it.
Most small business websites are built by people who've never operated at that scale. You don't need enterprise architecture for a plumber's website. But the habits transfer.
When I build a small site, images are optimized before they hit the page. CSS is minimal. JavaScript loads only when it's needed. The hosting is configured for speed. Static generation where possible, proper caching, a setup that absorbs traffic spikes without falling over. These aren't heroic efforts. They're just how I build things.
A small business site probably won't get ten times its normal traffic. But it might. A promotion goes viral, you get featured in a local news story, someone shares your blog post. I've built sites for clients that got unexpected surges and handled them without anyone noticing. That's not luck. That's architecture.
The result is a five-page site that loads in under a second and stays up when it matters.
Code That Someone Else Can Maintain
In enterprise environments, you never write code just for yourself. You write code that dozens of developers will read, modify, and debug. If it's unclear, it gets sent back. If it's clever but unreadable, it gets sent back. If it works but it's fragile, it gets sent back.
That discipline sticks with you.
When I build a small business site, variables are named clearly, components are organized logically, and there are comments where they matter. If I get hit by a bus (the freelancer's favorite hypothetical), another developer can pick up the project without spending days reverse-engineering it.
Small business owners switch developers all the time. When that handoff happens, the quality of the code determines whether it takes the new developer two hours or two weeks to get up to speed.
Security Is a Habit, Not a Feature
Years in financial services will rewire how you think about security. It stops being a checklist item and becomes instinct.
WordPress sites get hacked constantly. Not because hackers want your plumbing company's customer list, but because automated bots scan the entire internet for vulnerabilities and exploit whatever they find. Your small business site isn't a high-value target. It's a soft one. The second kind is arguably worse.
I build with security defaults. HTTPS everywhere. Secure headers. No unnecessary third-party scripts. Admin interfaces behind strong authentication. Dependencies updated and monitored. Basic things, but I'm consistently surprised by how many small business sites get them wrong.
Process Without Bureaucracy
Enterprise work teaches you process whether you like it or not. Sprints, code reviews, testing, staging environments, deployment checklists, documentation. Some of it's genuine bureaucracy. But the core is sound: don't wing it.
I don't run two-week sprints for a five-page website. But I do have a defined scope, milestones, a staging environment, a deployment checklist, and documentation for how to use what I built. AI's a big part of that workflow now too. I wrote about how I use AI to build sites faster if you're curious.
A shocking number of freelance projects have no process at all. The developer builds, the client sees it when it's done, and everyone hopes for the best.
The Animal Science Detour
Before all of this, I studied animal science. I was going to be a large animal veterinarian. Life had other plans.
I think starting outside of tech gave me something pure computer science graduates sometimes lack: the ability to explain things to people who aren't technical. When you come to technology from another field, you remember what it felt like to not understand it. You remember the jargon that confused you.
I talk to clients in plain language because I remember when all of this was foreign to me too. That's not a pedagogical technique. It's empathy born from experience.
Not a Brag. A Perspective.
I'm not arguing that every small business needs to hire someone with a decade of enterprise experience. Plenty of talented developers build great small business sites without ever setting foot inside a Fortune 500 company.
But the experience transfers in ways that aren't immediately obvious. The way you think about a problem changes when you've solved it at scale. The way you write code changes when everything gets reviewed. The way you approach security changes when you've built systems that handle sensitive data.
You're paying for the absence of problems. Which is a terrible sales pitch. Nobody gets excited about the vulnerability that doesn't exist or the technical debt that was never created. But six months after launch, when your site is still fast, still secure, still working exactly the way it should, you'll feel it.
The result is a small project built with big-project discipline. You won't notice it until you need to, and that's the whole point.