Design Perspective: Working with Lovable (Matilda)

Our design team’s perspective, working with Lovable was an interesting but mixed experience. It showcased the speed and potential of AI-assisted design, but also revealed what happens when strong design systems aren’t in place.

What worked well:
Lovable made it easy to generate quick layout ideas and wireframes, especially for SaaS workflows that typically require multiple states and screens. It accelerated early exploration and provided a structure to discuss with the team. The speed and automation were valuable in the early brainstorming phase.

What didn’t work well:
Most generated designs violated core design principles such as hierarchy, spacing, and consistency. Accessibility and contrast ratios were often off, and interaction logic felt random rather than system-driven. Without integration to our design tokens or style guide, outputs lacked brand alignment and required heavy correction in Figma.

What could have been better:
If Lovable could be trained or prompted using our existing design system and component library, it would have produced more coherent results. A feedback loop between AI generation and manual refinement in Figma would make it genuinely powerful for scalable design systems like ours.

Frontend Perspective: Working with Lovable (Ibrahim)

From our frontend team, Lovable currently feels more like a prototyping tool than a development solution.

What worked well:
The UI generation is impressive: clean layouts that look good and communicate intent quickly. It’s excellent for visualizing concepts and aligning stakeholders early without heavy coding.

What didn’t work well:
Under the hood, the generated code often struggles with structure and maintainability. Integrating it into an existing production codebase risks introducing technical debt and bugs over time. The generated React code also clashed with our Vue.js environment, reducing developer experience and reusability.

What could have been better:
Lovable would benefit from allowing developers to define existing project standards, folder structures, and UI libraries (Vue, React, Angular, etc.) before generation. Optional Figma exports for code review and design parity would also help. These changes could make Lovable more than a visual playground: a genuine bridge between prototype and production.

Context, Constraints, and Reality

Maybe this wasn’t Lovable’s fault: maybe it was ours.
Would the outcome have been different if we had given the designer and engineer uninterrupted time to explore it deeply on their own? Probably.

But in a scale-up environment, where every sprint is tightly scheduled, that kind of open-ended exploration comes at a real cost. The reality is that teams have to deliver. Experimentation windows are narrow, and tooling must prove its value fast.

There’s also the privacy and IP concern. Giving an external AI platform access to internal design systems, codebases, and component libraries isn’t a trivial decision, especially when proprietary assets are involved.

Still, Lovable did something meaningful: it helped us prototype faster, get feedback earlier, and iterate with clearer context. That acceleration, even if imperfect, shortened our learning cycle.

The takeaway is simple: Lovable isn’t ready to sit inside a SaaS level production workflow, but it’s a strong ally in early ideation. The challenge and opportunity lie in bridging that gap between AI speed and production rigor.

In the end, we settled on using Lovable primarily as a rapid prototyping accelerator: a way to get early structure, flow, and alignment without overinvesting in code or pixel perfection. Once the prototype captured the right intent, we handed it off to our design team as a blueprint, enabling them to layer in Wowzi’s platform-specific requirements, brand system, and usability refinements. This approach let us benefit from Lovable’s speed while ensuring the final output met our design standards and integrated seamlessly into our established workflows.

In short:
Lovable gave us speed but not fidelity, direction but not depth.
If it evolves to safely understand team context, framework diversity, and real-world code discipline, it might just change the game.

At Wowzi, we’re constantly exploring ways to improve the experience of creators and advertisers through intelligent, scalable infrastructure. As part of that journey, our engineering team set out to introduce AI-powered services that could support content workflows across our platform: from content generation to moderation and insights.

The goal was to build a serverless service that could interface with LLMs behind the scenes and deliver fast, flexible responses at scale. Of course, it is retrieval augmented. We opted for a Lambda-first architecture to maintain our commitment to elastic infrastructure and reduce operational overhead. The plan was simple: integrate a general-purpose AI SDK and swap out model providers as needed.

Or so we thought.

The Setup

To accelerate development and ensure long-term flexibility, we chose to start with the openai Python SDK. It had a clean abstraction, support for multiple model types, and offered the promise of provider-agnostic usage if you stayed close to the OpenAI-compatible API standards.

Given our serverless-first approach, the natural next step was to deploy it within an AWS Lambda Layer, targeting Python 3.11 with the ARM64 architecture for cost and performance benefits.

Where Things Got Complicated

Things unraveled fast.

First, the openai package brought in pydantic-core, a compiled dependency with tight coupling to specific versions of Python and system architecture. Installing it locally was no problem, but once deployed into Lambda, we started encountering runtime errors like:

“cannot import name 'from_json' from 'pydantic_core._pydantic_core'”

This suggested binary mismatches. So we went back to basics and rebuilt everything inside Docker containers that mirrored Lambda’s runtime; even targeting manylinux2014_aarch64 for full compatibility.

That fixed the original import error…, but introduced a new one: Lambda could no longer find the openai module itself. Now you see the wahala.

We verified the zip structure, checked that python/ was at the correct level, ensured proper architecture matching, and even manually inspected every path Lambda was seeing during execution. The module was clearly there. Lambda simply refused to acknowledge it.

The Pivot

At this point, we paused and asked a deeper question:

Do we really need the SDK?

The value we were chasing was provider flexibility and a clean API interface. But that could just as easily be achieved by directly integrating with the REST APIs of each LLM provider.

And so, we pivoted.

Enter nemotalk: A Clean, Custom Abstraction

We built a small internal utility called nemotalk: a lightweight function that communicates directly with NVIDIA’s REST APIs. It handles authentication and response parsing without depending on any SDK or heavyweight Python packages. A couple other functions took handle the retrieval of data for prompt augmentation.

What we gained:

Portability: Switching from NVIDIA to another provider (e.g., Perplexity, Mistral, or open-source LLMs) is as simple as changing a base URL and a model identifier.

Zero SDK headaches: No more worrying about compiled dependencies breaking Lambda.

Control: We now own the interaction logic, which means better logging, failover strategies, and customization options going forward.

The end result is an AI-powered service that runs cleanly on AWS Lambda, aligns with our serverless infrastructure, and opens the door to faster iteration across multiple LLM platforms.

What’s Next

As our AI-assisted tooling matures, this foundation will allow us to deliver more intelligent features across the Wowzi platform. And as the LLM ecosystem evolves, we’re well-positioned to adapt quickly, with no need to rewrite large chunks of code or re-architect deployments.

This project is just one in a series of engineering efforts we’ll be sharing here on the Wowzi Tech blog, as we continue building scalable, modern infrastructure for Africa’s growing creator economy.

Stay tuned for more stories from the edge of AI, cloud, and creator tooling.

Our Engineering Philosophy

Engineering at Wowzi is about enabling seamless processes. Our goal is to remove friction and boost efficiency at every stage, whether that’s back-office operations, our mobile app, or our business platform. We build systems that are intuitive and largely self-sufficient, letting users focus on what matters while our technology handles the heavy lifting behind the scenes.

Central to our approach is a continuous user feedback loop. This drives an iterative development process ensuring our products evolve based on real-world use, keeping us aligned with our vision to be the definitive operating system for influencer marketing in Africa.

A Distributed Engineering Team

Our engineering team is truly global, with talent spread across Kenya, Nigeria, the UK, the Netherlands, and Ukraine. This diversity allows us to tap into a rich range of perspectives and collaborate across time zones, building solutions that reflect the varied needs of users across the continent and beyond.

The Wowzi Engineering Team

Our multi-disciplinary engineering team includes Backend (BE), Frontend Web and Mobile (FE), Data Engineering and Analytics, DevSecOps, and Quality Assurance (QA). Together with product management, design, and analytics teams, we deliver features that are both technically sound and user-centric.

We organize around specialized, autonomous feature teams that own delivery end-to-end. This empowers rapid innovation and meaningful impact. We’ve also heavily invested in AI-powered solutions for content moderation, creator insights, campaign automation, and reporting; all critical to scaling our platform across Africa.

Our Software Development Lifecycle (SDLC)

Our SDLC blends Agile best practices with clear, consistent communication:

• Planning & Design: Features start as Epics in Jira, broken down into Stories and Tasks to align the team and track progress.

• Development & Automation: We use a combination of monolithic and event-driven serverless microservices (like AWS Lambda) for scalable, cost-effective solutions.

• Testing & Quality Assurance: Rigorous unit tests, QA, and user acceptance testing (UAT) ensure stability and quality.

• Staging & Demos: Features are demoed regularly, from design to staging, with continuous feedback guiding improvements.

• Production & Monitoring: Real-time monitoring and user feedback drive reliability and future updates.

Building for the Future

Payments aren’t just an add-on; they’re a core part of creator-led campaigns. Our platform aims to unlock not only creative potential but also financial freedom for creators, starting in Africa and expanding globally.

We envision a future where every creator with a Wowzi account has a “Pay with Wowzi” option on every checkout page.

Engineering as an Enabler

Engineering at Wowzi powers the entire influencer marketing workflow. With automation, a focus on user experience, and feedback-driven iteration, we’re building a platform that will continue to innovate and shape influencer marketing’s future in Africa.

We embrace failure but fast failure. This mindset helps us deliver the most valuable automations and features that truly matter to our users.

Stay tuned as we share more insights from our engineering journey!

Hello, tech enthusiasts, developers, and curious minds! Our team at Wowzi Tech launched its official tech blog on Substack to share Wowzi's vision.

Wowzi Tech serves as your window into how our company builds scale and innovates through our mission to develop meaningful technology that enables perfect brand-creator connections.

What is Wowzi Tech About?

Every activity at Wowzi runs on technology as its fundamental driving force.

The engineering team at Wowzi develops mobile applications with user-friendly interfaces while establishing robust infrastructure, maintaining excellent quality through quality assurance practices, continuous monitoring and observability to advance the company's mission. Through our Wowzi Tech blog we will share the entire technological journey with our audience.

Expect deep dives into:

App Development: How we design and build user-centric apps that empower creators and brands.

Infrastructure: The backbone of our platform—scalable, reliable, and built for the future.

Quality Assurance: Our rigorous processes to ensure every release is polished and performant.

Monitoring & Observability: How we keep our systems humming with real-time insights and proactive solutions.

Why We’re Here

We develop technology solutions which solve practical issues through innovative methods and exactness. Our blog reveals how we build technology at Wowzi by revealing programming code and overcoming difficulties during triumphs in our development process. Every developer seeking information about our technology stack and product managers who want to understand our workflows as well as tech enthusiasts who want to learn will find relevant content in this platform.

What to Expect

In the following weeks we will feature stories about our technical operations:

• Detailed information about recent app feature development.

• Lessons learned from expanding our infrastructure to manage large interaction volumes.

• Our QA team will present debugging techniques which help identify issues before they become major problems.

• Our observability tools that enable us to maintain proactive issue detection and resolution.

• Spotlight on the brilliant minds on our engineering team.

Join the Journey

You can join our exciting journey with us. Subscribing to Wowzi Tech on Substack enables you to receive our newest blog entries in your email inbox.

Got a topic you’d love us to cover? Drop us a comment or reach out—we’re all ears.

Here’s to building, learning, and sharing the tech that powers Wowzi. Let’s get started!

—The Wowzi Tech Team

Subscribe now