@olaf_becker4Hi, I’m Olaf, founder of LSE Group. Building marketing software and AI infrastructure
Hi everyone, I’m Olaf Becker, founder and CEO of LSE Group Corporation, a technology holding company. We operate three divisions: an omni-channel marketing platform (SaaS), IT security solutions, and alternative energy.
My background is in enterprise systems, going back decades across private banking, hotel reservation systems, and payment processing. That experience shapes how I build: reliability first, then features.
Right now I’m focused on two things. On the product side, our Omni-Channel Marketing Platform handles publishing and per-post analytics across up to 16 social and content platforms, depending on the tier. On the infrastructure side, we’re planning a GPU server buildout in a colocation cage at Ashburn, Virginia, using HPE XD-series systems.
I’d value conversations with people who have run AI workloads on dedicated hardware, especially around power and cooling planning, and with anyone who has added AI features to a marketing or SaaS product. What’s one lesson you’d give a founder starting an AI build today?
LSE Group Corporation lumanet.info
Comments4
Hi Olaf, thanks for sharing. One lesson from building a multi-feature AI product (JobHunt AI): put cost control and provider abstraction in from day one. I route across Groq, Gemini and Cerebras behind a single layer, with a per-user budget guard. Without that, one rate limit or a heavy free-tier user can hurt every AI feature at once. For a marketing SaaS adding AI, I'd also strip customer PII before prompts leave your infrastructure.
Curious: for the GPU buildout, are you planning to run open models locally, or keep some workloads on hosted APIs as fallback?
Thanks Bazed, the lesson about cost control from day one is a good one. We handle the free-tier risk you describe by design. Free users only get BYOK access (Grok, ChatGPT, Mistral, Perplexity), so they run on their own keys and a heavy free user can't create a cost or rate-limit problem for us. Paid tiers run on proprietary models on our own hardware, with per-user limits. So no open models for us, and no hosted-API fallback on our side. Did you find per-user budget guards enough on their own, or did you need hard caps by feature as well?
Welcome to Lounge, Olaf. Per-post analytics across 16 platforms sounds like a messy data problem, since each API exposes different metrics. Before you commit to owning GPUs in Ashburn, which AI feature in the marketing product would actually keep them busy enough to beat renting?
Thanks for the welcome, Ryan. You're right that per-post analytics across 16 platforms is messy, since every API exposes different metrics and normalizing them is half the work. On owning versus renting, for us it's about cost certainty more than raw price. Usage-billed AI has no ceiling. Slash recently had one employee run up over $80K in AI credits in about a week, with no limits in place. Owned hardware turns that into a fixed, predictable cost. The steady load that keeps it busy is paid-tier generation, classification and analytics summaries. Free users never touch it, since they bring their own keys. Have you seen a case where renting stayed cheaper at scale?
4 comments
Hi Olaf, thanks for sharing. One lesson from building a multi-feature AI product (JobHunt AI): put cost control and provider abstraction in from day one. I route across Groq, Gemini and Cerebras behind a single layer, with a per-user budget guard. Without that, one rate limit or a heavy free-tier user can hurt every AI feature at once. For a marketing SaaS adding AI, I'd also strip customer PII before prompts leave your infrastructure.
Curious: for the GPU buildout, are you planning to run open models locally, or keep some workloads on hosted APIs as fallback?
Thanks Bazed, the lesson about cost control from day one is a good one. We handle the free-tier risk you describe by design. Free users only get BYOK access (Grok, ChatGPT, Mistral, Perplexity), so they run on their own keys and a heavy free user can't create a cost or rate-limit problem for us. Paid tiers run on proprietary models on our own hardware, with per-user limits. So no open models for us, and no hosted-API fallback on our side. Did you find per-user budget guards enough on their own, or did you need hard caps by feature as well?
Welcome to Lounge, Olaf. Per-post analytics across 16 platforms sounds like a messy data problem, since each API exposes different metrics. Before you commit to owning GPUs in Ashburn, which AI feature in the marketing product would actually keep them busy enough to beat renting?
Thanks for the welcome, Ryan. You're right that per-post analytics across 16 platforms is messy, since every API exposes different metrics and normalizing them is half the work. On owning versus renting, for us it's about cost certainty more than raw price. Usage-billed AI has no ceiling. Slash recently had one employee run up over $80K in AI credits in about a week, with no limits in place. Owned hardware turns that into a fixed, predictable cost. The steady load that keeps it busy is paid-tier generation, classification and analytics summaries. Free users never touch it, since they bring their own keys. Have you seen a case where renting stayed cheaper at scale?