Things I Wish I Knew Dev: What Looks Professional and Absolutely Isn't - Autom84You

There's a moment in every developer's career - usually around 2 AM, usually involving a production database - where you realize the thing that looked extremely professional was, in fact, a trap wearing a nice suit.

I've been collecting these moments for over twenty years. My personal list of things I wish I knew dev-side before building my first real project would fill a novel. But tonight I'm going to give you the highlight reel, because if you're a small business owner hiring someone to build your website, your app, or your automation - you deserve to know what "professional" actually looks like versus what just seems like it does.

Think of this as a field guide. A survival manual. A very nerdy confessional.

Things I Wish I Knew Dev: Complexity Is Not a Flex

When I was a younger developer, I thought the more moving parts a project had, the more impressive it was. Twelve microservices for a contact form? Chef's kiss. A custom CMS built from scratch when WordPress would've been fine? Obviously.

I was wrong. I was deeply, embarrassingly wrong.

The most professional thing a developer can do is use the simplest solution that actually works. A bakery in Sunnyvale doesn't need a React single-page application with server-side rendering and a headless CMS. They need a site that loads fast, shows the menu, and lets someone place an order. That's it. That's the whole thing.

If your developer is pitching you architecture that sounds like a NASA launch sequence, ask one question: why? If the answer involves the word "scalable" for a business with twelve employees, you're being oversold.

This is one of the earliest things I wish I knew dev-wise, and it took me years to internalize: the best work is often invisible. Nobody notices a site that just works. They only notice when it doesn't.

Copy-Paste Code Looks Great Until It Doesn't

Here's a fun story from the broader dev world that perfectly illustrates what I mean. Earlier this year, a developer named Johannes Link added a hidden prompt injection into his open-source Java testing library, jqwik. The injection told AI coding agents to delete all the tests and code they'd generated.

Was it a stunt? Partly. Was it reckless? Definitely - another developer pointed out that "a maximally destructive instruction with no qualifications, no opt-out" is not exactly responsible engineering. But the underlying point was real: if your "developer" is just copying code from AI tools without reading it, understanding it, or testing it, you're building on sand.

This is the vibe-coding problem. It looks professional. The output is clean, the syntax is correct, the site loads. And then one day someone updates a dependency, or a library author gets creative, and your entire project goes sideways because nobody actually understood what any of it did.

When I build custom sites and tools for small businesses, I read every line. I know what it does. I know why it's there. That's not a flex - it's the minimum. But you'd be surprised how many shops skip it.

Things I Wish I Knew Dev Side: "It Works on My Machine" Is Not a Deployment Strategy

Here's what usually happened: the previous developer tested everything locally, on their own laptop, with their own settings. It worked great. They shipped it. And then the real world - with its different servers, different PHP versions, different database configurations - politely disagreed.

Professional looks like: a staging environment that mirrors production. Version control with actual commit messages, not just "fixed stuff" fourteen times in a row. Documentation that a future human (or the same human six months later) can actually follow.

Unprofessional looks like: "Here's a ZIP file, good luck."

I've received that ZIP file. I've opened it with the same energy you open a mystery tupperware in the back of the fridge. The results were similar.

Security Is Boring Until It's the Only Thing That Matters

Nobody wakes up excited about SSL certificates. No dog groomer in Mountain View has ever said, "You know what I'm passionate about? Input sanitization." I get it.

But here's one of the critical things I wish I knew dev-first-day: security isn't a feature you add later. It's the foundation you build on. And the stuff that looks secure - a padlock icon in the browser bar, a login page - might be cosmetic if nobody configured the backend properly.

Real security for a small business site means: your forms don't accept malicious code. Your admin panel isn't at /admin with a default password. Your customer data is encrypted. Your backups exist and actually work. (That last one. Ask your developer to prove your backups work. Watch their face. It's very informative.)

The Pentagon knew for nearly a decade that commercial location data could track troops, and they still didn't fix it. If the Department of Defense can procrastinate on security, imagine what a freelancer on Fiverr is doing with your contact form data.

A Pretty Dashboard Doesn't Mean Smart Automation

I build custom automation and AI tools for small businesses. So trust me when I say: a pretty dashboard with colorful graphs can be completely meaningless.

I've seen businesses paying $200/month for analytics platforms that track seventeen metrics, none of which the owner actually uses to make decisions. That's not automation. That's decoration.

Good automation is boring to look at and life-changing to use. It's the HVAC company whose appointment reminders go out automatically and no-shows dropped 40%. It's the hair salon whose review requests send themselves after every appointment, and their Google rating climbed from 3.8 to 4.6 in four months. It's the landscaper whose invoices generate and send without anyone touching a spreadsheet.

None of that requires a pretty dashboard. It requires someone who understands your actual workflow - not your theoretical workflow, not the workflow the software vendor's demo assumes you have, but the messy real one where sometimes you text clients from your personal phone and track leads on a Post-it note stuck to your monitor.

That's what I do at Autom84You - I look at how your business actually runs and build the specific thing that saves you time. Not a platform. Not a suite. The thing.

Things I Wish I Knew Dev: Your Tech Stack Is Not Your Personality

Developers love arguing about tools. React vs. Vue. Python vs. JavaScript. Tabs vs. spaces (it's spaces, and I will not be taking questions).

Here's what twenty years taught me: your customer does not care. The plumber in Campbell whose website brings in three new leads a week does not care whether it's built in Next.js or plain HTML with some PHP glue. They care that it works. They care that it loads in under two seconds on their phone. They care that when someone searches "emergency plumber near me" at midnight, they show up.

Choosing the right tool for the job is professional. Choosing the trendy tool so your GitHub looks impressive is not. I've rebuilt more sites that were over-engineered with the wrong fancy framework than I've rebuilt sites that were too simple.

The Honest Takeaway

My full list of things I wish I knew dev-starting-out would take hours. But the short version is this: professionalism isn't about looking impressive. It's about being reliable, being honest about trade-offs, and building things that actually serve the person who's paying for them.

If your current site or automation setup feels like it's held together with duct tape and optimism - or if it looks beautiful but you have a nagging feeling nobody actually tested it - that's worth a conversation.

I'm Rishi. I've been building websites, AI tools, and automation for small businesses for over 20 years. I'm at autom84you.com, and you can email me at nerd@a84y.com. I'll tell you what you actually need, even if that answer is "honestly, you're fine - just update your plugins." That's the most professional thing I know how to do.