I partner with Wells Fargo building systems that serve millions of customers. Then I build automation for small businesses with Forte Web Designs.
Completely different scales. But the lessons transfer.
Here's what working on enterprise systems taught me that makes me better at small business automation.
Plan for failure. Because everything fails eventually.
At enterprise scale, you can't assume anything will work perfectly. APIs go down. Databases get overloaded. Network connections drop. External services fail.
So you build with failure in mind. Error handling. Retries. Fallbacks. Graceful degradation. Logging.
Small business automation needs the same thinking. Maybe not the same complexity. But the same mindset.
I built an automation for a client that pulled data from their e-commerce platform. Worked perfectly during testing. Deployed it. Worked great for two weeks. Then the e-commerce platform changed their API without warning. Automation broke.
Client was frustrated. "Why didn't you plan for this?"
Fair point. I should have. At Wells Fargo, we'd have error notifications. Fallback behavior. Automatic alerts when something breaks.
Now I build that into small business projects too. Costs a bit more upfront. Saves massive headaches later.
Logging isn't optional. It's mandatory.
Enterprise systems log everything. Every transaction. Every error. Every state change. Not because we're paranoid. Because when something breaks, you need to know what happened.
Small businesses rarely think about logging. They just want the automation to work. But when it doesn't work, they have no visibility into why.
I had a client's automation mysteriously stop processing orders. No obvious errors. Just stopped working.
Checked the logs. Turned out their vendor changed how they formatted order confirmations. One field was now optional instead of required. Automation expected that field. Didn't find it. Failed silently.
Without logs, that would have taken days to diagnose. With logs, took 10 minutes.
Now every automation I build includes logging. Doesn't need to be fancy. Just needs to record what happened, when, and whether it succeeded.
Security matters even when you're small.
At Wells Fargo, security is obsessive. Every system is hardened. Every connection encrypted. Every access point authenticated. Compliance audits constantly.
Small businesses think they're too small to worry about security. They're not.
I worked with a small medical practice. Wanted to automate patient appointment reminders. Simple project. But it involved patient data. HIPAA applies regardless of business size.
Had to think about encryption. Access controls. Data retention. Audit trails. All the enterprise security principles. Scaled down for their context but fundamentally the same.
You don't need enterprise-grade security infrastructure. But you need enterprise security thinking. Encrypt sensitive data. Use proper authentication. Don't store things you don't need. Follow compliance requirements.
Security bugs in small systems cause the same problems as security bugs in big systems. Just because you're small doesn't mean you're safe.
Documentation is for future you.
Enterprise systems are documented extensively. Not because we love writing docs. Because systems last years. People change teams. Someone needs to understand how things work.
Small business automation projects rarely get documented. I'm guilty of this too. Build it. Deploy it. Move on. Seems fine.
Until six months later when the client asks for a change. I open the code. Have no memory of why I did things that way. Wish past me had written a comment explaining the logic.
Now I document as I build. Not lengthy explanations. Just enough so future me or future maintainers can understand the decisions.
Why this approach instead of that one. What assumptions I made. What edge cases exist. What integrations are fragile.
Takes an extra 15 minutes during development. Saves hours during maintenance.
Version control isn't just for big teams.
Everything at Wells Fargo is in version control. Git repositories. Commit history. Code reviews. Branches.
Solo consultants often skip this. Code lives on their laptop. Or maybe Dropbox. No real version control.
That's risky. What if you need to roll back a change? What if you want to try something experimental without breaking the working version? What if your laptop dies?
I use Git for everything now. Even small projects. Even solo work. Commit frequently. Write decent commit messages. Push to a remote repository.
Has saved me multiple times when I needed to revert changes or understand what worked before.
Testing catches problems before clients do.
Enterprise development includes extensive testing. Unit tests. Integration tests. End-to-end tests. Automated test suites running constantly.
Small business projects rarely have formal testing. Too expensive. Too time-consuming. Just test manually and ship.
I don't do full enterprise testing for small projects. But I do systematic manual testing. Every path. Every edge case I can think of. Every integration point.
And I document the test cases. So when I make changes later, I can run through the same tests and verify nothing broke.
Catches most bugs before they reach clients. Much cheaper to fix bugs before deployment than after.
Simplicity scales better than complexity.
This one surprised me. You'd think enterprise systems are necessarily complex. Some are. But the best enterprise systems are simple at their core.
Clear architecture. Well-defined interfaces. Minimal dependencies. Simple logic.
Complexity is a liability. Makes things harder to maintain. Harder to debug. Harder to modify. More likely to break.
When I build automation for small businesses, I aim for the simplest solution that works. Not the cleverest. Not the most feature-rich. The simplest.
Because simple systems are reliable. Easy to understand. Easy to fix when they break. Easy to extend when requirements change.
I've seen small business automation projects that are over-engineered. Someone built a complex system because they could. Not because they needed to.
Those systems are nightmares to maintain. Every change risks breaking something. Every bug takes forever to diagnose.
Simple wins. Every time.
The lessons that matter work at any scale.
You don't need enterprise infrastructure for small business automation. Don't need the same tools. Don't need the same budget.
But you need the same principles. Plan for failure. Log everything important. Think about security. Document decisions. Use version control. Test systematically. Keep it simple.
These aren't enterprise principles. They're good engineering principles. They apply whether you're building for millions of users or one small business.
Working at Wells Fargo taught me that. Makes me a better consultant. Better engineer. Better problem solver.
That's why I'm keeping the day job.