Five Years of Enterprise Dev Taught Me to Build for Small Businesses

I spent five years as an enterprise-level developer. Global companies. Multi-million-dollar projects. Teams across four time zones. The kind of work where a single deploy requires sign-off from eight people and a two-week freeze window.

Then I started building software for 10-person businesses.

And I had to unlearn almost everything.

#What enterprise gets right

Let's start with what big companies do well, because they do do some things well:

#1. They document everything

Not because they're virtuous. Because they have to. When your team turns over every 18 months, documentation is the only institutional memory you have.

The lesson for small teams:
You don't need Confluence. You don't need a 40-page architecture doc. But you do need a README that explains:

• How to run the app locally
• Where the config lives
• What to do when something breaks

Your future self (six months from now, debugging at 9 PM) will thank you.

#2. They use boring technology

Enterprise doesn't chase trends. They use Java. Postgres. React (maybe). Load balancers from 2015 that just… work.

The lesson for small teams:
If you're building a business tool, you don't need:

• The newest JavaScript framework
• A cutting-edge database
• Microservices (you're three people!)

You need something that works, that you understand, and that will still work in five years.

Boring wins.

#3. They test in production (sort of)

Big companies have staging environments, QA teams, and automated test suites. But the final test? Ship it and see what breaks.

The lesson for small teams:
You don't have the budget for a full-time QA team. So:

• Write tests for the critical paths (auth, payments, data integrity)
• Use error monitoring (Sentry, LogRocket, whatever)
• Ship often and fix fast

Perfection is expensive. Iteration is cheap.

#What enterprise gets wrong

Now here's what big companies screw up—and what you should not copy:

#1. They over-engineer everything

Enterprise developers love abstractions. Layers. Interfaces. Dependency injection. Frameworks for frameworks.

Why? Because in a 200-person engineering org, you need guard rails. You need patterns. You need to ensure that Junior Dev #47 can't accidentally delete the production database.

The lesson for small teams:
You don't need that. You're three people. You all know what you're doing. You don't need:

• A service layer AND a repository layer AND a controller layer
• A custom ORM wrapper around your ORM
• A "scalability strategy" for 10 million users when you have 300

Write the simplest code that works. Add complexity only when you feel the pain.

#2. They optimize for the wrong metrics

Enterprise optimizes for:

• Uptime (99.99%!)
• Scalability (handles 50k requests/sec!)
• Process (JIRA tickets closed per sprint!)

None of that matters to a 10-person business.

What actually matters:

• Does it solve the customer's problem?
• Can they figure out how to use it?
• Does it make them money (or save them time)?

That's it. That's the list.

#3. They confuse "best practices" with universal law

"You have to write unit tests."
"You can't skip code review."
"Microservices are the only way to scale."

These aren't laws of physics. They're trade-offs.

The lesson for small teams:
Some "best practices" make sense:

• Version control (yes, always)
• Automated deploys (yes, always)
• Backups (yes, always)

Some don't:

• TDD for every feature (not at this stage)
• Mandatory code review (you're the only dev!)
• Splitting into microservices (please don't)

Ignore the dogma. Do what works.

#What I'd tell enterprise-me

If I could go back and talk to myself five years ago, here's what I'd say:

#1. "Boring" is a feature, not a bug

That cutting-edge framework? It'll be dead in three years. That boring, stable library? It'll still be here.

Boring is:

• Easier to hire for
• Easier to debug
• Easier to hand off

Choose boring.

#2. Shipping beats polish

Enterprise culture loves polish. Pixel-perfect designs. Zero bugs. A/B tested to death.

Small business culture loves shipping.

Version 1 doesn't have to be perfect. It has to exist.

#3. Your job is to make them money

This sounds obvious, but enterprise devs forget it all the time. We get obsessed with clean code, elegant solutions, architectural purity.

Small businesses don't care about any of that.

They care about:

• Does this let me sell more?
• Does this save me time?
• Does this prevent me from losing customers?

If the answer is "no" to all three, you're building the wrong thing.

#How we build for small businesses now

Here's how we approach projects at Forever Frameworks:

1. Start with the outcome. What does success look like for this business? More leads? Faster onboarding? Fewer support tickets?

2. Pick boring tech. Next.js. Postgres. Tailwind. Stuff that works and will keep working.

3. Ship fast, iterate faster. Get something in front of users in 2–4 weeks. Learn what works. Build more of that.

4. Optimize for maintenance. The client has to live with this code after we're gone. Make it understandable. Make it fixable. Make it boring.

5. Say no to complexity. Every abstraction, every dependency, every architectural decision is debt. Only take on debt that pays interest.

#The best part

The best part of working with small businesses? They know what they need.

Enterprise clients say: "We need a scalable, cloud-native solution with real-time analytics."

Small business clients say: "I'm spending 10 hours a week manually entering orders. Can you fix that?"

The second one is so much easier to solve.

Sean Cotter is the technical co-founder of Forever Frameworks. He's written code for billion-dollar companies and 10-person teams. The 10-person teams are more fun.