We wanted to enable that. The question was how to do it without creating security blind spots six months later.

We partnered with Lovable Enterprise to close the gap between AI-generated code and safely deployed applications. Not just to let teams build faster, but to maintain visibility and control while they did.

The unlock wasn’t just enabling teams to build apps. It was maintaining security visibility while they did.

The Blind Spot Problem

Here’s what kept me up at night: every AI code generation tool promises to “democratize development,” but almost none of them address what happens after the demo. You get the productivity boost—marketing builds their landing page optimizer, support builds their ticket triage dashboard—but you also get a shadow IT problem on steroids.

Apps built outside engineering pipelines typically lack:

• Authentication and access controls

• Security scanning and vulnerability management

• Visibility into what’s deployed and who owns it

• Any path to production-grade maturity

The usual options were either lock it down completely (killing the productivity gains) or let it run wild (creating audit nightmares). We needed a third option.

Why Lovable Enterprise Worked for Us

We evaluated a few platforms, but Lovable Enterprise had features that directly addressed our security concerns:

1. Private by Default, SSO-Protected

Every app created through Lovable could be locked down to Team Lovable members via our existing SSO setup. No public deploys by accident, no access management headaches. If you’re on the team, you can access the tools. If you’re not, you can’t. Simple.

This mattered because our marketing and customer success teams were building workflow tools that touched customer data. “Just make it public for now” was never an acceptable answer.

2. Built-in Security Scanning

Lovable’s integration with Aikido meant every app got automatic security scanning. Not as a nice-to-have feature we’d enable later—it shipped with the platform. Vulnerabilities in dependencies got flagged before they became incidents.

For us as a security team, this was huge. We didn’t need to build scanning infrastructure or convince teams to adopt it. It was just there, doing its job quietly in the background.

3. The Project Dashboard as a Discovery Layer

One unexpected win: Lovable’s project dashboard became our catalog of what existed. Instead of hunting through Slack threads or tribal knowledge, we had a single place showing:

• What apps existed

• Who built them

• What they did

• When they were last updated

This sounds basic, but it solved a real problem. When you have 47 applications scattered across teams, discoverability matters. Engineering could see what was being built without being gatekeepers. Other team members could discover existing tools before building duplicates.

4. Security Center: The Single Pane of Glass

The Security Center in Lovable was exactly what we needed. One view showing the security posture of every deployed app:

• Which apps had unresolved vulnerabilities

• Which dependencies were outdated

• Where access controls needed attention

We weren’t flying blind. We had visibility into apps deployed outside traditional engineering oversight, and we could prioritize remediation without blocking teams from shipping.

5. A Graduation Path to Engineering-Owned Infrastructure

Not every AI-built app needs to live forever in its initial form. Some experiments fail. Some become critical and need CI/CD, staging environments, and the full weight of production infrastructure.

We created a new GitHub team specifically for “graduating” Lovable apps. When an app hit a maturity threshold—sustained usage, handling sensitive data, or becoming load-bearing for operations—we could import it into our GitHub org and subject it to our standard deployment pipeline.

This gave teams permission to experiment fast, knowing there was a path forward if their tool became important.

The Results: 47 Apps and Counting

Across marketing, customer support, and customer success, teams have built 47 applications. That’s 47 workflow improvements, internal tools, and experiments that wouldn’t have happened if they required engineering tickets.

Some are small—a form that routes Creator inquiries to the right team. Others are substantial—a dashboard that tracks customer health signals and flags accounts needing outreach.

The important part: none of them are security blind spots.

Every app is access-controlled. Every app is scanned. Every app is discoverable. And the ones that matter can graduate into our core infrastructure when the time comes.

What This Unlocked

The real impact wasn’t just 47 apps. It was the shift in how teams approached problems.

Instead of writing a spec and lobbying engineering for roadmap priority, teams built prototypes. They tested ideas with real users. They iterated based on feedback. The ones that worked stuck around. The ones that didn’t got archived without ceremony.

Engineering wasn’t a bottleneck for experimentation anymore—and we didn’t sacrifice visibility or control to get there.

For security specifically, this model worked because:

• We never lost track of what existed

• We could assess risk across all deployed apps

• We had enforcement mechanisms (SSO, scanning) baked into the platform

• We could intervene when something needed to graduate or be sunset

