Lessons from Running a B2B System

Over the past three years, I’ve been building and supporting an on-premise Customer Data Platform (CDP) designed for businesses that want full control over their data infrastructure. This is not a SaaS product. Our platform is built for organizations that, for security, compliance, or strategic reasons, don’t want to send their most sensitive customer data to third-party SaaS companies.

While the platform itself is simple to install and flexible to use, maintaining and delivering it across a variety of corporate environments has taught me a number of lessons — especially in the B2B world, where expectations, workflows, and infrastructure vary dramatically.

Here’s what I’ve learned along the way.

1. Most Support Requests Aren’t About Your System

One of the first things I noticed is that most support issues have little to do with our actual platform. Instead, they come from the surrounding stack — databases, message queues, search engines, cloud infrastructure, and network policies.

Our platform depends on external components for storage and data processing, and it's often these dependencies — not our logic — that trigger the majority of support tickets.

That’s why I now design systems with minimal external dependencies. Every extra component becomes your responsibility, especially in on-premise environments where your client controls the infrastructure but looks to you for support.

2. Use Managed Services When You Can — But Be Ready for Clients Who Can’t

While I encourage the use of managed services whenever possible, not all of our clients are willing or able to use them. Many companies we work with have strict policies around data sovereignty, compliance, or simply don't trust cloud providers with their core customer data.

This is why we focus on on-premise deployment. Our platform runs inside the client’s environment — not ours. This gives them full control over where the data is stored, who has access to it, and how it's processed.

Ironically, many large enterprises actually prefer this model. The data we help them manage is often one of their most valuable assets, and they’re not willing to share it with any SaaS provider — no matter how secure or reputable.

But when clients can use managed services (e.g. hosted databases or monitoring tools), we encourage it — especially because enterprise teams often find labor more expensive than cloud infrastructure. For them, SaaS is a people-saver.

3. Don’t Build Only for Enterprises

One of the longest sales cycles I’ve ever experienced took nearly a full year — just to get from first meeting to contract signature. After that, implementation took several more months as the platform went through security reviews, architectural approvals, and integration steps.

By contrast, small and mid-sized businesses often make decisions within a week, and onboarding takes just a few days.

That’s why our platform supports both enterprise and SMB environments. The same system can be deployed in a Fortune 500 data center or on a mid-sized company’s bare-metal server. But making that possible required a lot of flexibility — modular design, clear separation of concerns, and adapters to plug into various environments.

4. Simplicity Scales Better Than Features

As developers, we’re often tempted to add features, polish edge cases, and offer advanced configuration options. But I’ve learned the hard way that simplicity beats capability, especially when your product is running on-premise, possibly in dozens of different environments.

Most users only touch a small portion of your product — often just 20%. But each customer needs a different 20%.

The solution isn’t to build a bloated platform that tries to be everything. It’s to identify and streamline critical workflows, reduce surface area, and build guardrails that make misconfiguration nearly impossible.

The fewer decisions users have to make, the less support they’ll need. And when you’re not on-site or running the system for them — that’s critical.

5. If You’re a Solo Developer or Small Team, Aim for "Install-and-Forget"

Early on, I was running everything solo. That experience taught me something important: I can’t afford to be the bottleneck.

If you're a one-person or small team, your product needs to work reliably without you. Clients should be able to install it, configure it once, and never need to touch it again unless they're upgrading.

Think of it like a door hinge — essential, but invisible when it works well. If your product is critical but simple and reliable, clients will keep using (and paying for) it, even if you’re not constantly available.

6. Your Clients Don’t Know How Infrastructure Works — You Do

In on-premise deployments, the client is often responsible for provisioning the environment — but that doesn’t mean they know how to run it.

Whether it's Postgres, Redis, Elasticsearch, or some message queue, you will be their support line, whether you intended to or not.

If you include a database in your stack, you need to understand how to tune it, secure it, back it up, and recover it. Not just for yourself — for your clients too. Documentation helps, but in practice, they’ll turn to you first.

7. Reliability Isn’t Optional — It’s Survival

In the SaaS world, you might be able to patch and deploy fixes quickly. In on-premise environments, you don't get that luxury. Every failure requires more work — often over email, or worse, remote access sessions.

That’s why reliability is everything. I no longer consider 90% uptime acceptable. We aim for 99.9% or better, because anything less means we’ll be spending our days debugging obscure setups we don’t control.

Every bug you ship in an on-premise product becomes someone else’s operational burden — and your headache to fix remotely.

8. Big Clients Are Slow — Small Clients Are Fast

Our longest enterprise deal took almost 12 months to close. There were multiple stakeholders, review cycles, legal approvals, and security assessments. Even after signing, it took months before the system was fully integrated.

In contrast, small clients often decide in under a week and complete onboarding in days. They’re agile, motivated, and can usually test, evaluate, and deploy independently.

Our platform installs quickly, but deployment speed depends on how widely and deeply it's integrated into the organization. Enterprise complexity isn’t about tech — it’s about process.

This is why it’s critical to diversify your client base. Relying only on large deals can starve your business in the short term. Fast-moving smaller clients keep the engine running while you pursue long-term enterprise growth.

Wrap up

Supporting a B2B system — especially an on-premise one — means you're not just writing software. You’re delivering trust, responsibility, and operational readiness into someone else’s infrastructure.

It’s not the same as SaaS. It requires a different mindset: one that prioritizes flexibility, independence, reliability, and clarity.

If I had to summarize what I’ve learned in one line, it would be:

You’re not building an app — you’re embedding a system inside another company’s world.

And in that world, your product needs to work flawlessly, quietly, and without surprises.