What looks effortless above the surface is engineered underneath.
At Nike, I spent five years designing cybersecurity controls across 50 AWS accounts. Before that, I worked on cloud migrations at Avanade for healthcare and financial-services clients. Before that, I shipped infrastructure for a New York fintech and Allstate.
Ten years. Four employers. Production systems the whole way through.
The disciplines that keep a Fortune 100 platform alive are not proprietary. They translate downward.
Most service businesses are not failing because they lack ambition. They are failing because the systems underneath the business are still held together like side projects.
three transferable disciplines.
1. observability before optimization.
At Nike, no production system shipped without metrics, logs, and alerts.
You cannot optimize what you cannot measure. You cannot fix what you cannot see.
Most service-business stacks have no observability layer at all.
A voicemail drops at 7pm. Nobody sees it. The owner only finds out three weeks later when the lost customer mentions it in a bad review.
The first build for many clients is not fancy AI.
It is making the operational signal visible.
- What came in?
- Who handled it?
- What got missed?
- Where did the workflow stop?
- What broke before the customer felt it?
Once you can see the leak, you can fix it.
2. idempotency by default.
Production systems assume things will happen twice.
Webhooks deliver twice. Network requests time out and come back. Cron jobs overlap. A user clicks the button again because nothing seemed to happen.
Every important operation has to be safe to repeat.
That is idempotency.
The Zapier chain that breaks because someone forgot one field is the opposite of this. One weird input poisons the whole flow. A duplicate webhook creates two records. A retry sends the same email twice. Nobody trusts the automation anymore, so the owner goes back to checking everything by hand.
Production engineering prevents that class of failure from becoming a business problem.
At SMB scale, this does not need to be complicated.
Sometimes it is just a status field, a unique ID, a retry rule, and a clear “already handled” check.
The point is simple:
The system should not collapse because Tuesday was weird.
3. the control plane is not the data plane.
Big systems separate the way work flows from the way behavior gets changed.
- You can pause an outbound campaign without redeploying code.
- You can rotate a vendor credential without touching the workflow.
- You can change a follow-up sequence without rebuilding the system.
- You can test a new rule without asking an engineer to rewrite the whole thing.
That separation matters.
The data plane is the work moving through the system.
The control plane is how you change the rules.
Most SMB stacks collapse the two together. Changing behavior means editing code, opening Zapier, texting the developer, or hoping nobody breaks the spreadsheet.
That cost is invisible until the business needs to move quickly.
A good system gives the operator control without forcing them into the engine room every time.
where smbs need the same discipline, not the same ceremony.
Fortune 100 companies over-engineer because the blast radius is enormous.
A 12-person service business does not need that ceremony.
It does not need a five-tier observability stack, SLO reviews, and a PagerDuty rotation.
It needs one operator dashboard showing the three numbers that matter.
It needs a simple alert when something breaks.
It needs retries that do not create duplicate work.
It needs handoffs that do not depend on memory.
It needs a way to change routine behavior without calling the developer every time.
The discipline is the same.
The cost structure is different by two orders of magnitude.
Idempotency at SMB scale might be a flag on a database row, not a distributed transaction.
The control plane might be a small admin screen, not an enterprise feature-flag platform.
Observability might be a dashboard and a Discord ping, not a full telemetry stack.
The point is not to copy enterprise architecture.
The point is to bring the useful part down to owner-operated scale.
That is what Floeberg builds.
Production-grade engineering for service businesses. The systems discipline that keeps large platforms alive, rebuilt at a scale that can pay back for a coaching practice, law firm, clinic, agency, or local service company.
The customer feels the foundation, not the polish. That is where we work.
the test.
A simple test for whether a system was production-engineered:
Does the owner notice when it breaks before the customer does?
If yes, the operational layer is there.
If no, the system is leaking through to the customer surface, and the brand is paying for it every Tuesday at 7pm.
If your stack is held together with shared docs, screenshots, manual checks, and personal memory, the next step is not another shiny tool.
The next step is the Blueprint.
One week of diagnostic work. The brief names what to build, what not to build, and whether Floeberg is the right partner to build it.