The Takeaway

If your organization is thinking about AI-assisted development for non-engineering teams, the question isn’t just “how do we enable this?” It’s “how do we enable this without creating chaos six months from now?”

Custom-built solutions are one answer—you control every detail, and you can architect exactly the guardrails you need. But building that infrastructure is a project in itself.

Lovable Enterprise was our shortcut to the same outcome: empowered teams, maintained visibility, and a path to maturity for the tools that earned it.

We’re 47 apps in, and I’m not worried about shadow IT. I’m watching our Creator experience improve as teams build the tools they actually need—and I can see exactly what they’re building.

That’s the unlock.

Subscribe now

We’re the engineering team at Stan, and we’re launching this Substack because we believe the best engineering happens when knowledge moves freely between teams, companies, and practitioners.

If you’re not familiar with Stan, we’re building an all-in-one creator platform that helps entrepreneurs turn their social following into income—link-in-bio storefronts, digital products, bookings, memberships, email marketing, the works. But we’re also building something more ambitious: Stanley, our AI coach that helps creators actually grow their audience and succeed on platforms like LinkedIn and Instagram. Not just content scheduling—real coaching on strategy, voice, performance analysis, and growth.

That means we’re dealing with full-stack AI product engineering at scale. We’re a team of 14 engineers working alongside 3 designers and a 6-person (and growing) data team, building products that need to feel simple and fast for creators while handling the complexity of personalized AI coaching, content generation, monetization infrastructure, and analytics under the hood.

We’re here to share what we’re learning as we build—the decisions that worked, the ones that didn’t, and the architectural patterns we’re evolving in real time. If you’ve ever wished you could see inside another engineering org’s decision-making process, or wanted honest retrospectives on what breaks when AI moves to production, you’re in the right place.

What kind of community are we building?

This isn’t a marketing channel or a highlight reel. We’re building a space for practitioners who value transparency over polish.

You’ll find us writing about:

• Architecture decisions and the tradeoffs we’re navigating as AI tooling matures faster than best practices can keep up—how do you build coaching that feels personalized when you’re serving thousands of creators? How do you instrument AI systems so you can actually debug them?

• Incident retrospectives that show what actually breaks and how we responded (not just what we wish had happened)

• Team practices and philosophy that shape how we work, collaborate cross-functionally, and make technical decisions when the “right answer” isn’t obvious

• Engineering challenges we’re facing in real time, including the messy middle parts where the path forward isn’t clear yet

We’re sprinkling in teaching and enablement content when patterns emerge that feel worth documenting. Think of this as a mix of thought leadership and ground truth—we’re figuring things out alongside you.

Who is this for?

We’re writing for:

• Fellow engineers building AI products or dealing with similar full-stack complexity

• Data teams navigating the handoff between models and production systems

• Design teams collaborating with engineering on product that involves AI/ML

• CTOs and engineering leaders making architectural bets and building team culture

• Our future selves who will inevitably need to remember why we made certain calls

If you care about how things actually get built—not just the polished case studies—this is for you.

What to expect (and when)

We’re aiming for bi-weekly posts, with additional pieces when we hit something worth sharing in real time. This isn’t a content treadmill; we’re only publishing when we have something genuine to say.

Some posts will be long-form deep dives. Others will be shorter reflections or quick retrospectives. We’ll let the content dictate the format rather than forcing a template.

Why now?

Two reasons: building in public and recruiting visibility.

Building in public keeps us honest. When you know other engineers will read your architectural decisions, you think harder about them. When you commit to explaining your incident response, you’re more likely to actually learn from what broke.

And yes, visibility matters. We’re growing our engineering, data, and design teams, and we want to work with people who share our values around transparency, craftsmanship, and curiosity. If reading our thinking makes you want to build alongside us, we should talk.

What’s coming first

Our first few posts will cover:

• How we’re thinking about observability for AI products (spoiler: traditional APM doesn’t cut it when you need to instrument LLM behavior)

• A retrospective on a recent incident that taught us something surprising about our architecture

• The team practices that help us move fast without breaking trust across engineering, data, and design

We’re excited to build this with you. Hit subscribe if you want to follow along, and feel free to reply to any post—we’re here for the conversation, not the broadcast.

Let’s build.

—
The Stan Engineering Team